越來越多的組織開始放棄單體應用，逐步轉向微服務的架構模式–將業(yè)務流程分為多個獨立的服務。

例如，在一個機票預訂中，就可能涉及許多個單獨的過程：在航空公司預訂機票，付款，并在機票成功預訂后向客戶發(fā)送確認信息。

微服務架構，就是將各個流程按照業(yè)務拆分為獨立的服務。在上面的示例中，機票預訂服務可以被拆分為機票預訂，付款和確認，拆分后的微服務可以通過接口相互通信。

那么，微服務與單體應用，究竟有什么不同？

對比1：網絡延遲

當涉及微服務時，有一個基本的物理定律在起作用，每當微服務通過網絡調用另一服務時，字節(jié)就通過網絡發(fā)送，這涉及將字節(jié)轉換為電信號或脈沖光，然后將這些信號轉換回字節(jié)。根據模擬結果，微服務調用的等待時間至少為24ms。如果我們假設實際處理大約需要100毫秒，則總處理時間如下所示：

網絡延遲-微服務與單體應用

假設在理想情況下，所有調用執(zhí)行可以同時發(fā)生，并且彼此之間不依賴–這稱為扇出模式( fan-out pattern)。下圖顯示了隨著越來越多的調用同時執(zhí)行，總時間如何減少。

同時執(zhí)行多個調用意味著總執(zhí)行時間減少

并行執(zhí)行所有調用，意味著最長的調用執(zhí)行完，服務將返回給使用者。

從上圖可以看出，單體應用沒有網絡延遲，因為所有調用都是本地調用。即使在完全可并行化的世界中，單體應用仍會更快。而微服務由于需要多個服務間通信，即使并行調用，也是需要一定的網絡延遲。

這一次，單體應用勝利了。

對比2：復雜性

考慮復雜性時，有許多因素在起作用：開發(fā)的復雜性和運行軟件的復雜性。

由于開發(fā)的復雜性，在構建基于微服務的軟件時，代碼庫的大小會快速增長。因為微服務涉及多個源代碼，使用不同的框架甚至不同的語言。由于微服務需要彼此獨立，因此經常會有代碼重復。

另外，由于開發(fā)和發(fā)布時間不一致，因此不同的服務可能會使用不同版本的庫。

對于日志和監(jiān)控方面，在單體應用中，日志記錄就像查看單個日志文件一樣簡單。但是，對于微服務，跟蹤問題可能涉及檢查多個日志文件。不僅需要查找所有相關的日志輸出，而且還需要以正確的順序將它們放在一起。

