在技術(shù)演進的歷史長河中，單體架構(gòu)曾是眾多項目的起點，但隨著業(yè)務(wù)需求日益復(fù)雜，微服務(wù)架構(gòu)憑借其靈活性和可擴展性逐漸成為新寵。行業(yè)內(nèi)對此有著激烈的討論，尤其是互聯(lián)網(wǎng)大廠和行業(yè)技術(shù)大佬們對微服務(wù)架構(gòu)的看法頗具影響力。

亞馬遜的CTO Werner Vogels就曾強調(diào)過微服務(wù)架構(gòu)對企業(yè)快速迭代的重要性，他認為，構(gòu)建小型、松散耦合的服務(wù)能夠提高系統(tǒng)的可靠性和效率。谷歌也傾向于使用微服務(wù)架構(gòu)，這對于他們快速部署新功能和實現(xiàn)全球規(guī)模的服務(wù)至關(guān)重要。

此外，技術(shù)界的權(quán)威如Martin Fowler也對微服務(wù)架構(gòu)持肯定態(tài)度，他在多篇文章中詳細闡述了微服務(wù)架構(gòu)的優(yōu)勢和實施策略，強調(diào)了它在現(xiàn)代軟件開發(fā)中的適用性。

這些討論讓企業(yè)更清楚地認識到，微服務(wù)架構(gòu)能顯著增強系統(tǒng)穩(wěn)定和并發(fā)處理能力。盡管存在服務(wù)治理和分布式事務(wù)等挑戰(zhàn)，但互聯(lián)網(wǎng)大廠的成功案例和技術(shù)大佬們的深入分析，都為其他企業(yè)轉(zhuǎn)型微服務(wù)架構(gòu)提供了寶貴的經(jīng)驗和信心。

當(dāng)然，單體架構(gòu)與微服務(wù)架構(gòu)的辯論不止觸及技術(shù)的表層，更關(guān)乎對未來業(yè)務(wù)模式和運營效率的深遠考量。對于企業(yè)而言，選擇適合自己的架構(gòu)，才是重要的。

1?單體架構(gòu)與微服務(wù)架構(gòu)

1.1 什么是單體架構(gòu)

單體架構(gòu)（Monolithic Architecture）是一種將所有功能打包在一個容器中一起運行的一種架構(gòu)，一個實例中集成了一個系統(tǒng)的所有功能。通過負載均衡軟件/設(shè)備實現(xiàn)多實例調(diào)用。

1、優(yōu)點

部署簡單：由于是完整的結(jié)構(gòu)體，可以直接部署在一個服務(wù)器上；

代碼統(tǒng)一：組建密集集成，源碼通用，代碼組織一致；

研發(fā)成本低：單一服務(wù)和業(yè)務(wù)聚合，減少人力成本；

技術(shù)簡單：只需要知道簡單的技術(shù)棧，即可研發(fā)。

2、缺點

維護困難：隨著業(yè)務(wù)量的增加，服務(wù)逐步復(fù)雜，由于組件高度耦合，開發(fā)人員實現(xiàn)業(yè)務(wù)功能的同時大概率會影響到其它功能；

系統(tǒng)啟動慢：業(yè)務(wù)多、代碼模塊多，啟動周期漫長；

伸縮性差：不能針對業(yè)務(wù)模塊單獨擴容，需要對整體服務(wù)進行擴容；

故障風(fēng)險大：單體服務(wù)的某個組件出現(xiàn)問題，會導(dǎo)致整個服務(wù)不能用；

技術(shù)棧僵化：隨著新技術(shù)迭代出現(xiàn)，單體服務(wù)技術(shù)風(fēng)險更大。技術(shù)僵化在原地，時間越長，技術(shù)漏洞將越來越難以修復(fù)。

1.2 什么是微服務(wù)架構(gòu)

微服務(wù)架構(gòu)是一種架構(gòu)概念，它強調(diào)將應(yīng)用程序的功能分解為多個小的服務(wù)，這些服務(wù)可以獨立開發(fā)、管理和部署，每個服務(wù)運行在自己的進程中，并通過輕量級的通信機制如REST API進行交互。微服務(wù)架構(gòu)的核心在于解耦，它通過減少服務(wù)之間的依賴和耦合，提高了系統(tǒng)的靈活性和可擴展性。

1、優(yōu)點?

業(yè)務(wù)容易實現(xiàn)：服務(wù)職責(zé)單一，業(yè)務(wù)邏輯單一，代碼量少，便于代碼管理和迭代開發(fā)；

