蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海
Mesh 模式的引入是实现应用云原生的关键路径,蚂蚁集团已在内部实现大规模落地。随着 Message、DB、Cache Mesh 等更多的中间件能力的下沉,从 Mesh 演进而来的应用运行时将是中间件技术的未来形态。应用运行时旨在帮助开发人员快速的构建云原生应用,帮助应用和基础设施进一步解耦,而应用运行时最核心是 API 标准,期望社区一起共建。
蚂蚁集团 Mesh 化介绍
蚂蚁是一家技术和创新驱动的公司,从最早淘宝里的一个支付应用,到现在服务 全球十二亿用户的大型公司,蚂蚁的技术架构演进大概会分为如下几个阶段:
2006 之前,最早的支付宝就是一个集中式的单体应用,不同的业务做了模块化的开发。
2007 年的时候,随着更多场景支付的推广,开始做了一下应用、数据的拆分,做了 SOA 化的一些改造。
2010 年之后,推出了快捷支付,移动支付,支撑双十一,还有余额宝等现象级产品,用户数到了亿这个级别,蚂蚁的应用数也数量级的增长,蚂蚁自研了很多全套的微服务中间件去支撑蚂蚁的业务;
2014 年,像借呗花呗、线下支付、更多场景更多业务形态的出现,对蚂蚁的可用性和稳定性提出更高的要求,蚂蚁对微服务中间件进行了 LDC 单元化的支持,支撑业务的异地多活,以及为了支撑双十一超大流量的混合云上的弹性扩缩容。
2018 年,蚂蚁的业务不仅仅是数字金融,还有数字生活、国际化等一些新战略的出现,促使我们要有更加高效的技术架构能让业务跑得更快更稳,所以蚂蚁结合业界比较流行的云原生的理念,在内部进行了 Service Mesh、Serverless、可信原生方向的一些落地。
可以看到蚂蚁的技术架构也是跟随公司的业务创新不断演进的,前面的从集中式到 SOA 再到微服务的过程,相信搞过微服务的同学都深有体会,而从微服 务到云原生的实践是蚂蚁近几年自己探索出来的。
为什么要引入 Service Mesh
蚂蚁既然有一套完整的微服务治理中间件,那为什么还需要引入 Service Mesh 呢?
拿蚂蚁自研的服务框架 SOFARPC 为例,它是一个功能强大的 SDK,包含了服务发现、路由、熔断限流等一系列能力。在一个基本的 SOFA(Java) 应用里,业务代码集成了 SOFARPC 的 SDK,两者在一个进程里运行。在蚂蚁的大规模落地微服务之后,我们就面临了如下的一些问题:
升级成本高:SDK 是需要业务代码引入的,每次的升级都需要应用修改代码进行发布。由于应用规模较大,在一些大的技术变更或者安全问题修复的时候。每次需要数千个应用一起升级,费时费力。 版本碎片化:由于升级成本高,SDK 版本碎片化严重,这就导致我们写代码的时候需要兼容历史逻辑,整体技术演进困难。 跨语言无法治理:蚂蚁的中后台在线应用大多使用 Java 作为技术栈,但是在前台、AI、大数据等领域有很多的跨语言应用,例如 C++/Python/Golang 等等,由于没有对应语言的 SDK,他们的服务治理能力其实是缺失的。
我们注意到云原生里有 Service Mesh 一些理念开始出现,所以开始往这个方向探索。在 Service Mesh 的理念里,有两个概念,一个是 Control Plane 控制平面,一个是 Data Plane 数据平面。控制面这里暂时不展开,其中数据平面的核心思想就是解耦,将一些业务无需关系的复杂逻辑(如 RPC 调用里的服务发现、服务路由、熔断限流、安全)抽象到一个独立进程里去。只要保持业务和独立进程的通信协议不变,这些能力的演进可以跟随这个独立的进程自主升级,整个 Mesh 就可以做到统一演进。而我们的跨语言应用,只要流量是经过我们的 Data Plane 的,都可以享受到刚才提到的各种服务治理相关的能力,应用对底层的基础设施能力是透明的,真正的云原生的。
蚂蚁 Mesh 落地过程
所以从 2017 年底开始,蚂蚁就开始探索 Service Mesh 的技术方向,并提出了 基础设施统一,业务无感升级 的愿景。主要的里程碑就是:
2017 年底开始技术预研 Service Mesh 技术,并确定为未来发展方向;
2018 年初开始用 Golang 自研 Sidecar MOSN 并开源,主要支持 RPC 在双十一小范围试点;
2019 年 618,新增 Message Mesh 和 DB Mesh 的形态,覆盖若干核心链路,支撑 618 大促;
2019 年双十一,覆盖了所有大促核心链路几百个应用,支撑当时的双十一大促;
2020 年双十一,全站超过 80% 的在线应用接入了 Mesh 化,整套 Mesh 体系也具备了 2 个月从能力开发到全站升级完成的能力。
蚂蚁 Mesh 落地架构
目前 Mesh 化在蚂蚁落地规模是应用约数千个,容器数十 万的级别,这个规模的落地,在业界是数一数二的,根本就没有前人的路可以学习,所以蚂蚁在落地过程中,也建设一套完整的研发运维体系去支撑蚂蚁的 Mesh 化。
蚂蚁 Mesh 架构大概如图所示,底下是我们的控制平面,里面部署了服务治理中心、PaaS、监控中心等平台的服务端,都是现有的一些产品。还有就是我们的运维体系,包括研发平台和 PaaS 平台。那中间是我们的主角数据平面 MOSN,里面管理了 RPC、消息、MVC、任务四种流量,还有健康检查、监控、配置、安全、技术风险都下沉的基础能力,同时 MOSN 也屏蔽了业务和基础平台的一些交互。DBMesh 在蚂蚁是一个独立的产品,图里就没画出来。然后最上层是我们的一些应用,目前支持 Java、Nodejs 等多种语言的接入。 对应用来说,Mesh 虽然能做到基础设施解耦,但是接入还是需要一次额外的升级成本,所以为了推进应用的接入,蚂蚁做了整个研发运维流程的打通,包括在现有框架上做最简化的接入,通过分批推进把控风险和进度,让新应用默认接入 Mesh 化等一些事情。
同时随着下沉能力的越来越多,各个能力之前也面临了研发协作的一些问题,甚至互相影响性能和稳定性的问题,所以对于 Mesh 自身的研发效能,我们也做了一下模块化隔离、新能力动态插拔、自动回归等改进,目前一个下沉能力从开发到全站推广完成可以在 2 个月内完成。