解讀六邊形架構(gòu)
追溯微服務(wù)架構(gòu)的淵源，一般會(huì)涉及到六邊形架構(gòu)。追溯六邊形架構(gòu)的起源，要看始作俑者Alistair Cockburn的這篇文章 http://alistair.cockburn.us/Hexagonal+architecture， 讀原文，譯重點(diǎn)，記感受， 如下：
六邊形架構(gòu)意圖
采用同等的方式，應(yīng)用可以通過用戶，程序，自動(dòng)化測(cè)試或批處理腳本來驅(qū)動(dòng)，而獨(dú)立于最終的運(yùn)行環(huán)境及數(shù)據(jù)庫(kù)進(jìn)行開發(fā)和測(cè)試。
當(dāng)外部事件到達(dá)端口的時(shí)候，相應(yīng)的適配器將其轉(zhuǎn)化成合適的過程調(diào)用或者消息，然后傳遞給應(yīng)用，而應(yīng)用對(duì)輸入設(shè)備一無所知。輸出內(nèi)容時(shí)，應(yīng)用通過端口把要傳遞出去的消息傳給適配器，適配器再針對(duì)信息接收者的具體實(shí)現(xiàn)要求將其轉(zhuǎn)化成合適的信號(hào)。從語(yǔ)義上來說，應(yīng)用跟它周圍的適配器有著良好的互動(dòng)，而對(duì)適配器外部的一切無感知。
這是一種設(shè)計(jì)模式，被Cockburn定義為“端口和適配器模式“，設(shè)計(jì)模式不僅指導(dǎo)了代碼的實(shí)現(xiàn)，同時(shí)支持結(jié)構(gòu)的實(shí)現(xiàn)，又是一種解耦合的技巧。
所需解決的問題場(chǎng)景
不能解決問題的架構(gòu)，都只是架構(gòu)師手中的玩具。六邊形架構(gòu)面對(duì)的一個(gè)典型問題是業(yè)務(wù)邏輯與用戶界面的代碼交叉，這是開發(fā)中一個(gè)非常令人頭痛的問題，有三個(gè)惡果：
- 系統(tǒng)無法方便地進(jìn)行自動(dòng)化測(cè)試，因?yàn)椴糠诌壿嬕蕾嚱缑嬖氐?，比如輸入框的長(zhǎng)度或按鈕的位置，而這些細(xì)節(jié)又是易變的;
- 同樣，無法把一個(gè)面向人機(jī)交互的系統(tǒng)移植到一個(gè)自動(dòng)化處理的系統(tǒng)
- 另外，應(yīng)用程序之間的相互驅(qū)動(dòng)變得很困難，有時(shí)甚至不可能的
“***的那一層”出現(xiàn)了，可以在架構(gòu)里增加一個(gè)新的層，并承諾不會(huì)有業(yè)務(wù)邏輯被放到著一新層里。然而隨著時(shí)間的推移，會(huì)發(fā)現(xiàn)新的層里還是摻雜了業(yè)務(wù)邏輯，于是老問題又出現(xiàn)了。
怎么辦呢?假設(shè)一下，如果應(yīng)用提供的每一個(gè)功能都有相應(yīng)的API會(huì)是怎樣的結(jié)果呢?QA可以通過自動(dòng)化測(cè)試腳本來監(jiān)測(cè)新改的代碼，檢驗(yàn)是否會(huì)破壞已有的功能。業(yè)務(wù)專家在GUI出來之前就可以創(chuàng)建自動(dòng)化測(cè)試用例，作為程序員們檢測(cè)是否正確完成工作的依據(jù)，同時(shí)，這也將成為測(cè)試部門所運(yùn)行的測(cè)試的一部分。應(yīng)用以"headless"模式部署，其它程序通過調(diào)用API的方式使用所提供的功能。這種方式使得復(fù)雜系統(tǒng)的設(shè)計(jì)變得容易，面向業(yè)務(wù)的應(yīng)用之間不需要人工干預(yù)就可以互相調(diào)用。***，回歸測(cè)試檢測(cè)到出現(xiàn)問題的地方，并加以修復(fù)，而保證業(yè)務(wù)邏輯不會(huì)進(jìn)入表現(xiàn)層。
另一個(gè)典型的問題是，如果應(yīng)用綁定了外部數(shù)據(jù)庫(kù)或其它服務(wù)，當(dāng)數(shù)據(jù)庫(kù)宕機(jī)或者正在遷移的時(shí)候，依賴數(shù)據(jù)庫(kù)的程序就無法正常工作。這會(huì)導(dǎo)致響應(yīng)延遲，這是一種相當(dāng)糟糕的體驗(yàn)。
這兩個(gè)問題之間沒有明顯的聯(lián)系，但它們之間看起來是對(duì)稱的。這又是一種面向接口的設(shè)計(jì)么? 可以這樣理解，因?yàn)榻涌诘母拍钔庋犹罅耍诰唧w的編程語(yǔ)言實(shí)現(xiàn)中，interface 有往往太小了。這里把它明確為端口和適配器。
方案
不論用戶端交互問題還是服務(wù)端數(shù)據(jù)庫(kù)編程問題，其同源原因就是在設(shè)計(jì)和實(shí)現(xiàn)過程中出現(xiàn)的業(yè)務(wù)邏輯混淆，以及與外部實(shí)體之間的交互關(guān)系。我們要關(guān)注的非對(duì)稱性不是應(yīng)用的"左邊"和"右邊"，而是它的"內(nèi)部"和"外部"，該屬于"內(nèi)部"的代碼就不要泄露到"外部"去，其基礎(chǔ)理論還是那些基本的設(shè)計(jì)原則。
六邊形架構(gòu)的核心理念是：應(yīng)用通過"端口"跟外部進(jìn)行交互的。"端口"讓人聯(lián)想到操作系統(tǒng)的端口，任何符合協(xié)議的設(shè)備都可以被插到相應(yīng)的端口上。端口的協(xié)議是為了兩個(gè)設(shè)備之間能夠進(jìn)行通信而設(shè)計(jì)的，位于OSI 7層協(xié)議模型中的傳輸層。
對(duì)應(yīng)用來說，API就是協(xié)議。對(duì)于每一個(gè)外部設(shè)備，都有對(duì)應(yīng)的適配器把API轉(zhuǎn)換成自己所需要的信號(hào)，反之亦然。用戶圖形界面就是一個(gè)很好的例子，它是把用戶操作映射到端口API的適配器，還有其它的例子如自動(dòng)測(cè)試套件，批處理驅(qū)動(dòng)器，以及任何需要跨應(yīng)用程序交互的代碼。
對(duì)于應(yīng)用的數(shù)據(jù)處理層面，應(yīng)用通過與外部實(shí)體交互得到數(shù)據(jù)，這里用到的協(xié)議一般指數(shù)據(jù)庫(kù)協(xié)議。從應(yīng)用角度來看，把SQL數(shù)據(jù)庫(kù)遷移到普通的文件或者其它類型的數(shù)據(jù)庫(kù)，API仍然保持不變。適應(yīng)于同一個(gè)端口的適配器還包括SQL適配器，文件適配器，以及更重要的數(shù)據(jù)庫(kù)mock，它可以是駐存在內(nèi)存里的數(shù)據(jù)庫(kù)，不一定是真實(shí)的數(shù)據(jù)庫(kù)。
很多應(yīng)用都只有兩個(gè)端口：用戶端端口 和 數(shù)據(jù)庫(kù)端端口。這種情況看起來是對(duì)稱的，很自然地就會(huì)用單維度多層次的架構(gòu)來構(gòu)建它。在開發(fā)應(yīng)用程序時(shí)，就是我們經(jīng)?？吹降娜龑?、四層或五層架構(gòu)。這種架構(gòu)有兩個(gè)問題：
- 很容易跨越層間的邊界，把業(yè)務(wù)邏輯滲透到其它層中去。
- 有的應(yīng)用可能不止需要兩個(gè)端口，所以不能用單維度架構(gòu)來構(gòu)建。
這就是六邊形架構(gòu)提出的原因，它著重解決對(duì)稱性問題，應(yīng)用通過端口與外部進(jìn)行交互，而外部的實(shí)體也可以用同樣的方式來處理。六邊形架構(gòu)強(qiáng)調(diào)以下兩點(diǎn)：
首先，通過"內(nèi)外"的不對(duì)稱性以及端口的特點(diǎn)，擺脫單維度多層次架構(gòu)的束縛?？梢远x不同數(shù)量的端口，2個(gè)，3個(gè)或者4個(gè)，這里說的六邊形不限于只有六個(gè)邊， 可以根據(jù)需要加入更多的端口和適配器，"六邊形架構(gòu)"只是視覺上的一種叫法。
其次，關(guān)注整體架構(gòu)的結(jié)果導(dǎo)向，一個(gè)端口對(duì)應(yīng)一個(gè)或一組有目的交互行為。但一個(gè)端口一般會(huì)有多個(gè)適配器，可以是無人應(yīng)答機(jī)，語(yǔ)音留言機(jī)，按鍵電話，用戶圖形界面，測(cè)試套件，批處理驅(qū)動(dòng)器，HTTP接口，程序之間的接口，mock的數(shù)據(jù)庫(kù)，或者真實(shí)的數(shù)據(jù)庫(kù)。
從應(yīng)用層面來看，這一架構(gòu)的目的是將注意力聚焦在內(nèi)外非對(duì)稱性上，讓外部的實(shí)體從應(yīng)用視角來看都是一樣的。
結(jié)構(gòu)
一個(gè)典型的六邊形架構(gòu)應(yīng)用有兩個(gè)端口，每個(gè)端口對(duì)應(yīng)幾個(gè)適配器，這兩個(gè)端口分別用于應(yīng)用控制和數(shù)據(jù)獲取。該應(yīng)用可以被自動(dòng)化測(cè)試，系統(tǒng)層面的回歸測(cè)試，用戶交互操作，遠(yuǎn)程HTTP調(diào)用或者另外一個(gè)本地應(yīng)用驅(qū)動(dòng)。在數(shù)據(jù)方面，通過配置使用外部的數(shù)據(jù)庫(kù)，可以是Oracle數(shù)據(jù)庫(kù)，mock的數(shù)據(jù)庫(kù)，測(cè)試數(shù)據(jù)庫(kù)或生產(chǎn)數(shù)據(jù)庫(kù)，從而實(shí)現(xiàn)應(yīng)用和外部數(shù)據(jù)庫(kù)的解耦。應(yīng)用的功能說明是依據(jù)六邊形內(nèi)部的接口來編寫的，而不是依據(jù)外部可能用到的任何一種技術(shù)。
對(duì)于一個(gè)典型的三層架構(gòu)而言，簡(jiǎn)化起見，每個(gè)端口只給出兩個(gè)適配器。架構(gòu)的頂層跟底層可以適用多個(gè)適配器，這些適配器是可以按照一定順序來開發(fā)。帶有數(shù)字的箭頭展示了一個(gè)團(tuán)隊(duì)是如何按照一定順序來開發(fā)和使用應(yīng)用的：
- 用測(cè)試套件(如FIT)來驅(qū)動(dòng)應(yīng)用，用mock的內(nèi)存數(shù)據(jù)庫(kù)模擬真實(shí)數(shù)據(jù)庫(kù)。
- 給應(yīng)用增加GUI，但仍然使用mock數(shù)據(jù)庫(kù)。
- 在集成測(cè)試的時(shí)候使用自動(dòng)化測(cè)試腳本(例如，通過Cruise Control觸發(fā))，數(shù)據(jù)庫(kù)換成包含測(cè)試數(shù)據(jù)的真實(shí)數(shù)據(jù)庫(kù)。
- 用戶在生產(chǎn)環(huán)境使用應(yīng)用，數(shù)據(jù)庫(kù)也是真實(shí)的。
代碼示例
FIT的文檔給出了一個(gè)簡(jiǎn)單的例子來說明端口與適配器模式，它是一個(gè)計(jì)算折扣價(jià)格的應(yīng)用：discount(amount) = amount * rate(amount);
在這個(gè)應(yīng)用里，amount來自用戶的輸入，而rate來自數(shù)據(jù)庫(kù)，所以需要兩個(gè)端口。先用測(cè)試代碼跟rate常量來測(cè)試，然后再使用GUI跟mock數(shù)據(jù)庫(kù)，來自IHC的Gyan Sharma提供這個(gè)示例的代碼，具體參考原文。
另一個(gè)用Ruby和Rack實(shí)現(xiàn)的例子可以看這里https://github.com/totheralistair/SmallerWebHexagon。
六邊形架構(gòu)中的左右非對(duì)稱性
六邊形架構(gòu)強(qiáng)調(diào)端口之間的相似性。在實(shí)現(xiàn)的時(shí)候一般有兩種風(fēng)格，稱之為"主"和"從"，或者叫驅(qū)動(dòng)者跟被驅(qū)動(dòng)者，實(shí)際上是CS結(jié)構(gòu)的又一體現(xiàn)。
在上面的例子中，F(xiàn)IT被用在左邊的端口上，而mock的東西在右邊。在三層架構(gòu)中，F(xiàn)IT在最頂層，mock在***層。這兩者之間的區(qū)別在于是誰觸發(fā)了會(huì)話，或者誰在會(huì)話中起主導(dǎo)作用。FIT就是"主"，這個(gè)框架就是被設(shè)計(jì)用來通過腳本來驅(qū)動(dòng)應(yīng)用的。Mock數(shù)據(jù)庫(kù)就是"從"，數(shù)據(jù)庫(kù)被設(shè)計(jì)用來響應(yīng)來自應(yīng)用的查詢或記錄變更事件的。
根據(jù)系統(tǒng)用例，把"主"的端口和適配器放在了六邊形的左邊，而"從"的端口和適配器放在了六邊形的右邊。它們之間的關(guān)系以及它們的實(shí)現(xiàn)方式是很有用的，但前提是要用在六邊形架構(gòu)中。端口與適配器模式***的好處就是可以讓應(yīng)用可以完全獨(dú)立地運(yùn)行。
六邊形架構(gòu)的應(yīng)用邊界
六邊形架構(gòu)對(duì)用例編寫也有強(qiáng)化作用。開發(fā)者在編寫用例時(shí)常犯的錯(cuò)誤是把端口外邊的技術(shù)細(xì)節(jié)包含在用例里，這樣的用例易讀性差，乏味，脆弱，難于維護(hù)。使用六邊形架構(gòu)后，編寫用例應(yīng)該以應(yīng)用的邊界為準(zhǔn)。用例要明確應(yīng)用能夠支持的功能和事件，而不用關(guān)心外部的技術(shù)是怎么樣的。
如何使用端口取決于個(gè)人經(jīng)驗(yàn)。一種極端的情況，每個(gè)用例都被賦予一個(gè)端口，這樣應(yīng)用里就會(huì)有成百上千的端口。另一種情況是，把左右兩邊的端口分別合并起來，這樣就只剩兩個(gè)端口了。這兩種情況都不是最理想的。一些大家所熟知的應(yīng)用是這樣的：
- 天氣預(yù)報(bào)系統(tǒng)有四個(gè)端口：天氣預(yù)報(bào)源，管理員，訂閱者，訂閱者數(shù)據(jù)庫(kù)。
- 咖啡機(jī)控制器有四個(gè)端口：用戶，包含菜單和價(jià)格的數(shù)據(jù)庫(kù)，調(diào)配師，硬幣盒。
- 醫(yī)藥系統(tǒng)有三個(gè)端口：護(hù)士，處方數(shù)據(jù)庫(kù)，藥劑師。
這些實(shí)例沒有拘泥于端口的數(shù)量，一切都是為了業(yè)務(wù)系統(tǒng)服務(wù)的。一般傾向于選擇更少的端口，實(shí)際上是另一種對(duì)分層模型的界定。
原文中談到的一個(gè)真實(shí)應(yīng)用是這樣的，報(bào)警系統(tǒng)從國(guó)家天氣服務(wù)中心獲取地震，龍卷風(fēng)，火災(zāi)和洪水的預(yù)警，然后通過電話或語(yǔ)音留言通知人們。如果遵循技術(shù)與業(yè)務(wù)目標(biāo)相關(guān)聯(lián)的原則，可以設(shè)計(jì)成一個(gè)接口用于接收來自預(yù)報(bào)源的數(shù)據(jù)，一個(gè)用來向語(yǔ)言留言機(jī)發(fā)送通知，一個(gè)GUI管理界面，以及一個(gè)獲取訂閱者數(shù)據(jù)的數(shù)據(jù)庫(kù)接口。當(dāng)希望向系統(tǒng)里增加一些接口的時(shí)候，比如一個(gè)來自天氣服務(wù)中心的http接口，或者一個(gè)到訂閱者的郵件接口，還要考慮怎么讓應(yīng)用套件滿足客戶定制化需求。這樣就會(huì)會(huì)陷入維護(hù)和測(cè)試的惡夢(mèng)，因?yàn)橐獮椴煌亩ㄖ菩枨箝_發(fā)不同的版本。
經(jīng)過系統(tǒng)接口設(shè)計(jì)的調(diào)整，新的六邊形架構(gòu)面向的是業(yè)務(wù)目標(biāo)，而不是具體的技術(shù)，而且把所有的具體技術(shù)換成了適配器。這樣，很快就把http和郵件接口加入到了系統(tǒng)中，把應(yīng)用部署成"headless"模式，并添加了一個(gè)適配器，可以按需通過API調(diào)用連接到其他應(yīng)用上。***，因?yàn)閼?yīng)用的獨(dú)立運(yùn)行能力和各種適配器的存在，就可以使用單獨(dú)的自動(dòng)化腳本進(jìn)行回歸測(cè)試了。
一句話體會(huì)
六邊形架構(gòu)的初衷是為了解決技術(shù)與業(yè)務(wù)系統(tǒng)的解耦合問題，以及技術(shù)與技術(shù)間的解耦合問題，這一架構(gòu)從設(shè)計(jì)模式中來，從業(yè)務(wù)的實(shí)體服務(wù)出發(fā)，將面向接口的設(shè)計(jì)具體化的端口協(xié)議和適配器實(shí)現(xiàn)，將業(yè)務(wù)實(shí)體實(shí)現(xiàn)自服務(wù)的完備性，可以看作是微服務(wù)的一個(gè)理論基礎(chǔ)吧。
【本文來自51CTO專欄作者老曹的原創(chuàng)文章，作者微信公眾號(hào)：喔家ArchiSelf,id:wrieless-com】
