诗和远方：蚂蚁金服 Service Mesh 深度实践

如果无法正常显示，请先停止浏览器的去广告插件。

1. 诗和远方蚂蚁金服 Service Mesh 深度实践敖小剑 @ 蚂蚁金服

3. 前言 • • 2017年：“Servicemesh: 下一代微服务”，布道Servicemesh技术 2018年：“长路漫漫踏歌而行：蚂蚁金服Service Mesh实践探索”，介绍蚂蚁金服在ServiceMesh领域的探索性实践今天，有幸第三次来到QCon，给大家带来的依然是蚂蚁金服在Servicemesh 领域的实践分享。和去年不同的是，今年蚂蚁金服进入了Servicemesh落地的深水区，规模巨大，而且即将迎来双十一大促考验。

4. 1 蚂蚁金服落地情况介绍（双十一） 2 内容 3 大规模落地的困难和挑战是否采用ServiceMesh的建议

5. 1 蚂蚁金服落地情况介绍（双十一）

6. 04 规模落地 03 2019年上半年，作为蚂蚁金融级云原生架构升级的主要内容之一，逐渐铺开到蚂蚁主站的业务应用，并平稳支撑了618大促 2018年开始内部落地，第一批场景是替代Java语言之外的其他语言的客户端SDK，之后开始内部小范围试点。小规模落地全面大规模落地 2019年下半年，在蚂蚁主站的业务中全面铺开，落地规模非常庞大，而且准备迎接双十一大促。应用数百个容器 10万+ 02 技术探索 2018年初开始用 Golang开发Sidecar SOFAMosn，年中开源基于Istio的SOFAMesh 01 技术预研 2017年底开始调研并探索Servicemesh技术，并确定为未来发展方向

7. • • • • • 多语言支持 *应用无感知的升级* 流量控制 RPC协议支持可观测性主要落地场景另外网商银行也在开始落地，除了常规功能外，主要使用场景是安全，如通讯加密、身份认证、服务鉴权等，包括支持国密算法。

8. 调查：大家最关心、最想看到的是什么？性能 Service （client） Sidecar Service （server）控制平面 Sidecar

9. 大促压测数据：对比带MOSN和不带MOSN +15M -7.5%~+5% 约0.2ms +0%~+2% CPU 内存延迟 CPU在峰值情况下增加 8%，均值约2%。带 Mosn 的节点比不带 Mosn 的节点内存平均多 15M 延迟增加约0.2ms。最新的一次压测，CPU已经基本持平。是不是感觉不科学？部分场景带MOSN比不带 MOSN RT增加约5%。部分场景带MOSN比不带 MOSN RT反而降低7.5%

10. 回顾ServiceMesh的基本思路：关注点分离 + 独立维护 - 专注服务间通讯和相关能力 - 与业务逻辑无关 - 专注业务实现 - 无需感知Mesh Service Service 业务逻辑 SDK 协议编解码服务发现将SDK客户端的功能剥离业务逻辑轻量级SDK 协议编解码服务发现负载均衡负载均衡熔断限流服务路由 …… 混合在一个进程内，应用既有业务逻辑，也有各种功能 + Sidecar （MOSN）业务进程专注于业务逻辑熔断限流服务路由 …… SDK中的大部分功能，拆解为独立进程，以Sidecar的模式运行

11. 真实世界中的应用和ServiceMesh Service Service （client） Sidecar 业务逻辑 1. 真实世界中，业务逻辑的占比很高，Sidecar转发的资源消耗相比之下要低很多 Sidecar 服务发现负载均衡 2. 真实世界中，SDK也是有消耗的，报文（body）序列化的编解码开销不低熔断限流服务路由 …… 推论：3倍推论：+2% 直连：业务逻辑=0，SDK=0，总开销=远程调用*1+0+0=1 直连：业务逻辑=100，SDK=10，总开销=远程调用*1+100+10=111 Mesh：业务逻辑=0，SDK=0，总开销=远程调用*3+0+0=3 Mesh：业务逻辑=100，SDK=10，总开销=远程调用*3+100+10=113

12. 意外惊喜：持续不断的优化+无感知升级=快速获得收益 Service 业务逻辑 Service SDK 业务逻辑协议编解码轻量级SDK 服务发现负载均衡 3. SDK的升级需要应用配合，这通常是一个漫长的等待过程 + Sidecar （MOSN）协议编解码服务发现负载均衡熔断限流服务路由 …… 2. 理论上说这些优化在 SOFARPC （SDK）中也能够做，但要等链路上的应用全部升级才能完全显现。 1. 主要的原因是我们在 MOSN上做了大量的优化，特别是路由的缓存熔断限流服务路由 …… 直连：业务逻辑=100，SDK=10，总开销=远程调用*1+100+10=111 Mesh：业务逻辑=100，SDK=1 ，总开销=远程调用*3+100+ 1=104 SDK下沉到基础设施后具备独立升级能力带来的红利

