來源：thenewstack.io/

                 
                
               
              
             
            
           
          
         
        
       
      
     
    

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

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

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

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

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

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

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

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

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

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

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

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

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

對(duì)比2：復(fù)雜性

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

由于開發(fā)的復(fù)雜性，在構(gòu)建基于微服務(wù)的軟件時(shí)，代碼庫(kù)的大小會(huì)快速增長(zhǎng)。因?yàn)槲⒎?wù)涉及多個(gè)源代碼，使用不同的框架甚至不同的語(yǔ)言。由于微服務(wù)需要彼此獨(dú)立，因此經(jīng)常會(huì)有代碼重復(fù)。

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

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

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

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

對(duì)比3：可靠性

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

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

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

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

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

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

對(duì)比4：資源使用

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

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

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

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

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

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

對(duì)比5：擴(kuò)展的精確性

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

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

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

對(duì)比6：吞吐量

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

對(duì)比7：部署時(shí)間

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

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

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

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

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

對(duì)比8：溝通

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

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

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

因此，將10個(gè)以上的開發(fā)人員分成幾個(gè)較小的團(tuán)隊(duì)，可以為任何開發(fā)項(xiàng)目提供更高的溝通效率。

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

誰(shuí)是贏家？

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

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

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

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

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