如何把單體式應(yīng)用拆解成微服務(wù)？【上】

微服務(wù)是當(dāng)下最流行的應(yīng)用架構(gòu)技術(shù)了，它跟容器服務(wù)、DevOps合稱云時代的三劍客，可以幫我們化解業(yè)務(wù)發(fā)展過快導(dǎo)致的產(chǎn)品迭代壓力，讓我們可以自由選擇最適合團(tuán)隊(duì)的技術(shù)棧，讓系統(tǒng)能夠承載互聯(lián)網(wǎng)海量用戶的訪問，讓我們可以更加輕松地運(yùn)維大型的互聯(lián)網(wǎng)系統(tǒng)。近些年在廠商、社區(qū)和用戶等各方努力推動下，微服務(wù)相關(guān)的理論和產(chǎn)品都日趨成熟，不同語言的微服務(wù)開發(fā)及治理套件(例如：Spring Cloud/Dubbo等)讓我們從零開始搭建微服務(wù)變得非常簡單快捷，那我們是否就此可以全面進(jìn)入微服務(wù)時代呢?

微服務(wù)的演進(jìn)成熟需要時間，我們熟悉掌握這套新技術(shù)也需要時間，除此之外機(jī)房里面還跑著大量的單體式應(yīng)用，它們需要繼續(xù)維護(hù)和升級，任何時候我們都不可能拋開歷史輕松上陣。這些單體式應(yīng)用還擔(dān)負(fù)著公司的核心業(yè)務(wù)，全部推倒重來、休克式重構(gòu)是不可取的，投入大周期長，風(fēng)險(xiǎn)完全不可控。我們必須學(xué)會邊行車邊換胎的技能，在不影響現(xiàn)網(wǎng)業(yè)務(wù)的前提下推動微服務(wù)改造，讓老系統(tǒng)煥發(fā)新的生命力，繼續(xù)支持業(yè)務(wù)下一個十年的發(fā)展。本文將跟你一起探討微服務(wù)改造相關(guān)的經(jīng)驗(yàn)方法，讓你更加從容地?fù)肀⒎?wù)!

1. 邊行車邊換胎三步走演進(jìn)策略

如何從單體式應(yīng)用演進(jìn)至微服務(wù)呢?這些單體式應(yīng)用都存在很長時間了，經(jīng)過這么長時間的修修補(bǔ)補(bǔ)，體量規(guī)模都比較大，尤其是經(jīng)過幾波人交接維護(hù)，業(yè)務(wù)邏輯也變得異常復(fù)雜。同時，它們都在線對外提供服務(wù)，全部推倒重建的可能性微乎其微，休克式重構(gòu)投入大周期長，風(fēng)險(xiǎn)也不好控制，還會影響業(yè)務(wù)對外服務(wù)的連續(xù)性。從現(xiàn)實(shí)情況出發(fā)，最可行的架構(gòu)優(yōu)化方案就是漸進(jìn)式的微服務(wù)改造，按照業(yè)界的最佳實(shí)踐和個人經(jīng)驗(yàn)，該演進(jìn)策略主要包括三個關(guān)鍵步驟：

• 將所有新特性都構(gòu)建成微服務(wù)，遏制單體式應(yīng)用的生長;

• 在微服務(wù)和單體式應(yīng)用之間構(gòu)建反腐層，防止老系統(tǒng)腐化新系統(tǒng);

• 按照特定的優(yōu)先順序由外而內(nèi)逐步瓦解單體式應(yīng)用。

1.1 新建微服務(wù)

通常單體式應(yīng)用所采用的技術(shù)相對較老舊，維護(hù)這些系統(tǒng)的同事缺少機(jī)會學(xué)習(xí)實(shí)踐當(dāng)前主流的技術(shù)，久而久之就跟不上主流技術(shù)的發(fā)展，在晉升、加薪和跳槽時都缺乏競爭力，這會影響到個人的價(jià)值。隨著系統(tǒng)規(guī)模越來越龐大，更新升級和運(yùn)營維護(hù)的難度越來越大，每次發(fā)版都要加班加點(diǎn)和心驚膽戰(zhàn)，逐漸滿足不了業(yè)務(wù)快速發(fā)展的需要。在單體式架構(gòu)之下，團(tuán)隊(duì)無法利用不同技術(shù)棧的優(yōu)勢解決不同場景下的問題，即使解決了問題也是事倍功半。

