來源：thenewstack.io/

                 
                
               
              
             
            
           
          
         
        
       
      
     
    

• 對比1：網(wǎng)絡(luò)延遲
• 對比2：復(fù)雜性
• 對比3：可靠性
• 對比4：資源使用
• 對比5：擴展的精確性
• 對比6：吞吐量
• 對比7：部署時間
• 對比8：溝通
• 誰是贏家？

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

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

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

那么，微服務(wù)與單體應(yīng)用，究竟有什么不同？

對比1：網(wǎng)絡(luò)延遲

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

網(wǎng)絡(luò)延遲-微服務(wù)與單體應(yīng)用

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

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

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

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

這一次，單體應(yīng)用勝利了。

對比2：復(fù)雜性

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

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

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

對于日志和監(jiān)控方面，在單體應(yīng)用中，日志記錄就像查看單個日志文件一樣簡單。但是，對于微服務(wù)，跟蹤問題可能涉及檢查多個日志文件。不僅需要查找所有相關(guān)的日志輸出，而且還需要以正確的順序?qū)⑺鼈兎旁谝黄稹?/p>

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

這一次，單體應(yīng)用又勝利了。

對比3：可靠性

在微服務(wù)中，如果A服務(wù)通過網(wǎng)絡(luò)以99.9％的可靠性調(diào)用B服務(wù)（這意味著在1000個調(diào)用中，有一個將由于網(wǎng)絡(luò)問題而失?。?，這時B調(diào)用再C服務(wù)，我們將獲得99.8％的可靠性。

隨著調(diào)用時間的延長，可靠性下降

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

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

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

最后，微服務(wù)取得了勝利。

對比4：資源使用

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

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

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

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

隨著越來越多的實例在運行，單體應(yīng)用比微服務(wù)需要更多的資源

資源使用率方面，微服務(wù)勝利了。

對比5：擴展的精確性

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

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

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

對比6：吞吐量

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

對比7：部署時間

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

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

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

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

勝利歸功于微服務(wù)。

對比8：溝通

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

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

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

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

這是微服務(wù)的另一個明顯勝利。

誰是贏家？

單體應(yīng)用獲得了3場勝利，微服務(wù)獲得了5場勝利。

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

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

以下是一些跡象，表明微服務(wù)架構(gòu)可能是一個合適的選擇：

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