在本文中，我將討論什么是微服務，它們為何如此重要。我們將從微服務歷史以及它們與單體架構的比較開始。然后，我們將討論微服務架構的一些原理，其潛在的缺點，以及如何與容器和Kubernetes等現代工具結合使用。

前言

當組織開始構建更復雜的應用程序時，編寫單體應用程序的做法變得越來越成問題，微服務就應運而生。

傳統上，應用程序是作為單體構建的，所有代碼都集中在一個大的代碼庫中。由于沒有明確區分不同功能，因此更新應用程序的一部分時，可能會無意中影響到完全不相關的功能。即使進行簡單的更改，你也必須重新部署整個應用程序，如果出現問題，則所有內容都會受到影響，而不僅僅是要被更新或擴展的組件。

針對這個問題，我們可以通過將單體架構拆分成模塊（半獨立組件）來解決，盡管它可能比實現微服務簡單得多，但它從未真正流行起來。

面向服務的體系結構（SOA）吸引了很多人，但很大程度上失敗了，主要是因為它留下了許多未解決的問題，例如如何正確拆分服務。基于微服務的體系結構是一種更具說明性的SOA類型，它源于現實世界的用例，并已被眾多組織成功采用。

微服務只不過是一種模塊化架構，不同模塊間通過網絡進行通信。

什么是微服務？

微服務是小型的自治應用程序組件，它們一起構成一個應用程序。他們從SOA繼承了基本的操作模型，但是以一種更具說明性的方式對其進行了擴展。微服務通常被認為是一個獨立部分，由一個團隊維護。

微服務為什么重要？由上文可知，要更新應用程序，我們可以獨立更新和部署微服務，而不必重新部署整個應用程序。它們還允許單個微服務團隊完全專注于單個業務流程，而無需了解整個應用程序。

為此，微服務具有以下屬性：

• 松耦合：每個服務都是自治的，只能松散地連接到系統的其余部分。這意味著它具有自己的生命周期，并且可以獨立部署，更新，擴展和刪除。
• 高內聚性：具有相關行為的代碼組合在一起。通過將所有相關行為分組在一起，工程師僅在需要更改特定行為時才在一個地方更新代碼。
• 信息隱藏：每個微服務僅共享其他服務所需的數據，并僅隱藏與其自己的流程相關的數據。數據共享可能會無意間導致耦合，因此應始終謹慎。

為了充當一個有凝聚力的應用程序，所有這些不同的自治服務都通過網絡接口進行通信。這為大量通信帶來了新的挑戰。順便說一下，這就是服務網格發揮作用的地方。

現在我們知道什么是微服務，讓我們探究組織為什么采用微服務。

微服務的好處

無論是通過使服務與團隊保持一致來解決“開發人員問題”，還是降低采用新技術的風險，或是減輕部署的復雜度和提高可伸縮性，采用微服務都會帶來很多好處。讓我們仔細看看：

• 自治團隊：微服務允許小型團隊完全擁有服務的整個生命周期。這樣可以提高責任心，代碼質量和工作滿意度。對于大多數大型組織而言，這種“人員分配”是采用微服務方法的主要原因之一。
• 技術的異構性：開發人員理論上可以使用不同的語言和不同的技術來構建每個服務。這使開發人員能夠為該特定服務選擇最佳技術，而不是采用更為傳統的標準化，一刀切的方法。
• 降低采用新技術的風險：開發人員還可以在低風險服務中試驗新技術，因為知道出了點問題，不會影響系統的其余部分。由于風險是采用新技術的最大障礙，因此這是一個巨大的優勢。
• 彈性：當組件發生故障時，它不一定會影響到系統的其他部分。但請注意，應用程序僅在其體系結構允許的范圍內具有彈性。如果沒有良好的代碼慣例（例如跟蹤，可觀察性和熔斷機智），那么小故障仍然可以在復雜的系統中級聯。
• 可擴展性：要擴展任何一項功能，你只需擴展該微服務，而不是擴展整個單體應用程序即可。
• 易于部署：如果更新一行代碼，只需更新和重新部署該特定的微服務，而不是重新部署整個單體應用程序。相反，回滾服務比回滾整個應用程序容易得多。Docker和Kubernetes之類的工具已大大降低了部署和回滾的成本。
• 可替換性：替換應用程序中的微服務比替換單體應用中的組件要容易得多。

微服務的最佳實踐

