如何把單體式應用拆解成微服務？【上】

昨日好評博文：《如何設計出優美的Web API？》

截止目前閱讀量近 2000，得到好評無數，小夥伴們不要錯過哦！

 

微服務是當下最流行的應用架構技術了，它跟容器服務、DevOps合稱雲時代的三劍客，能夠幫咱們化解業務發展過快致使的產品迭代壓力，讓咱們能夠自由選擇最適合團隊的技術棧，讓系統可以承載互聯網海量用戶的訪問，讓咱們能夠更加輕鬆地運維大型的互聯網系統。近些年在廠商、社區和用戶等各方努力推進下，微服務相關的理論和產品都日趨成熟，不一樣語言的微服務開發及治理套件（例如：Spring Cloud/Dubbo等）讓咱們從零開始搭建微服務變得很是簡單快捷，那咱們是否就此能夠全面進入微服務時代呢？

微服務的演進成熟須要時間，咱們熟悉掌握這套新技術也須要時間，除此以外機房裏面還跑着大量的單體式應用，它們須要繼續維護和升級，任什麼時候候咱們都不可能拋開歷史輕鬆上陣。這些單體式應用還擔負着公司的核心業務，所有推倒重來、休克式重構是不可取的，投入大週期長，風險徹底不可控。咱們必須學會邊行車邊換胎的技能，在不影響現網業務的前提下推進微服務改造，讓老系統煥發新的生命力，繼續支持業務下一個十年的發展。本文將跟你一塊兒探討微服務改造相關的經驗方法，讓你更加從容地擁抱微服務！

• 1. 邊行車邊換胎三步走演進策略
  

如何從單體式應用演進至微服務呢？這些單體式應用都存在很長時間了，通過這麼長時間的修修補補，體量規模都比較大，尤爲是通過幾波人交接維護，業務邏輯也變得異常複雜。同時，它們都在線對外提供服務，所有推倒重建的可能性微乎其微，休克式重構投入大週期長，風險也很差控制，還會影響業務對外服務的連續性。從現實狀況出發，最可行的架構優化方案就是漸進式的微服務改造，按照業界的最佳實踐和我的經驗，該演進策略主要包括三個關鍵步驟：

• 將全部新特性都構建成微服務，遏制單體式應用的生長；
• 在微服務和單體式應用之間構建反腐層，防止老系統腐化新系統；
• 按照特定的優先順序由外而內逐步瓦解單體式應用。

 

• 1.1 新建微服務

一般單體式應用所採用的技術相對較老舊，維護這些系統的同事缺乏機會學習實踐當前主流的技術，長此以往就跟不上主流技術的發展，在晉升、加薪和跳槽時都缺少競爭力，這會影響到我的的價值。隨着系統規模愈來愈龐大，更新升級和運營維護的難度愈來愈大，每次發版都要加班加點和心驚膽戰，逐漸知足不了業務快速發展的須要。在單體式架構之下，團隊沒法利用不一樣技術棧的優點解決不一樣場景下的問題，即便解決了問題也是事倍功半。

當意識到有必要將單體式應用改形成微服務時，咱們一般會認爲改造就是將單體式應用一塊一塊地敲下來改爲微服務，這種想法是最直接的，但難度和風險也是最大的。改造初始咱們對微服務相關技術也比較生疏，再加上拆解單體式應用自己的難度，雙重困難疊加每每會致使改造失敗或延期。

最靠譜的策略是先中止往單體式應用裏面添加新的特性，全部新特性都構建成微服務，從而遏制單體式應用繼續生長。新特性一般不會太複雜，新建微服務也要比從單體式應用上剝離微服務容易一些，藉助這個過程讓團隊逐漸熟悉掌握微服務技術棧，從小規模練兵再到全面鋪開。常見的微服務架構以下圖所示，主要包含如下幾大必備組件：

• 註冊中心，提供微服務的註冊、發現和狀態監測等功能；
• 配置中心，解耦代碼與配置，經過統一的遠程配置中心管理每一個微服務的配置數據，支持動態修改和當即生效等；
• 治理中心，依賴註冊中心和配置中心，提供服務降級、服務熔斷、流量控制、灰度管理等功能；
• API網關，將每一個微服務匯聚一塊兒對外提供服務，網關自己會提供安全鑑權、服務路由、流量控制、計量計費等橫切面功能。 

• 1.2 構建反腐層

