在互聯網的快速發展的今天，微服務架構能力已經成為了后端人員一個必備技能，這篇文章，我們來分享四種常見的微服務架構模型以及它們之間的區別。

一、洋蔥架構

洋蔥架構：Onion Architecture，它是由 Jeffrey Palermo（杰弗里·巴勒莫）在 2008年提出的，下圖摘自作者原論文：

洋蔥架構因為整個架構外形看似像洋蔥，因此而得名，它在很大程度上依賴于依賴倒置原則，所有代碼都可以依賴于更中心的層，但代碼不能依賴于遠離核心的層。換句話說，所有耦合都朝向中心。這種體系結構毫不掩飾地偏向于面向對象的編程，它將對象置于所有其他對象之上。

1. 各層說明

• Domain Model：領域模型層，它是最中心的，代表了為組織建模真相的狀態和行為組合，封裝了企業級的業務規則；
• Model Services：領域服務，涉及多個實體的復雜業務邏輯，例如抽象存儲庫（仍然將實現細節留給外層，例如數據庫連接）；
• Application Services：應用程序服務，它定義了應用程序的業務流程；
• User interface/Infrastructure/Tests：最外層是用戶界面、與外部基礎設施的連接和自動化測試。與端口和適配器一樣，此模式將與所有外部依賴項（例如數據庫、API 和用戶界面）的連接留在邊緣，以便輕松切換；

2. 提出原因

洋蔥架構被提出的原因是作者覺得傳統自上而下的分層架構模式存在嚴重的弊端弊端：耦合，每一層都耦合到它下面的層，每一層通常耦合到各種基礎設施問題。下圖為傳統分層架構圖：

從傳統架構圖可以看出每層的強依賴關系，UI 和業務邏輯與數據訪問的耦合，如果業務邏輯不存在，UI 將無法運行。如果沒有數據訪問，業務邏輯就無法運行。而洋蔥架構強調整個系統的關注點分離，使得應用程更易于維護。

3. 適用范圍

洋蔥架構不適合小型網站，它適用于長期存在的業務應用程序以及具有復雜行為的應用程序。

二、整潔架構

整潔架構：Clean Architecture，它是由 Robert C. Martin (Uncle Bob) 于 2012 年提出。整潔架構是基于洋蔥架構的概念之上提出的，但各層的細節有所不同。它的核心不叫"領域模型"，而是稱為"實體"，但仍然代表企業范圍的業務規則。下圖摘自作者原文：

從整潔架構的架構圖可以看出：整潔架構最主要的原則是依賴原則，它定義了各個層級的依賴關系，同心圓代表軟件的不同領域，越往里能力越是核心。外圓代碼依賴只能指向內圓，內圓無需關注外圓變化（包括函數、類。變量，或任何其他命名的軟件實體）。

各層說明

• Entities：實體。它封裝了企業范圍的業務規則，實體可以是具有方法的對象，也可以是一組數據結構和函數。只要實體可以被企業中的許多不同應用程序使用，就沒有關系。
• Use Cases：用例。該層中的軟件包含特定于應用程序的業務規則。它封裝并實現了系統的所有用例。這些用例協調進出實體的數據流，并指導這些實體使用其企業范圍的業務規則來實現用例的目標。
• Interface Adapters：接口適配器。該層中的軟件是一組適配器，可將數據從對用例和實體最方便的格式轉換為對某些外部機構（如數據庫或 Web）最方便的格式。例如，這一層將完全包含 GUI 的 MVC 架構。Presenters、Views 和 Controllers 都屬于這里。這些模型可能只是從控制器傳遞到用例，然后從用例返回到呈現器和視圖的數據結構。
• Frameworks and Drivers：框架和驅動程序。最外層主要提供適配的能力，適配能力分為主動適配和被動適配，一般由Database、Web Framework等框架和工具組成，這一層一般不會寫太多代碼，除了往內和下一個圈子通信的膠水代碼。

在圖表的右下方展示了如何跨越圓圈邊界的示例。它顯示了 Controller 控制器和 Presenters演示器與下一層中的用例進行通信。注意控制流。它從控制器開始，通過用例移動，然后結束在演示器中執行。還要注意源代碼依賴性。它們中的每一個都向內指向用例。

三、六邊形架構

1. 結構

