蚂蚁金服官网 蚂蚁金服微服务实践（附演讲PPT）

张庚，怀玉，蚂蚁金服高级技术专家。

2007年毕业后，一直从事服务相关工作。他先是在国家电网从事电子商务平台的SOA工作，之后负责JD.COM JD.COM的JSF。目前在蚂蚁金融中间件服务与框架组负责应用框架和沙发相关工作。

根据怀玉在2018年开源中国年终典礼上的讲话，完整的PPT分享方式显示在文章的底部。

这个分享主要分为三个部分:

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

在我们开始讨论架构演进之前，让我们看一组数据。

这是双十一历年的数据图表。专栏显示双十一的成交量，从最初的20亿到去年的1682亿，今年的2135亿。而这条橘黄色的虚线是支付宝双十一交易0: 00时的峰值，去年是26.5w笔/秒，今年更高。从这两组数据可以看出，蚂蚁的业务每年都在高速增长，对技术的压力也在不断加大。但是这几年虽然峰值越来越大，但是每个人都有个性感，就是大促销的购物体验更好，系统也比以前越来越稳定。

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

相信大家都听过“冰冻三尺，非一日之寒”这句话。蚂蚁金服科技的技术最早不是这样设计的。像所有的大公司一样，这些技术架构是随着业务和系统的发展而一步步演进的。

下面介绍一下蚂蚁的进化。

这是支付宝最早的架构图。可以看出，支付宝只是电子商务后台的一个支付系统，是一个单一的应用，简单的分成几个业务模块，连接到一个数据库。然而，随着业务规模的不断扩大，单一的系统架构已经不能满足业务需求。

所以支付宝把大系统拆分，把单个应用内部的多个模块变成了多个独立的子系统，这就是典型的SOA架构。首先，F5的硬件负载设备用于平衡系统之间的负载。但是由于F5设备的单点问题，中间引入了注册表组件。服务提供者去注册中心注册服务，服务消费者去注册中心订阅服务列表，服务消费者以软加载方式通过RPC框架直接调用服务提供者。这是目前非常明显的面向服务的架构，但是在2007年采用这种架构已经相当先进了。支付宝在做系统拆分的同时，按照子系统垂直拆分数据库。数据库的拆分会引入分布式事务的问题，蚂蚁金服中间件提供了基于TCC的分布式事务组件DTX。

业务不断拓展，系统越来越多。当系统节点数达到一定水平，单个物理机房已经无法承受。另外，考虑到同城容灾的问题，支付宝会在同城再扩建一个机房，通过专线部署为内网，然后部署应用。同一个城市的多机房会引入一个跨机房远程访问的问题。比起在同一个机房打电话，这个延时损失肯定更高。远程访问主要包括两种:RPC调用和数据库访问。为了解决跨机房的RPC调用问题，支付宝工程师选择在每个机房部署一个注册中心，同一个机房先调用这个机房的服务，成为图中的部署模式。然而，跨机房的数据库访问问题在现阶段还没有得到解决。

为了解决以上跨机房数据访问、数据库连接瓶颈、未来数据层次扩展等问题，蚂蚁工程师设计了一个单元化架构，这是一个单元化示意图。当没有单位化时，用户请求进入内部后，所有请求的链接都是随机走的，例如图中的S0到B1到C2到D0。首先，蚂蚁的请求都与用户有关，所以我们根据用户的维度对数据进行横向切片。例如，在这个图表中，我们将所有用户分为三组。然后我们把我们的应用部署成三组独立的逻辑单元，每个逻辑单元的应用和数据都是独立的，相当于每个逻辑单元处理总用户数据的1/3。

此时，当我们三个不同终端的用户请求进入统一接入层时，无论是在PC还是手机上，还是扫描二维码，接入层都会根据上述逻辑单元的分组规则，将用户请求转发到相应的逻辑单元。例如，user0的请求被转移到S0，后续应用之间的调用和数据只在逻辑单元0中。统一用户1只在逻辑单元1，用户2只在逻辑单元2。

