蚂蚁金服大规模微服务实践！

章耿，花名余淮，蚂蚁金服高级技术专家。

2007 年毕业后一直从事服务化相关的工作，最早在国家电网做电子商务平台 SOA 化的工作，之后在京东负责京东的服务化框架 JSF，目前在蚂蚁金服中间件服务与框架组负责应用框架及 SOFAStack 相关的工作。

本文是根据余淮在 2018 开源中国年终盛典的演讲内容整理，干货满满，诚意十足，这也是场主推荐这篇文章的原因。

注：【完整的分享 PPT 获取方式见文末

】

本次分享主要分为三部分：

• 蚂蚁金服服务化架构演进
• 蚂蚁金服微服务体系
• 蚂蚁金服 SOFAStack 的开源情况

1、蚂蚁金服服务化架构演进

在开始讲架构演进之前，我们先来看一组数据。

这是历年来的双十一数据图，柱状是双十一的交易额，从最初到20亿到去年的1682亿，今年是2135亿。而橙色的折线则是支付宝双十一 0 点的交易峰值，去年是 26.5w笔每秒，今年更高。

支撑这些数字的背后，是蚂蚁金融科技的一些核心技术，我们可以看到有三地五中心多活架构，分布式数据库OceanBase，金融级分布式架构SOFAStack，还有更多的一些黑科技，例如Zoloz生物识别，蚂蚁区块链，第五代智能风控引擎。

罗马不是一天建成的，蚂蚁金服科技的技术也不是最早就设计成这样，和所有的大公司发展一样，目前这些技术架构也是随着业务发展、系统的壮大，一步一步演进而来的。

下面给大家介绍下蚂蚁的演进。

这个是支付宝最早的架构示意图，可以看到当时支付宝只是电商后台的一个支付系统，是一个单体应用，里面简单的分了几个业务模块，连的也是一个数据库。但随着业务规模的不断扩展，单系统架构已经无法满足业务需求。

所以支付宝就对大系统进行了拆分，将原来的一个单体应用内部的多个模块变成了多个独立的子系统，这算是典型的 SOA 化的架构。最开始系统之间是使用 F5 的硬件负载设备来做系统间的负载均衡，但由于 F5 设备存在单点的问题，所以后面就在中间引入一个注册中心的组件。

服务提供者去注册中心注册服务，服务消费者去注册中心订阅服务列表，服务消费者通过软负载方式通过 RPC 框架直接调用服务提供者。这在现在看来是一种非常显而易见的服务化架构，但当时 07 年就采用这样的架构还是算比较超前的。支付宝在做系统拆分的同时，对数据库也按子系统进行了垂直拆分。数据库的拆分就会引入分布式事务的问题，蚂蚁金服中间件就提供了基于 TCC 思想的分布式事务组件 DTX。

业务还是不断扩展，系统也越来越多，当系统节点到一定数量的时候，单个物理机房已经无法承受。另外考虑到同城容灾的问题，支付宝就在同城再扩建另外一个机房，通过专线部署为一个内部网络，然后将应用部署上去。

同城多机房会引入一个跨机房远程访问的问题，相比同机房调用，这个延迟损耗一定是更高的。远程访问主要包括两种：RPC 调用和数据库访问。为了解决 RPC 跨机房调用的问题，支付宝的工程师选择的方案是在每个机房都部署注册中心，同机房优先调用本机房服务的方式，也就变成图中的部署模式。但是数据库跨机房访问的问题，在这个阶段并没有解决。

为了解决上面的跨机房数据访问、数据库连接数瓶颈以及未来数据水平扩展的问题，蚂蚁的工程师们设计了一套单元化的架构，这是单元化的一个示意图。在没有单元化的时候，用户请求进入内部后，所有请求链路都是随机走的，例如图里的 S0 到 B1 到 C2 到 D0。

首先蚂蚁的请求都是跟用户相关的，所以我们将数据按用户的维度进行水平分片，例如这张示意图我们将所有用户分为三组。然后我们将我们的应用也部署成三组独立的逻辑单元，每个逻辑单元的应用和数据都是独立的，相当于每个逻辑单元都处理1/3总量用户的数据。