六邊形架構：Hexagonal Architecture，又名“端口適配器架構”，它是由 Alistair Cockburn 于 2005 年在論文中引入的。

需要說明的是：六邊形架構中的六邊形不是六邊形，因為數字 6 很重要，而是讓繪圖的人有空間根據需要插入端口和適配器，而不受一維分層繪圖的限制。"六邊形架構"一詞就源于這種視覺效果。更直白地說，該圖案實際上與六邊形無關，它只是通常的繪制方式而已。下圖摘自作者原論文：

六邊形架構將系統分為內六邊形和外六邊形兩層，這兩層的職能劃分如下：

• 內六邊形實現應用的核心業務邏輯；
• 外六邊形完成外部應用、驅動和基礎資源等的交互和訪問，對前端應用以 API 主動適配的方式提供服務，對基礎資源以依賴倒置被動適配的方式實現資源訪問。

六邊形架構的核心理念是：應用是通過端口與外部進行交互的，一個端口可能對應多個外部系統。也就是說，在下圖的六邊形架構中，最內層的核心業務邏輯與外部資源（包括 APP、Web 應用以及數據庫資源等）完全隔離，僅通過適配器進行交互。它解決了業務邏輯與用戶界面的代碼交錯問題，很好地實現了前后端分離。六邊形架構各層的依賴關系與整潔架構一樣，都是由外向內依賴。

2. 實現邏輯

當任何驅動程序想要在端口上使用應用程序時，它會發送一個請求，該請求由針對驅動程序特定技術的適配器轉換為可用的過程調用或消息，然后將其傳遞到應用程序端口。該應用程序對驅動程序的技術一無所知。當應用程序有東西要發送時，它會通過端口將其發送到適配器，適配器會創建接收技術（人工或自動）所需的適當信號。應用程序在其所有方面都與適配器進行了語義上的聲音交互，而實際上并不知道適配器另一端事物的性質。

四、DDD分層架構

DDD 分層架構應該是目前流行度最高的一種架構方式，但是，其架構也經歷了多次的變更。DDD 最早使用的是傳統的四層架構；后來四層架構發生了優化，實現了各層對基礎層的解耦；再后來領域層和應用層之間增加了上下文環境（Context）層，五層架構（DCI）就此形成了。架構演變圖如下：

DDD 分層架構有一個重要的原則：每層只能與位于其下方的層發生耦合。

1. 各層說明

• User interface：用戶接口層，用戶接口層負責向用戶顯示信息和解釋用戶指令。這里的用戶可能是：用戶、程序、自動化測試和批處理腳本等等。
• Application：應用層，它可以協調多個聚合的服務和領域對象完成服務編排和組合，協作完成業務操作；
• Domain：領域層，領域層的作用是實現企業核心業務邏輯，通過各種校驗手段保證業務的正確性。領域層主要體現領域模型的業務能力，它用來表達業務概念、業務狀態和業務規則。
• Infrastructure：基礎層，基礎層是貫穿所有層的，它的作用就是為其它各層提供通用的技術和基礎服務，包括第三方工具、驅動、消息中間件、網關、文件、緩存以及數據庫等。比較常見的功能還是提供數據庫持久化。

22. 模型對比

通過上面對四種架構詳細介紹可以發現：幾種架構里面都有核心領域層（不同架構命名可能不一樣），但都是實現核心業務邏輯，它的作用就是將核心業務邏輯與外部應用、基礎資源進行隔離。不同架構，核心業務邏輯也是有差異的，有的業務邏輯屬于領域模型的能力，有的則屬于面向用戶的用例和流程編排能力。應用層實現面向用戶操作相關的用例和流程，對外提供粗粒度的 API 服務。它就像一個齒輪一樣進行前臺應用和領域層的適配，接收前臺需求，隨時做出響應和調整，盡量避免將前臺需求傳導到領域層。應用層作為配速齒輪則位于前臺應用和領域層之間。

五、總結

• 微服務的幾種模型見證了微服務架構的演進歷史，每種架構都有其使用場景和一定的時代意義；
• 四種架構都是分離關注點，將變與不變進行分離；
• 四種架構模型表現形式不一樣，但設計思想都體現了微服務架構高內聚低耦合原則，正所謂神同行異；
• 四種架構的核心層都是領域層，它保持領域模型和業務邏輯的穩定，對外提供穩定的細粒度的領域服務；