13. 2 大规模落地的困难和挑战

14. 困难和挑战：当Servicemesh遇到蚂蚁金服的规模稳定性 Stability 容量 Capability 性能 Performance 可维护性 Maintenance 当规模达到一定程度时，很多原本很小的问题都会急剧放大应用迁移 Migration

15. CPU优化内存优化延迟优化 § Golang writev 优化：多个包拼装一次写降低 syscall 调用，我们在 go 1.9 的时候发现 writev 有内存泄露的bug，内部使用的目前是 patch 了 writev bugfix 的 go 1.12。writev bugfix 已经集成在 go 1.13 中。 § 内存复用：报文直接解析可能会产生大量临时对象，mosn 通过直接复用报文字节的方式，将必要的信息直接通过 unsafe.Pointer 指向报文的指定位置来避免临时对象的产生。 § 协议升级，快速读取header： TR 协议请求头和 Body 均为 hessian 序列化，性能损耗较大。而 Bolt 协议中 Header 是一个扁平化map，解析性能损耗小。升级应用走 Bolt 协议来提升性能详情见我们当时给go提交的PR： https://github.com/golang/g o/pull/32138 § 路由缓存：内部路由的复杂性（一笔请求经常需要走多种路由策略最终确定路由结果目标），通过对相同条件的路由结果做秒级缓存，我们成功将某核心链路的全链路 RT 降低 7% 性能优化@数据平面：MOSN的各种性能优化

16. 性能优化@Mixer：老生常谈，避无可避 Mixer的性能问题，一直都是Istio中最被人诟病的地方。在Istio 1.1/1.2版本之后，引入 Out- Of-Process Adapter之后，更是雪上加霜 Mixer V1 （生命无法承受之重）折衷落地方案（眼前的苟且） Mixer V2 （诗和远方）对于生产级落地而言，性能难于接受，更不要提大规模落地…… 弃用Mixer v1，改为在MOSN 中直接实现功能，并只提供最基本的策略检查功能如限流，鉴权等 Mixer合并进Sidecar，引入 web assembly进行Adapter扩展，这是Mixer的正确姿势。然后社区望穿秋水，但迟迟不能启动，远水解不了近渴

17. 序列化优化预计算优化推送优化 § xds序列化升级：全面使用 types.Any类型，弃用 types.Struct类型，序列化性能提升70倍，整体性能提升4倍 § 支持Sidecar CRD维度的CDS /LDS/RDS 预计算，大幅降低重复计算，压测场景下整体性能提升6倍 § 支持运行时动态降级，支持熔断阈值调整，限流阈值调整，静默周期调整，日志级别调整 § CR序列化缓存，将序列化时机从 Get/List操作提前至事件触发时，并缓存结果。大幅降低序列化频率，压测场景下整体性能提升3 倍，GC频率大幅下降 § 支持Gateway维度的CDS / LDS / RDS 预计算 § 实现增量ADS接口，在配置相关处理上，sidecar cpu减少90%， pilot cpu减少42% § 计算变更事件的影响范围，支持局部推送，减少多余的计算和对无关sidecar的打扰性能优化@Pilot：被Mixer掩盖的重灾区

18. 运维：线上变更三板斧可监控可灰度可回滚生产无小事，变更需谨慎

19. 应用迁移：SOFA双模微服务平台双模微服务 = 传统微服务 + Service Mesh 双剑合璧服务路由服务限流服务拓扑实时监控 DB Advisor 安全加固 ........ SOFA 服务注册中心 Service Mesh 控制平面 Galley Pilot VM Pod VM Citadel Pod Inspector Pod Dubbo 应用 SOFA 应用 SOFA 应用 Dubbo 应用 Spring Cloud 应用 SOFA SDK SOFA SDK SOFAMosn SOFAMosn SOFAMosn 基于SDK的传统微服务互联互通，平滑迁移，灵活演进基于Sidecar的ServiceMesh微服务

20. 控制平面和传统注册中心/配置中心：各有千秋，如何结合？优点：支持海量数据，极强的分发能力，稳定可靠久经考验缺点：数据透传，大量控制逻辑需要在SDK中实现各种注册中心/配置中心 Nacos APP 内部实现机制 SOFARegistry SDK 其他注册中心如何打通两个体系是ServiceMesh社区的老大难问题 APP Sidecar xDS/UDPA DDS等扩展控制平面（Pilot） MCP 优点：控制平面提供强大的控制逻辑，解藕数据源和下发数据，扩展性好缺点：支持的容量有限，下发的性能和稳定性相比之下有差距 ServiceMesh/Istio方案 Galley k8s API Server