新特性所有構建成了微服務，但老特性還依舊在單體式應用當中，許多業務還須要新舊系統彼此協做才能完成，那麼微服務和單體式應用之間還存在彼此交互。但新舊系統對外服務時所採用的協議可能不一樣，例如：採用Spring Cloud框架開發的微服務主要以RESTful HTTP API對外服務，採用Dubbo框架開發的微服務以Dubbo協議對外服務，而單體式應用可能以Web Service、EJB T三、不規範HTTP API等形式對外服務。除了協議不一樣以外，新舊系統對領域模型的定義也可能不一樣，包括名稱和屬性等，如何調和微服務和單體式應用的不一樣呢？

在微服務和單體式應用之間構建一道反腐層，這或許是最切實可行的辦法。經過反腐層完成新舊系統的對接集成，又能夠避免舊系統領域模型對新系統的干擾，讓彼此保持鬆耦合狀態，阻止舊系統的腐爛蔓延至新系統。反腐層還能夠對單體式應用進行服務化封裝，讓其像微服務同樣以RESTful HTTP API的方式對外服務。反腐層支持雙向通信，重點解決新舊系統對接集成、協議適配和模型轉換等問題，按照此功能定位咱們能夠將反腐層劃分紅三個模塊：

• 外觀（Facade），經典設計模式，做爲舊系統全部服務接口的門面，簡化新舊系統對接的複雜度；
• 適配器（Adapter），經典設計模式，向新系統提供所需的服務實體，負責請求和應答的協議適配；
• 轉換器（Translator），負責請求和應答中新舊系統領域模型的轉換。

因爲單體式應用的架構較爲簡單，所以在設計之初它們不多考慮系統集成相關的設計，一般一個應用下的不一樣服務擁有各自的入口，外觀（Facade）就是解決此問題的，統一單體式應用對外服務的格式，像微服務同樣以RESTful HTTP API的方式對外服務，規範接口的協議類型、URL命名和報文格式等。若是舊系統不屬於咱們維護，那反腐層就須要包含Facade模塊，微服務經過它對接舊系統。若是舊系統也是由咱們本身維護，那建議將Facade模塊構建在單體式應用內部，微服務經過Adapter模塊對接舊系統。

• 1.3 圍剿單體式應用

在舊系統周邊構建微服務，遏制舊系統的不斷生長，而後再從舊系統逐步剝離出微服務，最後完成對單體式應用的絞殺。優良的微服務設計一樣遵循高內聚、低耦合原則，將關聯緊密的行爲封裝進一個微服務當中，從而能夠減小需求變動所影響的範圍。只要服務契約不發生改變，那對單個微服務的升級改造都不會影響到其餘服務，所以能夠發佈更少的服務來快速地知足業務需求，並下降同時部署多個微服務時帶來的風險。在從單體式應用剝離微服務以前，咱們先看看功能模塊之間的邊界有哪些類型：

• 技術邊界：將系統按照技術棧的不一樣劃分，造成兩個部件的邊界。它們所採用的技術截然不同，對開發人員的技能要求不一樣。業界將此種架構叫作洋蔥架構，擁有許多水平分層，不利於改形成微服務。
• 地域邊界：按照組織分佈的地域劃分，相對較容易改形成微服務。
• 業務邊界：按照業務類型劃分，最適合做爲微服務的邊界類型。

領域驅動設計（DDD）理論提出了有界上下文（Bounded Context）概念，這是咱們釐清服務邊界的有效工具，咱們能夠藉助它從單體式應用上剝離微服務。所以，單體式應用的微服務化改造，亦或新建微服務，咱們都離不開業務專家的支持，經過他們肯定有界上下文的劃分，從而設計出好的微服務。

• 2. 隔離網關接管新舊系統間交互

在前面章節中咱們已經知道在微服務改造過程當中須要構建反腐層，那在實際項目當中反腐層會以什麼樣的形態存在呢？一般咱們會將反腐層設計成隔離網關，以單獨的進程運行，在隔離網關內部實現Facade、Adapter和Translator等功能模塊。隔離網關不須要從零開始建設，咱們能夠在Nginx、Kong、Zuul等開源中間件基礎上擴展，它們都支持插件化或過濾器等擴展定製模式，咱們很容易實現反腐層須要的功能。

