【架構與設計】常見微服務分層架構的區別和落地實踐

作者：京東科技康志興

前言

從強調內外隔離的六邊形架構，逐漸發展衍生出的層層遞進、注重領域模型的洋蔥架構，再到和DDD完美契合的整潔架構。架構風格的不斷演進，其實就是為了適應軟體需求越來越複雜的特點。

可以看到，越現代的架構風格越傾向於清晰的職責定位，且讓領域模型成為架構的核心。

基於這些架構風格，在軟體架構設計過程中又有非常多的架構分層模型。

傳統服務通常使用三層架構：

• 門面層：作為服務暴露的入口，處理所有的外部請求。部分情況下，門面層甚至不需要單獨定義物件而是直接使用服務層的實體定義。

• 服務層：作為核心業務層，包含所有業務邏輯。並對基礎層能力進行簡單組合提供一定的能力複用。通常服務層會進行實體定義來防止下層物件體直接暴露給外部服務，導致底層任何變化都有可能直接傳遞到外部，非常不穩定。

• 基礎層：用來存放dao和外部rpc服務的封裝，二者可以拆分為不同的module，也可合二為一，以不同package進行隔離。

三層架構特點就是簡單，適用於一些無複雜業務場景的小型應用，或者「資料不可變」作為基礎原則的DOP（面向資料程式設計）服務。

但是當業務場景稍微複雜一些、呼叫層級較多時，可複用性、可維護性就都非常差了，很多程式碼都耦合在一起，牽一髮動全身。

DDD架構可以看做是整潔架構的一種實現，分層職責如下：

• 適配層：用來做外部不同端請求的介面卡，隔離不同端的協定差異，包裝不同端不同樣式的響應體。

• 應用層：用例、任務入口、訊息佇列監聽均在這一層，可以理解為業務流程的入口，通過聚合根的構造執行相應的命令操作。

• 領域服務層：包含核心的領域服務定義，並定義了gateway來做一層依賴倒置，使基礎設施層僅做實現。

• 基礎設施層包含一切基礎能力：資料庫、ES、遠端呼叫封裝等等。

• 核心穩定：領域模型在依賴鏈上是頂層角色，不依賴任何其他模組，所以極其穩定。其他任何業務域、儲存、邊緣能力的變化都不會對領域模型造成影響。

• 敏捷：適合不同團隊一起開發和維護而不會產生衝突。

• 可拆分：當有屆上下文隨著演進逐漸膨脹時，很容易拆分成微服務。

• 可延伸：新增新的功能非常簡單，從而使得開發人員能夠更快的部署和調整。

• 可演進：良好的可測試性帶來非常低的重構成本，不會隨著不斷迭代導致專案成為難以修改的「大泥球」。

• 專業性要求較高：需要對業務、架構原則理解深刻的人員進行設計和維護，不恰當的領域模型將使後續迭代極為痛苦。

• 開發成本高：複雜的架構設計，更多的架構分層，自然帶來程式碼行數的指數級增長。尤其是專案前期的開發任務變得異常繁重。

• 不再適合簡單的業務場景：實現一個簡單的CRUD顯得過於複雜。

• 改變決策困難：嘗試使用整潔架構需要和團隊的管理層和其他成員達成一致，這往往需要非常強大的說服力。如果在架構演進過程中想切換回其他架構模式也十分困難，幾乎是整個專案級別的重構工作。

基於六邊形架構規範的介面適配原則和防腐理念，同時借鑑了CQRS模式的優點，我們定義了一個簡單的微服務分層架構。

分層定義如下：

• 門面層：作為程式的入口，通過包隔離來存放JSF服務、Rest服務、定時任務和MQ消費，其中對外提供服務的介面定義存放在單獨的api包中。該層的請求定義命名以Request結尾，響應體命名以Response結尾。

• 領域服務層：每一個領域服務存放在單獨的module中，並通過單獨的api包對外暴露能力。該層的命令請求定義命名以Command結尾，查詢請求定義命名以Query結尾，響應體命名以Dto結尾。

• 基礎設施層：存放資料庫、ES、遠端呼叫服務的封裝。該層的持久化資料定義命名以Po結尾。遠端命令服務入參命名以RpcCommand結尾，遠端查詢服務入參命名以RpcQuery結尾，響應體命名以RpcDto結尾。

1. 開發效率

簡單的業務開發過程中，相比較書寫核心業務邏輯，更多的工作量幾乎都是來自處理跨層呼叫時物件轉換和Mapper定義，通過MapStruct和Fluent-Mybatis等元件的使用（也許再加上GitHub Copilot