21. 以MCP和xDS/UDPA为基础，融合控制平面和传统注册中心/配置中心设想：加强SDK，向Istio的功能靠拢目标：在Mesh和SDK方案之间自由选择和迁移新产品形态的能力来自： 1. 传统注册中心的数据存储能力 2. ServiceMesh控制平面的能力 3. 传统注册中心的分发能力 APP 带控制平面的注册中心/配置中心存储/分发能力加强版的控制平面各节点的通讯交互协议标准化 • • • 各种注册中心 SDK xDS/UDPA MCP Galley MCP 控制平面（Pilot） APP Sidecar xDS/UDPA DDS等扩展 Nacos MCP MCP SOFARegistry MCP MCP 支持MCP的注册中心 MCP Proxy 其他注册中心 Nacos sync 其他注册中心设想：通过MCP机制将不同源的注册中心集成起来目标：聚合多注册中心，打通异构注册中心

22. 最大限度的整合传统微服务框架和ServiceMesh：求同存异，保持兼容 SDK对接xDS，实现最小功能集可以社区共建 APP dubbo/HSF xDS/UDPA APP SOFARPC xDS/UDPA APP xDS/UDPA Spring Cloud APP Envoy MCP 控制平面（Pilot） xDS/UDPA 具备各种双模能力： 1. ServiceMesh与SDK 2. 容器（k8s）和虚拟机 MOSN MCP MCP Nacos MCP SOFARegistry C R D 扩展 MCP 支持MCP的注册中心 MCP xDS/UDPA APP Galley 控制台（web console） MCP Proxy 其他注册中心 Nacos Sync 其他注册中心通用的功能模块不通用的模块，但是API兼容

23. 3 是否采用ServiceMesh的建议

24. 如有下述痛点，可以考虑Servicemesh 多语言支持类库升级困难

25. 无侵入性：老应用无改动升级改造，堪称神器掌控系统流量确保系统安全 • 精准的流量控制 • 完善的可观测性 • 无侵入 • 零信任网络 • 身份/加密/访问控制 • 无侵入 01 02 流量控制安全观察系统行为 • 监控 • Metrics • 无侵入 03 可观测

26. 拿什么拯救你：技术栈不统一受制于人的中小企业传统烟囱架构 Ø 重复建设，重复造轮子 Ø 不同时期，不同厂商，用不同的轮子 Ø 难以维护和演进，后续成本高昂 Ø 掌控力不足，容易受制于人

27. 对于技术力量不足、严重依赖外包和采购的中小企业，尤其是银行/保险/证券类金融企业将乙方限制在业务逻辑的实现上避免乙方公司借项目机会引入： • • 各种技术栈：造成技术栈混乱，后期维护成本超高私有技术栈：造成对甲方事实上的技术绑定（甚至技术绑架）

28. 如果云原生是你的诗和远方 Micro Service Micro Service Micro Service App App App App Container Function 业务逻辑业务逻辑业务逻辑工作负载瘦身减负应用轻量化通信标准化 Mesh Cloud Service Mesh Security Storage Serverless Automatic scaling DB Mesh Network Schedule On Demand Zero Administration Msg Mesh Monitoring Mesh化是云原生落地的关键步骤 HA 助力转型 serverless

29. kubernetes 云原生时代的操作系统 Service Mesh Serverless 将应用与服务间通讯解耦将应用与服务器解耦云原生落地的三驾马车：相辅相成，相得益彰

30. Service Mesh的核心价值实现业务逻辑和非业务逻辑的分离 - 为下沉到基础设施提供可能 - 帮助应用轻量化，专注业务 - 进而实现应用云原生化

31. 4 总结

32. 静待双十一大考：ServiceMesh的历史时刻，敬请期待商务合作 Business 蚂蚁金服即将推出ServiceMesh产品，提供商业技术支持分享 Sharing 更多的技术分享：落地场景，经验教训，实施方案，架构设计… 落地数据 Data 公布更详细的落地数据，包括规模和性能表现，提振业界信心开源 Open Source 将落地实践中的技术实现和方案以不同的方式回馈社区，推动Servicemesh落地实践社区交流 Community Servicemesher技术社区继续承担国内 Servicemesh布道和交流的重任；加强和Istio的合作，和社区一起前进

33. 我们的ServiceMesh，我们的诗和远方……

34. 欢迎加入Service Mesher技术社区 Service Mesh Meetup Next：10月26日，相约成都！ http://www.servicemesher.com ServiceMesh中国技术社区

35.

36. THANKS http://skyao.io 敖小剑的博客 aoxiaojian@hotmail.com 我的邮箱，欢迎联系