Java 平臺微服務架構的項目組成形式

微服務項目的依賴關係

在微服務化架構中, 軟件項目被拆分紅多個自治的服務, 服務之間經過網絡協議進行調用, 一般使用透明的 RPC 遠程調用.

在 Java 領域, 每一個服務上線後, 對外輸出的接口爲一個 jar 包. 在微服務領域, jar 包被分爲一方庫、二方庫、三方庫.

• 一方庫: 本服務在 JVM 進程內依賴的 jar 包.
• 二方庫: 在服務外經過網絡通訊或 RPC 調用的服務的 JAR 包.
• 三方庫: 所依賴的其餘公司或者組織提供的服務或者模塊.

微服務項目的層級結構

Java 微服務項目的層級結構通常爲: 服務導出層、接口層和邏輯實現層, 以下圖.

其中, 每一個層級的職責和最終的表現形式以下:

• 服務導出層: 最後會打包成一個 War 包, 包含服務的實現 Jar 包、接口 Jar 包, 以及 Web 項目導出 RPC 服務所須要的配置文件等.
• 服務接口層: 包含業務接口、依賴的 DTO 及須要的枚舉類等, 最後打包成 Jar 包, 併發布到 Maven 服務器上, 也包含在服務導出層的 War 包中.
• 服務實現層: 包含業務邏輯實現類、依賴的第三方服務的包裝類, 以及下層數據庫訪問的 DAO 類等, 最後打包成 Jar 包, 包含在服務導出層的 War 包中.

Java 平臺下微服務實現層的架構圖:

本地服務層經過 DAO 層與數據庫進行交互. 這裏使用了數據庫事務, 保證了數據存取的強一致性, 業務流程層經過組合本地服務和外部服務來完成業務邏輯的實現, 因爲有遠程服務的依賴, 所以只能保證數據的最終一致性.

這裏有一個反模式, 切記永遠不要在本地事務終調用遠程服務, 在這種場景下若是遠程服務出現了問題, 則會拖長事務, 致使應用服務器佔用太多的數據庫鏈接, 讓服務器負載迅速攀升, 在嚴重狀況下會壓垮數據庫. 順便說一下, 雖然咱們要竭力避免這種場景的發生, 可是數據庫也應該有負載熔斷機制.

Java 平臺下微服務實現層的反模式架構