微服務分解策略
微服務架構的關鍵思想是功能分解。這意味着您無需開發單個大型應用程序,就可以將您的應用程序結構分解爲一組邏輯服務。
應用程序的體系結構很重要,因爲它決定了服務的質量
-
傳統目標:可伸縮性,可靠性和安全性。
-
其他現代目標:快速,安全地提供服務。可維護性,可測試性和可部署性。
◎軟件構架
應用程序的體系結構是將其分解爲組件以及這些組件之間的關係。
分解很重要,因爲它有助於團隊之間的工作和知識分配,並提供應用程序整體工作的清晰度。
軟件架構的 4 + 1 視圖模型
它定義了軟件體系結構的四個視圖
邏輯視圖
-
由開發人員創建
-
組件:類和包
-
關係:他們之間的關係
開發視圖 / 實施意見
-
組件:模塊(JAR)和可部署 / 可執行(WAR)
-
關係:依賴關係
進程視圖
-
組成部分:進程
-
關係:IPC
物理視圖
-
組件:機器和流程(節點)
-
關係:網絡
4 + 1 視圖模型中的 + 1 代表動畫視圖,並描述特定視圖中的各個組件如何協同工作以處理請求。
◎架構風格
分層架構
分層體系結構將軟件組件分層組織。層可以依賴於其下面的任何層。
流行的三層架構是分層架構
分層架構的缺點
-
依賴性沒有很好地表示。
-
並不表示架構可以具有多個表示層。
-
並不代表該體系結構可以具有多個數據存儲的事實。
-
應用程序層與數據層緊密耦合,因此在沒有數據庫的情況下很難測試應用程序邏輯。
◎六角形架構
基於建築風格的整體
整體架構可以定義爲一種架構樣式,該架構樣式將實現 視圖表示爲單個組件:單個可執行文件或可部署文件。
基於架構風格的微服務
架構風格的微服務架構表示一個具有一組多個組件的實現視圖:可執行文件和 Wars。
組件是服務,關係是通過通信協議進行的。儘管通常實現六邊形體系結構,但是各個服務可以自由選擇其體系結構。
微服務架構服務的關鍵約束應該鬆散耦合。
◎服務
服務是實現某些有用功能的獨立,可獨立部署的組件。
服務通常提供兩類動作
-
命令:執行操作並更新數據。
-
查詢:獲取數據
服務還會發布事件。
◎松耦合
任何兩個服務將僅通過 API 進行通信。API 隱藏了服務的內部實現。兩個服務不共享同一數據庫以提供運行時隔離,因此一個服務無法持有將阻止另一服務的鎖。
定義應用程序的微服務架構
步驟如下:
-
識別系統操作。
-
身份服務
-
爲每個服務及其之間的交互定義 API
◎識別系統操作
將系統視爲黑匣子。現在確定所有系統操作。
系統操作是應用程序必須處理的請求的抽象。它可以是命令,也可以是查詢。
它涉及以下操作:
-
收集系統的需求。
-
確定通常從需求中的名詞派生的域模型。
-
確定通常從需求中的動詞派生的系統操作。
-
從 UI 和 UX 的角度看,將在系統上執行哪些操作。
◎定義服務
有兩種方法可以識別系統中的服務:
-
按業務能力分解
-
按域驅動器設計分解
◎分解原理
單一責任原則
一個類只有一個改變的理由。(羅伯特 · 馬丁(Robert C.Martin))
包中的類應針對相同的更改一起封閉。影響軟件包的更改會影響該軟件包中的所有類。(羅伯 · 馬丁(Rober C.Martin))
◎將應用程序分解爲服務的障礙
-
網絡延遲(高往返)
-
由於同步通信,降低了應用程序的可用性。
-
維護各服務之間的數據一致性
-
獲取數據庫的一致視圖。
-
上帝類(在所有服務中都使用的班)
◎定義服務 API
-
暴露給外部客戶端。
-
用於內部服務協作。
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/Vk78i_LS8Q4yB0vXWWaLyg