如上所述，SOA實現之所以困難，原因之一是它們缺乏定義服務邊界的指導。讓我們看看微服務如何解決這個問題。

定義服務邊界

每個微服務都具有圍繞業務域建模的特定功能，業務域解決了特定的業務問題。例如，使用Gmail，其業務領域包括使世界各地的人們能夠通過電子郵件進行通信的所有功能。

業務域由多個有限上下文組成：與同一應用行為相關的代碼。Gmail具有多種功能，包括文本編輯，發送和接收，存檔，搜索等，所有這些功能都可能形成這樣的上下文。

但請注意，相關行為不一定與功能一一對應。

高度自治

解耦系統就是要能夠獨立更改系統的各個部分而不會影響系統的其他部分。

服務間彼此了解越少，它們就越自治。更大的自主權帶來更大的彈性。理想情況下，如果一項服務崩潰，則其他服務仍將能夠提供該應用程序的降級版本。

雖然解耦系統是最終目標，但并非總是能夠實現100％解耦。

網絡通訊

微服務通過其應用程序編程接口（API）在網絡上進行通信。要發送和接收消息，他們必須就網絡通信規則達成一致。你可能熟悉HTTP，還有更多這樣的協議。

根據網絡通訊的方式，可以將它們大致分為同步或異步通信。

• 同步模式：客戶端請求需要服務端即時響應，甚至可能由于等待而阻塞。

• 異步模式：客戶端請求不會阻塞進程，服務端的響應可以是非即時的

同步有點像座機。建立連接并交換信息，并且在連接時無法接聽其他電話。此類通信通常與請求/響應消息一起使用，其中一個服務發送請求并等待另一服務響應。等待時，兩個服務都被阻止。可以想象，這僅在連接速度很快的情況下才可行。

異步通信更像電子郵件。你向某人發送電子郵件，通常可以繼續其他工作。收到回復后，你將再次參與。這就是異步通信的本質：服務發送一條消息，并繼續執行它的所有操作，直到收到響應為止。當網絡不可靠或物理距離較遠時，通常使用這種通信方式。它通常與發布-訂閱（或pub-sub）模式一起使用，在該模式中，一項服務將發布事件，而訂閱該事件的人將得到通知。

采用那種網絡通訊方式，要根據實際的業務場景而定。

什么時候應該使用微服務？

開發和維護微服務比處理單體應用要耗費大量精力。我們已經看到微服務具有許多強大的優勢，但這是否總是最好的方法？不，開發者應該首選單體，除非他們有令人信服的理由不得不這樣做。

根據經驗，小型團隊的小型應用程序最好采用單體架構，而由多個團隊同時開發維護的大型應用程序最好采用微服務方法。組織應該從單體應用程序開始，當在需要伸縮性，性能或彈性優勢時，可以將其細分為微服務。何時需要拆分，將在很大程度上取決于你的用例。沒有靈丹妙藥，你必須在仔細考慮后做出決定。

你可以盡早做的是保持一個干凈且模塊化良好的代碼庫。當你開始運行和擴展應用程序時，這將使構建和擴展變得更容易，并且當你將單體應用細分為微服務時，它將減少你的成本和工作量。

結合容器和Kubernetes

如上圖所述，每個微服務都放置在一個容器中，這是一種新穎的包裝機制，其概念類似于超輕量級虛擬機（VM），有助于將微服務分隔開（請注意，盡管容器在概念上類似于VM，但它們并未提供相同的隔離性或安全性保證）。盡管微服務早于容器，但容器使微服務更加簡單和更具成本效益。

Kubernetes管理你的容器化服務，以確保它們具有足夠的資源并且可以正常運行。它充當容器的某種數據中心操作系統。

簡而言之，微服務包含業務邏輯，該代碼提供業務價值。容器幫助打包微服務，以便它們與系統的其余部分分離。容器和Kubernetes簡化了微服務的打包和管理，并且是微服務如此流行的原因之一。

結論

盡管微服務提供了比單體架構更大的靈活性并提供了令人難以置信的強大功能，但這些好處是以犧牲復雜性為代價的。組織必須仔細考慮采用微服務方法是否適合他們。

在微服務中，你越來越會聽到很多有關容器和Kubernetes的信息。這是因為它們是重要的技術創新，可為微服務提供巨大價值。如今，大多數使用微服務的組織都會采用容器和Kubernetes來管理它。