3.2 微服務化改造

對單體架構現狀的不滿和難以控制是推動微服務化改造的重要因素，企業在向微服務架構轉型的過程中面臨諸多挑戰，需要采用相應的策略模式進行微服務化改造。

3.2.1 技術債務

單體架構下技術債務的產生原因多種多樣，總結下來這些技術債務大體可以分為業務復雜、交付質量低、非功能需求不達標等三大類。

● 業務復雜：開發人員依靠模塊的疊加加速軟件交付，后期形成規模龐大的單體架構，導致業務代碼臃腫、業務邏輯耦合、無法復用等問題。

● 交付質量低：單體架構缺少自動化測試能力，存在局部代碼質量問題，容易引發整個系統的可用性問題。

● 非功能需求不達標：代碼的腐化和缺少維護、重構、改進導致性能逐漸下降等問題，在極端情況下，甚至出現不同資源競爭的短板效應，造成整個系統崩潰。

3.2.2 微服務化改造時機

對于存在技術債務的單體架構，在實施微服務化改造工作前，需要從客觀和主觀兩個方面來判斷當前時間點是否是進行微服務化改造的最佳時機。

所謂客觀因素包括上一節所說的技術債務因素。此外，代碼沖突頻率、組織人員規模、產品迭代速速、用戶規模量級等量化指標也可以作為微服務化改造的重要客觀依據。

微服務化改造時機同樣受到技術團隊主體愿望和人員技術能力的制約，概括如下：

● 團隊的技術選型需要達成一致，并在組織層面上有一致的指導和規范。

● 團隊需要根據業務所處階段、當前系統項目使用的技術棧和團隊人員能力決定是否適宜轉型微服務。

● 團隊是否具備自動化交付和微服務治理平臺等技術支撐能力。

3.2.3 單體架構的改造模式

單體架構進行微服務化改造需求遵循一定的改造模式。在不影響業務正常運行的前提下實現業務的平滑過渡，下面我們列舉一些經常使用的微服務化改造模式。

絞殺者模式（Strangler Pattern）

絞殺者模式通過逐步替換而非一次性替換的方式來保證新舊系統的平滑過渡。運用一系列易于理解的小規模替換定期交付新的微服務，逐步淘汰遺留系統的功能模塊，最終實現全部替換，流程如下圖所示。

修繕者模式

修繕者模式源于古老的軟件工程格言“任何問題都可以通過增加一個中間層解決”，就如修房或修路一樣，將老舊待修繕的部分進行隔離，用新的方式對其進行單獨修復。修復的同時，需保證與其他部分仍然能夠協同完成工作。修繕者模式的基本原理來自Martin Fowler的重構方法，如下圖所示。

這種模式的實現方式可以分成三個主要步驟。

● 抽象層提取：首先通過識別內部的待拆分功能，對其增加抽象接口層，同時對原有代碼進行改造，確保其同樣實現該抽象層，這樣在依賴關系上就添加了一個中間層。

● 抽象層實現：為抽象層提供新的實現，新的實現采用微服務方式。

● 抽象層替換：采用新的實現對原有的各個抽象層實現進行逐步替換，直至原有實現被完全廢棄，從而完成新老實現方式的替換。

演進式改造流程

演進式改造流程是一種以逐步演進的方式對遺留系統進行改造的流程，通過構建服務路標圖、服務選擇、服務改造、業務驗證、迭代優化完成微服務化改造，如下圖所示。

● 構建服務路標圖：由架構師、業務分析師及技術負責人共同參與構造出一個服務路標圖，并接受來自各個方面人員的反饋。

● 服務選擇：有了服務路標圖之后，遵循價值最大化的原則，從多種角度去制定優先拆分策略，優先拆分相對獨立、容易實施的業務部分。

● 服務改造和業務驗證：在改造過程中需要驗證新的服務是否滿足業務需求。在新服務上線投入使用并穩定后，可以從遺留系統中移除原有的代碼模塊。

邊車（SideCar）模式

傳統企業中存在大量的遺留系統，對這些遺留系進行微服務化改造的成本很高。對于這些系統，我們的選擇并不一定是將其進行微服務化改造，而是將其接入微服務環境中，與其他服務共同協作來實現業務需求。邊車模式可為不同語言的遺留系統提供一個同構的接入接口。對于原遺留系統應用程序的每個實例都部署和托管了一個邊車實例，實現非侵入式接入。