1. 程式人生 > >如何把單體式應用拆解成微服務?【下】

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

熱評博文:《如何設計出優美的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老兵哥 」!

關注「 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 核心技術與產品理念剖析【下】