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