对于服务网格，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端构建一个轻缓存体系，来实现控制中心宕机下的可用性。

关键词： 控制中心 访问控制 就可以了 还是希望 提供了一个