服務(wù)獨立：每個服務(wù)都采用獨立的技術(shù)棧進行開發(fā)，使得部署更新可以針對單個服務(wù)進行，從而降低整體風(fēng)險并提高系統(tǒng)的靈活性和可維護性；

可擴展性：微服務(wù)架構(gòu)允許根據(jù)業(yè)務(wù)需求靈活地增減資源應(yīng)對負載變化。單個應(yīng)用變更時，只需要重新部署，保持服務(wù)顆粒度隔離，即可確保系統(tǒng)即使發(fā)生局部故障也可繼續(xù)運行；

技術(shù)棧靈活：每個服務(wù)可以有獨立的技術(shù)棧，每個服務(wù)都可以獨立更新對應(yīng)的技術(shù)棧，從而不斷升級技術(shù)棧提高服務(wù)質(zhì)量。

2、缺點

復(fù)雜度增加：微服務(wù)架構(gòu)可將一個系統(tǒng)拆分為多個獨立的服務(wù)，這增加了額外的復(fù)雜度。例如，需管理分布式數(shù)據(jù)的一致性，且需處理服務(wù)間的通訊問題；

成本高：服務(wù)越多，運維要求越高，投入資源越多，成本越高。

通過上述內(nèi)容，我們對單體架構(gòu)和微服務(wù)架構(gòu)的概念及兩者之間的差異有了一個整體的了解。接下來，我們將探討如何在實際項目實踐中將單體項目拆分為微服務(wù)架構(gòu)。

2?充電樁拆分前項目剖析

我們已經(jīng)掌握了單體架構(gòu)與微服務(wù)架構(gòu)的差異，接下來我們將在最新的充電樁項目中實際操作，將傳統(tǒng)的單體應(yīng)用進行拆分，實施微服務(wù)架構(gòu)。

在開始一個項目時，首先需要對項目進行定位，明確其架構(gòu)類型，并評估其是否能夠支持高并發(fā)、高性能和高可用性，同時考慮它是否能適應(yīng)未來的業(yè)務(wù)發(fā)展需求。

充電樁項目是一個外采項目，它是一個十分典型的單體項目，服務(wù)有狀態(tài)而且手動單機部署，且服務(wù)不能高并發(fā)、高可用與高性能?，F(xiàn)有架構(gòu)只能滿足當(dāng)時的現(xiàn)有設(shè)備，在未來10倍業(yè)務(wù)量倍增下，現(xiàn)有的架構(gòu)明顯不能滿足這些需求。

為了應(yīng)對未來三年10倍業(yè)務(wù)量倍增的挑戰(zhàn)，并確保服務(wù)的高并發(fā)、高性能和高可用性，微服務(wù)的可擴展性高、服務(wù)高獨立、職責(zé)單一，并且技術(shù)棧靈活，便于升級與維護。因此，微服務(wù)架構(gòu)成為了首/選。

在選擇未來架構(gòu)后，首先需要考慮從單體架構(gòu)遷移到微服務(wù)架構(gòu)過程中可能遇到的以下障礙：

技術(shù)棧較老舊：無法更新到最/新/技術(shù)棧，無法適配spring cloud/云原生微服務(wù)架構(gòu)；

服務(wù)有狀態(tài)：服務(wù)訪問負載固定IP Hash訪問指定一臺機器，可以用性十分差；

前后端不分離：前端代碼和后端代碼緊密耦合，不易重用。頁面響應(yīng)慢，用戶體驗差，不易維護；

可維護性差：代碼耦合模塊，修改一個模塊會導(dǎo)致其他模塊發(fā)生意想不到的變化，從而增加了維護成本；

可擴展性差：模塊之間過于依賴，不容易擴展功能；

可重用性差：高耦合的模塊不容易在其他系統(tǒng)中重用；

可測試性差：測試一個模塊需要依賴其他模塊，增加測試難度；

部署架構(gòu)不靈活：需要手動部署，停機時間長，且可用性差。

要實現(xiàn)充電樁項目微服務(wù)化，就必須解決以上阻礙。

3?充電樁拆分微服務(wù)架構(gòu)步驟

3.1 單體服務(wù)實現(xiàn)無狀態(tài)

單體服務(wù)實現(xiàn)無狀態(tài)