这个时候我们的三个不同终端的用户，不管是在PC端或者手机端或者扫二维码，当请求进入统一接入层的时候，接入层会按上面逻辑单元的分组规则，将用户请求转发到对应的逻辑单元，例如 user0 的请求转到 S0，后面的应用之间的调用、数据都只在逻辑单元 0 内。统一的 user1 只在逻辑单元 1，user2 也只到逻辑单元 2。

我们把这种逻辑单元称之为 RegionZone。在实际的部署过程中，物理数据中心 IDC 和 逻辑单元的数量没有完全的对等关系。例如图中我们物理机房可以是两地三中心，而 RegionZone 则是分为五个。

两地三中心是国家对金融机构的一个容灾指导方案，要求在同城或相近区域内 （ ≤ 200K M ）建立两个数据中心 : 一个为数据中心，负责日常生产运行 ; 另一个为灾难备份中心，负责在灾难发生后的应用系统运行。同时在异地（＞ 200KM ) 建立异地容灾中心。

有了这套单元化的架构做指导思想，蚂蚁进行大规模的改造，包括应用改造、基础框架改造、数据中心的建设。

机房建设完成后，同时蚂蚁金服将自己的用户分成了若干份，划了几个逻辑单元，分别部署进了不同的物理机房，同时完成大规模的数据迁移。

从两地三中心到容灾能力更强大的三地五中心，我们只需要先进行第三个城市的机房建设，然后将部分 RegionZone 部署到第三个城市，最后再完成数据迁移和引流即可。

每一个 RegionZone 在异地都有备份，当发生城市级的故障时，我们通过统一的管控中心将新的逻辑规则推送到统一接入层以及异地的备 RegionZone 时，就可以做到城市级的整体容灾切换。

再后面我们基于单元化的思想做了更多弹性调度等能力，这里就不展开了。

2015 年 9 月蚂蚁金融云对外正式发布，在今年 9 月的云栖大会，蚂蚁金融云正式升级为蚂蚁金融科技，并宣布技术全面对外开放，其中就包括金融级分布式架构 SOFAStack：https://tech.antfin.com/sofa。

云上的 SOFAStack 继承了蚂蚁金服内部的能力，有三大特点，分别是开放（全栈开放、开源共建）、云原生（异地多活、无限扩展）、金融级（资金安全、无损容灾），下面是一些核心能力大家可以看下。这一切就使得蚂蚁金服的微服务体系不仅仅在蚂蚁内部玩得转，也需要适应云上例如云原生、多租户等更复杂的场景。

2、蚂蚁微服务体系

讲到微服务，大家就会看到或者脑子就跳出各种各样的词，例如RPC框架、服务安全、路由寻址等等。

除了这些以外，其实还有更多的服务归属、服务测试、服务编排等更多概念。

那蚂蚁内部围绕微服务体系，也建设了很多的组件和框架对应这些微服务的概念点。

这是一张蚂蚁内部微服务体系的一张简图，只列了部分主要组件，这些组件都是自研的，部分已经开源。

可以看到有配置中心 DRM、注册中心 SOFARegistry，应用开发框架 SOFABoot，应用里的 RPC 框架、分布式链路跟踪组件 Tracer、监控度量组件 Lookout 等微服务组件，应用旁边是我们的 SOFAMosn，也就是 ServiceMesh 里的数据平面 SideCar，会将 RPC 里的路由、限流、鉴权等一些能力集成到这个组件里，下面的 OCS 是我们的可观测性平台，可以在上面看 tracer 和 metrics 信息，两边的两个组件是 Edge Proxy，主要是在跨机房或者跨 BU 的远程服务访问的 Proxy。

下面我会逐一介绍各个组件：

SOFABoot 是我们的开发框架，目前已经开源。开源地址是：https://github.com/alipay/sofa-boot

SOFABoot 是基于 Spring Boot 的，我们对其做了功能扩展，同时也保持完全兼容。SOFABoot 提供了基于 Spring 上下文隔离的模块化开发、基于 SOFAArk 的类隔离/动态模块、中间件和业务日志框架隔离等能力。

由于 Spring Cloud 也是基于 Spring Boot 的，所以 SOFABoot 和 Spring Cloud 体系也是完全兼容的。我们将 SOFAStack 下的中间件都作为 SOFABoot Starter，同时一些会员、安全等基础业务我们也作为 Starter 供各个应用方便的集成使用。

