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

舒適提示：同步在其餘平臺發佈的熱評好文：如何設計出優美的Web API？，現閱讀量超過了2400，小夥伴們千萬不要錯過哦！Segmentfault 地址：如何設計出優美的Web API？

緊接昨天的上篇：如何把單體式應用拆解成微服務？【上】，今天咱們一塊兒來看看各類具體拆解場景的解決方案：

場景1：數據庫表外鍵引用關係

若是單體式應用中兩個功能模塊存在數據引用關係，那咱們在拆解微服務時如何消除這種外鍵引用關係呢？首先，停⽌外鍵引⽤；而後，改爲經過RESTful HTTP API⽅式獲取原先外鍵關聯的信息。以下圖，改造前Payment數據庫表中的記錄經過外鍵引用Order，代碼層面一般會藉助對象關係映射（ORM）框架創建數據對象的關聯，改造後代碼層面就不能經過ORM框架作關聯了。在Payment數據庫表的記錄中會保存Order的主鍵值，除此以外還會保存Order的關鍵屬性信息，這樣能夠避免頻繁的跨進程調用，從而能夠提升系統的總體效率表現。

下圖是改造前的狀況：

下圖是改造後的狀況：

場景2：共享靜態數據關係

若是單體式應用中兩個功能模塊彼此共享靜態數據，那咱們在拆解微服務時如何消除這種共享關係呢？靜態數據一般存儲在數據庫當中，例如：商品類目代號。若是這些靜態數據須要更新，那咱們就須要頻繁地發佈系統，這樣會致使多個服務的中斷。

爲了不這個問題，咱們也能夠將這些靜態數據拷貝多份，分別⽤於每一個服務，但維護多份數據拷⻉的一致性是個問題。另外，咱們也能夠將這些靜態數據存⼊每一個服務的配置文件，下降更新數據的難度。統一配置中心，微服務架構中的必選組件，咱們能夠經過它來管理這些靜態數據，這樣在維護更新上會帶來極大的便利。

場景3：共享基礎數據關係

若是單體式應用中兩個功能模塊共享某類基礎數據，那咱們在拆解微服務時如何消除這種共享關係呢？多個服務共享某類基礎數據，例如：用戶數據、物流公司數據等等，那咱們要爲這類數據提煉出專門的領域模型，將它封裝成微服務，而後經過該服務來訪問這些共享的基礎數據。服務化帶來的好處就是彼此之間僅僅依賴服務契約，雙方具體採用什麼技術和方案都是自由的。只要服務契約沒有改變，那彼此的升級改造就不會影響。

下圖是改造前的狀況：

下圖是改造後的狀況：

場景4：共享數據庫表格

若是單體式應用中兩個功能模塊共享一張數據表格，那咱們在拆解微服務時如何消除這種共享關係呢？多個服務各自引⽤的數據被合併存儲在一張數據庫表當中，代碼層面藉助ORM框架實現多態，這種狀況咱們須要將每一個服務所關注的數據剝離出來，分別存到不一樣的表格當中。

下圖是改造前的狀況：

下圖是改造後的狀況：

場景5：共享數據庫

在拆解微服務過程當中，咱們該如何拆分數據庫呢？最穩妥的方案就是分階段重構數據庫，數據是最寶貴的資源，咱們不要貪圖一步到位。

下圖是改造前的狀況：

• 第一步，按照業務上下文先將一個數據庫拆解成兩個數據庫，但應用仍然是單體式應用，經過多數據源相關技術應用能夠同時訪問兩個數據庫，以下圖所示：

• 第二步，將單體式應用拆解成微服務，每一個微服務都有各自獨立的數據庫，以下圖所示：

舊模塊微服務改造優先級原則

從單體式應用中劃分出有界的上下文，做爲剝離微服務的候選，而後開始依次重構每一個功能模塊。那如何判斷哪些模塊應該優先被剝離成微服務呢？從模塊剝離難度看，咱們能夠遵循先易後難的原則，逐步積累重構經驗，這適用於在微服務構建方面經驗不太豐富的團隊；從需求變化頻率看，優先剝離那些變動頻繁的模塊，總體收益會更大一些，這對於人力資源較爲緊張的團隊不失爲一個好的判斷準則；從資源消耗類型看，那些計算或內存密集的模塊適合優先剝離，這樣有利於彈性伸縮時提高資源利用效率，這對系統規模較大的場景效果最明顯；從服務邊界粒度看，粒度越粗越好剝離。具體按哪一個規則來安排微服務的改造順序，這就要根據每一個團隊的具體狀況來具體分析了。