經過反腐層（隔離網關）微服務能夠與單體式應用進行正常通訊，同時彼此之間保持鬆耦合，單體式應用能夠不用作傷筋動骨地改動，微服務能夠採用最新的技術獨立演進，但這種方案下這些遺留的單體式應用是沒法享受到雲原生帶來的好處。有沒有一種方案可讓這些遺留系統也享受到服務發現、流量控制、服務熔斷、服務降級等新特性呢？

Service Mesh，下一代微服務架構，能夠給咱們帶來更加完善的解決方案，它將原先經過微服務開發框架（例如：Spring Boot等）侵入到應用內部的服務治理等功能模塊封裝進了Sidecar，與應用結對部署，做爲獨立的進程存在，這樣能夠作到與應用鬆耦合，架構上更加靈活，能夠支持微服務治理相關基礎設施的獨立升級部署，還能夠支持多語言。若是在Sidecar基礎上再擴展隔離網關的功能，那遺留的單體式應用也能夠更加融入微服務架構了。

 

• 3. 單體式應用拆解微服務的方法
  

本章節咱們將梳理從單體式應用剝離微服務的一些常見場景和方案。在談具體案例以前，咱們有必要先了解一下業界最佳實踐的經驗總結，它主要包含如下幾個基本步驟：

• 識別出某個業務板塊的上下文邊界，這是拆解單體式應用的關鍵步驟。微服務是按照業務來劃分和組織的，在動手拆解以前先要理清當前一個單體式應用提供了哪些業務功能，例如：用戶管理、商品展現、訂單管理、支付管理和物流管理等，按照垂直方向劃分出來的功能板塊均可以改形成微服務。具體操做時大部分編程語言都提供了命名空間（NameSpace）特性，咱們在重構過程當中能夠藉助它將同一個上下文相關的代碼歸集在一塊兒，而後從整個工程中將其拆解出來造成微服務。
• 釐清業務功能模塊之間的依賴，儘可能減小依賴關係，從變化頻繁、投入產出比高的模塊開始剝離，這樣能夠逐步緩解平常開發的進度壓力。通過依賴關係的梳理，冗餘的依賴將會被消除，剩下的依賴將會從進程內部的函數調用改形成進程之間的RESTful HTTP API調用。
• 拆解數據，包括數據訪問層和數據庫表等。除了代碼，數據也要被拆解，數據訪問層要被打散到不一樣的命名空間當中，數據庫表之間的外鍵依賴須要被清理消除等。

從業務開始，再到代碼，最後纔是數據，這就是上述三個步驟的關鍵。業務是全部代碼和數據的源頭，面向對象設計（OOD）和領域驅動設計（DDD）是作好微服務設計的專業技能，而用好這兩項技能的前提就是對業務有深入的洞悉，在（下）篇中咱們將一塊兒來看看具體的拆解場景，敬請期待！今天先分享到這裏，若是你以爲有價值，麻煩動動手指點下文 「 推薦 」按鈕，讓更多小夥伴能夠看到，我也會更加有動力堅持分享。另外，老兵哥我後續還會分享職業規劃、應聘面試、技能提高、影響力打造等經驗，歡迎 關注 本專欄或歪信公主號 「 IT老兵哥 」！

關注「 IT老兵哥 」，賦能程序人生！

• 軟技能類熱點文章：

1. 「花式」裁人套路深，你知道嗎？
2. 遭遇裁人，如何渡過心理危機？
3. 如何在寒冬中找到好工做？
4. 2C 仍是 2B，跟找工做有什麼關係？
5. 大公司 vs 小公司，你會選哪一個？
6. 記住這一點，不怕找不到好工做！
7. 跳槽，跳仍是不跳，該怎麼跳？
8. 程序員「求包養」攻略揭祕
9. 很努力了，爲何我還在原地踏步？

 

• 硬技能類熱點文章：

1. 如何設計出優美的Web API？
2. 程序員必須懂的架構入門課
3. 從程序員到架構師，有捷徑嗎？
4. 圖解 Spring：HTTP 請求的處理流程與機制【1】
5. 圖解 Spring：HTTP 請求的處理流程與機制【2】
6. 圖解 Spring：HTTP 請求的處理流程與機制【3】
7. 圖解 Spring：HTTP 請求的處理流程與機制【4】
8. 圖解 Spring：HTTP 請求的處理流程與機制【5】
9. 如何正確使用 Spring Cloud？【上】
10. 如何正確使用 Spring Cloud？【中】
11. 如何正確使用 Spring Cloud？【下】
12. Spring 核心技術與產品理念剖析【上】
13. Spring 核心技術與產品理念剖析【下】