在互聯(lián)網(wǎng)的快速發(fā)展的今天，微服務(wù)架構(gòu)能力已經(jīng)成為了后端人員一個必備技能，這篇文章，我們來分享四種常見的微服務(wù)架構(gòu)模型以及它們之間的區(qū)別。

一、洋蔥架構(gòu)

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

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

1. 各層說明

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

2. 提出原因

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

從傳統(tǒng)架構(gòu)圖可以看出每層的強依賴關(guān)系，UI 和業(yè)務(wù)邏輯與數(shù)據(jù)訪問的耦合，如果業(yè)務(wù)邏輯不存在，UI 將無法運行。如果沒有數(shù)據(jù)訪問，業(yè)務(wù)邏輯就無法運行。而洋蔥架構(gòu)強調(diào)整個系統(tǒng)的關(guān)注點分離，使得應(yīng)用程更易于維護。

3. 適用范圍

洋蔥架構(gòu)不適合小型網(wǎng)站，它適用于長期存在的業(yè)務(wù)應(yīng)用程序以及具有復(fù)雜行為的應(yīng)用程序。

二、整潔架構(gòu)

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

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

各層說明

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

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

三、六邊形架構(gòu)

1. 結(jié)構(gòu)

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

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

六邊形架構(gòu)將系統(tǒng)分為內(nèi)六邊形和外六邊形兩層，這兩層的職能劃分如下：

• 內(nèi)六邊形實現(xiàn)應(yīng)用的核心業(yè)務(wù)邏輯；
• 外六邊形完成外部應(yīng)用、驅(qū)動和基礎(chǔ)資源等的交互和訪問，對前端應(yīng)用以 API 主動適配的方式提供服務(wù)，對基礎(chǔ)資源以依賴倒置被動適配的方式實現(xiàn)資源訪問。

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

2. 實現(xiàn)邏輯

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

四、DDD分層架構(gòu)

DDD 分層架構(gòu)應(yīng)該是目前流行度最高的一種架構(gòu)方式，但是，其架構(gòu)也經(jīng)歷了多次的變更。DDD 最早使用的是傳統(tǒng)的四層架構(gòu)；后來四層架構(gòu)發(fā)生了優(yōu)化，實現(xiàn)了各層對基礎(chǔ)層的解耦；再后來領(lǐng)域?qū)雍蛻?yīng)用層之間增加了上下文環(huán)境（Context）層，五層架構(gòu)（DCI）就此形成了。架構(gòu)演變圖如下：

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

1. 各層說明

• User interface：用戶接口層，用戶接口層負責(zé)向用戶顯示信息和解釋用戶指令。這里的用戶可能是：用戶、程序、自動化測試和批處理腳本等等。
• Application：應(yīng)用層，它可以協(xié)調(diào)多個聚合的服務(wù)和領(lǐng)域?qū)ο笸瓿煞?wù)編排和組合，協(xié)作完成業(yè)務(wù)操作；
• Domain：領(lǐng)域?qū)?，領(lǐng)域?qū)拥淖饔檬菍崿F(xiàn)企業(yè)核心業(yè)務(wù)邏輯，通過各種校驗手段保證業(yè)務(wù)的正確性。領(lǐng)域?qū)又饕w現(xiàn)領(lǐng)域模型的業(yè)務(wù)能力，它用來表達業(yè)務(wù)概念、業(yè)務(wù)狀態(tài)和業(yè)務(wù)規(guī)則。
• Infrastructure：基礎(chǔ)層，基礎(chǔ)層是貫穿所有層的，它的作用就是為其它各層提供通用的技術(shù)和基礎(chǔ)服務(wù)，包括第三方工具、驅(qū)動、消息中間件、網(wǎng)關(guān)、文件、緩存以及數(shù)據(jù)庫等。比較常見的功能還是提供數(shù)據(jù)庫持久化。

22. 模型對比

通過上面對四種架構(gòu)詳細介紹可以發(fā)現(xiàn)：幾種架構(gòu)里面都有核心領(lǐng)域?qū)樱ú煌軜?gòu)命名可能不一樣），但都是實現(xiàn)核心業(yè)務(wù)邏輯，它的作用就是將核心業(yè)務(wù)邏輯與外部應(yīng)用、基礎(chǔ)資源進行隔離。不同架構(gòu)，核心業(yè)務(wù)邏輯也是有差異的，有的業(yè)務(wù)邏輯屬于領(lǐng)域模型的能力，有的則屬于面向用戶的用例和流程編排能力。應(yīng)用層實現(xiàn)面向用戶操作相關(guān)的用例和流程，對外提供粗粒度的 API 服務(wù)。它就像一個齒輪一樣進行前臺應(yīng)用和領(lǐng)域?qū)拥倪m配，接收前臺需求，隨時做出響應(yīng)和調(diào)整，盡量避免將前臺需求傳導(dǎo)到領(lǐng)域?qū)?。?yīng)用層作為配速齒輪則位于前臺應(yīng)用和領(lǐng)域?qū)又g。

五、總結(jié)

• 微服務(wù)的幾種模型見證了微服務(wù)架構(gòu)的演進歷史，每種架構(gòu)都有其使用場景和一定的時代意義；
• 四種架構(gòu)都是分離關(guān)注點，將變與不變進行分離；
• 四種架構(gòu)模型表現(xiàn)形式不一樣，但設(shè)計思想都體現(xiàn)了微服務(wù)架構(gòu)高內(nèi)聚低耦合原則，正所謂神同行異；
• 四種架構(gòu)的核心層都是領(lǐng)域?qū)?，它保持領(lǐng)域模型和業(yè)務(wù)邏輯的穩(wěn)定，對外提供穩(wěn)定的細粒度的領(lǐng)域服務(wù)；