微服務(wù)是當(dāng)下最流行的應(yīng)用架構(gòu)技術(shù)了，它跟容器服務(wù)、DevOps合稱云時(shí)代的三劍客，可以幫我們化解業(yè)務(wù)發(fā)展過(guò)快導(dǎo)致的產(chǎn)品迭代壓力，讓我們可以自由選擇最適合團(tuán)隊(duì)的技術(shù)棧，讓系統(tǒng)能夠承載互聯(lián)網(wǎng)海量用戶的訪問，讓我們可以更加輕松地運(yùn)維大型的互聯(lián)網(wǎng)系統(tǒng)。近些年在廠商、社區(qū)和用戶等各方努力推動(dòng)下，微服務(wù)相關(guān)的理論和產(chǎn)品都日趨成熟，不同語(yǔ)言的微服務(wù)開發(fā)及治理套件(例如：Spring Cloud/Dubbo等)讓我們從零開始搭建微服務(wù)變得非常簡(jiǎn)單快捷，那我們是否就此可以全面進(jìn)入微服務(wù)時(shí)代呢?
微服務(wù)的演進(jìn)成熟需要時(shí)間，我們熟悉掌握這套新技術(shù)也需要時(shí)間，除此之外機(jī)房里面還跑著大量的單體式應(yīng)用，它們需要繼續(xù)維護(hù)和升級(jí)，任何時(shí)候我們都不可能拋開歷史輕松上陣。這些單體式應(yīng)用還擔(dān)負(fù)著公司的核心業(yè)務(wù)，全部推倒重來(lái)、休克式重構(gòu)是不可取的，投入大周期長(zhǎng)，風(fēng)險(xiǎn)完全不可控。我們必須學(xué)會(huì)邊行車邊換胎的技能，在不影響現(xiàn)網(wǎng)業(yè)務(wù)的前提下推動(dòng)微服務(wù)改造，讓老系統(tǒng)煥發(fā)新的生命力，繼續(xù)支持業(yè)務(wù)下一個(gè)十年的發(fā)展。本文將跟你一起探討微服務(wù)改造相關(guān)的經(jīng)驗(yàn)方法，讓你更加從容地?fù)肀⒎?wù)!
如何從單體式應(yīng)用演進(jìn)至微服務(wù)呢?這些單體式應(yīng)用都存在很長(zhǎng)時(shí)間了，經(jīng)過(guò)這么長(zhǎng)時(shí)間的修修補(bǔ)補(bǔ)，體量規(guī)模都比較大，尤其是經(jīng)過(guò)幾波人交接維護(hù)，業(yè)務(wù)邏輯也變得異常復(fù)雜。同時(shí)，它們都在線對(duì)外提供服務(wù)，全部推倒重建的可能性微乎其微，休克式重構(gòu)投入大周期長(zhǎng)，風(fēng)險(xiǎn)也不好控制，還會(huì)影響業(yè)務(wù)對(duì)外服務(wù)的連續(xù)性。從現(xiàn)實(shí)情況出發(fā)，最可行的架構(gòu)優(yōu)化方案就是漸進(jìn)式的微服務(wù)改造，按照業(yè)界的最佳實(shí)踐和個(gè)人經(jīng)驗(yàn)，該演進(jìn)策略主要包括三個(gè)關(guān)鍵步驟：
將所有新特性都構(gòu)建成微服務(wù)，遏制單體式應(yīng)用的生長(zhǎng);
在微服務(wù)和單體式應(yīng)用之間構(gòu)建反腐層，防止老系統(tǒng)腐化新系統(tǒng);
按照特定的優(yōu)先順序由外而內(nèi)逐步瓦解單體式應(yīng)用。
通常單體式應(yīng)用所采用的技術(shù)相對(duì)較老舊，維護(hù)這些系統(tǒng)的同事缺少機(jī)會(huì)學(xué)習(xí)實(shí)踐當(dāng)前主流的技術(shù)，久而久之就跟不上主流技術(shù)的發(fā)展，在晉升、加薪和跳槽時(shí)都缺乏競(jìng)爭(zhēng)力，這會(huì)影響到個(gè)人的價(jià)值。隨著系統(tǒng)規(guī)模越來(lái)越龐大，更新升級(jí)和運(yùn)營(yíng)維護(hù)的難度越來(lái)越大，每次發(fā)版都要加班加點(diǎn)和心驚膽戰(zhàn)，逐漸滿足不了業(yè)務(wù)快速發(fā)展的需要。在單體式架構(gòu)之下，團(tuán)隊(duì)無(wú)法利用不同技術(shù)棧的優(yōu)勢(shì)解決不同場(chǎng)景下的問題，即使解決了問題也是事倍功半。
當(dāng)意識(shí)到有必要將單體式應(yīng)用改造成微服務(wù)時(shí)，我們通常會(huì)認(rèn)為改造就是將單體式應(yīng)用一塊一塊地敲下來(lái)改成微服務(wù)，這種想法是最直接的，但難度和風(fēng)險(xiǎn)也是大的。改造初始我們對(duì)微服務(wù)相關(guān)技術(shù)也比較生疏，再加上拆解單體式應(yīng)用本身的難度，雙重困難疊加往往會(huì)導(dǎo)致改造失敗或延期。
最靠譜的策略是先停止往單體式應(yīng)用里面添加新的特性，所有新特性都構(gòu)建成微服務(wù)，從而遏制單體式應(yīng)用繼續(xù)生長(zhǎng)。新特性通常不會(huì)太復(fù)雜，新建微服務(wù)也要比從單體式應(yīng)用上剝離微服務(wù)容易一些，借助這個(gè)過(guò)程讓團(tuán)隊(duì)逐漸熟悉掌握微服務(wù)技術(shù)棧，從小規(guī)模練兵再到全面鋪開。常見的微服務(wù)架構(gòu)如下圖所示，主要包含以下幾大必備組件：
注冊(cè)中心，提供微服務(wù)的注冊(cè)、發(fā)現(xiàn)和狀態(tài)監(jiān)測(cè)等功能;
配置中心，解耦代碼與配置，通過(guò)統(tǒng)一的遠(yuǎn)程配置中心管理每個(gè)微服務(wù)的配置數(shù)據(jù)，支持動(dòng)態(tài)修改和立即生效等;
治理中心，依賴注冊(cè)中心和配置中心，提供服務(wù)降級(jí)、服務(wù)熔斷、流量控制、灰度管理等功能;
API網(wǎng)關(guān)，將每個(gè)微服務(wù)匯聚一起對(duì)外提供服務(wù)，網(wǎng)關(guān)本身會(huì)提供安全鑒權(quán)、服務(wù)路由、流量控制、計(jì)量計(jì)費(fèi)等橫切面功能。
新特性全部構(gòu)建成了微服務(wù)，但老特性還依舊在單體式應(yīng)用當(dāng)中，許多業(yè)務(wù)還需要新舊系統(tǒng)彼此協(xié)作才能完成，那么微服務(wù)和單體式應(yīng)用之間還存在彼此交互。但新舊系統(tǒng)對(duì)外服務(wù)時(shí)所采用的協(xié)議可能不同，例如：采用Spring Cloud框架開發(fā)的微服務(wù)主要以RESTful HTTP API對(duì)外服務(wù)，采用Dubbo框架開發(fā)的微服務(wù)以Dubbo協(xié)議對(duì)外服務(wù)，而單體式應(yīng)用可能以Web Service、EJB T3、不規(guī)范HTTP API等形式對(duì)外服務(wù)。除了協(xié)議不同之外，新舊系統(tǒng)對(duì)領(lǐng)域模型的定義也可能不同，包括名稱和屬性等，如何調(diào)和微服務(wù)和單體式應(yīng)用的不同呢?
在微服務(wù)和單體式應(yīng)用之間構(gòu)建一道反腐層，這或許是最切實(shí)可行的辦法。通過(guò)反腐層完成新舊系統(tǒng)的對(duì)接集成，又可以避免舊系統(tǒng)領(lǐng)域模型對(duì)新系統(tǒng)的干擾，讓彼此保持松耦合狀態(tài)，阻止舊系統(tǒng)的腐爛蔓延至新系統(tǒng)。反腐層還可以對(duì)單體式應(yīng)用進(jìn)行服務(wù)化封裝，讓其像微服務(wù)一樣以RESTful HTTP API的方式對(duì)外服務(wù)。反腐層支持雙向通訊，重點(diǎn)解決新舊系統(tǒng)對(duì)接集成、協(xié)議適配和模型轉(zhuǎn)換等問題，按照此功能定位我們可以將反腐層劃分成三個(gè)模塊：
外觀(Facade)，經(jīng)典設(shè)計(jì)模式，作為舊系統(tǒng)所有服務(wù)接口的門面，簡(jiǎn)化新舊系統(tǒng)對(duì)接的復(fù)雜度;
適配器(Adapter)，經(jīng)典設(shè)計(jì)模式，向新系統(tǒng)提供所需的服務(wù)實(shí)體，負(fù)責(zé)請(qǐng)求和應(yīng)答的協(xié)議適配;
轉(zhuǎn)換器(Translator)，負(fù)責(zé)請(qǐng)求和應(yīng)答中新舊系統(tǒng)領(lǐng)域模型的轉(zhuǎn)換。
由于單體式應(yīng)用的架構(gòu)較為簡(jiǎn)單，因此在設(shè)計(jì)之初它們很少考慮系統(tǒng)集成相關(guān)的設(shè)計(jì)，通常一個(gè)應(yīng)用下的不同服務(wù)擁有各自的入口，外觀(Facade)就是解決此問題的，統(tǒng)一單體式應(yīng)用對(duì)外服務(wù)的格式，像微服務(wù)一樣以RESTful HTTP API的方式對(duì)外服務(wù)，規(guī)范接口的協(xié)議類型、URL命名和報(bào)文格式等。如果舊系統(tǒng)不屬于我們維護(hù)，那反腐層就需要包含F(xiàn)acade模塊，微服務(wù)通過(guò)它對(duì)接舊系統(tǒng)。如果舊系統(tǒng)也是由我們自己維護(hù)，那建議將Facade模塊構(gòu)建在單體式應(yīng)用內(nèi)部，微服務(wù)通過(guò)Adapter模塊對(duì)接舊系統(tǒng)。
在舊系統(tǒng)周邊構(gòu)建微服務(wù)，遏制舊系統(tǒng)的不斷生長(zhǎng)，然后再?gòu)呐f系統(tǒng)逐步剝離出微服務(wù)，最后完成對(duì)單體式應(yīng)用的絞殺。優(yōu)良的微服務(wù)設(shè)計(jì)同樣遵循高內(nèi)聚、低耦合原則，將關(guān)聯(lián)緊密的行為封裝進(jìn)一個(gè)微服務(wù)當(dāng)中，從而可以減少需求變更所影響的范圍。只要服務(wù)契約不發(fā)生改變，那對(duì)單個(gè)微服務(wù)的升級(jí)改造都不會(huì)影響到其他服務(wù)，因此可以發(fā)布更少的服務(wù)來(lái)快速地滿足業(yè)務(wù)需求，并降低同時(shí)部署多個(gè)微服務(wù)時(shí)帶來(lái)的風(fēng)險(xiǎn)。在從單體式應(yīng)用剝離微服務(wù)之前，我們先看看功能模塊之間的邊界有哪些類型：
技術(shù)邊界：將系統(tǒng)按照技術(shù)棧的不同劃分，形成兩個(gè)部件的邊界。它們所采用的技術(shù)大相徑庭，對(duì)開發(fā)人員的技能要求不同。業(yè)界將此種架構(gòu)叫做洋蔥架構(gòu)，擁有許多水平分層，不利于改造成微服務(wù)。
地域邊界：按照組織分布的地域劃分，相對(duì)較容易改造成微服務(wù)。
業(yè)務(wù)邊界：按照業(yè)務(wù)類型劃分，最適合作為微服務(wù)的邊界類型。
領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(DDD)理論提出了有界上下文(Bounded Context)概念，這是我們厘清服務(wù)邊界的有效工具，我們可以借助它從單體式應(yīng)用上剝離微服務(wù)。因此，單體式應(yīng)用的微服務(wù)化改造，亦或新建微服務(wù)，我們都離不開業(yè)務(wù)專家的支持，通過(guò)他們確定有界上下文的劃分，從而設(shè)計(jì)出好的微服務(wù)。
在前面章節(jié)中我們已經(jīng)知道在微服務(wù)改造過(guò)程中需要構(gòu)建反腐層，那在實(shí)際項(xiàng)目當(dāng)中反腐層會(huì)以什么樣的形態(tài)存在呢?通常我們會(huì)將反腐層設(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ò)展，它們都支持插件化或過(guò)濾器等擴(kuò)展定制模式，我們很容易實(shí)現(xiàn)反腐層需要的功能。
通過(guò)反腐層(隔離網(wǎng)關(guān))微服務(wù)可以與單體式應(yīng)用進(jìn)行正常通信，同時(shí)彼此之間保持松耦合，單體式應(yīng)用可以不用做傷筋動(dòng)骨地改動(dòng)，微服務(wù)可以采用最新的技術(shù)獨(dú)立演進(jìn)，但這種方案下這些遺留的單體式應(yīng)用是無(wú)法享受到云原生帶來(lái)的好處。有沒有一種方案可以讓這些遺留系統(tǒng)也享受到服務(wù)發(fā)現(xiàn)、流量控制、服務(wù)熔斷、服務(wù)降級(jí)等新特性呢?
Service Mesh，下一代微服務(wù)架構(gòu)，可以給我們帶來(lái)更加完善的解決方案，它將原先通過(guò)微服務(wù)開發(fā)框架(例如：Spring Boot等)侵入到應(yīng)用內(nèi)部的服務(wù)治理等功能模塊封裝進(jìn)了Sidecar，與應(yīng)用結(jié)對(duì)部署，作為獨(dú)立的進(jìn)程存在，這樣可以做到與應(yīng)用松耦合，架構(gòu)上更加靈活，可以支持微服務(wù)治理相關(guān)基礎(chǔ)設(shè)施的獨(dú)立升級(jí)部署，還可以支持多語(yǔ)言。如果在Sidecar基礎(chǔ)上再擴(kuò)展隔離網(wǎng)關(guān)的功能，那遺留的單體式應(yīng)用也可以更加融入微服務(wù)架構(gòu)了。
本章節(jié)我們將梳理從單體式應(yīng)用剝離微服務(wù)的一些常見場(chǎng)景和方案。在談具體案例之前，我們有必要先了解一下業(yè)界最佳實(shí)踐的經(jīng)驗(yàn)總結(jié)，它主要包含以下幾個(gè)基本步驟：
識(shí)別出某個(gè)業(yè)務(wù)板塊的上下文邊界，這是拆解單體式應(yīng)用的關(guān)鍵步驟。微服務(wù)是按照業(yè)務(wù)來(lái)劃分和組織的，在動(dòng)手拆解之前先要理清當(dāng)前一個(gè)單體式應(yīng)用提供了哪些業(yè)務(wù)功能，例如：用戶管理、商品展示、支付管理和物流管理等，按照垂直方向劃分出來(lái)的功能板塊都可以改造成微服務(wù)。具體操作時(shí)大部分編程語(yǔ)言都提供了命名空間(NameSpace)特性，我們?cè)谥貥?gòu)過(guò)程中可以借助它將同一個(gè)上下文相關(guān)的代碼歸集在一起，然后從整個(gè)工程中將其拆解出來(lái)形成微服務(wù)。
厘清業(yè)務(wù)功能模塊之間的依賴，盡量減少依賴關(guān)系，從變化頻繁、投入產(chǎn)出比高的模塊開始剝離，這樣可以逐步緩解日常開發(fā)的進(jìn)度壓力。經(jīng)過(guò)依賴關(guān)系的梳理，冗余的依賴將會(huì)被消除，剩下的依賴將會(huì)從進(jìn)程內(nèi)部的函數(shù)調(diào)用改造成進(jìn)程之間的RESTful HTTP API調(diào)用。
拆解數(shù)據(jù)，包括數(shù)據(jù)訪問層和數(shù)據(jù)庫(kù)表等。除了代碼，數(shù)據(jù)也要被拆解，數(shù)據(jù)訪問層要被打散到不同的命名空間當(dāng)中，數(shù)據(jù)庫(kù)表之間的外鍵依賴需要被清理消除等。
從業(yè)務(wù)開始，再到代碼，最后才是數(shù)據(jù)，這就是上述三個(gè)步驟的關(guān)鍵。業(yè)務(wù)是所有代碼和數(shù)據(jù)的源頭，面向?qū)ο笤O(shè)計(jì)(OOD)和領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(DDD)是做好微服務(wù)設(shè)計(jì)的專業(yè)技能，而用好這兩項(xiàng)技能的前提就是對(duì)業(yè)務(wù)有深刻的洞悉，在(下)篇中我們將一起來(lái)看看具體的拆解場(chǎng)景，敬請(qǐng)期待!
原創(chuàng)不易，請(qǐng)動(dòng)動(dòng)手指點(diǎn)個(gè)「 贊 」哦，后續(xù)我會(huì)持續(xù)分享職業(yè)規(guī)劃、應(yīng)聘面試、技能提升、影響力打造等經(jīng)驗(yàn)， 關(guān)注「 IT老兵哥」，賦能程序人生 ！
重慶分公司
重慶分公司
