圖1，標準微服務分層模型

出處：https://johng.cn/micro-service-layers/

二、通用閘道器層

與業務無關的請求接入層，一般是Nginx/Kong或者Istio的Api-Gateway中介軟體，核心作用如下：

1、動靜分離

靜態資源和動態Api介面分開管理，以便於靜態資源的CDN。

2、流量管理

通用閘道器是所有請求流量的入口，可以對流量執行多種管理方式。

3、負載均衡

通用閘道器必須是多節點叢集方式部署，負責均衡終端使用者的流量，防止單點故障。

4、協議轉換

通用閘道器負責HTTPS->HTTP的協議轉換，從外部HTTPS加密通訊轉換為內部可信的HTTP普通請求。

5、安全控制

通用閘道器統一透過HTTPS加密通訊方式接入。此外，對網路級的系統安全性（防DDOS、釣魚、跨域等）、請求監控等也是由通用閘道器層負責。一些第三方的安全產品，也是在這一層接入。

6、CDN加速

由於通用閘道器負責請求資源的動靜分離，靜態資源不透過內部服務轉發（浪費效能）而是由通用閘道器統一維護儲存規則，CDN加速將靜態資源進行CDN同步，第三方的CDN僅會在回源的時候會請求到通用閘道器。

三、業務閘道器層

業務閘道器層往往又被稱作業務聚合層，該層由若干個業務服務構成，負責接收通用閘道器轉發過來的流量。醫聯架構中的 埠層 的作用與業務閘道器層相同。核心作用如下：

1、路由管理

業務閘道器層的服務負責自己服務的路由表維護。

2、引數校驗

業務閘道器層的服務負責執行與客戶端約定的引數校驗，驗證透過之後再組裝成後端微服務需要的資料結構請求到後端。

3、許可權校驗

各個業務閘道器層的服務透過底層的使用者服務呼叫來實現許可權校驗，對於哪些路由需要許可權校驗，哪些路由不需要，完全由業務閘道器層的服務自行維護。

4、介面聚合

業務閘道器層的服務可能需要呼叫多個後端的微服務來組合實現一個介面，根據自身需求來對下層返回的資料進行聚合和處理。

6、資料轉換

業務閘道器層的服務的輸入和輸出資料結構必須是表示層需要的，因此它所負責的資料結構和後端GRPC微服務的資料結構會不一樣。業務閘道器層的服務需要負責資料結構的轉換和封裝處理。

7、定時任務

是的，定時任務放在這一層。定時任務不屬於微服務，也不提供HTTP API，往往是一個獨立的守護程序部署，呼叫內部的微服務實現業務邏輯。

四、業務邏輯層

對業務邏輯的封裝，是業務軟體的核心。高內聚，低耦合，複用，解耦。

業務邏輯層中的服務在實際場景中不可避免的會存在相互請求呼叫的場景，這種情況往往需要將耦合的功能進行下沉，資料請求可以下沉為資料訪問層服務，業務的可以下沉為穩定的通用業務服務。

五、資料訪問層

資料訪問層主要的作用是對資料訪問請求做統一的收口，試想一下，假如沒有資料訪問層服務的存在，那麼幾乎所有的業務邏輯層服務都會與資料庫繫結依賴（明顯的現象是配置中存在多個數據庫配置），耦合性較高。

業務資料訪問往往是會被給各個業務服務訪問，被依賴程度往往比較高。將資料訪問能力從業務邏輯層中單獨剝離了出來，形成相對穩定的服務。

對於微服務架構架構的前期，開發效率會成為第一考量的優先順序，過細的層級劃分結構其實會增加一定的維護成本，因此微服務架構前期來講沒有必要將層次劃分這麼細，可以根據業務場景需要選擇性地實現資料訪問層的建設。

六、基礎設施層

基礎設施層是與業務無關的一層，主要包含的是資料儲存和基礎服務。

1、資料儲存

例如MySQL、MongoDB、Redis等等資料服務。

2、訊息佇列

例如Kafka、RocketMQ等等。

4、第三方服務

例如七牛、阿里雲等服務。

5、中介軟體服務

例如分散式鎖、分散式事務、資料庫Client等。

七、常見問題1、層級訪問順序業務請求在層級間應當是從上至下順序訪問的。微服務跨層級訪問是不允許的。例如，業務閘道器層是不應當直接去呼叫資料訪問層。下層如果存在向上層發起的通訊只能透過中介軟體等間接方式進行。2、基礎設施層是否只能層級順序訪問？

基礎設施層雖然在分層模型中展示在最底層，但是卻允許被微服務分層模型中的任何一層訪問。

3、同一個業務是否需要建立不同的專案倉庫以適應不同分層？

不需要。微服務分層模型要求 程式架構 設計和 部署架構 設計切合，但是程式碼維護是放一個還是多個倉庫沒作要求。

出處：https://johng.cn/micro-service-layers/