譯者：王延飛
原文鏈接：http://dwz.date/bPpg
越來越多的組織開始放棄單體應用，逐步轉向微服務的架構模式–將業(yè)務流程分為多個獨立的服務仅叫。
例如，在一個機票預訂中糙捺，就可能涉及許多個單獨的過程：在航空公司預訂機票诫咱，付款，并在機票成功預訂后向客戶發(fā)送確認信息洪灯。
微服務架構坎缭，就是將各個流程按照業(yè)務拆分為獨立的服務。在上面的示例中签钩，機票預訂服務可以被拆分為機票預訂掏呼，付款和確認，拆分后的微服務可以通過接口相互通信铅檩。
那么憎夷，微服務與單體應用，究竟有什么不同昧旨？
對比1：網絡延遲
當涉及微服務時拾给，有一個基本的物理定律在起作用，每當微服務通過網絡調用另一服務時兔沃，字節(jié)就通過網絡發(fā)送蒋得，這涉及將字節(jié)轉換為電信號或脈沖光，然后將這些信號轉換回字節(jié)乒疏。根據模擬結果额衙，微服務調用的等待時間至少為24ms。如果我們假設實際處理大約需要100毫秒怕吴，則總處理時間如下所示：
假設在理想情況下窍侧，所有調用執(zhí)行可以同時發(fā)生，并且彼此之間不依賴–這稱為扇出模式( fan-out pattern)转绷。下圖顯示了隨著越來越多的調用同時執(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ā)現戴卜，雖然服務連接數量下降了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或隊列事件什猖。
- 幾乎沒有跨服務的事務
推薦
- Netflix 微服務架構設計解析
- 為什么阿里規(guī)定需要在事務注解@Transactional中指定rollbackFor？
- 下一代構建工具 Gradle 红淡，比 Maven 強在哪里不狮！
- 如何讓你的Nginx 提升10倍性能？
- 面試必需要明白的 Redis 分布式鎖實現原理在旱！
學習資料分享
12 套 微服務摇零、Spring Boot、Spring Cloud 核心技術資料颈渊，這是部分資料目錄：
- Spring Security 認證與授權
- Spring Boot 項目實戰(zhàn)（中小型互聯網公司后臺服務架構與運維架構）
- Spring Boot 項目實戰(zhàn)（企業(yè)權限管理項目））
- Spring Cloud 微服務架構項目實戰(zhàn)（分布式事務解決方案）
- ...
公眾號后臺回復arch028獲取資料：：
