微服務分解策略

微服務架構的關鍵思想是功能分解。這意味着您無需開發單個大型應用程序,就可以將您的應用程序結構分解爲一組邏輯服務。

應用程序的體系結構很重要,因爲它決定了服務的質量

◎軟件構架

應用程序的體系結構是將其分解爲組件以及這些組件之間的關係。

分解很重要,因爲它有助於團隊之間的工作和知識分配,並提供應用程序整體工作的清晰度。

軟件架構的 4 + 1 視圖模型

它定義了軟件體系結構的四個視圖

邏輯視圖

開發視圖 / 實施意見

進程視圖

物理視圖

4 + 1 視圖模型中的 + 1 代表動畫視圖,並描述特定視圖中的各個組件如何協同工作以處理請求。

◎架構風格

分層架構

分層體系結構將軟件組件分層組織。層可以依賴於其下面的任何層。

流行的三層架構是分層架構

分層架構的缺點

◎六角形架構

基於建築風格的整體

整體架構可以定義爲一種架構樣式,該架構樣式將實現 視圖表示爲單個組件:單個可執行文件或可部署文件。

基於架構風格的微服務

架構風格的微服務架構表示一個具有一組多個組件的實現視圖:可執行文件和 Wars。

組件是服務,關係是通過通信協議進行的。儘管通常實現六邊形體系結構,但是各個服務可以自由選擇其體系結構。

微服務架構服務的關鍵約束應該鬆散耦合。

◎服務

服務是實現某些有用功能的獨立,可獨立部署的組件。

服務通常提供兩類動作

服務還會發布事件。

◎松耦合

任何兩個服務將僅通過 API 進行通信。API 隱藏了服務的內部實現。兩個服務不共享同一數據庫以提供運行時隔離,因此一個服務無法持有將阻止另一服務的鎖。

定義應用程序的微服務架構

步驟如下:

◎識別系統操作

將系統視爲黑匣子。現在確定所有系統操作。

系統操作是應用程序必須處理的請求的抽象。它可以是命令,也可以是查詢。

它涉及以下操作:

◎定義服務

有兩種方法可以識別系統中的服務:

◎分解原理

單一責任原則

一個類只有一個改變的理由。(羅伯特 · 馬丁(Robert C.Martin))

包中的類應針對相同的更改一起封閉。影響軟件包的更改會影響該軟件包中的所有類。(羅伯 · 馬丁(Rober C.Martin))

◎將應用程序分解爲服務的障礙

◎定義服務 API

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/Vk78i_LS8Q4yB0vXWWaLyg