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

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

• 傳統目標：可伸縮性，可靠性和安全性。

• 其他現代目標：快速，安全地提供服務。可維護性，可測試性和可部署性。

◎軟件構架

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

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

軟件架構的 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