1.1.1 從單體系統(tǒng)到微服務(wù)架構(gòu)

在軟件技術(shù)發(fā)展的很長一段時間內(nèi)，軟件系統(tǒng)都表現(xiàn)為一種單體系統(tǒng)。時至今日，很多單體系統(tǒng)仍然在一些行業(yè)和組織中得到開發(fā)和維護。所謂單體系統(tǒng)，簡單來講就是把一個系統(tǒng)所涉及的各個組件都打包成一個一體化結(jié)構(gòu)并進行部署和運行。單體系統(tǒng)存在一些固有的問題，在本節(jié)中，我們從這些問題出發(fā)來剖析微服務(wù)架構(gòu)的誕生背景和特性。

1.單體系統(tǒng)存在的問題

圖1-1展示的就是一個典型的單體系統(tǒng)，我們可以看到在應(yīng)用服務(wù)器上同時運行著面向用戶的Web服務(wù)層、封裝業(yè)務(wù)邏輯的業(yè)務(wù)邏輯層和完成數(shù)據(jù)持久化操作的數(shù)據(jù)訪問層組件，這些組件作為一個整體進行統(tǒng)一的開發(fā)、部署和維護。

單體架構(gòu)簡單且容易實現(xiàn)，但隨著公司或者組織業(yè)務(wù)的不斷擴張、業(yè)務(wù)結(jié)構(gòu)的不斷變化以及用戶量的不斷增加，單體架構(gòu)面臨著越來越多的挑戰(zhàn)，已逐漸無法適應(yīng)互聯(lián)網(wǎng)時代的快速發(fā)展。讓我們一起來分析一下。

對于大多數(shù)系統(tǒng)而言，架構(gòu)設(shè)計是為了滿足業(yè)務(wù)需求。衡量架構(gòu)好壞與否的一個重要方面是看其面對復雜業(yè)務(wù)變更時所具有的靈活性，也就是我們通常所說的可擴展性（Extensibility）。可擴展性是指系統(tǒng)在經(jīng)歷不可避免的變更時足夠靈活，針對提供這樣的靈活性所要付出的成本進行平衡的能力。所謂可擴展，擴展的是業(yè)務(wù)。當向一個現(xiàn)有系統(tǒng)中添加新業(yè)務(wù)功能時，如果不需要改變原有的業(yè)務(wù)體系而只需把新功能封閉在一個新的模塊或子系統(tǒng)中就能完成整體業(yè)務(wù)的升級，我們就可以認為該系統(tǒng)具有較好的可擴展性。顯然，單體系統(tǒng)不具備良好的可擴展性，因為對系統(tǒng)業(yè)務(wù)進行任何一處修改，都需要重新構(gòu)建整個系統(tǒng)并進行發(fā)布。單體系統(tǒng)內(nèi)部沒有根據(jù)業(yè)務(wù)結(jié)構(gòu)進行合理的拆分是導致其可擴展性低下的主要原因。

前面講到單體系統(tǒng)的可擴展性很差，實際上它的可伸縮性同樣也有問題。所謂可伸縮（Scalability），伸縮的是性能，即當系統(tǒng)性能出現(xiàn)問題時，如果我們只需要簡單地添加應(yīng)用服務(wù)器等硬件設(shè)備就能避免系統(tǒng)出現(xiàn)性能瓶頸，那么該系統(tǒng)無疑具備較高的可伸縮性。通常，我們會考慮采用水平伸縮的方法實現(xiàn)可伸縮性。當考慮水平伸縮時，一般的做法是建立一個集群，在集群中不斷地添加新節(jié)點，然后借助前端的負載均衡器，將用戶的請求按照某種算法分配到不同的節(jié)點上。但是，由于單體系統(tǒng)的所有程序代碼都運行在服務(wù)器上的同一個進程中，內(nèi)存密集型和CPU密集型并存，也就要求所有應(yīng)用的服務(wù)器都必須有足夠的內(nèi)存和強勁的CPU來滿足需求。這種方法成本會比較高，而且資源利用率通常都比較低下。

以圖1-2所示內(nèi)容為例，單體系統(tǒng)中的組件A的負載已經(jīng)達到了80%，也就是到了不得不對系統(tǒng)的運行能力進行擴容的時候，但同一系統(tǒng)的另外兩個組件B和C的負載還沒有到其處理能力的20%。由于單體系統(tǒng)中的各個組件是打包在同一個運行包中的，因此雖然通過添加一個額外的系統(tǒng)運行實例可以將需要擴容組件的負載降低一半，但是顯然其他組件的利用率變得更為低下，造成了資源浪費。另外，對于那些需要保持類似會話（Session）數(shù)據(jù)的需求而言，擴容之后的運行機制在如何保持各個服務(wù)器之間數(shù)據(jù)的一致性上也存在較大的實現(xiàn)難度。

