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

Razor

2019/10/19 发布于 技术 分类

文字内容
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版本之后,引入 OutOf-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中国技术社区
36. THANKS http://skyao.io 敖小剑的博客 aoxiaojian@hotmail.com 我的邮箱,欢迎联系