《微服務架構設計模式》讀書筆記 | 第2章 服務的拆分政策 #yyds幹貨盤點#

(第2章 服務的拆分政策)

前言

這是一本關于微服務架構設計方面的書，這是本人閱讀的學習筆記。首先對一些符号做些說明：

（）為補充，一般是書本裡的内容；

[]符号為筆者筆注；

1. 微服務架構到底是什麼

1.1 軟體架構的4+1視圖

1.2 應用程式的兩個層面需求

• 功能性需求；
• 非功能性需求，又稱品質屬性需求。（包括可擴充性、可靠性、可維護性、可測試性與可部署性等）[這點是架構為什麼重要的原因]

1.3 分層式架構風格

流行的三層架構是應用于邏輯視圖的分層架構，如下：

• 表現層：包含實作使用者界面或外部API的代碼；
• 業務邏輯層：包含業務邏輯；
• 資料持久層：實作與資料庫互動的邏輯；

其弊端是：

• 單個表現層：無法展現應用程式可能不僅僅由單個系統調用的事實；
• 單一資料持久化層：無法展示應用程式可能與多個資料庫進行互動的事實；
• 将業務邏輯層定義為依賴于資料持久化層：理論上，這樣是依賴會妨礙在沒有資料庫的情況下測試業務邏輯；

1.4 關于架構風格的六邊形

六邊形架構是分層架構風格的替代品 [解決分層架構的弊端]，六邊形架構選擇以業務邏輯為中心的方式組織邏輯視圖。

圖解：

• 業務邏輯具有一個或多個端口，端口定義了一組操作，關于業務邏輯如何與外部互動。
• 有兩種端口：入站端口與出站端口；
  • 入站端口是業務邏輯公開的API（如服務接口等，外部可以通路）；
  • 出站端口是業務邏輯調用外部系統的方式（如儲存庫接口，定義資料通路操作的集合）；
• 業務邏輯周圍是擴充卡，有兩種擴充卡：入站擴充卡與出站擴充卡；
  • 入站擴充卡：通過調用入站端口處理外部請求（如Spring MVC Controller，實作REST接口或一組Web界面）；
  • 出站擴充卡：通過調用外部應用程式或服務處理來自業務邏輯的請求（如實作資料通路對象DAO類）；

好處：

• 将業務邏輯與擴充卡中包含的表示層和資料通路層的邏輯分離開，使單獨測試業務邏輯容易；
• 反映現代應用程式的架構；

1.5 什麼是服務

服務是一個單一的、可獨立部署的軟體元件，它實作了一些有用的功能。

圖解：

• 服務具有API，為用戶端提供對功能的通路；
• API由指令、查詢和事件組成；
• 開發人員無法繞過API直接通路服務内部的方法或資料（松耦合）；

1.6 微服務架構的架構風格

• 它實作的視圖由多個元件構成；
• 元件是服務，連接配接器是使這些服務能夠協作的通信協定；
• 松耦合；
• 共享類庫（裡面實作不太可能改變的功能）；
• 服務大小不重要；

2 為應用程式定義微服務架構

定義架構是一項藝術而非技術；在現實世界中，這是一個不斷疊代和持續創新的過程。

2.1 定義應用程式架構的三步式流程

• 第一步：識别系統操作；
• 第二步：定義服務；
• 第三步：定義服務API；

2.2 第一步：識别系統操作

抽象的領域模型與系統操作能夠回答這個應用“做什麼”這一問題，有助于推動應用程式的架構設計。

2.2.1 識别系統操作的步驟與一些事項：

• 第一步：建立抽象領域模型；
  • 可以通過分析使用者故事和場景中頻繁出現的名詞，經過疊代分析為這個領域模型的一些類；
• 第二步：定義系統操作；
  • 識别系統必須的各種請求， 通常有兩種：
    • 指令型：建立、更新或删除資料的系統操作；
    • 查詢型：查詢和讀取資料的系統操作；
  • 系統操作的切入點在分析使用者故事和場景中頻繁出現的動詞；
  • 需要考慮指令規範（參數、傳回值和領域模型類）與行為規範（前置條件、後置條件）；

2.3 第二步：定義服務

2.3.1 根據業務能力進行服務拆分

拆分步驟：