當(dāng)意識到有必要將單體式應(yīng)用改造成微服務(wù)時，我們通常會認(rèn)為改造就是將單體式應(yīng)用一塊一塊地敲下來改成微服務(wù)，這種想法是最直接的，但難度和風(fēng)險(xiǎn)也是最大的。改造初始我們對微服務(wù)相關(guān)技術(shù)也比較生疏，再加上拆解單體式應(yīng)用本身的難度，雙重困難疊加往往會導(dǎo)致改造失敗或延期。

最靠譜的策略是先停止往單體式應(yīng)用里面添加新的特性，所有新特性都構(gòu)建成微服務(wù)，從而遏制單體式應(yīng)用繼續(xù)生長。新特性通常不會太復(fù)雜，新建微服務(wù)也要比從單體式應(yīng)用上剝離微服務(wù)容易一些，借助這個過程讓團(tuán)隊(duì)逐漸熟悉掌握微服務(wù)技術(shù)棧，從小規(guī)模練兵再到全面鋪開。常見的微服務(wù)架構(gòu)如下圖所示，主要包含以下幾大必備組件：

• 注冊中心，提供微服務(wù)的注冊、發(fā)現(xiàn)和狀態(tài)監(jiān)測等功能;

• 配置中心，解耦代碼與配置，通過統(tǒng)一的遠(yuǎn)程配置中心管理每個微服務(wù)的配置數(shù)據(jù)，支持動態(tài)修改和立即生效等;

• 治理中心，依賴注冊中心和配置中心，提供服務(wù)降級、服務(wù)熔斷、流量控制、灰度管理等功能;

• API網(wǎng)關(guān)，將每個微服務(wù)匯聚一起對外提供服務(wù)，網(wǎng)關(guān)本身會提供安全鑒權(quán)、服務(wù)路由、流量控制、計(jì)量計(jì)費(fèi)等橫切面功能。

1.2 構(gòu)建反腐層

新特性全部構(gòu)建成了微服務(wù)，但老特性還依舊在單體式應(yīng)用當(dāng)中，許多業(yè)務(wù)還需要新舊系統(tǒng)彼此協(xié)作才能完成，那么微服務(wù)和單體式應(yīng)用之間還存在彼此交互。但新舊系統(tǒng)對外服務(wù)時所采用的協(xié)議可能不同，例如：采用Spring Cloud框架開發(fā)的微服務(wù)主要以RESTful HTTP API對外服務(wù)，采用Dubbo框架開發(fā)的微服務(wù)以Dubbo協(xié)議對外服務(wù)，而單體式應(yīng)用可能以Web Service、EJB T3、不規(guī)范HTTP API等形式對外服務(wù)。除了協(xié)議不同之外，新舊系統(tǒng)對領(lǐng)域模型的定義也可能不同，包括名稱和屬性等，如何調(diào)和微服務(wù)和單體式應(yīng)用的不同呢?

在微服務(wù)和單體式應(yīng)用之間構(gòu)建一道反腐層，這或許是最切實(shí)可行的辦法。通過反腐層完成新舊系統(tǒng)的對接集成，又可以避免舊系統(tǒng)領(lǐng)域模型對新系統(tǒng)的干擾，讓彼此保持松耦合狀態(tài)，阻止舊系統(tǒng)的腐爛蔓延至新系統(tǒng)。反腐層還可以對單體式應(yīng)用進(jìn)行服務(wù)化封裝，讓其像微服務(wù)一樣以RESTful HTTP API的方式對外服務(wù)。反腐層支持雙向通訊，重點(diǎn)解決新舊系統(tǒng)對接集成、協(xié)議適配和模型轉(zhuǎn)換等問題，按照此功能定位我們可以將反腐層劃分成三個模塊：

• 外觀(Facade)，經(jīng)典設(shè)計(jì)模式，作為舊系統(tǒng)所有服務(wù)接口的門面，簡化新舊系統(tǒng)對接的復(fù)雜度;

• 適配器(Adapter)，經(jīng)典設(shè)計(jì)模式，向新系統(tǒng)提供所需的服務(wù)實(shí)體，負(fù)責(zé)請求和應(yīng)答的協(xié)議適配;

