关于云原生-cloud-native:蚂蚁云原生应用运行时的探索和实践-ArchSummit-上海

6次阅读

共计 5397 个字符，预计需要花费 14 分钟才能阅读完成。

Mesh 模式的引入是实现利用云原生的要害门路，蚂蚁团体已在外部实现大规模落地。随着 Message、DB、Cache Mesh 等更多的中间件能力的下沉，从 Mesh 演进而来的利用运行时将是中间件技术的将来状态。利用运行时旨在帮忙开发人员疾速的构建云原生利用，帮忙利用和基础设施进一步解耦，而利用运行时最外围是 API 规范，冀望社区一起共建。

蚂蚁是一家技术和翻新驱动的公司，从最早淘宝里的一个领取利用，到当初服务
寰球十二亿用户的大型公司，蚂蚁的技术架构演进大略会分为如下几个阶段：

2006 之前，最早的支付宝就是一个集中式的单体利用，不同的业务做了模块化的开发。

2007 年的时候，随着更多场景领取的推广，开始做了一下利用、数据的拆分，做了 SOA 化的一些革新。

2010 年之后，推出了快捷领取，挪动领取，撑持双十一，还有余额宝等景象级产品，用户数到了亿这个级别，蚂蚁的利用数也数量级的增长，蚂蚁自研了很多全套的微服务中间件去撑持蚂蚁的业务；

2014 年，像借呗花呗、线下领取、更多场景更多业务状态的呈现，对蚂蚁的可用性和稳定性提出更高的要求，蚂蚁对微服务中间件进行了 LDC 单元化的反对，撑持业务的异地多活，以及为了撑持双十一超大流量的混合云上的弹性扩缩容。

2018 年，蚂蚁的业务不仅仅是数字金融，还有数字生存、国际化等一些新策略的呈现，促使咱们要有更加高效的技术架构能让业务跑得更快更稳，所以蚂蚁联合业界比拟风行的云原生的理念，在外部进行了 Service Mesh、Serverless、可信原生方向的一些落地。

能够看到蚂蚁的技术架构也是追随公司的业务翻新一直演进的，后面的从集中式到 SOA 再到微服务的过程，置信搞过微服务的同学都深有体会，而从微服务到云原生的实际是蚂蚁近几年本人摸索进去的。

蚂蚁既然有一套残缺的微服务治理中间件，那为什么还须要引入 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 的，都能够享受到方才提到的各种服务治理相干的能力，利用对底层的基础设施能力是通明的，真正的云原生的。

所以从 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 架构大略如图所示，底下是咱们的管制立体，外面部署了服务治理核心、PaaS、监控核心等平台的服务端，都是现有的一些产品。还有就是咱们的运维体系，包含研发平台和 PaaS 平台。那两头是咱们的配角数据立体 MOSN，外面治理了 RPC、音讯、MVC、工作四种流量，还有健康检查、监控、配置、平安、技术危险都下沉的根底能力，同时 MOSN 也屏蔽了业务和根底平台的一些交互。DBMesh 在蚂蚁是一个独立的产品，图里就没画进去。而后最上层是咱们的一些利用，目前反对 Java、Nodejs 等多种语言的接入。
对利用来说，Mesh 尽管能做到基础设施解耦，然而接入还是须要一次额定的降级老本，所以为了推动利用的接入，蚂蚁做了整个研发运维流程的买通，包含在现有框架上做最简化的接入，通过分批推动把控危险和进度，让新利用默认接入 Mesh 化等一些事件。

同时随着下沉能力的越来越多，各个能力之前也面临了研发合作的一些问题，甚至相互影响性能和稳定性的问题，所以对于 Mesh 本身的研发效力，咱们也做了一下模块化隔离、新能力动静插拔、主动回归等改良，目前一个下沉能力从开发到全站推广实现能够在 2 个月内实现。

大规模落地后的新问题与思考

蚂蚁 Mesh 大规模落地之后，目前咱们遇到了一些新的问题：
跨语言 SDK 的保护老本高：拿 RPC 举例，大部分逻辑曾经下沉到了 MOSN 里，然而还有一部分通信编解码协定的逻辑是在 Java 的一个轻量级 SDK 里的，这个 SDK 还是有肯定的保护老本的，有多少个语言就有多少个轻量级 SDK，一个团队不可能有精通所有语言的研发，所以这个轻量级 SDK 的代码品质就是一个问题。

业务兼容不同环境的新场景：蚂蚁的一部分利用是既部署在蚂蚁外部，也对外输入到金融机构的。当它们部署到蚂蚁时，对接的是蚂蚁的管制面，当对接到银行的时候，对接的是银行已有的管制面。目前大多数利用的做法是本人在代码里封装一层，遇到不反对的组件就长期反对对接一下。

从 Service Mesh 到 Multi-Mesh：蚂蚁最早的场景是 Service Mesh，MOSN 通过网络连接代理的形式进行了流量拦挡，其它的中间件都是通过原始的 SDK 与服务端进行交互。而当初的 MOSN 曾经不仅仅是 Service Mesh 了，而是 Multi-Mesh，因为除了 RPC，咱们还反对了更多中间件的 Mesh 化落地，包含音讯、配置、缓存的等等。能够看到每个下沉的中间件，在利用侧简直都有一个对应的轻量级 SDK 存在，这个在联合方才的第一问题，就发现有十分多的轻量级 SDK 须要保护。为了放弃性能不相互影响，每个性能它们开启不同的端口，通过不同的协定去和 MOSN 进行调用。例如 RPC 用的 RPC 协定，音讯用的 MQ 协定，缓存用的 Redis 协定。而后当初的 MOSN 其实也不仅仅是面向流量了，例如配置就是裸露了一下 API 给业务代码去应用。

