企業(yè)向微服務(wù)架構(gòu)轉(zhuǎn)型需要采用哪些策略模式進行微服務(wù)化改造呢？
微服務(wù)化改造
對單體架構(gòu)現(xiàn)狀的不滿和難以控制是推動微服務(wù)化改造的重要因素，企業(yè)在向微服務(wù)架構(gòu)轉(zhuǎn)型的過程中面臨諸多挑戰(zhàn)，需要采用相應(yīng)的策略模式進行微服務(wù)化改造。
技術(shù)債務(wù)
單體架構(gòu)下技術(shù)債務(wù)的產(chǎn)生原因多種多樣，總結(jié)下來這些技術(shù)債務(wù)大體可以分為業(yè)務(wù)復(fù)雜、交付質(zhì)量低、非功能需求不達標等三大類。
● 業(yè)務(wù)復(fù)雜：開發(fā)人員依靠模塊的疊加加速軟件交付，后期形成規(guī)模龐大的單體架構(gòu)，導(dǎo)致業(yè)務(wù)代碼臃腫、業(yè)務(wù)邏輯耦合、無法復(fù)用等問題。
● 交付質(zhì)量低：單體架構(gòu)缺少自動化測試能力，存在局部代碼質(zhì)量問題，容易引發(fā)整個系統(tǒng)的可用性問題。
● 非功能需求不達標：代碼的腐化和缺少維護、重構(gòu)、改進導(dǎo)致性能逐漸下降等問題，在極端情況下，甚至出現(xiàn)不同資源競爭的短板效應(yīng)，造成整個系統(tǒng)崩潰。
微服務(wù)化改造時機
對于存在技術(shù)債務(wù)的單體架構(gòu)，在實施微服務(wù)化改造工作前，需要從客觀和主觀兩個方面來判斷當(dāng)前時間點是否是進行微服務(wù)化改造的最佳時機。
所謂客觀因素包括上一節(jié)所說的技術(shù)債務(wù)因素。此外，代碼沖突頻率、組織人員規(guī)模、產(chǎn)品迭代速速、用戶規(guī)模量級等量化指標也可以作為微服務(wù)化改造的重要客觀依據(jù)。
微服務(wù)化改造時機同樣受到技術(shù)團隊主體愿望和人員技術(shù)能力的制約，概括如下：
● 團隊的技術(shù)選型需要達成一致，并在組織層面上有一致的指導(dǎo)和規(guī)范。
● 團隊需要根據(jù)業(yè)務(wù)所處階段、當(dāng)前系統(tǒng)項目使用的技術(shù)棧和團隊人員能力決定是否適宜轉(zhuǎn)型微服務(wù)。
● 團隊是否具備自動化交付和微服務(wù)治理平臺等技術(shù)支撐能力。
單體架構(gòu)的改造模式
單體架構(gòu)進行微服務(wù)化改造需求遵循一定的改造模式。在不影響業(yè)務(wù)正常運行的前提下實現(xiàn)業(yè)務(wù)的平滑過渡，下面我們列舉一些經(jīng)常使用的微服務(wù)化改造模式。
絞殺者模式（Strangler Pattern）
絞殺者模式通過逐步替換而非一次性替換的方式來保證新舊系統(tǒng)的平滑過渡。運用一系列易于理解的小規(guī)模替換定期交付新的微服務(wù)，逐步淘汰遺留系統(tǒng)的功能模塊，最終實現(xiàn)全部替換，流程如下圖所示。
修繕者模式
修繕者模式源于古老的軟件工程格言“任何問題都可以通過增加一個中間層解決”，就如修房或修路一樣，將老舊待修繕的部分進行隔離，用新的方式對其進行單獨修復(fù)。修復(fù)的同時，需保證與其他部分仍然能夠協(xié)同完成工作。修繕者模式的基本原理來自Martin Fowler的重構(gòu)方法，如下圖所示。
這種模式的實現(xiàn)方式可以分成三個主要步驟。
● 抽象層提取：首先通過識別內(nèi)部的待拆分功能，對其增加抽象接口層，同時對原有代碼進行改造，確保其同樣實現(xiàn)該抽象層，這樣在依賴關(guān)系上就添加了一個中間層。
● 抽象層實現(xiàn)：為抽象層提供新的實現(xiàn)，新的實現(xiàn)采用微服務(wù)方式。
● 抽象層替換：采用新的實現(xiàn)對原有的各個抽象層實現(xiàn)進行逐步替換，直至原有實現(xiàn)被完全廢棄，從而完成新老實現(xiàn)方式的替換。
演進式改造流程
演進式改造流程是一種以逐步演進的方式對遺留系統(tǒng)進行改造的流程，通過構(gòu)建服務(wù)路標圖、服務(wù)選擇、服務(wù)改造、業(yè)務(wù)驗證、迭代優(yōu)化完成微服務(wù)化改造，如下圖所示。
● 構(gòu)建服務(wù)路標圖：由架構(gòu)師、業(yè)務(wù)分析師及技術(shù)負責(zé)人共同參與構(gòu)造出一個服務(wù)路標圖，并接受來自各個方面人員的反饋。
● 服務(wù)選擇：有了服務(wù)路標圖之后，遵循價值最大化的原則，從多種角度去制定優(yōu)先拆分策略，優(yōu)先拆分相對獨立、容易實施的業(yè)務(wù)部分。
● 服務(wù)改造和業(yè)務(wù)驗證：在改造過程中需要驗證新的服務(wù)是否滿足業(yè)務(wù)需求。在新服務(wù)上線投入使用并穩(wěn)定后，可以從遺留系統(tǒng)中移除原有的代碼模塊。
邊車（SideCar）模式
傳統(tǒng)企業(yè)中存在大量的遺留系統(tǒng)，對這些遺留系進行微服務(wù)化改造的成本很高。對于這些系統(tǒng)，我們的選擇并不一定是將其進行微服務(wù)化改造，而是將其接入微服務(wù)環(huán)境中，與其他服務(wù)共同協(xié)作來實現(xiàn)業(yè)務(wù)需求。邊車模式可為不同語言的遺留系統(tǒng)提供一個同構(gòu)的接入接口。對于原遺留系統(tǒng)應(yīng)用程序的每個實例都部署和托管了一個邊車實例，實現(xiàn)非侵入式接入。
本文給大家講解的內(nèi)容是微服務(wù)架構(gòu)深度解析：微服務(wù)構(gòu)建，微服務(wù)化改造
下篇文章給大家講解的是微服務(wù)架構(gòu)深度解析：微服務(wù)構(gòu)建進階，從更宏觀的軟件構(gòu)建視角切入來總結(jié)微服務(wù)構(gòu)建的最佳實踐
覺得文章不錯的朋友可以轉(zhuǎn)發(fā)此文關(guān)注小編；
感謝大家的支持！
本文就是愿天堂沒有BUG給大家分享的內(nèi)容，大家有收獲的話可以分享下，想學(xué)習(xí)更多的話可以到微信公眾號里找我，我等你哦。