去中心化的API网关是否就是ServiceMesh?

今天谈下去中心化的API网关。

对于API网关我前面多篇文章都已经指出过，其本身要实现请求的统一代理，必然是一种中心化的架构，如果不希望中心化你可以走服务注册中心来实现服务注册发现和服务请求。最近出现一个新的概念API Gateway Mesh，个人感觉这个概念不太合适。

不合适的原因就是在API网关去中心化后，其常说的服务注册发现，安全，限流熔断，日志等微服务管控治理能力本身就通过Sidecar模式下沉到微服务中。也就是说ServiceMesh基本可以实现所有的API网关的能力，除了统一的流量代理和负载均衡。

在我谈这个问题前，先引用一段蚂蚁金服技术专家关于API Gateway Mesh的一些阐述，具体可以参考公众号完整文章。

从本质概念上来讲，API Gateway 用一句话概括：「Exposes your services as managed APIs」，将内部的服务以更加可控可管理的方式暴露出去，这里的关键词是「暴露」和「可控」。Service Mesh 用一句话概括：「A infrastructure to decouple the application network from your service code」，一种将服务代码与应用网络解耦的基础设施，这里的关键词是「解耦」。

在流量上，API Gateway 是管理南北流量的，而 Servcie Mesh 中的 Sidecar 一般情况下是用来负载东西流量的Proxy。两者都具备负载均衡的能力，API Gateway 一般情况下是通过 lvs 、nginx 中心化的一个负载均衡器，我们管这个叫硬负载；而 Service Mesh 一般情况下是通过服务发现，Sidecar 之间是点对点的调用，我们叫软负载。

通信协议上，API Gateway 一般对外接收开放的通信协议，一般是 HTTP、gRPC 等，而且可能涉及到协议的转换，将 HTTP 转换成内部的 RPC 协议，而 Service Mesh 代理的内部流量一般是内部的私有 RPC 协议（WebService、Dubbo、SOFABolt、Thrift 等等）。在鉴权、流控、安全等控制流量的层面上，对于 API Gateway 来讲都是强依赖的，这样才体现「可控」的特点，而 Service Mesh 代理的内部流量，由于一般处于内网环境，这些控制一般情况下都是弱依赖。

具体文章可以参考。

https://mp.weixin.qq.com/s/o4yrZXhW4tnggctL03t7kw

API网关核心是请求代理

当重新思考API网关的时候，又回到其核心能力即请求代理和负载均衡，因此对于负载均衡和代理这块一定是中心化的架构，不可能去中心化。但是传统API网关在拦截了流量后，往往对API接口请求进行了安全，日志，限流熔断等各种管控治理能力的增加，那么增加的这部分能力是可以Mesh化的。

在上篇文章里面谈到API网关和ServiceMesh的另外一个区别就是API网关是内部能力的对外暴露，解决的是南北流量的交互；而对于ServiceMesh往往是解决微服务应用内部，各个微服务之间东西流量的交互。

也就是ServiceMesh并不一定需要具备对外的服务暴露和负载均衡能力。

在了解了这点后，简化理解就是：去中心化API网关 = 中心化的负载均衡能力+ ServiceMesh去中心化的管控能力。

也就是说API网关的请求代理全部转移到负载均衡设备来完成，而其他管控治理能力全部下沉到SeriviceMesh架构中的Sidecar来完成。

服务注册发现和负载均衡配置

当把上面这点思考清楚后，你会看到去中心化网关要解决的核心问题在哪里？

我个人理解其中有一个关键能力就是SeviceMesh的服务注册发现和负载均衡设备或类似Nginix反向代理之间的自动化集成和协同问题。

在云原生和DevOps下可以看到。

当一个微服务应用完成持续交付和自动化部署后，会自动下发一个Sidecar边车到微服务部署的Pod中，这个边车里面包括了API网关需要的管控治理代理Jar包，实现流量拦截和各种微服务治理能力。

在Sidecar下发完成后，会自动完成微服务的自动化注册和接入过程。但是并不会和负载均衡设备协同，完成负载均衡配置信息的自动化修改。因此在这里需要增加一个关键能力，即：

在微服务部署并自动化注册后，需要自动化更新更新负载均衡设备的路由配置表信息，也就是这个负载均衡能力不会使用ServiceMesh的负载均衡，而是需要借助独立的负载均衡组件来完成统一的服务代理和服务对外暴露。

微服务和微服务暴露的API接口

第二点，在谈微服务网关和API网关的时候就谈到过，微服务网关只管理到微服务组件的粒度，而API网关需要管理到一个个的API接口的细粒度。

对应回ServiceMeshd的解决方案也是同样的道理，当前的开源Mesh化解决方案往往无法管理到一个个的API接口这个粒度，这部分能力仍然是需要进行定制，即将API网关这部分的能力剥离出来后下沉到Sidecar中来实现。

管理到一个个的API接口服务力度是对Mesh架构做的一个大定制化能力提升。

服务请求端无法下发Sidecar

注意，在同一服务能对外暴露的时候，前端本身具备多样性，比如前端很可能就是一个APP应用，这个时候可能并没有办法采用统一的微服务开发框架，自然也无法在前端模块下发标准的Sidecar代理模块。

拿服务访问安全来举例说明。

在传统的API网关架构中，会直接在API网关拦截到请求流量后，进行服务安全检查，如果没有访问权限直接拒绝并返回。在ServiceMesh架构下，安全能力会在微服务请求模块来完成，即请求模块中的Sidecar代理在鉴权不通过的时候直接拒绝，该流量请求并不会达到API接口服务的提供模块上。

那么在请求端无法下发Sidecar情况下，这部分能力只能是转移到API接口服务提供端来完成，即请求端不做请求流量拦截和管控能力。

负载均衡和心跳检测，健康检查

最后一点，负载均衡实现的时候需要考虑到心跳和健康检查问题。而负载均衡往往并不具备集群节点的心跳和健康检查能力。

因此这部分能力仍然需要在Mesh的控制中心来完成。

即Mesh的控制中心在监控检查发现了不可用的微服务集群节点的时候，应该动态的将该集群节点从负载均衡设备的路由配置表中移出。

如何改造扩展？

简单来说即基于Ngnix和Istio两个开源组件来进行扩展和集成，同时自定义一个apiGateway.jar包，通过DevOps过程以Sidecar模式自动化部署到微服务中来实现微服务管控治理。

当前也可以使用OpenRestry来代理Ngnix，但是只使用OpenRestry的负载均衡，服务代理，节点心跳检查能力，其它管控能力仍然是下发到边车完成。