我们把这个逻辑单元叫做RegionZone。在实际部署过程中，物理数据中心IDC和逻辑单元数量并不完全相等。比如图中，我们的物理机房可以是两个地方的三个中心，而RegionZone分为五个。

两地三个中心是国家金融机构容灾指导方案，要求在同一城市或类似地区(≤ 200K M)建立两个数据中心:一个是数据中心，负责日常生产运营；另一个是灾难备份中心，负责灾难发生后应用系统的运行。同时建立异地(> 200公里)的容灾中心。

蚂蚁以这个单元化框架为指导思想，进行大规模的改造，包括应用改造、基础框架改造和数据中心建设。

机房建设完成后，蚂蚁金服将自己的用户分成几个部分，画出几个逻辑单元，部署到不同的物理机房，完成大规模数据迁移。

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

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

后来我们基于单元化的思想做了更灵活的调度能力，这里就不展开了。

蚂蚁金服云于2015年9月正式发布。在今年9月的云起会议上，蚂蚁金服云正式升级为蚂蚁金服科技，并宣布该技术全面对外开放，包括金融级分布式架构沙发塔克，网站位于左上角。感兴趣的朋友可以看看:https://tech.antfin.com/sofa.

沙发上云继承了蚂蚁金服的内部能力，有三大特点，即开放(全栈开放，开源共建)，云原生(异地多住，无限扩展)，财务水平(资金安全，无损灾难恢复)。这里有一些核心能力，你可以看看。这些都使得蚂蚁金服的微服务系统不仅能在蚂蚁内部很好的发挥作用，还能适应云原生、多租户等更复杂的场景。

2.蚂蚁微服务系统

说到微服务，人们会看到或想到各种各样的词，比如RPC框架、服务安全、路由寻址等等。

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

蚂蚁围绕微服务系统构建了很多组件和框架，对应这些微服务的概念点。

这是一个蚂蚁内部的微服务系统的草图，里面只列出了一些主要的组件，有自主开发的，也有开源的。可以看到，应用中有配置中心DRM、注册中心SOFARegistry、应用开发框架SOFABoot、RPC框架、分布式链路跟踪组件Tracer、监控测量组件Lookout等微服务组件。应用程序旁边是我们的SOFAMosn，它是ServiceMesh中的数据平面SideCar。一些功能，如路由、限流和RPC中的身份验证，将被集成到该组件中。下面的OCS是我们的可观测平台，可以在上面查看tracer和metrics的信息。两边的两个组件是Edge Proxy，主要用于跨机房或BU的远程服务访问。

下面我将逐一介绍每个组件:

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支持多种负载均衡策略，随机/权重/轮询/一致性hash 等支持多种注册中心，zookeeper/consul/etcd/nacos 等支持多协议， Bolt/Rest/HTTP/H2/gRPC/dubbo 等支持多种调用方式，同步、单向、回调、泛化等支持集群容错、服务预热、自动故障隔离

SOFARPC基于Java Proxy机制透明，默认基于二进制协议Bolt和NIO异步无阻塞，实现高性能通信。SOFARPC基于其事件总线的扩展机制和事件总线机制，可以方便地集成各种扩展。比如在注册中心，我们内置支持ZooKeeper和nacos的实现，社区帮助我们分享consul和etcd的实现。

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

SOFARegistry是自行开发的注册中心。

SOFARegistry与Zookeeper和etcd Registry的区别在于，它属于AP架构，保证了数据的高可用性和最终一致性。注册表客户端和注册表之间有很长的连接。当订阅数据更改时，注册表会将数据推送到注册表客户端。为了维护大量的长连接，我们将注册表分为两个角色:会话节点和数据节点，其中会话节点与客户端保持长连接，数据节点存储数据。SOFARegistry恢复支持多个数据中心和组合场景。在蚂蚁金融云上，SOFARegistry增加了Meta节点角色，支持多租户和数据碎片化，使其具备支持海量服务注册信息存储的能力。

