阿里巴巴集团在内部很早就开始使用 Service Mesh 了，是国内 Service Mesh 应用规模最大的公司之一，为了在集团大规模落地 Service Mesh，在内部对 Envoy 和 Istio 做了大量优化，同时也将这些优化贡献给了社区，目前阿里巴巴是国内对于 Envoy 贡献最多的公司，给 Envoy 贡献了 Dubbo filter、内存优化、EGDS 等。在阿里巴巴内部集群的规模很大，上百万 Endpoint 的集群是很常见的，一个应用通常都会使用上百个服务，频繁的服务上下线都会导致大量的 xDS 推送，我们对 Envoy 和 Istio 做了很多优化以解决这些问题。通过本次的分享，你可以了解到 Envoy 和 Istio 在大规模落地时会遇到的一些问题，以及如何来解决，如 Envoy Subset 重复计算和内存占用大、Istio 全量推送 EDS 导致数据面产生大量的 CPU 开销、Envoy 连接池优化、优雅热升级等问题。

内容大纲

1. 运维和架构

• Service Mesh 的架构演进思路
• 如何控制 Service Mesh 上线的风险
• Service Mesh 在阿里巴巴内部的部署和运维

2. Service Mesh 内部落地所遇到的问题和价值

• 服务规模大
• 接入 Service Mesh 成本高
• Serivce Mesh 价值短期很难体现
• 为什么要落地 Service Mesh

3. 开源和内部优化

• EGDS （解决频繁推送问题）
• Subset 优化（解决 Envoy CPU 和内存高的问题）
• 连接池优化 （解决连接数过多的问题）
• Dubbo filter 优化（解决数据面带来的 RT 损耗）
• 优雅热升级 （数据面频繁升级如何不影响业务）
• 透明拦截 （方便接入 Mesh，控制风险）

4. 未来展望

• 下一步的规划

听众收益

1. 了解 Service Mesh 落地可能会遇到的一些问题
2. 了解 Service Mesh 所带来的一些价值
3. 了解 Service Mesh 在大规模场景下存在哪些问题，如何解决

适合人群

CIO、架构上、运维、希望在 Istio/Envoy 上做二次开发的人，对 Service Mesh 感兴趣的人。