咱們在支持不一樣系統實施微服務改造的過程當中，上述優先級原則都被採用過，優先級存在的緣由就是資源不夠。微服務改造不是一蹴而就的事情，這個過程會持續很長時間，可能跨度幾年，在不一樣階段須要考慮的問題也就不一樣，最核心的原則就是按照適合本身的節奏有條不紊地開展工做，在確保線上業務穩定的前提下適當地追求速度。

微服務改造是否結束判斷標準

那何時纔算完成微服務改造呢？判斷標準就是舊系統中所有有界上下文都被剝離成微服務，此時反腐層就能夠被廢除了；或者遺留的單體式應用相對較穩定，再也不發生變化，重構的投入產出比再也不划算；或者遺留的單體式應用關聯業務已經退出市場了，系統下線了。

微服務架構新挑戰與解決方案

當單體式應用被拆解成多個微服務以後，原先在一個事務邊界內的操做如今要跨多個事務邊界了，咱們如何保證事務的一致性呢？下面是一些分佈式事務機制：

• 再次嘗試，最終一致：將每一個操做步驟放⼊隊列排隊，後續再次嘗試，確保最後執行成功，狀態達成⼀致。
• 撤銷所有操做：補償事務機制，原事務操做失敗以後，啓動一個新的事務去撤銷以前的操做。若是補償事務也失敗了，那系統須要提供手動或自動再次運⾏補償事務的功能。
• 分佈式事務：經過一個全局事務管理器來協調各個事務得以成功執行。對於短時間事務，一般採用兩階段提交（Two-Phase Commit），第一階段是投票階段，分佈式事務的參與者告訴事務管理器，判斷本地事務是否能夠順利執行。若是事務管理器收集到全部投票結果都是YES，那就開始提交事務執行。

分佈式事務機制自己不算太複雜，咱們借鑑業界的一些開源產品自研了一套分佈式事務框架，跟微服務框架結合起來，應用開發者只須要按照框架的約定實現特定的接口，經過一些註解就能夠發起分佈式事務，相關細節能夠參考阿里的全局事務服務GTS。

當單體式應用被拆解成多個微服務以後，原先集中存儲的數據也被分開存儲了，報表生成將會遇到新的挑戰。在單體式應⽤狀況下，一般有一個用於生成報表的從庫，從主庫同步數據，僅⽤於查詢等讀操做，避免⽣成報表過程影響主庫的讀寫效率。在微服務狀況下，咱們將要經過服務調用來獲取數據，設計適合報表統計的批量接口，以及增長緩存用於提高數據獲取效率。

• 數據抽取：經過服務調⽤來獲取報表所需數據，這會形成很是⼤的負載，以及專⻔爲報表設計的API。爲了彌補上述不足，咱們能夠將數據抽取程序獨立出來，專門從業務數據庫中抽取數據到報表數據庫。
• 事件驅動數據抽取：基於事件驅動的微服務架構，咱們能夠開發特定事件的訂閱者，負責將數據同步到報表數據庫，這樣能夠解耦底層數據庫系統。

微服務改造是一個長期過程，這個過程會遇到各式各樣的問題，方法論能夠幫助咱們更好地解決這些問題，而且下降風險。歡迎你們一塊兒探討微服務改造過程當中遇到的任何問題！

今天先分享到這裏，若是你以爲有價值，麻煩動動手指點下文 「點贊 」按鈕，讓更多小夥伴能夠看到，我也會更加有動力堅持分享。另外，老兵哥我後續還會分享職業規劃、應聘面試、技能提高、影響力打造等經驗，歡迎 關注 本專欄或公衆號「IT老兵哥」，賦能程序人生！

• 軟技能-熱點文章：（均發佈於公衆號）

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

• 硬技能-熱點文章：

1. 如何設計出優美的Web API？
2. 如何寫出好的產品幫助文檔？
3. 圖解 Spring：HTTP 請求的處理流程與機制【1】
4. 圖解 Spring：HTTP 請求的處理流程與機制【2】
5. 圖解 Spring：HTTP 請求的處理流程與機制【3】
6. 圖解 Spring：HTTP 請求的處理流程與機制【4】
7. 如何正確使用 Spring Cloud？【上】
8. 如何正確使用 Spring Cloud？【下】
9. Spring 核心技術與產品理念剖析【上】
10. Spring 核心技術與產品理念剖析【下】