我們?yōu)槭裁匆獙⒎?wù)去狀態(tài)？服務(wù)有狀態(tài)對系統(tǒng)會造成哪些影響？我們先來分析一下服務(wù)有狀態(tài)有哪些缺點：

1、狀態(tài)管理問題：每個服務(wù)實例可能需要維護自己的狀態(tài)，這會導(dǎo)致大量的內(nèi)存占用和管理成本；

2、擴展性問題：有狀態(tài)服務(wù)不易于進行水平擴展，因為擴展實例時，它們將失去之前的狀態(tài)，并且需要合理地管理狀態(tài)遷移；

3、高可用性問題：如果服務(wù)實例失敗，有狀態(tài)服務(wù)可能需要額外的機制來保證狀態(tài)的高可用性；

4、數(shù)據(jù)一致性問題：在分布式系統(tǒng)中，多個實例同時訪問和修改同一狀態(tài)時，可能會出現(xiàn)數(shù)據(jù)一致性問題；

5、性能問題：有狀態(tài)服務(wù)可能需要更多資源來處理本地的狀態(tài)，這可能會影響性能。

從上述單體服務(wù)有狀態(tài)缺陷性分析，我們可以看出，服務(wù)有狀態(tài)是實現(xiàn)服務(wù)高并發(fā)、高性能和高可用目標(biāo)的障礙。因此，接下來，我們將重點探討服務(wù)無狀態(tài)的分析和設(shè)計。

3.2 充電樁單體服務(wù)有狀態(tài)架構(gòu)圖

當(dāng)用戶A的IP固定哈希到主機A后，那么它后面的流量都會一直流向主機A，而不會流向主機B。用戶A的所有請求校驗信息都存儲在session中，用戶B同理。這樣一來，如果有某臺服務(wù)器發(fā)生故障，那么所有依賴該服務(wù)器的用戶都會無法訪問資源，降低了系統(tǒng)的可用性。具體見下圖所示：

與服務(wù)有狀態(tài)相比，服務(wù)無狀態(tài)的主要優(yōu)勢在于它們能夠輕松地實現(xiàn)高可伸縮性和高可用性。無狀態(tài)服務(wù)不需要保存會話狀態(tài)，因此不會成為系統(tǒng)的瓶頸。當(dāng)請求分布在多個無狀態(tài)服務(wù)實例之間時，每個實例只需處理它接收到的請求，不需要共享任何內(nèi)部狀態(tài)。

3.3?無狀態(tài)實現(xiàn)步驟

無狀態(tài)是指一個系統(tǒng)或者組件不存儲關(guān)于先前交互的信息或者狀態(tài)。

微服務(wù)架構(gòu)設(shè)計中的一個核心原則就是服務(wù)無狀態(tài)化。微服務(wù)處理每個請求時不會依賴于會話信息或者狀態(tài)，無需考慮之前的交互邏輯。服務(wù)無狀態(tài)的目的是簡化請求處理、服務(wù)部署、服務(wù)伸縮、服務(wù)容錯、資源優(yōu)化或者服務(wù)狀態(tài)恢復(fù)和同步等。

如何實現(xiàn)無狀態(tài)？其實現(xiàn)步驟如下：

1、狀態(tài)分離：將狀態(tài)從服務(wù)中分離出來，并將其存儲在外部系統(tǒng)中，如數(shù)據(jù)庫或分布式緩存，服務(wù)脫離狀態(tài)管理。

2、網(wǎng)絡(luò)請求管理狀態(tài)：通過請求（API請求參數(shù)、http請求頭及cookie等）傳遞狀態(tài)信息，以保證請求執(zhí)行所需要的參數(shù)。

3、使用消息隊列：將請求封裝到消息隊列，通過消息隊列通訊實現(xiàn)服務(wù)無狀態(tài)化。

綜合來說，服務(wù)無狀態(tài)化是實現(xiàn)高可用、可伸縮和易于管理的分布式系統(tǒng)的關(guān)鍵因素。

3.4 充電樁單體服務(wù)無狀態(tài)架構(gòu)圖

在無狀態(tài)時，用戶A和用戶B可以正常地通過Webview進行訪問。由于系統(tǒng)設(shè)計中包括對兩臺輪服務(wù)器的輪詢機制，即使其中一臺服務(wù)器出現(xiàn)故障，請求可以被另一臺服務(wù)器處理，保障了系統(tǒng)的正常運行和高可用性。具體見下圖所示：

3.5?電樁單體服務(wù)前后端分離無狀態(tài)架構(gòu)圖

