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

緣起還是在多年前和客戶交流ESB產(chǎn)品的時(shí)候，客戶就提出能否將ESB產(chǎn)品去中心化，將ESB產(chǎn)品的能力通過SDK代理包放到各個(gè)業(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總線本身可能相處一個(gè)性能瓶頸點(diǎn)，同時(shí)所有服務(wù)調(diào)用請(qǐng)求全部經(jīng)過ESB總線，那么ESB如果宕機(jī)將是一個(gè)巨大的災(zāi)難。

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

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

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

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

那么有無(wú)一種去中心化架構(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)的一個(gè)對(duì)比。

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

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

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

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

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

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

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

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

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

http://10.0.0.1/VendorInfo

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

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

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

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

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

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

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