为了解决方才的问题和场景，咱们就在思考如下的几个点：

1. 不同中间件、不同语言的 SDK 是否格调对立？

2. 各个下沉能力的交互协定是否对立？

3. 咱们的中间件下沉是面向组件还是面向能力？

4. 底层的实现是否能够替换？

从去年的 3 月份开始，通过外部的多轮探讨，以及对业界一些新理念的调研，咱们提出了一个“云原生利用运行时”（下称运行时）的概念。顾名思义，咱们心愿这个运行时可能蕴含利用所关怀的所有分布式能力，帮忙开发人员疾速的构建云原生利用，帮忙利用和基础设施进一步解耦！

云原生利用运行时设计里外围的几个点如下：
第一，因为有了 MOSN 规模化落地的教训和配套的运维体系，咱们决定基于 MOSN 内核去开发咱们的云原生利用运行时。
第二，面向能力，而不是面向组件，对立定义出这个运行时的 API 能力。
第三，业务代码和 Runtime API 之间的交互采纳对立的 gRPC 协定，这样的话，业务端侧能够间接通过 proto 文件去反向生成一个客户端，间接进行调用。
第四，能力前面对应的组件实现是能够替换的，例如注册服务的提供者能够是 SOFARegistry，也能够是 Nacos 或者 Zookeeper。

运行时能力形象

为了形象出云原生利用最须要的一些能力，咱们先定了几个准则：

1. 关注分布式应用所需的 API 和场景而不是组件；
2.API 合乎直觉，开箱即用，约定优于配置；
3.API 不绑定实现，实现差异化应用扩大字段。

有了准则之后，咱们就形象出了三组 API，别离是利用调用运行时的 mosn.proto，运行时调用利用的 appcallback.proto，运行时运维相干的 actuator.proto。例如 RPC 调用、发消息、读缓存、读配置这些都属于利用到运行时的，而 RPC 收申请、收音讯、接管任务调度这些属于运行时调利用的，其它监控查看、组件治理、流量管制这些则属于运行时运维相干的。

这三个 proto 的示例能够看下图：

运行时组件管控

另外一方面，为了实现运行时的实现可替换，咱们也在 MOSN 提了两个概念，咱们把一个个分布式能力称为 Service，而后有不同的 Component 去实现这个 Service，一个 Service 能够有多个组件实现它，一个组件能够实现多个 Service。例如图里的示例就是有“MQ-pub”这个发消息的 Service 有 SOFAMQ 和 Kafka 两个 Component 去实现，而 Kafka Component 则实现了发消息和健康检查两个 Service。
当业务真正通过 gRPC 生成的客户端发动申请的时候，数据就会通过 gRPC 协定发送给 Runtime，并且散发到前面一个具体的实现下来。这样的话，利用只须要应用同一套 API，通过申请里的参数或者运行时的配置，就对接到不同的实现。

运行时和 Mesh 的比照

综上所述，云原生利用运行时和方才 Mesh 简略比照如下：

云原生利用运行时落地场景
从去年中开始研发，运行时目前在蚂蚁外部次要落地了上面几个场景。

异构技术栈接入

在蚂蚁，不同的语言的利用除了 RPC 服务治理、音讯等的需要之外，还心愿应用上蚂蚁对立的中间件等基础设施能力，Java 和 Nodejs 是有对应的 SDK 的，而其余语言是没有的对应的 SDK 的。有了利用运行时之后，这些异构语言就能够间接通过 gRPC Client 调用运行时，对接上蚂蚁的基础设施。

解除厂商绑定

方才提到，蚂蚁的区块链、风控、智能客服、金融中台等等业务是既在主站部署，又有阿里云或者专有云部署的场景。有了运行时之后，利用能够一套代码和运行时一起出一个镜像，通过配置去决定调用哪个底层的实现，不跟具体的实现绑定。例如在蚂蚁外部对接的是 SOFARegistry 和 SOFAMQ 等产品，而到云上对接的是 Nacos、RocketMQ 等产品，到专有云对接的又是 Zookeeper、Kafka 等。这个场景咱们正在落地当中。当然这个也能够用在遗留零碎治理上，例如从 SOFAMQ 1.0 降级到 SOFAMQ 2.0，接了运行时的利用也无需降级。

FaaS 冷启预热池

FaaS 冷启预热池也是咱们近期在摸索的一个场景，大家晓得 FaaS 里的 Function 在冷启的时候，是须要从创立 Pod 到下载 Function 再到启动的，这个过程会比拟长。有了运行时之后，咱们能够提前把 Pod 创立进去并启动好运行时，等到利用启动的时候其实曾经非常简单的应用逻辑了，通过测试发现能够将从 5s 缩短 80% 到 1s。这个方向咱们还会继续摸索当中。

API 共建

运行时里最次要的一部分就是 API 的定义，为了落地外部，咱们曾经有一套较为残缺的 API，然而咱们也看到业界的很多产品有相似的诉求，例如 dapr、envoy 等等。所以接下来咱们会去做的一件事件就是联结各个社区去推出一套大家都认可的云原生利用 API。

继续开源

另外咱们近期也会将外部的运行时实际逐渐开发进去，预计五六月份会公布 0.1 版本，并放弃每月公布一个小版本的节奏，争取年底之前公布 1.0 版本。

最初做一下小结：

1.Service Mesh 模式的引入是实现利用原云生的要害门路；
2. 任何中间件兼可 Mesh 化，但研发效率问题仍然局部存在；
3.Mesh 大规模落地是工程化的事件，须要残缺的配套体系；
4. 云原生利用运行时将是中间件等根底技术的将来状态，进一步解耦利用与分布式能力；
5. 云原生利用运行时外围是 API，冀望社区共建一个规范。

延长浏览