SOFARPC 是内部的 RPC 框架，目前也已经开源，开源地址是：https://github.com/alipay/sofa-rpc

SOFARPC 和其它的开源的 RPC 框架一样，做了很多分层很多的模型抽象，例如图中的 Filter/Router/Cluster/Loadbalance/Serilization/Protocol/Transport 等这些模型。

它的特点如下：

• 透明化、高性能
• 丰富的扩展机制、事件机制
• 支持自定义Filter和自定义Router
• 支持多种负载均衡策略，随机/权重/轮询/一致性hash 等
• 支持多种注册中心，zookeeper/consul/etcd/nacos 等
• 支持多协议， Bolt/Rest/HTTP/H2/gRPC/dubbo 等
• 支持多种调用方式，同步、单向、回调、泛化等
• 支持集群容错、服务预热、自动故障隔离

SOFARPC 基于Java Proxy 机制实现透明的，默认的基于二进制协议 Bolt 和 NIO 异步非阻塞实现高性能通讯。SOFARPC 基于其 ExtensionLoader 扩展机制和 EventBus 的事件总线机制可以进行非常方便集成各种各样的扩展。例如注册中心，我们内置支持了 ZooKeeper 和 nacos 的实现，社区帮我们共享了 consul 和 etcd 等实现。

SOFARPC 还支持多协议，Bolt 是蚂蚁内部使用多年的内部协议，也已开源，地址是：https://github.com/alipay/sofa-bolt。

此外，还有SOFARegistry 自研注册中心、RM 分布式配置中心、uardian熔断限流组件、OFALookout监控度量组件、OFATracer分布式链路跟踪组件、TX 分布式事务组件、CTS 测试框架，用 Golang 语言开发的 sidecar等

3、SOFAStack 开源

SOFAStack 中的 SOFA 其实是 Scalable Open Financial Architecture 的首字母缩写，它是用于快速构建金融级分布式架构的一套中间件，也是在金融场景里锤炼出来的最佳实践。

目前 SOFAStack 采用的开源策略我们称之为是「Open Core」，就是将 API 层、接口层以及核心实现逻辑通通开源，内部实现保留的是一些兼容内部系统，兼容老的 API，或者是一些历史包袱比较重的代码。

这是内部的 Landscape，可以看到微服务领域各个功能点都有对应的内部系统或者组件。部分前面已经介绍过了，不做过多介绍。

这张是 OpenSource Landscape，目前只开源了部分组件，部分组件还在开源准备中，虽然不少内部组件没有开源，但是在每个微服务领域我们都会打通当前已经开源的比较成熟的组件。例如微服务里的服务发现，我们没有开源内部的 SOFARegistry，但是我们对接了 ZooKeeper/etcd/nacos 等业界成熟的注册中心产品。通过保持和业界众多优秀开源产品的兼容性，使得 SOFAStack 有更多可能。

目前 SOFAStack 的源码托管在 Github 和 Gitee 上面，SOFAStack 下的项目大概有 30 来个，每天的 PV 在 10000 以上，总 Star 数一万多，到 12 月初已经有 80 多位小伙伴贡献过代码或者文章。

另外，SOFAStack也和其它一些国内社区保持了良好的交流与合作，包括 ServiceMesher、Skywalking、Eggjs、K8S 中国社区等。

感兴趣的朋友可以上去看看，也欢迎给 Star呀！

SOFA 文档: http://www.sofastack.tech/

SOFA 开源整体地址: https://github.com/alipay

SOFA（Scalable Open Financial Architecture）

SOFA 中间件是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。 SOFA 在2018年4月份宣布开源，期望通过逐步向社区开源 SOFA 中各个组件，来帮助更多机构和合作伙伴完成金融分布式转型，帮助大家更加快速构建稳定的金融级云原生的架构，也期望 SOFA 在蚂蚁体系之外的更大场景下去应用，来进一步锻造改进这套体系。

注：场主偷偷告诉养码人，@蚂蚁金服 SOFAStack 官方微博正在给程序员送圣诞礼物，据说今晚8点就开奖，冲一波？