最后，我們需要認識到，在軟件開發(fā)過程中，代碼腐化在一定程度上是一種不可避免的現(xiàn)象。在單體系統(tǒng)中，由于缺乏合理的業(yè)務(wù)和技術(shù)實現(xiàn)邊界，隨著產(chǎn)品業(yè)務(wù)功能的增多，當出現(xiàn)缺陷時，有可能引起缺陷的原因組合比較多，這會導致分析缺陷、定位缺陷、修復缺陷的成本相應(yīng)增加，也就意味著缺陷的平均修復周期可能會延長，從而影響產(chǎn)品的正常迭代和演進。同時，隨著功能不斷疊加，單體系統(tǒng)的代碼結(jié)構(gòu)也日益復雜，修復一個缺陷的同時還有可能引入其他的缺陷，在很多技術(shù)團隊并不具備完善的持續(xù)集成（Continuous Integration, CI）和持續(xù)交付（Continuous Delivery, CD）能力的客觀條件下，很可能導致出現(xiàn)問題越修越多的不良循環(huán)。

針對以上集中式單體系統(tǒng)普遍存在的問題，基本的解決方案就是微服務(wù)架構(gòu)系統(tǒng)的合理構(gòu)建。

2.微服務(wù)架構(gòu)的特性

軟件工程大師Martin Fowler在“Microservices”一文中提到，微服務(wù)架構(gòu)具有服務(wù)組件化、按業(yè)務(wù)能力組織服務(wù)、去中心化和基礎(chǔ)設(shè)施自動化等核心特性。

組件（Component）是一種可獨立替換和升級的軟件單元。在日常開發(fā)過程中可能會設(shè)計和使用很多組件，這些組件可能服務(wù)于系統(tǒng)內(nèi)部，也可能存在于系統(tǒng)所運行的進程之外。而服務(wù)就是一種進程外組件，服務(wù)之間利用HTTP完成交互。服務(wù)組件化的主要目的是服務(wù)可以獨立部署。如果你的應(yīng)用程序是由一個運行在獨立進程中的很多組件組成的，那么對任何一個組件的改變都將導致必須重新部署整個應(yīng)用程序。但是如果你把應(yīng)用程序拆分成很多服務(wù)，顯然，通常你只需要重新部署那個改變的服務(wù)。在微服務(wù)架構(gòu)中，每個服務(wù)運行在獨立的進程中，服務(wù)與服務(wù)之間采用輕量級通信機制進行交互。

當尋找把一個大的應(yīng)用程序進行拆分的方法時，研發(fā)過程通常都會圍繞產(chǎn)品團隊、UED（用戶體驗設(shè)計）團隊、App前端團隊和服務(wù)端團隊展開，這些團隊也就是通常所說的職能團隊（Function Team）。當使用這種標準對團隊進行劃分時，任何一個需求變更，無論大小，都將導致跨團隊協(xié)作，從而增加溝通和協(xié)作成本。而微服務(wù)架構(gòu)下的劃分方法有所不同，它傾向于圍繞業(yè)務(wù)功能的組織來分割服務(wù)。這些服務(wù)面向具體的業(yè)務(wù)結(jié)構(gòu)，而不是面向某項技術(shù)能力。因此，團隊是跨職能的（Cross-Functional）特征團隊（Feature Team），包含用戶體驗、項目管理和技術(shù)研發(fā)等開發(fā)過程所要求的所有崗位和技能。每個服務(wù)都圍繞著業(yè)務(wù)進行構(gòu)建，并且能夠被獨立部署到生產(chǎn)環(huán)境。

集中式系統(tǒng)的一個好處是技術(shù)的標準化，但采用微服務(wù)的團隊更喜歡不同的標準。把集中式系統(tǒng)中的組件拆分成不同的服務(wù)，我們在構(gòu)建這些服務(wù)時就會有更多的選擇。對具體的某一個服務(wù)而言，應(yīng)該根據(jù)業(yè)務(wù)上下文，選擇合適的語言和工具進行構(gòu)建。另外，微服務(wù)架構(gòu)也崇尚對數(shù)據(jù)進行分散管理，讓每個服務(wù)管理自己的數(shù)據(jù)庫，無論是相同數(shù)據(jù)庫的不同實例，還是不同的數(shù)據(jù)庫系統(tǒng)。

許多使用微服務(wù)架構(gòu)的產(chǎn)品或者系統(tǒng)，其團隊擁有豐富的持續(xù)集成和持續(xù)交付經(jīng)驗。團隊使用微服務(wù)架構(gòu)構(gòu)建軟件需要更廣泛地依賴基礎(chǔ)設(shè)施自動化技術(shù)。

當然，在微服務(wù)中同樣需要考慮網(wǎng)絡(luò)傳輸?shù)娜龖B(tài)性、異構(gòu)性、數(shù)據(jù)一致性和服務(wù)容錯性設(shè)計等分布式系統(tǒng)所需要考慮的問題。隨著本書內(nèi)容的展開，會對這些特性進行詳細的分析和討論。