引言
越来越多的公司开始研究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
稳定性指标的测试