DRM是我们内部的分布式配置中心。

配置中心客户端与配置中心服务器的数据交互采用长连接推送方式，而不是HTTP短轮询或长轮询。配置中心客户端将配置存储在本地磁盘上，以防止配置中心服务器不可用，客户端还定期检查数据一致性；在服务器Nginx和服务器内存中设计缓存以提高性能，不会向数据库请求任何数据。配置中心的控制台支持单点、灰度、分组、全局等多种推送模式，并会读取和检查推送结果的一致性。

守护者是我们内部的保险丝限流元件。

支持监听模式(只录不截取)和截取模式。支持各种场景，如RPC请求、Web请求等。支持令牌桶、漏桶等限流算法。支持多种熔断规则，如限时熔断和退化。支持空处理、固定返回值、抛出异常等降级策略。有时候，如果这些规则过于复杂，用户可以在管理端配置定制的groovy脚本，规则会通过配置中心分发到各个拦截点。Guardian还支持故障注入操作，用于日常应急演练，测试系统健壮性等。

SOFALookout是我们的内部监控和测量组件。目前客户端已经开源。地址是

https://github.com/alipay/sofa-lookout

SOFALookout的客户端基于Mectrics 2.0标准，内置JVM/cpu/mem/load等度量规则。用户也可以自定义测量。Lookout-gateway是一个测量数据采集终端，可以连接各种数据采集终端(如Lookout客户端、代理或来自Queue的事件报告)，同时具有内置的计算能力，将处理后的数据扔入消息队列，最后分发给OB/HBase/ES等不同的数据存储。不同的后端数据显示平台可以直接从数据存储中捞出数据进行显示。OCS是我们可观察的平台，它可以检查跟踪器和度量信息。

SOFATracer是我们内部的分布式链接跟踪组件。目前客户端已经开源。地址是

https://github.com/alipay/sofa-tracer

SOFATracer基于opentracking规范，提供了丰富的组件支持，比如servlet/Spring MVC/HttpClient/RPC/JDBC，也支持opentracking的官方集成实现。SOFATracer在底部提供了多种存储实现，可以放在磁盘上，也可以直接报告给远程服务器。同时，SOFATracer还提供了链路数据透明传输的能力，广泛应用于全链路压力测量等场景。

DTX是一个分布式事务组件，它是蚂蚁在大规模分布式环境下保证业务活动数据一致性的重要依赖组件。

DTX支持三种模式:TCC/FMT/XA，最常用的是灵活的交易模式TCC。在TCC模式的简单介绍下，其实是一个两阶段提交的思路，将交易分为尝试阶段和协同确认/取消阶段两个阶段，用户在业务代码中实现每个阶段要做的事情。交易开始时，交易发起方通知所有交易参与方进行尝试操作，并在尝试时预留业务资源或数据验证操作。如果所有尝试都成功，则确认确认业务操作的执行，否则取消取消业务操作的执行。此外，还提供了FMT模式，这是另一种更自动化的分布式事务模式，便于用户快速访问，没有业务入侵。

DTX还支持幂等控制和反绞刑。事务日志与各种日志存储实现兼容，并且事务还支持从本地或远程服务器进行异步恢复。

ACTS是我们的测试框架之一。

众所周知，编写测试用例对于开发来说其实是一件复杂的事情，尤其是当开发人员水平参差不齐，业务系统复杂的时候。ACTS是数据对象模型驱动的新一代测试框架，致力于提高开发人员和测试人员编写测试用例的效率，给开发人员更好的测试体验。ACTS支持IDEA和Eclipse IDE插件。开发人员可以在IDE中直接生成标准化的测试用例，然后对测试数据进行可视化编辑，可以对结果进行精细验证，自动清理测试数据。此外，支持API重写，提高测试代码的可扩展性和可重用性，并提供特殊注释，提高测试代码排列的灵活性。

