其他
诗和远方:蚂蚁金服 Service Mesh 深度实践 | QCon 实录
The following article is from InfoQ Author 敖小剑
敖小剑,蚂蚁金服高级技术专家,十七年软件开发经验,微服务专家,Service Mesh 布道师,ServiceMesher 社区联合创始人。专注于基础架构和中间件,Cloud Native 拥护者,敏捷实践者,坚守开发一线打磨匠艺的架构师。曾在亚信、爱立信、唯品会等任职,目前就职蚂蚁金服,在中间件团队从事 Service Mesh/ Serverless 等云原生产品开发。本文整理自10月18日在 QCon 上海 2019 上的演讲内容。
前言
2017年,当时 Service Mesh 在国内还属于蛮荒时代,我当时做了一个名为“Service Mesh: 下一代微服务”的演讲,开始在国内布道 Service Mesh 技术; 2018年,做了名为“长路漫漫踏歌而行:蚂蚁金服 Service Mesh 实践探索”的演讲,介绍蚂蚁金服在 Service Mesh 领域的探索性的实践,当时蚂蚁金服刚开始在 Service Mesh 探索。
备注:现场做了一个调研,了解听众对 Servicve Mesh 的了解程度,结果不太理想:在此之前对 Service Mesh 有了解的同学目测只有10%多点(肯定不到20%)。Service Mesh 的技术布道,依然任重道远。
蚂蚁金服落地情况介绍:包括大家最关心的双十一落地情况; 大规模落地的困难和挑战:分享一下我们过去一年中在大规模落地上遇到的问题; 是否采用 Service Mesh 的建议:这个问题经常被人问起,所以借这个机会给出一些中肯的建议供大家参考;
蚂蚁金服落地情况介绍
技术预研 阶段:2017年底开始调研并探索 Service Mesh 技术,并确定为未来发展方向; 技术探索 阶段:2018年初开始用 Golang 开发 Sidecar SOFAMosn,年中开源基于 Istio 的 SOFAMesh; 小规模落地 阶段:2018年开始内部落地,第一批场景是替代 Java 语言之外的其他语言的客户端 SDK,之后开始内部小范围试点; 规模落地 阶段:2019年上半年,作为蚂蚁金融级云原生架构升级的主要内容之一,逐渐铺开到蚂蚁金服内部的业务应用,并平稳支撑了618大促; 全面大规模落地 阶段:2019年下半年,在蚂蚁金服内部的业务中全面铺开,落地规模非常庞大,而且准备迎接双十一大促;
多语言支持:目前除了支持 Java 之外,还支持 Golang,Python,C++,NodeJS 等语言的相互通信和服务治理; 应用无感知的升级:关于这一点我们后面会有特别的说明; 流量控制:经典的 Istio 精准细粒度流量控制; RPC 协议支持:和 Istio 不同,我们内部使用的主要是 RPC 协议; 可观测性;
CPU:CPU 使用在峰值情况下增加8%,均值约增加2%。在最新的一次压测中,CPU 已经优化到基本持平(低于1%); 内存:带 SOFAMosn 的节点比不带 SOFAMosn 的节点内存占用平均多 15M; 延迟:延迟增加平均约0.2ms。部分场景带 SOFAMosn 比不带 SOFAMosn RT 增加约5%,但是有部分特殊场景带 SOFAMosn 比不带 SOFAMosn RT 反而降低7.5%;
业务进程:专注业务实现,无需感知 Mesh; Sidecar 进程:专注服务间通讯和相关能力,与业务逻辑无关;
业务逻辑的占比很高:Sidecar 转发的资源消耗相比之下要低很多,通常是十倍百倍甚至千倍的差异; SDK 也是有消耗的:即使不考虑各种复杂的功能特性,仅仅就报文(尤其是 Body)序列化的编解码开销也是不低的。而且,客户端和服务器端原有的编解码过程是需要处理 Body 的,而在 Sidecar 中,通常都只是读取 Header 而透传 Body,因此在编解码上要快很多。另外应用和 Sidecar 的两次远程通讯,都是走的 Localhost 而不是真实的网络,速度也要快非常多;
备注:这里我依然是刻意拼凑出-7%这个估算结果,请注意这不是准确数值,只是用来模拟示意。
大规模落地的困难和挑战
CPU 优化:在 SOFAMosn 中我们进行了 Golang 的 writev 优化,将多个包拼装一次写以降低 syscall 调用。测试中发现,Golang 1.9 的时候 writev 有内存泄露的 bug。当时 debug 的过程非常的辛苦...... 详情见我们当时给 Golang 提交的 PR: https://github.com/golang/go/pull/32138 内存优化:在内存复用,我们发现报文直接解析会产生大量临时对象。SOFAMosn 通过直接复用报文字节的方式,将必要的信息直接通过 unsafe.Pointer 指向报文的指定位置来避免临时对象的产生; 延迟优化:前面我们谈到 Sidecar 是通过只解析 Header 而透传 Body 来保证性能的。针对这一点,我们进行了协议升级,以便快速读取 Header。比如我们使用的 TR 协议请求头和 Body 均为 hessian 序列化,性能损耗较大。而 Bolt 协议中 Header 是一个扁平化 map,解析性能损耗小。因此我们升级应用改走 Bolt 协议来提升 Sidecar 转发的性能。这是一个典型的针对 Sidecar 特性而做的优化;
序列化优化:我们全面使用 types.Any 类型,弃用 types.Struct 类型,序列化性能提升70倍,整体性能提升4倍。Istio 最新的版本中也已经将默认模式修改为 types.Any 类型。我们还进行了 CR(CustomResource) 的序列化缓存,将序列化时机从 Get/List 操作提前至事件触发时,并缓存结果。大幅降低序列化频率,压测场景下整体性能提升3倍,GC 频率大幅下降; 预计算优化:支持 Sidecar CRD 维度的 CDS /LDS/RDS 预计算,大幅降低重复计算,压测场景下整体性能提升6倍;支持 Gateway 维度的 CDS / LDS / RDS 预计算;计算变更事件的影响范围,支持局部推送,减少多余的计算和对无关 Sidecar 的打扰; 推送优化:支持运行时动态降级,支持熔断阈值调整,限流阈值调整,静默周期调整,日志级别调整;实现增量 ADS 接口,在配置相关处理上,Sidecar cpu 减少90%,Pilot cpu 减少42%;
可灰度:任何变更,都必须是可以灰度的,即控制变更的生效范围。先做小范围内变更,验证通过之后才扩大范围; 可监控:在灰度过程中,必须能做到可监控,能了解到变更之后对系统的应用。如果没有可监控,则可灰度也就没有意义了; 可回滚:当通过监控发现变更后会引发问题时,还需要有方法可以回滚;
互联互通:两个体系中的应用可以相互访问; 平滑迁移:应用可以在两个体系中迁移,对于调用该应用的其他应用,做到透明无感知; 灵活演进:在互联互通和平滑迁移实现之后,我们就可以根据实际情况进行灵活的应用改造和架构演进;
传统注册中心的数据存储能力:支持海量数据; Service Mesh 控制平面的能力:解耦之后 API 设计的弹性和灵活度; 传统注册中心的分发能力:性能、速度、稳定性;
MCP 协议:MCP 协议是 Istio 中用 于Pilot 和 Galley 之间同步数据的协议,源自 xDS 协议。我们设想通过 MCP 协议将不同源的注册中心集成起来,目标是聚合多注册中心的数据到 Pilot 中,实现打通异构注册中心(未来也会用于多区域聚合)。 xDS/UDPA 协议:xDS 协议源自 Envoy,是目前数据平面的事实标准,UDPA 是正在进行中的基于 xDS 协议的标准化版本。Sidecar 基于 xDS/UDPA 协议接入控制平面,我们还有进一步的设想,希望加强 SDK 方案,向 Istio 的功能靠拢,具体表现为 SDK 支持 xDS 协议(初期版本先实现最小功能集)。目标是希望在对接控制平面的前提下,应用可以在 Service Mesh 和 SDK 方案之间自由选择和迁移。
Galley 和底下的 k8s API Server 可以视为一个特殊的注册中心,这是 Istio 的官方方式; Nacos/SOFARegistry 是阿里集团和蚂蚁金服的注册中心,支持海量规模。我们计划添加 MCP 协议的支持,直接对接 Pilot; 其他的注册中心,也可以通过提供 MCP 协议支持的方式,接入到这个方案中; 对于不支持 MCP 的注册中心,可以通过开发一个 MCP Proxy 模块以适配器模式的方式间接接入。当然最理想的状态是出现成熟的通用开源方案来统一解决,比如 Nacos Sync 有计划做类似的事情;
Service Mesh 体系下的 Sidecar(如 Envoy 和蚂蚁金服的 SOFAMosn)目前都已经支持 xDS/UDPA; 相对来说,这个方案中比较“脑洞”的是在 SDK 方案如 Spring Cloud/Dubbo/SOFARPC 中提供 xDS 的支持,以便对接到已经汇总了全局数据的控制平面。从这个角度说,支持 xDS 的 SDK 方案,也可以视为广义的数据平面。我们希望后面可以推动社区朝这个方向推进,短期可以先简单对接,实现 xDS 的最小功能集;长期希望 SDK 方案的功能能向 Istio 看齐,实现更多的 xDS 定义的特性;
是否采用 Service Mesh 的建议
重复建设,重复造轮子; 不同时期,不同厂商,用不同的轮子; 难以维护和演进,后续成本高昂; 掌控力不足,容易受制于人;
最下方是云,以 Kubernetes 为核心,关于这一点社区基本已经达成共识:Kubernetes 就是云原生下的操作系统; 在 Kubernetes 之上,是 Mesh 层。不仅仅有我们熟悉的 Service Mesh,还有诸如 Database Mesh 和 Message Mesh 等类似的其他 Mesh 产品形态,这些 Mesh 组成了一个标准化的通信层; 运行在各种 Mesh 的应用,不管是微服务形态,还是传统非微服务形态,都可以借助 Mesh 的帮助实现应用轻量化,非业务逻辑的各种功能被剥离到 Mesh 中后,应用得以“瘦身减负”; 瘦身之后的应用,其内容主要是业务逻辑实现。这样的工作负载形式,更适合 Serverless 的要求,为接下来转型 Serverless 做好准备;
Service Mesh 的多语言支持和应用无感知升级; 无侵入的为应用引入各种高级特性如流量控制,安全,可观测性; 形成统一的技术栈; 为非业务逻辑相关的功能下沉到基础设施提供可能,帮助应用轻量化,使之专注于业务,进而实现应用云原生化;
总结
经验分享:会有更多的技术分享,包括落地场景,经验教训,实施方案,架构设计… 开源贡献:蚂蚁金服会将落地实践中的技术实现和方案以不同的方式回馈社区,推动 Service Mesh 落地实践。目前这个工作正在实质性的进行中, 请留意我们稍后公布的消息; 商务合作:蚂蚁金服即将推出 Service Mesh 产品,提供商业产品和技术支持,提供金融级特性,欢迎联系; 社区交流:ServiceMesher 技术社区继续承担国内 Service Mesh 布道和交流的重任;欢迎参加我们今年正在持续举办的 Service Mesh Meetup 活动。
2017年,国内 Service Mesh 一片蛮荒的时候,我做了 Service Mesh 的布道,介绍了 Service Mesh 的原理,喊出了“下一代微服务”的口号; 2018年,以蚂蚁金服为代表的国内互联网企业,陆陆续续开始了 Service Mesh 的落地探索,所谓摸着石头过河不外如是。第二次演讲我分享了蚂蚁金服的探索性实践,介绍了蚂蚁金服的 Service Mesh 落地方式和思路。 今天,2019年,第三次演讲,蚂蚁金服已经建立起了全球最大规模的 Service Mesh 集群并准备迎接双十一的严峻挑战,这次的标题也变成了深度实践。
QCon 上海 2017《Service Mesh: 下一代微服务》: https://skyao.io/talk/201710-service-mesh-next-generation-microservice/ QCon 上海 2018《长路漫漫踏歌而行:蚂蚁金服 Service Mesh 实践探索》 SOFAMosn: https://github.com/sofastack/sofa-mosn Golang writev 优化: https://github.com/golang/go/pull/32138 SOFARegistry: https://github.com/sofastack/sofa-registry