ServiceMesh上线需要解决的问题性埋下隐患。目前，整个开源生态的成熟度还有待提高。本文总结了在测试ServiceMesh过程中发现的问题。1.目标与价值业务方只需要引入轻量级SDK，其他基础能力下沉到网格SideCar代理中。一个美好的愿望是“接管所有与业务无关的能力”。1.业务赋能价值提升开发效率：只需要专注业务，加速业务探索：快速迭代上线，快速无感知验证代理升级：无需努力推动业务升级或卡点升级带来的各种问题2.运维提升统一有效性和价值治理体系：屏蔽不同语言系统治理的复杂性统一技术演进：无需关心版本碎片化问题，能力统一，自我进化2.组织整合如果ServiceMesh是作为公司战略推广，ServiceMesh依托于Kubernetes基础，相关人员最好整合到一个部门统一运维和开发。将ServiceMesh团队、Serverless团队、容器团队整合为一个部门，负责云原生系统的建设。其他部门配合改造衔接。总结。1、注册中心接入服务网格的目的：公司现有注册中心接入服务网格（Istio），完成服务注册和发现能力基本原理：将离网注册中心通过Istio提供的ServiceEntryhttps://img.ydisp.cn/news/20220903/kdcs2rvqls2data-id="h26976cb-b7MPJR4B"id="h26976cb-b7MPJR4B">2.RPC框架协议兼容性问题实现目的：需要实现网格内外通信，则网格中的服务调用原有服务，需要支持原有的RPC协议基本原则：与使用的RPC框架相关联。如果使用gRPC自研，因为Istio原生支持HTTP/2，变化很小。如果使用dubbo或者自研的RPC框架，可以通过EnvoyFilter转换来实现。可以参考腾讯的开源框架aerakihttps://github.com/aeraki-framework/aeraki3。网格流量治理问题实现目标：网格流量需要支持限流、熔断等治理能力，并与现有融合治理平台集成的基本原则：通过Envoy提供的Filter插件机制，限流配置和EnvoyFilter规则被映射以完成限流。可以参考网易开源的slime框架https://github.com/slime-io/slime4.grid流量监控问题的目的：网格流量的监控指标和埋点需要和原来的监控结合起来系统。实现原理：Istio提供了kiali、jaeger、grafana、prometheus相关的监控系统，并将这些表接入到原有的监控系统中。另外，可以通过wasm扩展一些自定义的监控指标。https://img.ydisp.cn/news/20220903/h3dua0wp0s5data-id="h26976cb-keBjLTIg"id="h26976cb-keBjLTIg">5.按需订阅配置（懒加载）问题默认情况下，Istio会将注册中心配置信息全量下发，占用内存过多，严重影响性能。常见的解决方案有：社区SidecarScope的全局隔离代理方案第一步是去代理获取服务依赖的配置，之后就不再需要和代理通信（参考Slime提供的懒加载功能）并维护它通过在SideCar中同时部署Agent服务依赖6.热部署和升级问题在部署和升级agentSideCar时，需要做到平滑，先抽取流量再部署升级。进程级代理模式，监控，版本管理，数据平面升级。双容器模式，一个容器在运行，另一个容器在Standby；Standby容器升级后，检测正常后切换到依赖应用发布和升级数据面。7.性能和稳定性问题是数据平面上的代理会增加时间消耗。根据Ant商用版，数据面单跳延迟在0.5ms以内，稳定性指标测试中平均值为0.2~0.3ms。
