對于服務網(wǎng)格，API網(wǎng)關和傳統(tǒng)的中心化架構ESB服務總線，在我頭條前面文章已經(jīng)談到多次，今天繼續(xù)再談下對三者的一些思考。

緣起還是在多年前和客戶交流ESB產品的時候，客戶就提出能否將ESB產品去中心化，將ESB產品的能力通過SDK代理包放到各個業(yè)務系統(tǒng)里面去。而這也是當前ServiceMesh服務網(wǎng)關和Sidecar的核心思路。

在傳統(tǒng)的單體架構下，通過ESB總線集成已經(jīng)是一種標準做法，但是ESB總線本身的集中化架構是被人詬病最多的地方。由于ESB本身中心化，導致ESB總線本身可能相處一個性能瓶頸點，同時所有服務調用請求全部經(jīng)過ESB總線，那么ESB如果宕機將是一個巨大的災難。

ESB有一個很重要的核心功能就是Proxy服務代理路由，對底層位置透明并提供統(tǒng)一出口，所以你可以看到類似Ngnix也可以提供這個核心能力。當前很多API網(wǎng)關也是基于Ngnix和OpenRestry進行二次開發(fā)。

所以到了微服務階段。

很多人理解通過服務注冊中心實現(xiàn)了徹底的去中心化，但是當你考慮到多個獨立的微服務團隊集成，一個大的微服務應用需要對外統(tǒng)一暴露API接口服務的時候，這些場景仍然需要使用API網(wǎng)關或微服務網(wǎng)關。

所以API網(wǎng)關本身也是中心化的架構，由于是中心化架構，更加容易增加各種流量攔截插件來實現(xiàn)安全，日志，流控，路由等各種接口管控能力。

那么有無一種去中心化架構也能夠實現(xiàn)上述能力?

當前主流方案就演進到下發(fā)Sidecar代理，控制流和數(shù)據(jù)流分離的ServiceMesh服務網(wǎng)格架構模式。下圖是API網(wǎng)格和ServiceMesh架構的一個對比。

可以看到API網(wǎng)關的大部分能力都可以被SericeMesh來替代。

唯一的就是上圖提到的南北流量和對外統(tǒng)一接口暴露問題，這個仍然需要處理，即實現(xiàn)最基本的Proxy和南北流量分發(fā)的能力。

只要具備這個能力就可以了，這個能力可以是硬件負載均衡能力，也可以是軟件集群或反向代理。如果對應到K8s集群來說，即對應到K8s的Ingress網(wǎng)關來提供統(tǒng)一對外出口。

在Docker+K8s的容器云資源調度平臺下，動態(tài)擴展的彈性計算節(jié)點統(tǒng)一由K8s來進行管理，那么由K8s Ingress網(wǎng)關對外暴露統(tǒng)一接口是合理的。剩余的接口管控能力應該全部下沉到SreviceMesh來完成。

因此：SreviceMesh網(wǎng)格+Ingress網(wǎng)關可完全實現(xiàn)去中心化的ESB能力。

簡單來說我們還是希望去實現(xiàn)一個去中心化的ESB產品，完全保留ESB總線具備的各種能力，實現(xiàn)數(shù)據(jù)流和控制流分離，并配合ServiceMesh的思路來進行開源實現(xiàn)。

服務自發(fā)現(xiàn)還是服務手工注冊?

在基于微服務架構框架下，可以實現(xiàn)服務自發(fā)現(xiàn)。服務自發(fā)現(xiàn)實際是對開發(fā)態(tài)有影響，類似的開發(fā)框架，在開發(fā)階段就需要做的開發(fā)配置，代碼注解增加等。

還有一種就是還是傳統(tǒng)的人工去注冊和接入API接口。如上圖，供應商微服務提供了一個查詢的Rest API接口服務。

http://10.0.0.1/VendorInfo

那我們還是需要在管控平臺對該接口進行注冊操作。該注冊還是要通過網(wǎng)關，僅僅使用了最基本的Proxy路由代理能力進行一次封裝后暴露。如果是南北流量走網(wǎng)關封裝后的接口暴露，如果是東西流量則直接走原始的供應商微服務提供的API接口地址即可。因此實際消費端的服務調用，仍然通過服務注冊中心能力。

• 先在管控治理平臺對供應商查詢服務進行注冊
• 消費方先從注冊中心查詢供應商查詢接口服務
• 消費方發(fā)起接口調用
• 消費方或提供方端的Sidecar進行攔截處理

即兩種流量場景不同的方式進行處理。

內部微服務間東西流量場景可以在消費端和提供端都通過Sidecar流量攔截進行各種安全，日志管控處理。如果是外部的APP或外部應用對接口調用，則只在服務提供端進行Sidecar的流量攔截和處理。

Sidecar和控制中心協(xié)同

在SIdecar中的各個攔截插件實際和控制中心之間存在協(xié)同，類似鑒權處理需要訪問控制中心的服務授權信息，對于日志處理需要攔截日志后將日志寫入到消息中間件。對于路由處理需要訪問控制中心的路由配置表等。

那么如控制中心本身也出現(xiàn)故障，對于接口服務調用還是存在影響，控制中心本身也需要分布式集群部署以提升高可用性。同時可以通過在Sidecar端構建一個輕緩存體系，來實現(xiàn)控制中心宕機下的可用性。