在無狀態(tài)實現(xiàn)完成后，可以逐步將JSP頁面遷移到Vue前端服務(wù)中，并通過Nginx實現(xiàn)轉(zhuǎn)發(fā)。具體見下圖所示：

3.6?充電樁微服務(wù)前后端完全分離態(tài)架構(gòu)圖

4?充電樁項目實踐拆分

4.1?單體架構(gòu)充電樁項目架構(gòu)

從上圖的架構(gòu)圖可以看出，所有的服務(wù)都依賴于center服務(wù)。center是一個功能混雜的服務(wù)，沒有具體的功能劃分。一旦center服務(wù)故障，將導(dǎo)致整個服務(wù)無法正常工作。

4.2 單體架構(gòu)拆分步驟

斷開gateway tcp和gateway ssl對center的直接依賴，所有的調(diào)用應(yīng)該通過MQ來實現(xiàn)。

center主要提供三個功能：小程序訪問功能、主營數(shù)據(jù)消費功能及設(shè)備消費的功能。為了提高系統(tǒng)性能和降低故障分析，可以將center功能拆分為主數(shù)據(jù)kafka消費、設(shè)備服務(wù)與小程序服務(wù)這三個模塊。

將webview/管理系統(tǒng)單獨拆分為微服務(wù)，解除其對center的依賴。

將frontview/管理系統(tǒng)單獨拆分為微服務(wù)，解除其對center的依賴。

我們從單體架構(gòu)開始，逐步將其核心功能模塊轉(zhuǎn)化為微服務(wù)架構(gòu)。具體而言，是在保留center的三大功能——小程序訪問、主營數(shù)據(jù)消費以及設(shè)備消費功能的基礎(chǔ)上，我們將網(wǎng)關(guān)、webview和frontview從對center的依賴中解耦，使它們演變?yōu)楠毩⒌奈⒎?wù)架構(gòu)。

通過這種轉(zhuǎn)變，center避免了直接處理服務(wù)調(diào)用，實現(xiàn)了與其他服務(wù)的完全分離。這導(dǎo)致center不再直接管理流量的進出，從而顯著減少了系統(tǒng)的復(fù)雜性及可能的故障源，增強了系統(tǒng)的維護性和可靠性。

4.3?微服務(wù)架構(gòu)領(lǐng)域劃分

在拆分服務(wù)邊界和職責(zé)之前，通常會設(shè)置一些基礎(chǔ)服務(wù)，包括用戶服務(wù)、工單服務(wù)、訂單服務(wù)、支付服務(wù)、任務(wù)調(diào)度服務(wù)、設(shè)備服務(wù)及數(shù)據(jù)總線消費微服。基于這些基礎(chǔ)服務(wù)，我們進一步定義了上層服務(wù)，如公眾號服務(wù)、小程序服務(wù)與后臺管理系統(tǒng)服務(wù)等。最后，為了支持第三方業(yè)務(wù)整合，我們還提供了第三方業(yè)務(wù)支撐服務(wù)，以實現(xiàn)與外部系統(tǒng)的無縫對接和數(shù)據(jù)交換。

5 總結(jié)

在將單體架構(gòu)拆分成微服務(wù)架構(gòu)的過程中，我們從這兩種架構(gòu)的基本概念出發(fā)，詳盡探討了拆分過程中可能遇到的障礙及具體的拆分步驟，并分享了充電樁項目實踐經(jīng)驗。對此，我們總結(jié)出以下關(guān)鍵點：

將單體架構(gòu)拆分成微服務(wù)架構(gòu)的核心是服務(wù)無狀態(tài)、前后端逐步分離和流量切分；

解耦單體服務(wù)到職責(zé)單一的多元服務(wù)是服務(wù)“三高”（高并發(fā)、高性能和高可用）可用的關(guān)鍵；

技術(shù)棧的不斷迭代升級是維持微服務(wù)架構(gòu)活力的血液，分布式數(shù)據(jù)管理和監(jiān)控是維持微服務(wù)架構(gòu)監(jiān)控的保障，而統(tǒng)一規(guī)范的RPC通信協(xié)議則是微服務(wù)調(diào)度通信的質(zhì)量基準(zhǔn)。

本文作者：

王志堅：碧桂園服務(wù)JAVA開發(fā)專家

指導(dǎo)人：

毛卓：碧桂園服務(wù)技術(shù)總監(jiān)

劉剛：碧桂園服務(wù)架構(gòu)師