本文來自微信公眾號“開源云中文社區(qū)”。
當人們談論云原生應用程序開發(fā)時，微服務是一個熱門話題——這是有充分理由的。
微服務架構是一種結構化的方式，用于在組織中部署一組自包含和獨立的服務。與過去的一些應用程序開發(fā)方法相比，它們正在改變游戲規(guī)則，允許開發(fā)團隊在云原生規(guī)模上獨立工作。
讓我們深入了解應用程序開發(fā)的歷史、微服務的特點以及這對云原生可觀察性的意義。
微服務架構與單體架構
了解微服務架構的最簡單方法是將其與單體架構進行比較。
單體架構
正如前綴“mono”所暗示的那樣，單體架構是一種將所有組件組合成一個可執(zhí)行文件的軟件。這種架構通常有三個優(yōu)點：
——易于開發(fā)。許多開發(fā)工具支持創(chuàng)建單體應用程序。
——易于部署。將單個文件或目錄部署到運行時。
——易于縮放。通過在某種負載均衡器后面運行多個副本，可以輕松地擴展應用程序。
微服務架構
微服務是關于小型、獨立的服務。其優(yōu)點是這些服務具有高度可維護性和可測試性，與其他服務松散耦合，可獨立部署，并由小型、高效的開發(fā)團隊開發(fā)。微服務架構的一些服務類型可能包括以下示例。
——客戶端。客戶端服務用于收集客戶端請求，例如搜索、構建等請求。
——身份提供程序。在發(fā)送到API網(wǎng)關之前，來自客戶端的請求由身份提供者處理，身份提供者是一種創(chuàng)建、驗證和管理數(shù)字身份信息的服務。
——API網(wǎng)關。API（應用程序編程接口）是允許兩個服務相互對話的中間系統(tǒng)。在微服務的情況下，API網(wǎng)關就像一個入口點：它接受來自客戶端的請求，從后端收集完成這些請求所需的服務，并返回正確的響應。
——數(shù)據(jù)庫。在微服務中，每個微服務通常都有自己的數(shù)據(jù)庫，通過API服務進行更新。
——消息格式。服務以兩種類型的方式進行通信：同步消息和異步消息。
同步消息用于客戶端等待響應時。這種類型包括REST（表示狀態(tài)傳輸）和HTTP協(xié)議。異步消息傳遞適用于客戶端不等待服務立即響應的場景。此類消息傳遞的常見協(xié)議包括AMQP、STOMP和MQTT。
——靜態(tài)內(nèi)容。一旦微服務完成通信，任何靜態(tài)內(nèi)容都會被發(fā)送到基于云的存儲系統(tǒng)，該存儲系統(tǒng)可以直接將該內(nèi)容傳遞給客戶端。
——管理。在微服務結構中有一個管理元素可以幫助監(jiān)控服務并識別故障，以保持一切順利運行。
——服務發(fā)現(xiàn)。對于客戶端和服務器端服務，服務發(fā)現(xiàn)是一種在特定網(wǎng)絡上定位設備和服務的工具。
單體模型更為傳統(tǒng)，當然也有一些優(yōu)點，但微服務在云原生環(huán)境中越來越普遍。以下是兩種模型之間最明顯的區(qū)別。
微服務架構的好處
微服務在現(xiàn)代云原生企業(yè)中取得了巨大成功。企業(yè)從使用這種架構中受益有很多原因。
——靈活性：因為每個服務都是獨立的，所以編程語言可以在所有微服務之間變化（盡管在一種現(xiàn)代編程語言上盡可能標準化是明智的）。
——更快的部署：對于大多數(shù)開發(fā)人員來說，微服務不僅更容易理解，而且部署速度也更快。將代碼中的一件事更改為單體結構，它會影響所有方面。微服務是獨立部署的，不會影響其他服務。
——可擴展性：如果你通過一個應用程序運行所有內(nèi)容，那么隨著應用程序的增長，很難管理大規(guī)模的服務。相反，微服務架構允許團隊修改單個服務的功能，而不是重新部署整個系統(tǒng)。這甚至適用于應用程序中每個服務的規(guī)模。例如，如果一個支付服務比其他服務的需求量更大，則可以根據(jù)需要擴展該微服務。
——孤立故障：對于單體架構，一個服務中的故障可能會危及整個應用程序。微服務隔離每個組件，因此，如果一個服務失敗或出現(xiàn)問題，其他應用程序仍然可以運行，盡管可能處于降級狀態(tài)。
最后，微服務架構節(jié)省了團隊的時間，為每個服務提供了更精細的修改，并可根據(jù)每個服務和接口的整體需求進行擴展。
挑戰(zhàn)
微服務非常有用，但它們也有自己的挑戰(zhàn)。
——增加了復雜性和依賴關系問題：微服務的設計有利于單個服務，但這也增加了用戶數(shù)量、用戶行為的多樣性以及服務之間的交互。這使得從前端到后端跟蹤單個流量變得更加困難，并可能導致服務之間的依賴關系問題。當微服務彼此如此獨立時，管理兼容性以及不同現(xiàn)有版本和工作負載造成的其他影響并不總是容易的。
——測試：在整個應用程序中進行測試可能很困難，因為每個執(zhí)行的服務路由都可能不同和不同。靈活性是微服務的一個重要元素，但在分布式部署中很難一致地觀察到相同的多樣性。
——管理通信系統(tǒng)：即使服務可以輕松地相互通信，開發(fā)人員也必須管理服務通信的架構。API在服務之間可靠有效的通信中起著至關重要的作用，這需要API網(wǎng)關。這些網(wǎng)關很有用，但它們可能會失敗，導致依賴關系問題或通信瓶頸。
——可觀察性：因為微服務是分布式的，所以監(jiān)控和可觀察性對于開發(fā)人員和可觀察團隊來說是一個挑戰(zhàn)。重要的是考慮一個監(jiān)控系統(tǒng)或平臺來幫助監(jiān)督、排除故障和觀察整個微服務系統(tǒng)。
應該采用微服務架構嗎？
有時，單體結構可能是一條路，但微服務架構的發(fā)展是有原因的。問問自己：
應用程序在什么環(huán)境中工作？
因為大多數(shù)云原生架構都是為微服務而設計的，所以如果你想獲得云原生環(huán)境的全部好處，微服務是最佳選擇。隨著應用程序轉向基于云的設置，應用程序開發(fā)傾向于微服務架構，并將繼續(xù)這樣做。
團隊如何運作？
在微服務架構中，代碼庫通?？梢杂奢^小的團隊管理。然而，開發(fā)團隊還需要工具來識別、監(jiān)控和執(zhí)行不同組件的活動，包括它們是否以及如何相互交互。團隊還需要確定哪些服務是可重用的，因此在構建新服務時不必從頭開始。
應用程序有多靈活？
如果你必須不斷修改應用程序或進行調(diào)整，微服務方法將是最好的，因為可以編輯單個服務，而不是整個單體系統(tǒng)。
有多少項服務，還會有更多嗎？
如果你有很多服務或計劃繼續(xù)增長（在基于云的平臺中，你應該期待增長），那么微服務架構也是理想的，因為單體應用軟件不能很好地擴展。
帶微服務的Chronosphere
微服務架構旨在使云原生環(huán)境中的應用軟件開發(fā)更簡單，而不是更困難。隨著管理每一項服務所帶來的挑戰(zhàn)，團隊擁有可觀察性解決方案以適應其業(yè)務的增長更為關鍵。
Chronosphere專注于云原生世界的可觀察性，因此團隊在應用程序開發(fā)的每一個級別都有更好的控制、可靠的功能和靈活的可擴展性。使用可靠且靈活的平臺監(jiān)控微服務可以大大降低風險，有助于預測故障，并使開發(fā)團隊能夠了解其數(shù)據(jù)。