• 轉(zhuǎn)換器(Translator)，負(fù)責(zé)請求和應(yīng)答中新舊系統(tǒng)領(lǐng)域模型的轉(zhuǎn)換。

由于單體式應(yīng)用的架構(gòu)較為簡單，因此在設(shè)計(jì)之初它們很少考慮系統(tǒng)集成相關(guān)的設(shè)計(jì)，通常一個應(yīng)用下的不同服務(wù)擁有各自的入口，外觀(Facade)就是解決此問題的，統(tǒng)一單體式應(yīng)用對外服務(wù)的格式，像微服務(wù)一樣以RESTful HTTP API的方式對外服務(wù)，規(guī)范接口的協(xié)議類型、URL命名和報(bào)文格式等。如果舊系統(tǒng)不屬于我們維護(hù)，那反腐層就需要包含F(xiàn)acade模塊，微服務(wù)通過它對接舊系統(tǒng)。如果舊系統(tǒng)也是由我們自己維護(hù)，那建議將Facade模塊構(gòu)建在單體式應(yīng)用內(nèi)部，微服務(wù)通過Adapter模塊對接舊系統(tǒng)。

1.3 圍剿單體式應(yīng)用

在舊系統(tǒng)周邊構(gòu)建微服務(wù)，遏制舊系統(tǒng)的不斷生長，然后再從舊系統(tǒng)逐步剝離出微服務(wù)，最后完成對單體式應(yīng)用的絞殺。優(yōu)良的微服務(wù)設(shè)計(jì)同樣遵循高內(nèi)聚、低耦合原則，將關(guān)聯(lián)緊密的行為封裝進(jìn)一個微服務(wù)當(dāng)中，從而可以減少需求變更所影響的范圍。只要服務(wù)契約不發(fā)生改變，那對單個微服務(wù)的升級改造都不會影響到其他服務(wù)，因此可以發(fā)布更少的服務(wù)來快速地滿足業(yè)務(wù)需求，并降低同時部署多個微服務(wù)時帶來的風(fēng)險(xiǎn)。在從單體式應(yīng)用剝離微服務(wù)之前，我們先看看功能模塊之間的邊界有哪些類型：

• 技術(shù)邊界：將系統(tǒng)按照技術(shù)棧的不同劃分，形成兩個部件的邊界。它們所采用的技術(shù)大相徑庭，對開發(fā)人員的技能要求不同。業(yè)界將此種架構(gòu)叫做洋蔥架構(gòu)，擁有許多水平分層，不利于改造成微服務(wù)。

• 地域邊界：按照組織分布的地域劃分，相對較容易改造成微服務(wù)。

• 業(yè)務(wù)邊界：按照業(yè)務(wù)類型劃分，最適合作為微服務(wù)的邊界類型。

領(lǐng)域驅(qū)動設(shè)計(jì)(DDD)理論提出了有界上下文(Bounded Context)概念，這是我們厘清服務(wù)邊界的有效工具，我們可以借助它從單體式應(yīng)用上剝離微服務(wù)。因此，單體式應(yīng)用的微服務(wù)化改造，亦或新建微服務(wù)，我們都離不開業(yè)務(wù)專家的支持，通過他們確定有界上下文的劃分，從而設(shè)計(jì)出好的微服務(wù)。

2. 隔離網(wǎng)關(guān)接管新舊系統(tǒng)間交互

在前面章節(jié)中我們已經(jīng)知道在微服務(wù)改造過程中需要構(gòu)建反腐層，那在實(shí)際項(xiàng)目當(dāng)中反腐層會以什么樣的形態(tài)存在呢?通常我們會將反腐層設(shè)計(jì)成隔離網(wǎng)關(guān)，以單獨(dú)的進(jìn)程運(yùn)行，在隔離網(wǎng)關(guān)內(nèi)部實(shí)現(xiàn)Facade、Adapter和Translator等功能模塊。隔離網(wǎng)關(guān)不需要從零開始建設(shè)，我們可以在Nginx、Kong、Zuul等開源中間件基礎(chǔ)上擴(kuò)展，它們都支持插件化或過濾器等擴(kuò)展定制模式，我們很容易實(shí)現(xiàn)反腐層需要的功能。