在Kubernetes集群中運行微服務時，復雜度進一步增加。雖然Kubernetes啟用了諸如彈性伸縮等功能，但它并不是一個易于管理的系統(tǒng)。要部署單體應用，簡單的復制操作就足夠了。要啟動或停止單體應用，通常只需一個簡單的命令即可。還有與單體應用相比，事務還增加了運行微服務架構的復雜性?？绶盏恼{用，很難保證數據是同步的。例如，執(zhí)行不當的調用，重試可能會執(zhí)行兩次付款。

這一次，單體應用又勝利了。

對比3：可靠性

在微服務中，如果A服務通過網絡以99.9％的可靠性調用B服務（這意味著在1000個調用中，有一個將由于網絡問題而失敗），這時B調用再C服務，我們將獲得99.8％的可靠性。

隨著調用時間的延長，可靠性下降

因此，在設計微服務架構時，要考慮網絡會在某個時刻斷開。微服務提供了一些解決此問題的解決方案。Spring Cloud提供了負載均衡和網絡故障處理，諸如Istio之類的服務網格還能夠處理多種編程語言的服務。當微服務集群中的服務失敗時，集群管理器給出替代方案。這就使得微服務架構具有高度的彈性。

Netflix創(chuàng)建了一個名為Chaos Monkey的工具，該工具可以模擬隨機終止虛擬機和容器。微服務的開發(fā)者，可以使用Chaos Monkey的工具在測試環(huán)境模擬網絡斷連和網絡故障等問題，這樣，他們就可以確保系統(tǒng)能夠處理生產環(huán)境中的停機故障。

單體應用中的所有調用都是在本地完成，因此很少發(fā)生網絡故障，雖然如此，然而單體應用在云環(huán)境卻無法滿足彈性伸縮的需求。

最后，微服務取得了勝利。

對比4：資源使用

一般來說，微服務會比單體應用使用更多的資源。即使在Docker中運行時，基準測試發(fā)現(xiàn)，雖然服務連接數量下降了8％，但是容器編排還將消耗資源，日志聚合和監(jiān)視也將消耗資源。

但是，微服務使我們可以更聰明地使用資源。由于集群管理器可以根據需要分配資源，因此實際的資源使用量可能要低得多。

在軟件中，20％的代碼一般會完成80％的工作。如果單體應用的一個實例使用8GB，則兩個實例使用16GB，依此類推。使用微服務后，我們可以把單體應用中負責主要職能的20%代碼提取成一個服務，因此對于兩個實例，我們的RAM使用量為降低到了9.6GB左右。

下圖顯示了資源使用情況的差異。

隨著越來越多的實例在運行，單體應用比微服務需要更多的資源

資源使用率方面，微服務勝利了。

對比5：擴展的精確性

單體應用的擴展有多種辦法，運行多個實例，或運行多個線程，或者使用非阻塞IO。對于微服務架構，這三個也都是適用的。

但是，面對客戶端越來越多的請求，由于微服務架構更精細，因此擴展單個服務也更加精細。所以，對于微服務來說，擴展既簡單又精確。而且，由于微服務的資源消耗較少，又可以節(jié)省資源。

相比單體應用，微服務精確的擴展和更少的資源使用，是一個明顯的勝利。

對比6：吞吐量

讓我們再看一個性能指標–吞吐量。在微服務架構體系中，數據需要在不同服務之間發(fā)送，從而會產生一定的開銷。如果微服務還不是一個分布式架構，那么他的吞吐量還不如一個單體應用高。

對比7：部署時間

人們選擇微服務架構的原因之一就是-能夠節(jié)省部署時間，滿足快速迭代。

由于微服務的職責單一原則，因此對其進行的任何更改都有很明確。然而，修改一個單體應用的功能，可能會“牽一發(fā)動全身”。

此外，微服務更易于測試。由于微服務僅覆蓋有限的一組功能，因此代碼依賴性低，便于編寫測試并且運行得快。

還有，微服務的資源消耗較少，并且可以按比例擴展。這就使微服務可以無感知部署，例如，可以先在集群一部分節(jié)點上啟動微服務的新版本，然后遷移一部分用戶到新版本，如果有問題，這可以快速回滾到舊版本。

勝利歸功于微服務。

對比8：溝通

在微服務誕生之前，弗雷德·布魯克斯（Fred Brooks）撰寫了開創(chuàng)性的著作《人月神話》，本書的其中一項內容是，溝通渠道的數量隨著團隊成員的數量而增加。由兩個人組成的團隊，只有一個溝通渠道。如果有四個人，則最多可以訪問六個頻道。通信通道數的公式為n(n ? 1)/2。由20位開發(fā)人員組成的團隊擁有190個可能的溝通渠道。將這些開發(fā)人員分成兩個團隊，就可以大大減少溝通渠道的數量。

我們以擁有20個開發(fā)人員的團隊為例，將其分為四個微服務團隊（每個團隊五個人），則每個團隊有10個溝通渠道。四個團隊之間的溝通渠道只有六個。溝通渠道的總數為46，大約占20個人團隊的四分之一。

下圖顯示了，一個大團隊的通信渠道數量，和單個微服務團隊的通信渠道數量的對比。

因此，將10個以上的開發(fā)人員分成幾個較小的團隊，可以為任何開發(fā)項目提供更高的溝通效率。

這是微服務的另一個明顯勝利。

誰是贏家？

單體應用獲得了3場勝利，微服務獲得了5場勝利。

但是，在查看此圖表時，請記住它是相對的。微服務并不是解決所有開發(fā)問題的萬能藥。

例如，一個由5個開發(fā)人員組成的小型團隊可能會傾向于選擇單體應用。因為，單體應用不僅更易于管理，同時如果軟件產品每秒僅有幾個訪問量，那么單體應用可能就足夠了。

以下是一些跡象，表明微服務架構可能是一個合適的選擇：

• 需要7*24的可靠性
• 精確的擴展
• 峰值和正常負載明顯不同
• 超過10個開發(fā)人員的團隊
• 業(yè)務領域可以被細分
• 方法調用鏈路短
• 方法調用可以使用REST API或隊列事件。
• 幾乎沒有跨服務的事務