诗和远方:蚂蚁金服 Service Mesh 深度实践
如果无法正常显示,请先停止浏览器的去广告插件。
1. 诗和远方
蚂蚁金服 Service Mesh 深度实践
敖小剑 @ 蚂蚁金服
2.
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
我的邮箱,欢迎联系