架構(gòu)與設計 常見微服務分層架構(gòu)的區(qū)別和落地實踐

前言

從強調(diào)內(nèi)外隔離的六邊形架構(gòu)，逐漸發(fā)展衍生出的層層遞進、注重領域模型的洋蔥架構(gòu)，再到和DDD完美契合的整潔架構(gòu)。架構(gòu)風格的不斷演進，其實就是為了適應軟件需求越來越復雜的特點。

可以看到，越現(xiàn)代的架構(gòu)風格越傾向于清晰的職責定位，且讓領域模型成為架構(gòu)的核心。

基于這些架構(gòu)風格，在軟件架構(gòu)設計過程中又有非常多的架構(gòu)分層模型。

傳統(tǒng)三層架構(gòu)

傳統(tǒng)服務通常使用三層架構(gòu)：

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

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

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

三層架構(gòu)特點就是簡單，適用于一些無復雜業(yè)務場景的小型應用，或者“數(shù)據(jù)不可變”作為基礎原則的DOP（面向數(shù)據(jù)編程）服務。

但是當業(yè)務場景稍微復雜一些、調(diào)用層級較多時，可復用性、可維護性就都非常差了，很多代碼都耦合在一起，牽一發(fā)動全身。

??

?

DDD架構(gòu)

DDD架構(gòu)可以看做是整潔架構(gòu)的一種實現(xiàn)，分層職責如下：

?適配層：用來做外部不同端請求的適配器，隔離不同端的協(xié)議差異，包裝不同端不同樣式的響應體。

?應用層：用例、任務入口、消息隊列監(jiān)聽均在這一層，可以理解為業(yè)務流程的入口，通過聚合根的構(gòu)造執(zhí)行相應的命令操作。

?領域服務層：包含核心的領域服務定義，并定義了gateway來做一層依賴倒置，使基礎設施層僅做實現(xiàn)。

?基礎設施層包含一切基礎能力：數(shù)據(jù)庫、ES、遠程調(diào)用封裝等等。

??

優(yōu)點

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

?敏捷：適合不同團隊一起開發(fā)和維護而不會產(chǎn)生沖突。

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

?可擴展：添加新的功能非常簡單，從而使得開發(fā)人員能夠更快的部署和調(diào)整。

?可演進：良好的可測試性帶來非常低的重構(gòu)成本，不會隨著不斷迭代導致項目成為難以修改的“大泥球”。

如此多的優(yōu)點自然帶來明確的缺點

?專業(yè)性要求較高：需要對業(yè)務、架構(gòu)原則理解深刻的人員進行設計和維護，不恰當?shù)念I域模型將使后續(xù)迭代極為痛苦。

?開發(fā)成本高：復雜的架構(gòu)設計，更多的架構(gòu)分層，自然帶來代碼行數(shù)的指數(shù)級增長。尤其是項目前期的開發(fā)任務變得異常繁重。

?不再適合簡單的業(yè)務場景：實現(xiàn)一個簡單的CRUD顯得過于復雜。

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

簡單的微服務分層架構(gòu)

基于六邊形架構(gòu)規(guī)范的接口適配原則和防腐理念，同時借鑒了CQRS模式的優(yōu)點，我們定義了一個簡單的微服務分層架構(gòu)。

骨架Maven坐標：

com.jdt.open
simple-microservices-layered-architecture-archetype
1.4.0

分層定義：

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

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

?基礎設施層：存放數(shù)據(jù)庫、ES、遠程調(diào)用服務的封裝。該層的持久化數(shù)據(jù)定義命名以Po結(jié)尾。遠程命令服務入?yún)⒚訰pcCommand結(jié)尾，遠程查詢服務入?yún)⒚訰pcQuery結(jié)尾，響應體命名以RpcDto結(jié)尾。

??

最佳實踐

1.命令服務必須訪問領域服務層，允許簡單查詢直接調(diào)用基礎設施層。

2.參數(shù)校驗、請求出入?yún)⑷罩?、審計日志記錄、TraceID預埋、異常處理等非核心業(yè)務能力均由公共組件（參考： Open-Lab組件包 ）完成，減少項目內(nèi)部的邊緣能力代碼。

3.由于在門面層進行統(tǒng)一的異常處理，非必要時無需在項目中進行大面積的try-catch，讓代碼更清爽。

4.實際開發(fā)過程中，門面層、領域服務層和基礎設施層均有各自的實體定義，跨層調(diào)用的對象體轉(zhuǎn)換使用MapStruct組件來減少手寫映射代碼的工作量。

5.數(shù)據(jù)層使用Fluent-Mybatis，最大好處是減少后期迭代中，數(shù)據(jù)對象增減字段時修改Mapper的成本。

優(yōu)點

1. 開發(fā)效率

簡單的業(yè)務開發(fā)過程中，相比較書寫核心業(yè)務邏輯，更多的工作量幾乎都是來自處理跨層調(diào)用時對象轉(zhuǎn)換和Mapper定義，通過MapStruct和Fluent-Mybatis等組件的使用（也許再加上GitHub Copilot

審核編輯 黃宇