中臺架構思考——基於微服務架構和六邊形架構

中臺架構思考——基於微服務架構和六邊形架構

1. 引言

​ 微服務架構能夠說是目前人氣最高而且最受歡迎的軟件架構模式，它徹底迎合如今的軟件開發模式，在保證高併發、高可用的前提下，儘可能下降複雜軟件的開發成本和部署成本。

​ 然而在海量的微服務工程中避免不了的就是重複的造輪子，或者兩個模塊間的很小的區別也會驅使開發者從新開發一個微服務而不是優化已有的微服務（開閉原則），這直接形成了服務器上運行了大量的功能類似的代碼，且咱們須要維護它們全部。

​ 隨着中臺架構思想的興起，微服務單元的標準化和可重用性也愈來愈被重視，本着通用基礎服務下，沉定製業務服務上浮的原則，硬生生把海量微服務一刀切爲兩類，可是大部分中臺迎合業務的最終結果就是中臺裏會添加大量適配業務的模塊，致使中臺失去了通用性，最終致使中臺愈來愈臃腫，變爲糅合了各個業務方邏輯的怪獸。

2. 六邊形架構和GraphAPI

​ 六邊形架構又稱爲端口-適配器架構，從內到外分爲：內核層、適配層、接入層。六邊形架構和中臺架構作對應關係的話，六邊形架構的內核層能夠比做中臺自己，六邊形架構的接入層能夠認爲是中臺架構中的上層業務單元，六邊形架構的精髓之適配層在中臺架構中並無體現。

​ GraphAPI是Facebook開源的一種接口查詢語言，用github的原話是：

咱們爲API v4選擇GraphQL，是由於它爲咱們的集成商提供了顯著的靈活性。相比於REST API v3，它最強大的優點在於，你可以精確的定義所須要的數據，而且毫無冗餘。經過GraphQL，你只須要一次請求就能取到經過多個REST請求才能得到的數據。

​ 說白了意思就是前端請求後端API時，傳入參數指定請求哪一個數據模型的哪一個字段，後端根據這個參數精確推送數據，從而達到更少的request，更準確的數據推送。說到底也是一種適配思想，用靜態的API爲Client動態的裁剪並推送數據。

3. 中臺思想、六邊形架構和GraphAPI

​ 從上面的描述中感受，中臺服務實際上是一個很尷尬的東西，它既不能最終爲程序員和產品開發節省什麼，也不能爲老闆實際獲利，或者這句話有點偏激，不過中臺確實增長了系統的複雜性，而且有最終落地質量的不肯定性（勿噴(^_^)）。

​ 計算機界有一句名言：「任何軟件工程遇到的問題均可以經過增長一箇中間層來解決」。能不能在中臺服務和業務單元之間加一層，像六邊形架構同樣。

​ 適配層適配業務單元和中臺之間的不對等，而且能夠作一些權限方面的校驗和過濾，中臺中的通用服務只須要提供最基本的CRUD功能便可，而且也不須要作大量的權限、業務定製等邏輯，保持中臺服務的單純性，全部的這些差別交給適配服務來搞定。爲了快速適配業務層的多變性，適配層的開放API接入GraphAPI能力，作到根據業務層傳過來的參數動態組裝元數據並返回。

4. 小結

​ 加入適配層有好處也有壞處，壞處是增長系統總體複雜性且適配層可能會成爲系統瓶頸，好處也比較明顯：

1. 保護中臺通用能力的簡單性和專業性。
2. 業務層的易變性和不一樣業務的差別性不會直接影響到中臺通用能力。
3. 現有業務不會拖死中臺的演進和進化的步伐。
4. 當有新業務單元接入時不須要遷就其餘業務單元的歷史包袱，快速接入。