對于服務網格，API網關和傳統的中心化架構ESB服務總線，在我頭條前面文章已經談到多次，今天繼續再談下對三者的一些思考。
緣起還是在多年前和客戶交流ESB產品的時候，客戶就提出能否將ESB產品去中心化，將ESB產品的能力通過SDK代理包放到各個業務系統里面去。而這也是當前ServiceMesh服務網關和Sidecar的核心思路。
在傳統的單體架構下，通過ESB總線集成已經是一種標準做法，但是ESB總線本身的集中化架構是被人詬病最多的地方。由于ESB本身中心化，導致ESB總線本身可能相處一個性能瓶頸點，同時所有服務調用請求全部經過ESB總線，那么ESB如果宕機將是一個巨大的災難。
ESB有一個很重要的核心功能就是Proxy服務代理路由，對底層位置透明并提供統一出口，所以你可以看到類似Ngnix也可以提供這個核心能力。當前很多API網關也是基于Ngnix和OpenRestry進行二次開發。
所以到了微服務階段。
很多人理解通過服務注冊中心實現了徹底的去中心化，但是當你考慮到多個獨立的微服務團隊集成，一個大的微服務應用需要對外統一暴露API接口服務的時候，這些場景仍然需要使用API網關或微服務網關。
所以API網關本身也是中心化的架構，由于是中心化架構，更加容易增加各種流量攔截插件來實現安全，日志，流控，路由等各種接口管控能力。
那么有無一種去中心化架構也能夠實現上述能力?
當前主流方案就演進到下發Sidecar代理，控制流和數據流分離的ServiceMesh服務網格架構模式。下圖是API網格和ServiceMesh架構的一個對比。
可以看到API網關的大部分能力都可以被SericeMesh來替代。
唯一的就是上圖提到的南北流量和對外統一接口暴露問題，這個仍然需要處理，即實現最基本的Proxy和南北流量分發的能力。
只要具備這個能力就可以了，這個能力可以是硬件負載均衡能力，也可以是軟件集群或反向代理。如果對應到K8s集群來說，即對應到K8s的Ingress網關來提供統一對外出口。
在Docker+K8s的容器云資源調度平臺下，動態擴展的彈性計算節點統一由K8s來進行管理，那么由K8s Ingress網關對外暴露統一接口是合理的。剩余的接口管控能力應該全部下沉到SreviceMesh來完成。
因此：SreviceMesh網格+Ingress網關可完全實現去中心化的ESB能力。
簡單來說我們還是希望去實現一個去中心化的ESB產品，完全保留ESB總線具備的各種能力，實現數據流和控制流分離，并配合ServiceMesh的思路來進行開源實現。
服務自發現還是服務手工注冊?
在基于微服務架構框架下，可以實現服務自發現。服務自發現實際是對開發態有影響，類似的開發框架，在開發階段就需要做的開發配置，代碼注解增加等。
還有一種就是還是傳統的人工去注冊和接入API接口。如上圖，供應商微服務提供了一個查詢的Rest API接口服務。
http://10.0.0.1/VendorInfo
那我們還是需要在管控平臺對該接口進行注冊操作。該注冊還是要通過網關，僅僅使用了最基本的Proxy路由代理能力進行一次封裝后暴露。如果是南北流量走網關封裝后的接口暴露，如果是東西流量則直接走原始的供應商微服務提供的API接口地址即可。因此實際消費端的服務調用，仍然通過服務注冊中心能力。
先在管控治理平臺對供應商查詢服務進行注冊消費方先從注冊中心查詢供應商查詢接口服務消費方發起接口調用消費方或提供方端的Sidecar進行攔截處理即兩種流量場景不同的方式進行處理。
內部微服務間東西流量場景可以在消費端和提供端都通過Sidecar流量攔截進行各種安全，日志管控處理。如果是外部的APP或外部應用對接口調用，則只在服務提供端進行Sidecar的流量攔截和處理。
Sidecar和控制中心協同在SIdecar中的各個攔截插件實際和控制中心之間存在協同，類似鑒權處理需要訪問控制中心的服務授權信息，對于日志處理需要攔截日志后將日志寫入到消息中間件。對于路由處理需要訪問控制中心的路由配置表等。
那么如控制中心本身也出現故障，對于接口服務調用還是存在影響，控制中心本身也需要分布式集群部署以提升高可用性。同時可以通過在Sidecar端構建一個輕緩存體系，來實現控制中心宕機下的可用性。
X 關閉
X 關閉