熱評博文：《如何設計出優美的Web API？》，現閱讀量超 2300，小伙伴們不要錯過哦！
緊接昨天的上篇《如何把單體式應用拆解成微服務？【上】》，今天我們一起來看看具體的拆解場景：
- 場景1：資料庫表外鍵參考關系
如果單體式應用中兩個功能模塊存在資料參考關系，那我們在拆解微服務時如何消除這種外鍵參考關系呢？首先，停?外鍵引?；然后，改成通過RESTful HTTP API?式獲取原先外鍵關聯的資訊，如下圖，改造前Payment資料庫表中的記錄通過外鍵參考Order，代碼層面通常會借助物件關系映射（ORM）框架建立資料物件的關聯，改造后代碼層面就不能通過ORM框架做關聯了，在Payment資料庫表的記錄中會保存Order的主鍵值，除此之外還會保存Order的關鍵屬性資訊，這樣可以避免頻繁的跨行程呼叫，從而可以提高系統的整體效率表現，
下圖是改造前的情況：
下圖是改造后的情況：
- 場景2：共享靜態資料關系
如果單體式應用中兩個功能模塊彼此共享靜態資料，那我們在拆解微服務時如何消除這種共享關系呢？靜態資料通常存盤在資料庫當中，例如：商品類目代號，如果這些靜態資料需要更新，那我們就需要頻繁地發布系統，這樣會導致多個服務的中斷，
為了避免這個問題，我們也可以將這些靜態資料拷貝多份，分別?于每個服務，但維護多份資料拷?的一致性是個問題，另外，我們也可以將這些靜態資料存?每個服務的組態檔，降低更新資料的難度，統一配置中心，微服務架構中的必選組件，我們可以通過它來管理這些靜態資料，這樣在維護更新上會帶來極大的便利，
- 場景3：共享基礎資料關系
如果單體式應用中兩個功能模塊共享某類基礎資料，那我們在拆解微服務時如何消除這種共享關系呢？多個服務共享某類基礎資料，例如：用戶資料、物流公司資料等等，那我們要為這類資料提煉出專門的領域模型，將它封裝成微服務，然后通過該服務來訪問這些共享的基礎資料，服務化帶來的好處就是彼此之間僅僅依賴服務契約，雙方具體采用什么技術和方案都是自由的，只要服務契約沒有改變，那彼此的升級改造就不會影響，
下圖是改造前的情況：
下圖是改造后的情況：
- 場景4：共享資料庫表格
如果單體式應用中兩個功能模塊共享一張資料表格，那我們在拆解微服務時如何消除這種共享關系呢？多個服務各自引?的資料被合并存盤在一張資料庫表當中，代碼層面借助ORM框架實作多型，這種情況我們需要將每個服務所關注的資料剝離出來，分別存到不同的表格當中，
下圖是改造前的情況：
下圖是改造后的情況：
- 場景5：共享資料庫
在拆解微服務程序中，我們該如何拆分資料庫呢？最穩妥的方案就是分階段重構資料庫，資料是最寶貴的資源，我們不要貪圖一步到位，
下圖是改造前的情況：
- 第一步，按照業務背景關系先將一個資料庫拆解成兩個資料庫，但應用仍然是單體式應用，通過多資料源相關技術應用可以同時訪問兩個資料庫，如下圖所示：
- 第二步，將單體式應用拆解成微服務，每個微服務都有各自獨立的資料庫，如下圖所示：
- 舊模塊微服務改造優先級原則
從單體式應用中劃分出有界的背景關系，作為剝離微服務的候選，然后開始依次重構每個功能模塊，那如何判斷哪些模塊應該優先被剝離成微服務呢？從模塊剝離難度看，我們可以遵循先易后難的原則，逐步積累重構經驗，這適用于在微服務構建方面經驗不太豐富的團隊；從需求變化頻率看，優先剝離那些變更頻繁的模塊，整體收益會更大一些，這對于人力資源較為緊張的團隊不失為一個好的判斷準則；從資源消耗型別看，那些計算或記憶體密集的模塊適合優先剝離，這樣有利于彈性伸縮時提升資源利用效率，這對系統規模較大的場景效果最明顯；從服務邊界粒度看，粒度越粗越好剝離，具體按哪個規則來安排微服務的改造順序，這就要根據每個團隊的具體情況來具體分析了，
我們在支持不同系統實施微服務改造的程序中，上述優先級原則都被采用過，優先級存在的原因就是資源不夠，微服務改造不是一蹴而就的事情，這個程序會持續很長時間，可能跨度幾年，在不同階段需要考慮的問題也就不同，最核心的原則就是按照適合自己的節奏有條不紊地開展作業，在確保線上業務穩定的前提下適當地追求速度，
- 微服務改造是否結束判斷標準
那什么時候才算完成微服務改造呢？判斷標準就是舊系統中全部有界背景關系都被剝離成微服務，此時反腐層就可以被廢除了；或者遺留的單體式應用相對較穩定，不再發生變化，重構的投入產出比不再劃算；或者遺留的單體式應用關聯業務已經退出市場了，系統下線了，
- 微服務架構新挑戰與解決方案
當單體式應用被拆解成多個微服務之后，原先在一個事務邊界內的操作現在要跨多個事務邊界了，我們如何保證事務的一致性呢？下面是一些分布式事務機制：
- 再次嘗試，最終一致：將每個操作步驟放?佇列排隊，后續再次嘗試，確保最后執行成功，狀態達成?致，
- 撤銷全部操作：補償事務機制，原事務操作失敗之后，啟動一個新的事務去撤銷之前的操作，如果補償事務也失敗了，那系統需要提供手動或自動再次運?補償事務的功能，
- 分布式事務：通過一個全域事務管理器來協調各個事務得以成功執行，對于短期事務，通常采用兩階段提交（Two-Phase Commit），第一階段是投票階段，分布式事務的參與者告訴事務管理?，判斷本地事務是否可以順利執行，如果事務管理?收集到所有投票結果都是YES，那就開始提交事務執行，
分布式事務機制本身不算太復雜，我們借鑒業界的一些開源產品自研了一套分布式事務框架，跟微服務框架結合起來，應用開發者只需要按照框架的約定實作特定的介面，通過一些注解就可以發起分布式事務，相關細節可以參考阿里的全域事務服務GTS，
當單體式應用被拆解成多個微服務之后，原先集中存盤的資料也被分開存盤了，報表生成將會遇到新的挑戰，在單體式應?情況下，通常有一個用于生成報表的從庫，從主庫同步資料，僅?于查詢等讀操作，避免?成報表程序影響主庫的讀寫效率，在微服務情況下，我們將要通過服務呼叫來獲取資料，設計適合報表統計的批量介面，以及增加快取用于提升資料獲取效率，
- 資料抽取：通過服務調?來獲取報表所需資料，這會造成非常?的負載，以及專?為報表設計的API，為了彌補上述不足，我們可以將資料抽取程式獨立出來，專門從業務資料庫中抽取資料到報表資料庫，
- 事件驅動資料抽取：基于事件驅動的微服務架構，我們可以開發特定事件的訂閱者，負責將資料同步到報表資料庫，這樣可以解耦底層資料庫系統，
微服務改造是一個長期程序，這個程序會遇到各式各樣的問題，方法論可以幫助我們更好地解決這些問題，并且降低風險，歡迎大家一起探討微服務改造程序中遇到的任何問題！
今天先分享到這里，如果你覺得有價值，麻煩動動手指點下文 「 推薦 」按鈕，讓更多小伙伴可以看到，我也會更加有動力堅持分享，另外，老兵哥我后續還會分享職業規劃、應聘面試、技能提升、影響力打造等經驗，關注「 IT老兵哥 」，賦能程式人生！
- 軟技能-熱點文章：
- “花式”裁員套路深，你知道嗎？
- 遭遇裁員，如何渡過心理危機？
- 如何在寒冬中找到好作業？
- 2C 還是 2B，跟找作業有什么關系？
- 大公司 vs 小公司，你會選哪個？
- 記住這一點，不怕找不到好作業！
- 跳槽，跳還是不跳，該怎么跳？
- 程式員“求包養”攻略揭秘
- 很努力了，為什么我還在原地踏步？
- 硬技能-熱點文章：
- 如何設計出優美的Web API？
- 程式員必須懂的架構入門課
- 從程式員到架構師，有捷徑嗎？
- 圖解 Spring：HTTP 請求的處理流程與機制【1】
- 圖解 Spring：HTTP 請求的處理流程與機制【2】
- 圖解 Spring：HTTP 請求的處理流程與機制【3】
- 圖解 Spring：HTTP 請求的處理流程與機制【4】
- 圖解 Spring：HTTP 請求的處理流程與機制【5】
- 如何正確使用 Spring Cloud？【上】
- 如何正確使用 Spring Cloud？【中】
- 如何正確使用 Spring Cloud？【下】
- Spring 核心技術與產品理念剖析【上】
- Spring 核心技術與產品理念剖析【下】
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/29301.html
標籤：架構設計
下一篇：UI自動化技術在高德的實踐