Service Mesh在超大规模场景下的最佳实践

1、Service Mesh在超大规模场景下的最佳实践技术创新，变革未来分布式应用架构在阿里巴巴的现状围绕电商业务构建了最庞大的微服务架构应用生态业务复杂，天猫、淘宝、菜鸟、高德、饿了么、考拉、Dubbo RPC 是连接微服务的主要方式，MetaQ 用于服务间异步解耦Java技术栈具有最完备的微服务治理能力，其他技术栈的微服务治理能力偏弱服务可见性无隔离Dubbo RPC 仍是接口级服务发现正经历着 Pandora/SDK 升级之痛Service Mesh 落地所面临的挑战新技术自身如何平滑演进如何协调好技术与业务的发展技术向前演进时又如何处置历史包袱克服超大规模所带来的问题Mesh Sideca

2、r的规模化运维新技术在架构上平滑演进是关键演进演进数据平面和控制平面并重 发展经历了三种形态演进三位一体一定是终态规模化落地方案能更好地 反哺 Istio 和 Envoy 开源 社区业务与技术协同发展 飞行中换引擎永远不可回避的话题：“新技术对业务的价值”着手短期价值并放眼长远价值短期价值中间件能力下沉，去除历史包袱让技术轻装上阵向前演进业务对中间件升级无感，中间件资源消耗可量化、优化可度量长远价值业务与基础技术全面解耦，业务更聚集于自身而加速创新，基础技术独立演进而加速迭代对微服务生态完成标准化、体系化的收口与治理，收敛故障和促进安全生产为多种编程语言的应用提供微服务治理能力，完善并丰富云原

3、生多编程语言的应用生态共建全球事实标准，通过阿里云的产品落实客户 IT 设施的多云和混合云战略，加速中国社会的数字化转型业务与技术协同发展 飞行中换引擎动态流量无损透明拦截实现无侵入业务mesh化过去现在终态（云原生）业务与技术协同发展 飞行中换引擎流量无损热升级RPC Consumer 视角技术方案的ROI 是核心考量业务与技术协同发展 飞行中换引擎流量无损热升级RPC Provider 视角同一机制发展新技术是偿还技术债的重要契机“不变”从来都无法消除“技术债”的风险“技术债”属于软件的本质属性， “还债”是常态Dubbo Groovy 脚本所带来的问题过于灵活而导致了开发框架与应用代码的

4、耦合给流量治理能力下沉制造了障碍扩展 Istio 的 VirtualService 和 DestinationRule 去除 Groovy 脚本兼容平滑演进仍是关键抽象出按应用名、方法和参数路由的能力系统性解决超大规模问题多途径探索解决Service Mesh 技术自身持续优化Dubbo 实现应用级服务发现服务注册数据进行单元封闭并分级治理阿里对开源社区的阶段性贡献Istio 开源社区：提交 9 个 PR，解决性能问题和 bugfixEnvoy 开源社区：提交 14 个 PR，内存开销下降 50%，新增对 Dubbo、RocketMQ 协议 的支持曾实现了 EGDS 但没能提交到 Istio 和 Envoy 开源社区系统性解决超大规模问题大规模落地方案所取得的显著优化效果应用mesh化后数据推送的CPU开销大幅下降应用mesh化后内存开销下降直连注册 中心方案走Pilot的纯 EDS方案Mesh方案 Java SDK方案系统性解决超大规模问题后续计划考虑参与共建 Envoy 社区所提出的 LEDS 协议，让 Istio + Envoy 天然支持超大规模Mesh Sidecar 的规模化运维基于 OpenKruise 的 Sidec