• 首先要确定業務能力，通常指這個組織的業務是做什麼，可以通過對組織的目标、結構和商業化流程分析得來；
• 确定了業務能力後，就可以為每個能力組定義服務，這是一個非常主觀的判斷；
• 下圖為FTGO應用程式從能力到服務的映射：

  

2.3.2 根據子域進行服務拆分

又稱：基于領域驅動設計分解應用程式的方法

一些概念：

• 領域模型：以解決具體問題的方式包含了一個領域的知識；
• DDD通用語言：定義了目前領域相關團隊的詞彙表，其有兩個重要概念：
  • 子域：是領域的一部分，識别方式跟識别業務類似；
  • 限界上下文：領域模型的邊界，通常每一個限界上下文對應一個或一組服務；

拆分步驟：

• 通過DDD的方式定義子域；
• 把子域對應為每一個服務；
• 下圖為FTGO應用程式從子域到服務的映射：

2.3.3 拆分的指導原則

受啟發于面型對象設計原則。

• 單一職責原則：定義的每一個類都應該隻有一個職責；
• 閉包原則：如果出于某種原因，兩個類的修改必須耦合先後發生，那麼就應該把它們放在同一個包内；

2.3.4 拆分單體應用為服務的難點

• 網絡延遲：
  • 描述：對服務的特定分解導緻兩個服務之間的大量往返調用；
  • 解決：把多個相關服務組合在一起，用程式設計語言的函數調用替換程序間通信；或者實施批處理API在一次往返中擷取多個對象；
• 同步程序間通信導緻可用性降低：
  • 描述：使用REST協定同步調用其他服務時，會降低service的可用性；
  • 解決：參考《第三章 異步消息》；
• 在服務之間維護資料一緻性：
  • 描述：當一個系統操作需要修改多個服務的資料時，需要維護資料的一緻性；
  • 解決：參考《第四章 Saga相關》；
• 擷取一緻的資料視圖：
  • 描述：無法跨多個資料庫獲得真正一緻的資料視圖；
  • 解決：（在實踐中很少帶來真正的問題）；
• 上帝類阻礙了拆分：
  • 描述：上帝類是在整個應用程式中使用的全局類，通常與多個服務的狀态與行為綁定；
  • 解決：參考本章《2.3.5 上帝類阻礙了拆分》，以FTGO的Order類為例；

2.3.5 上帝類阻礙了拆分

在定義微服務架構時，必須識别并消除上帝類。

問題描述：在FTGO應用程式中，Order類與訂單處理、餐館訂單管理、送餐與付款等服務有關，具有複雜的狀态模型，如下圖所示；

解決方法：

• 将Order類打包到庫中并建立一個中央Order資料庫（違反松耦合原則）；
• 将Order資料庫封裝在Order Service中，該服務由其他服務調用用以檢索和更新訂單（問題在于Order Service将成為一個純資料服務，成為很少或沒有業務邏輯的貧血領域模型）；
• 【推薦】應用DDD将每個服務視為具有自己的領域模型的單獨子域，使每個與訂單有關的服務都有自己的領域模型及其對應的Order類版本，如下圖所示；

2.4 第三步：定義服務API

2.4.1 定義服務API的步驟與事項

• 第一步：把系統操作配置設定給服務；
  • 即确定哪個服務是請求的初始入口點；
• 第二步：确定支援服務協作所需要的API；
  • 某些系統操作完全由單個服務處理；也可能分散在多個服務周圍。

3. 本章小結

• 架構決定了軟體的各種非功能性因素，比如可維護性、可測試性、可部署性和可擴充性，它們會直接影響開發速度；
• 微服務架構是一種架構風格，它給應用程式帶來了更高的可維護性、可測試性、可部署性和可擴充性；
• 微服務中的服務是根據業務需求進行組織的，按照業務能力或者子域，而不是技術上的考量；
• 有兩種分解模式：
  • 按業務能力分解，其起源于業務架構；
  • 基于領域驅動設計的概念，通過子域進行分解；
• 可以通過應用DDD并為每個服務定義單獨的領域模型來消除上帝類，正是上帝類引起了阻礙分解的交織依賴項。

最後

::: hljs-center

新人制作，如有錯誤，歡迎指出，感激不盡！

:::

::: hljs-center

歡迎關注公衆号，會分享一些更日常的東西！

:::

::: hljs-center

如需轉載，請标注出處！

:::