基于 Apache APISIX 的服务网格方案( 二 ) 服务网格（ServiceMesh）是处理服

2.3基于ApacheAPISIX的服务网格
无论是使用服务网格，还是使用API网关，有一个共性原因是服务治理。既然二者有一些共性，那么API网关是否能够在服务网格里使用呢？ApacheAPISIX是否能够胜任服务网格sidecar这样一个角色呢？
2.3.1设计方案前的调研
在2021年1月，我做了一个调研，调研了全国十几家企业对服务网格的使用。这些企业中有一些正在做服务网格调研的，有些正在落地的，有些已经上生产环境了。调研结果总结归纳为以下三点：
大家对于服务网格的使用和落地在国内处于早期阶段（仅业务落地，同时也有大量基于虚拟机的应用并存）
主要会使用到HTTP代理、灰度发布和蓝绿部署等功能
关注服务的可观测性。
对于服务网格，大家关注的大多是上述比较基础的功能。但是服务网格的功能是十分强大的，而大家只看到了其中一小部分核心功能。
ApacheAPISIX已经支持：
HTTP代理， gRPC的代理
TCP、UDP代理
流量切分（灰度发布、蓝绿部署）
负载均衡
健康检查
认证（mTLS、JWTToken）
可观测性
ApacheAPISIX能与ApacheSkyWalking、Prometheus、ZipKin等组件的结合，获取metrics和tracing、logging的数据实现可观测性。
由此可以看出ApacheAPISIX的功能满足服务网格数据面的要求。
2.3.2ApacheAPISIX作为数据面带来的问题
问题一：如何及时获取配置变更？
在服务网格场景下，数据面实例可能有很多，如何保证在实例数特别多时配置变更的下发延时较低？
问题二：控制面的选型
一个完整的服务网格方案必须有数据面和控制面， ApacheAPISIX可以作为数据面，控制面该怎么选呢？是选现有的服务网格产品，如：Istio/Kuma/OpenServiceMesh ，还是自研？
问题三：对ApacheAPISIX的改造成本
假设ApacheAPISIX需要做些修改才能在服务网格中使用，这些修改的范围有哪些？会不会太大？比如大到需要考虑Lua和OpenResty的生态。是否需要自研实现某些功能？自研过程中踩坑的成本有多大？
如何及时获取配置变更？

文章图片
ApacheAPISIX的架构图
从ApacheAPISIX的架构图中可以看到，控制面是使用etcd作为配置中心的。
etcd是一个强一致性的分布式KV存储，使用Raft协议做分布式共识。使用Raft协议，每一个读写请求都需要过一遍Raft的状态机，比如：一个有5节点的etcd集群，至少需要3个节点都确认某次请求，这次请求中的数据才会提交成功。
由于Raft算法特性使得组件的QPS不能太高，客户端连接数不能太多。在服务网格中，控制面如果使用etcd下发配置数据，可能就会把etcd集群冲垮， etcd成为了解决问题的瓶颈。
etcdProxy支持设置连接很多个客户端（比如一千或者更多），直接引入etcdProxy组件是否能解决问题呢？答案是不能，因为ApacheAPISIX与etcd的通信协议是HTTP协议，依靠etcd集成的gRPCgateway把HTTP转成了gRPC ， etcdProxy不支持协议转换。
在服务网格场景下，数据面实例可能有很多，为保证在实例数特别多时配置变更下发延时较低，只能通过对etcdProxy组件二次开发来及解决延时问题，保证及时获取配置的变更。
控制面的选型
以下列出了现有的两类控制面：
一类是Istio、Kuma、OpenServiceMesh ，这三个控制面的共性是数据面都是Envoy ，通过xDS协议把配置从控制面加载到数据面。
另一类是Linkerd ，比较老牌的一个服务网格方案，数据面和控制面都是自研的。
除了采用现有的控制面，还有一个方案就是自研。如果自研控制面，需要考虑很多方面。如：如何设计CRDs（CustomResourceDefinition），能让管理员和控制面交互？如何解决数据从控制面下发到数据面？自研控制面的成本也是非常大的。