通過反腐層(隔離網(wǎng)關(guān))微服務(wù)可以與單體式應(yīng)用進(jìn)行正常通信，同時彼此之間保持松耦合，單體式應(yīng)用可以不用做傷筋動骨地改動，微服務(wù)可以采用最新的技術(shù)獨(dú)立演進(jìn)，但這種方案下這些遺留的單體式應(yīng)用是無法享受到云原生帶來的好處。有沒有一種方案可以讓這些遺留系統(tǒng)也享受到服務(wù)發(fā)現(xiàn)、流量控制、服務(wù)熔斷、服務(wù)降級等新特性呢?

Service Mesh，下一代微服務(wù)架構(gòu)，可以給我們帶來更加完善的解決方案，它將原先通過微服務(wù)開發(fā)框架(例如：Spring Boot等)侵入到應(yīng)用內(nèi)部的服務(wù)治理等功能模塊封裝進(jìn)了Sidecar，與應(yīng)用結(jié)對部署，作為獨(dú)立的進(jìn)程存在，這樣可以做到與應(yīng)用松耦合，架構(gòu)上更加靈活，可以支持微服務(wù)治理相關(guān)基礎(chǔ)設(shè)施的獨(dú)立升級部署，還可以支持多語言。如果在Sidecar基礎(chǔ)上再擴(kuò)展隔離網(wǎng)關(guān)的功能，那遺留的單體式應(yīng)用也可以更加融入微服務(wù)架構(gòu)了。

3. 單體式應(yīng)用拆解微服務(wù)的方法

本章節(jié)我們將梳理從單體式應(yīng)用剝離微服務(wù)的一些常見場景和方案。在談具體案例之前，我們有必要先了解一下業(yè)界最佳實(shí)踐的經(jīng)驗(yàn)總結(jié)，它主要包含以下幾個基本步驟：

• 識別出某個業(yè)務(wù)板塊的上下文邊界，這是拆解單體式應(yīng)用的關(guān)鍵步驟。微服務(wù)是按照業(yè)務(wù)來劃分和組織的，在動手拆解之前先要理清當(dāng)前一個單體式應(yīng)用提供了哪些業(yè)務(wù)功能，例如：用戶管理、商品展示、支付管理和物流管理等，按照垂直方向劃分出來的功能板塊都可以改造成微服務(wù)。具體操作時大部分編程語言都提供了命名空間(NameSpace)特性，我們在重構(gòu)過程中可以借助它將同一個上下文相關(guān)的代碼歸集在一起，然后從整個工程中將其拆解出來形成微服務(wù)。

• 厘清業(yè)務(wù)功能模塊之間的依賴，盡量減少依賴關(guān)系，從變化頻繁、投入產(chǎn)出比高的模塊開始剝離，這樣可以逐步緩解日常開發(fā)的進(jìn)度壓力。經(jīng)過依賴關(guān)系的梳理，冗余的依賴將會被消除，剩下的依賴將會從進(jìn)程內(nèi)部的函數(shù)調(diào)用改造成進(jìn)程之間的RESTful HTTP API調(diào)用。

• 拆解數(shù)據(jù)，包括數(shù)據(jù)訪問層和數(shù)據(jù)庫表等。除了代碼，數(shù)據(jù)也要被拆解，數(shù)據(jù)訪問層要被打散到不同的命名空間當(dāng)中，數(shù)據(jù)庫表之間的外鍵依賴需要被清理消除等。

從業(yè)務(wù)開始，再到代碼，最后才是數(shù)據(jù)，這就是上述三個步驟的關(guān)鍵。業(yè)務(wù)是所有代碼和數(shù)據(jù)的源頭，面向?qū)ο笤O(shè)計(jì)(OOD)和領(lǐng)域驅(qū)動設(shè)計(jì)(DDD)是做好微服務(wù)設(shè)計(jì)的專業(yè)技能，而用好這兩項(xiàng)技能的前提就是對業(yè)務(wù)有深刻的洞悉，在(下)篇中我們將一起來看看具體的拆解場景，敬請期待!

原創(chuàng)不易，請動動手指點(diǎn)個「  贊  」哦，后續(xù)我會持續(xù)分享職業(yè)規(guī)劃、應(yīng)聘面試、技能提升、影響力打造等經(jīng)驗(yàn)，   關(guān)注「  IT老兵哥 」，賦能程序人生 ！