原文地址：https://xie.infoq.cn/article/e4f0b01a56bc4cdba07bbd185
越來越多的組織開始放棄單體應用，逐步轉向微服務的架構模式–將業務流程分為多個獨立的服務。
例如，在一個機票預訂中，就可能涉及許多個單獨的過程：在航空公司預訂機票，付款，並在機票成功預訂后向客戶發送確認信息。
微服務架構，就是將各個流程按照業務拆分為獨立的服務。在上面的示例中，機票預訂服務可以被拆分為機票預訂，付款和確認，拆分后的微服務可以通過接口相互通信。
那么，微服務與單體應用，究竟有什么不同？
對比1：網絡延遲
當涉及微服務時，有一個基本的物理定律在起作用，每當微服務通過網絡調用另一服務時，字節就通過網絡發送，這涉及將字節轉換為電信號或脈沖光，然后將這些信號轉換回字節。根據模擬結果，微服務調用的等待時間至少為24ms。如果我們假設實際處理大約需要100毫秒，則總處理時間如下所示：
網絡延遲-微服務與單體應用
假設在理想情況下，所有調用執行可以同時發生，並且彼此之間不依賴–這稱為扇出模式( fan-out pattern)。下圖顯示了隨着越來越多的調用同時執行，總時間如何減少。
同時執行多個調用意味着總執行時間減少
並行執行所有調用，意味着最長的調用執行完，服務將返回給使用者。
從上圖可以看出，單體應用沒有網絡延遲，因為所有調用都是本地調用。即使在完全可並行化的世界中，單體應用仍會更快。而微服務由於需要多個服務間通信，即使並行調用，也是需要一定的網絡延遲。
這一次，單體應用勝利了。
對比2：復雜性
考慮復雜性時，有許多因素在起作用：開發的復雜性和運行軟件的復雜性。
由於開發的復雜性，在構建基於微服務的軟件時，代碼庫的大小會快速增長。因為微服務涉及多個源代碼，使用不同的框架甚至不同的語言。由於微服務需要彼此獨立，因此經常會有代碼重復。
另外，由於開發和發布時間不一致，因此不同的服務可能會使用不同版本的庫。
對於日志和監控方面，在單體應用中，日志記錄就像查看單個日志文件一樣簡單。但是，對於微服務，跟蹤問題可能涉及檢查多個日志文件。不僅需要查找所有相關的日志輸出，而且還需要以正確的順序將它們放在一起。
在Kubernetes集群中運行微服務時，復雜度進一步增加。雖然Kubernetes啟用了諸如彈性伸縮等功能，但它並不是一個易於管理的系統。要部署單體應用，簡單的復制操作就足夠了。要啟動或停止單體應用，通常只需一個簡單的命令即可。還有與單體應用相比，事務還增加了運行微服務架構的復雜性。跨服務的調用，很難保證數據是同步的。例如，執行不當的調用，重試可能會執行兩次付款。
這一次，單體應用又勝利了。
對比3：可靠性
在微服務中，如果A服務通過網絡以99.9％的可靠性調用B服務（這意味着在1000個調用中，有一個將由於網絡問題而失敗），這時B調用再C服務，我們將獲得99.8％的可靠性。
隨着調用時間的延長，可靠性下降
因此，在設計微服務架構時，要考慮網絡會在某個時刻斷開。微服務提供了一些解決此問題的解決方案。Spring Cloud提供了負載均衡和網絡故障處理，諸如Istio之類的服務網格還能夠處理多種編程語言的服務。當微服務集群中的服務失敗時，集群管理器給出替代方案。這就使得微服務架構具有高度的彈性。
Netflix創建了一個名為Chaos Monkey的工具，該工具可以模擬隨機終止虛擬機和容器。微服務的開發者，可以使用Chaos Monkey的工具在測試環境模擬網絡斷連和網絡故障等問題，這樣，他們就可以確保系統能夠處理生產環境中的停機故障。
單體應用中的所有調用都是在本地完成，因此很少發生網絡故障，雖然如此，然而單體應用在雲環境卻無法滿足彈性伸縮的需求。
最后，微服務取得了勝利。
對比4：資源使用
一般來說，微服務會比單體應用使用更多的資源。即使在Docker中運行時，基准測試發現，雖然服務連接數量下降了8％，但是容器編排還將消耗資源，日志聚合和監視也將消耗資源。
但是，微服務使我們可以更聰明地使用資源。由於集群管理器可以根據需要分配資源，因此實際的資源使用量可能要低得多。
在軟件中，20％的代碼一般會完成80％的工作。如果單體應用的一個實例使用8GB，則兩個實例使用16GB，依此類推。使用微服務后，我們可以把單體應用中負責主要職能的20%代碼提取成一個服務，因此對於兩個實例，我們的RAM使用量為降低到了9.6GB左右。
下圖顯示了資源使用情況的差異。
隨着越來越多的實例在運行，單體應用比微服務需要更多的資源
資源使用率方面，微服務勝利了。
對比5：擴展的精確性
單體應用的擴展有多種辦法，運行多個實例，或運行多個線程，或者使用非阻塞IO。對於微服務架構，這三個也都是適用的。
但是，面對客戶端越來越多的請求，由於微服務架構更精細，因此擴展單個服務也更加精細。所以，對於微服務來說，擴展既簡單又精確。而且，由於微服務的資源消耗較少，又可以節省資源。
相比單體應用，微服務精確的擴展和更少的資源使用，是一個明顯的勝利。
對比6：吞吐量
讓我們再看一個性能指標–吞吐量。在微服務架構體系中，數據需要在不同服務之間發送，從而會產生一定的開銷。如果微服務還不是一個分布式架構，那么他的吞吐量還不如一個單體應用高。