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

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

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

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

所以到了微服務(wù)階段。

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

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

那么有無一種去中心化架構(gòu)也能夠?qū)崿F(xiàn)上述能力?

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

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

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

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

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

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

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

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

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

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

http://10.0.0.1/VendorInfo

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

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

即兩種流量場景不同的方式進(jìn)行處理。

內(nèi)部微服務(wù)間東西流量場景可以在消費端和提供端都通過Sidecar流量攔截進(jìn)行各種安全，日志管控處理。如果是外部的APP或外部應(yīng)用對接口調(diào)用，則只在服務(wù)提供端進(jìn)行Sidecar的流量攔截和處理。

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

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

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