SOFAMosn是我们用Golang语言开发的sidecar，目前已经开源。地址是:

https://github.com/alipay/sofa-mosn

这张图片实际上是一张官方的istio图片，除了我们把特使改成了SOFAMosn。SOFAMosn可以与istio无缝集成，并与其API完全兼容。SOFAMosn还支持多种协议。除了特使，还额外支持SOFARPC和Dubbo协议。当然，您也可以非常方便地扩展和支持定制协议。SOFAMosn有内置的可观察组件，用户可以监控他们的网络，请求压力和其他信息。SOFAMosn还可以支持平滑重载和平滑升级。

3.开源

SOFA in SOFAStack实际上是可伸缩开放金融架构(Scaleable Open Financial Architecture)的缩写，是一套用于快速构建金融级分布式架构的中间件，也是在金融领域锤炼出来的最佳实践。

目前，SOFAStack采用的开源策略被称为“开放核心”(Open Core)，这意味着API层、接口层和核心实现逻辑都是开源的，而内部实现保留了一些与内部系统兼容、与旧API兼容或者历史包袱沉重的代码。

这是今年SOFAStack开源的时间线。今年4月19日，SOFAStack正式宣布开源。我们主要打开了sofabot和SOFARPC框架，以及SOFABolt、SOFAArk、SOFAHessian等外围组件；

5月31日，我们开通了第二批SOFATracer和SOFALookout客户端，完善了微服务组件；6月28日，我们的开源官网正式上线，域名为http://sofa tack . tech；7月16日，我们开启了ServiceMesh领域的第三批两个项目，SOFAMesh和SOFAMosn。截至今年双十一，这些项目的总星数已经超过1万个，单个项目的最高数超过2700个。

这是我们的内部景观，我们可以看到，在微服务领域，每个功能点都有相应的内部系统或组件。有些已经介绍过了，不要介绍太多。

此外，这是我们的开源景观。目前只有部分组件是开源的，部分组件还在为开源做准备。虽然许多内部组件不是开源的，但我们将在每个微服务领域开放更成熟的开源组件。比如在微服务的服务发现上，我们没有开源的内部SOFARegistry，但是对接了zoookeeper/etcd/nacos等业界成熟的注册中心产品，比如分布式跟踪。虽然我们已经打开了自己的SOFATracer，但我们还提供了skywalking作为SOFARPC中分布式跟踪的实现。通过保持与行业内许多优秀开源产品的兼容性，SOFAStack有了更多的可能性。

目前SOFAStack的源代码托管在Github和Gitee上。欢迎有兴趣的朋友来看看，也欢迎给我们明星。

沙发策略下约有30个项目，日光伏超过10000，总星超过10000。到12月初，已经有80多个小伙伴给我们投稿了代码或者文章。此外，我们还与国内其他社区保持着良好的沟通与合作，包括ServiceMesher、Skywalking、AntDesign、Eggjs、K8S华人社区等。

如果您对沙发图克感兴趣，您可以通过这些方式参与我们的沙发图克社区活动，我们为参与者准备了定制的丰富礼物:

您可以使用我们的组件给我们反馈，或者查看改进我们的文档，或者为 SOFAStack 写技术分享或者实践类文章，我们会同步到我们微信公众号（金融级分布式架构）里；当然最好可以贡献 PR，不管是改错别字、修复 Bug 还是提 Feature；也欢迎来见我们，目前我们已经在北京上海深圳杭州举办过四次 ServiceMesh Meetup，下一次 1月 6 日在广州，欢迎感兴趣的同学可以参加，历届活动可参考：http://www.servicemesher.com/

PPT下载及相关地址

PPT地址:

http://www.sofastack.tech/posts/2018-12-17-01

沙发文件:http://www.sofastack.tech/

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

开源中国地址:

https://www.oschina.net/p/sofaboot