Service Mesh上线需解决的问题整理

引言

越来越多的公司开始研究Service Mesh，线上大批量应用案例的依旧很少，已经上线的很多问题解决的并不完美，为后面迭代和稳定性埋下隐患。目前来看整体开源生态成熟度还有需要完善，本文为笔者试水service mesh过程中发现的问题归纳整理。

一、目标与价值

业务侧只需要引入轻量级SDK，其他基础能力下沉到网格SideCar代理中，一个美好的愿望 “接管所有非业务关心的能力”。

1.业务赋能价值

提升开发效率：只需专注业务

加速业务探索：快速迭代上线、快速验证

代理升级无感知：不需要费力推动业务升级或者通过卡点升级引起的各类问题

2.运维提效价值

• 治理体系统一：屏蔽不同语言体系治理的复杂性
• 技术演进统一：不必关心版本碎片化问题，能力统一自住演进

二、组织形态整合

如果将Service Mesh作为公司战略推动，Service Mesh依赖Kubernate底座，相关人员最好整合到一个部门，统一运维和开发。

将Service Mesh团队、Serverless团队、容器团队整合到一个部门负责云原生体系建设

其他部门配合改造和对接

三、技术问题

下面就使用最广泛的Istio和Envoy为例就其线上运行需要解决的技术问题归纳整理。

1.注册中心接入服务网格

实现目的： 公司已有的注册中心接入服务网格(Istio)，完成服务注册与发现能力

基本原理： 通过Istio提供的ServiceEntry将网格外注册中心接入网格

https://mp.weixin.qq.com/s/4bTdmaQVKi8YHhBJCbrVKQ

2.RPC框架协议兼容问题

实现目的： 需要实现网格内外通信，那网格内的服务调用原有服务需要支持原有的RPC协议

基本原理： 与使用的RPC框架关联，如果使用gRPC自研由于Istio原生支持HTTP/2则改动极小，如果使用dubbo或者自研RPC框架，可以通过EnvoyFilter转换实现，可以参考腾讯开源框架 aeraki

https://github.com/aeraki-framework/aeraki

3.网格流量治理问题

实现目的： 网格流量需要支持限流、熔断等治理能力并与现有治理平台融合

基本原理： 通过Envoy提供的Filter插件机制，将限流配置与EnvoyFilter规则映射完成限流，可以参考网易开源的slime框架

https://github.com/slime-io/slime

4.网格流量监控问题

实现目的： 网格流量的监控指标和埋点需要与原有监控体系融合

实现原理： Istio提供了kiali、jaeger、grafana、prometheus相关监控体系，将这些这表对接到原有监控系统。另外一些自定义的监控指标可以通过wasm扩展。

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

5.按需订阅配置(懒加载)问题

在默认情况下，Istio会全量下发注册中心配置信息，占用过多的内存严重影响性能。常见的方案有：

社区SidecarScope的隔离

全局代理方案第一跳先去代理拿服务依赖的配置，之后不再需要跟代理通信(参考Slime提供的懒加载功能)

通过在SideCar中同时部署Agent的方式维护服务依赖关系

6.热部署和升级问题

在对代理SideCar进行部署和升级时的处理，需要做到平滑先摘流量再部署升级。

进程级别代理方式，对数据面进行监控、版本管理和升级

双容器模式，一个容器运行，另外一个容器Standby;Standby容器完成升级后检测正常后再切换

依赖应用发布升级数据面

7.性能和稳定性问题

数据面代理会增加耗时，据蚂蚁商业版本是数据面单跳延迟在0.5ms以内，平均为0.2~0.3ms

稳定性指标的测试