蚂蚁金服面对亿级并发场景的组件体系设计

5 月 6 日，InfoQ 主办的 QCon 2019 全球软件开发大会在北京举行。蚂蚁金服技术专家吕丹（凝睇）在大会上作了《蚂蚁金服面对亿级并发场景的组件体系设计》的分享，咱们根据演讲整理以下：

今天，我主要想和你们分享一下移动领域基础组件体系，内容大体能够分为四大块，第一块是标准移动研发所需的基础服务体系，第二块是支撑亿级并发的核心组件“移动接入”的架构演进过程，第三块是双11、双12、新春红包这种大促活动的的应付方法，最后一块是目前已经对外输出的基础服务产品。

0. 移动研发基础服务体系

首先介绍一下支付宝客户端的演进过程。以前，支付宝客户端的主要功能是转帐、订单支付、交易查询等等，更像是一个工具类的 APP，在须要付钱的时候才会掏出来，用完了就放回去了。2013 年，蚂蚁金服 all in 无线以后，加入了不少服务，例如余额宝、卡券、探索发现等，基本是把支付宝网站上的功能都尽可能迁移到客户端，支付宝也逐渐演化成一个平台级别的客户端。以后，随着移动互联网的快速发展，公司内部孵化出了更多的 APP，其余行业也在移动互联网圈内铺开了大量的业务，为了提高用户量、用户粘性，APP 之间也开始进行了大量的业务融合，超级 APP 也所以而诞生，APP 开始朝着生态化的模式发展。

截止到目前为止，支付宝客户端的年活跃用户数超过 8 亿，在大促场景下，同时在线量超过 3 亿，并发请求超过 1 亿，同时上线的用户数超过百万每秒。

而在这些数据的背后必定须要一套庞大、复杂、完整的支撑体系来支持支付宝的运做，移动研发基础服务体系就是其中的重要组成部分。

按照研发过程，咱们把移动研发基础服务体系分红四大块：APP 研发阶段，主要包括 App 框架、基础组件、云端服务和研发工具；App 测试阶段 ，主要包括研发协做平台和真机测试平台，其中研发协做平台包含版本管理、迭代管理、安装包编译、构建和打包的能力，而真机测试主要是代替人工服务，减小人工消耗，提高测试效率； App 运维阶段 ，主要包括智能发布、日志回溯、应急管理和动态配置；App 运营阶段，主要包括舆情反馈、实时分析、离线计算和智能营销。

1. 蚂蚁移动接入架构演进

今天的主题为支撑亿级并发下的基础服务，而在亿级并发下移动接入又是最核心、最重要的一个环节。移动接入并非单个系统，而是一整套组件的总称，包括：Spanner+ 链接管理、API 网关、PUSH 通知和 SYNC 数据同步，它是全部移动业务的流量入口，须要维持客户端的状态，支持进行统一的管控，同时还须要进行部分的业务数据处理。

其实，一开始并无移动接入这个说法，与支付宝客户端的演进过程相似，后端移动接入也是逐步迭代演进的。最开始，各个业务服务都是本身提供 API 或者直接暴露能力给客户端，没有统一的架构，没有统一的模型，也没有统一的管控。

为了解决这个问题，在 all in 阶段咱们引伸出了一个 API 网关，由它来作集中式管理，同时添加了 PUSH 推送的能力。由于公司内部有不少 APP，咱们但愿这些能力可以复用，因此在架构上，咱们支持多 APP 同构，客户端会提供多个 SDK，能够随时进行集成。

【网关架构】

上图是一个移动 API 网关的架构，从图中能够看到，咱们把 API 生命周期定义为如下几个阶段：API 定义、API 研发、API 发布、API 配置、API 上线、API 运营和 API 下线。而移动网关又把 API 生命周期切分红三大块，分别是研发支撑阶段、运行时阶段和服务治理阶段。

研发支撑阶段主要有四个能力，分别为 Code-Gen、API-MAN、API-Test 和 API-Mock。为了提升 API 数据在网络上的传输效率，目前蚂蚁的 API 模型所有都采用了 protobuf 进行序列化，所以，为了方便业务开发，API 网关提供了统一的基于 proto 文件的代码生成工具，而且为了减小客户端的文件大小和方法数限制，咱们修改了官方提供的生成代码，有效减小了冗余的方法并大大减少了客户端文件大小。

在运行时阶段，核心的功能包括 API 流量管控、数据验签、用户鉴权以及接口系统路由等。

API 平常的运维由服务治理体系来搞定，主要的能力为 API 监控，并根据实时数据进行 API 质量模型评估，同时提供了一些应急的管理措施。

API 网关最为核心的架构设计是 Pipeline，正如你们所知，网关看起来只是一个简单的 API 管控和路由，但其中涉及的节点却很是多，而每一个节点的功能又相互独立，而且随着业务的发展，功能节点会逐渐增长，在某些场景下，还须要作不一样的节点组合。若是采用传统的链式调用，代码执行串会很是的长，同时扩展和维护起来都很是的困难。所以咱们参考了 netty 的 Pipeline 设计，完成了本身的 Pipeline 链路。Pipeline 中的各个 handler 保持相互独立，同时能够根据须要、根据配置自由捆绑，也为后续的功能延伸提供了良好的架构支撑；

【代码变革】

从代码来看，咱们能够明确的感觉到以前的调用过程是一个远程调用，须要感知路径、参数等，而在统一了整个数据的交互以后，对于业务系统来讲，这个调用过程更像是本地调用，直接调用函数，封装模型。经过这种方式，业务类研发同窗可以更关注于本身业务系统的代码逻辑编写，彻底不用关注底层通信的实现，较大的提高了研发效率。

移动网络跟有线网络是有很大区别的。移动网络比较复杂，用户状态也比较复杂，有多是在地下室、电梯或者其它弱网环境中，而且用户在移动场景下对于体验的要求很是高，例如在支付时，用户须要立马拿到支付结果。以前，咱们主要是作了服务端的改进，针对客户端并无作改进。为了解决用户问题、性能问题、提高用户体验，咱们在进行了一次升级，作了一个统一接入网关，并把它架在基础组件之上，同时研发了性能数据同步、加强了 IP 调度等能力。

【统一接入网关】

统一接入网关（ACCGW），能够理解成一个前置的 Nginx，是蚂蚁基于 Nginx 二次开发的一套组件，在内部咱们叫作 Spanner，它在接入架构中主要负责非业务的那一部分逻辑处理，主要包括 SSL 的卸载，MMTP 的协议解析，数据的压缩、解压缩，客户端 TCP 长链接的维持，接入流量的总控，数据包的路由以及客户端日志的接入。API 网关、PUSH 推送、数据同步等组件，都在它的庇荫之下。

【网络协议优化】

MMTP 协议的全称是蚂蚁移动传输协议，基于 TLV 的数据结构，这种数据结构的好处是分包解包的效率很是高，且它是基于二进制的，存储成本相对较低。同时还知足了客户端多个组件的链路复用，固然 MMTP 配合客户端也有本身的一些特性，同时咱们也加入了不少新特性，例如智能链接策略。由于移动环境下用户的网络状态不是很可靠，若是是传统的链接方式，不必定能知足全部 RPC 请求，因此咱们作了策略改进。在可以使用长链接的状况下尽可能使用长链接，若是出现长链接连不上或者闪断的状况，咱们就尝试使用短链接的方式，短链接能够知足当时紧急的 RPC 发数据。同时咱们也会用一些并发建连的策略，运营商网络一般是先连上哪一个就使用哪一个链接，链接以后咱们会使用智能心跳策略，用以捕捉不一样运营商、不一样地区，对于维持链接的心跳时间的差别。

在并发建连的过程当中常常会出现客户端同时存在多端长链接的现象，数据包可能会在中间作传输，若是立马断掉的话，数据包就丢了，极可能对业务产生影响，所以咱们加入了柔性断连，以确保可能在传输过程当中的数据包能被安全送达。另外，多个链接建完以后，客户端可能出现情况，服务端没有及时感知到，没法获知这个链接是好是坏。所以，咱们加入了假链接监测，数据包派发的时候携带一个序列号，客户端回报以后，若是序列号返回了，就证实这个链接是可用的，反之，咱们就认为这个链接是假死状态，能够在合适的时间点断掉该链接。

MTLS 是蚂蚁移动安全传输协议，基于 TLS1.3。咱们在作的时候，TLS1.3 尚未正式发布，可是咱们了解到一些它的特性，并将某些特性加入到了设计中。好比采用了 1RTT ECDHE 的握手方式。1RTT ECDHE 是基于 ECC 加密套件，ECC 的最大特色是密钥串比较小，更小的数据在移动方面有很是大的优点，例如提高传输效率，节省存储成本。在存储或传输过程当中，数据包大小是移动领域特别关注的点。也由于如此，咱们选择了 ZSTD 压缩算法，ZSTD 有很是大的压缩比，且在该压缩比之下，压缩和解压缩的效率都不错。另外，在某些可支持重放的业务场景中，咱们还加入了 0RTT 策略，第一时间把数据从客户端发送到服务端。经过上述优化，RPC 的平均响应效率提高了 5~6 倍。

【SYNC 数据同步】

SYNC 数据同步听起来有点陌生，其实能够理解成是 PUSH 的演进版本。它是基于 TCP、双向传输的。虽然传统的 RPC 可以解决绝大多数的问题，可是在某些场景下，它是有缺陷的。例如，客户端启动以后，须要经过 RPC 请求去判断服务端是否是有数据。其实 90% 的状况是查询接口没有任何的变化或者返回的数据客户端已经存在了，因此这个过程很是冗余。除了数据冗余之外，请求也冗余，由于没有发生变化，调用在原则上是能够省下来的。

当初，在 all in 以后，咱们作了一些体验上的优化，如预加载能力，当客户端启动以后，触发数据预加载，虽然没有进入到模块，但为了提高用户体验，客户端发送不少 RPC 请求，也所以形成了大量的冗余并发请求。

另外一个不足是客户端没办法主动感知到服务端的数据变化，好比在聊天场景中，用户是等着交互的，若是使用 RCP 定时拉取的方式，客户端和服务端的成本会很是高，总体响应时间也比较慢。而经过 SYNC 的推送模式，能够在服务端产生数据的时候，基于 TCP 方式把数据推送到客户端，客户端能够在第一时间拿到数据作业务渲染，好比支付宝的扫码支付、当面付都是经过 SYNC 服务来同步的结果数据。

SYNC 的基础核心是——oplog，它相似于 mysql 的 binlog，是每一条增量数据的快照。SYNC 会为每一条 oplog 生成一个惟一的、递增的版本号，而后经过记录客户端当前数据版本号的方式来计算两端之间的差量，并仅同步差量数据。由于 SYNC 是基于 TCP，可双向主动传输，从而达到实时、有序、可靠、增量的数据传输效果。同时，SYNC 在客户端触发场景中，并不是基于业务场景，而是基于事件，如建联、登陆、从后台到前台等动做，所以，能够达到单次事件触发多业务的增量计算，而当无增量数据时客户端也不须要进行任何的其余 RPC 请求，从而极大的减小了客户的请求数和冗余数据传输，不但提升了效率、实时性，还间接的下降了系统压力。

【移动调度中心】

对于客户端请求来讲最重要的是在第一时间内找到正确的 IP 并把请求发出去。以前这些工做通常是由传统 DNS 来作，但传统 DNS 会有一些问题，例如 DNS 劫持、DNS 解析失败、不一样运营商 DNS 解析效率不一样等等，解析 DNS 须要消耗额外的 RTT。

针对这些状况，咱们设立了移动调度中心，它是基于 HTTPDNS，并在此基础上加入了用户分区信息。什么叫用户分区呢？面对亿级并发，服务端确定不会在一个机房里，多是在多个机房中，且机房内部还有逻辑分区。用户属于哪一个逻辑区只有服务端知道，客户端自己是感知不到的。当某个分区的用户接入进来后，若是没有在正确的分区内，且又须要转到其它分区作业务处理时，若是是采用传统 DNS 是没法实现的，由于没法解析出用户属于哪一个 IP 列表。而 HTTPDNS+ 分区数据的模型，可让客户端快速拿到最准确的 IP 地址，同时客户端还能够针对这个 IP 地址作质量检测和有效性检测，在请求以前就肯定最优的 IP 地址。另外，HTTPDNS 还能够支持海外节点的部署。HTTPDNS 必定不会比 DNS 的效果差，由于它还有 DNS 来兜底，一旦 HTTPDNS 出现问题，那么就会切换到 DNS 去作解析。

以上的演进过程知足了绝大多很多天常的需求，可是支付宝有不少大促场景，每次大促的玩法都不一样，且峰值集中在一刹那。针对这个场景，咱们又孵化出了新的模式，一是 API 网关的去中心化，二是 SYNC-PULL 机制，三是 SYNC-Bucket 计算模式。

【网关去中心化】

网关去中心化解决的一个核心问题就是成本。大促场景下，业务量不停上升，峰值可能很是高。但峰值只有一刹那，其余时间内机器都是处于空闲状态，这是很是大的资源浪费。而为了保证大促时不崩溃，机器又不能减小，因此对应用的压力是很是大的。

若是都是作单点，那么还会存在稳定性的问题。若是网关在发布时出现了某些差错，那么有可能影响全部业务流程的处理。另外，若是单个接口出现问题，客户端出现死循环等问题，也会影响到其余系统业务的流程。面对以上状况，咱们把网关去中心化就能够抵消这些风险，若是只是单个系统出问题，那么不会由于网络的问题致使其余业务发生问题。

【SYNC-PULL 读扩散】

为何会有 SYNC-PULL 读扩散的需求呢？由于支付宝内部有很是多大 V 商户，每一个商户有很是多的关注用户，它须要按期或不按期的作一些运营消息投放。若是按照 SYNC 的场景，经过写扩散的方式给每一个关注投放一条数据，不只浪费存储，并且效率很低下。假设某个商户有 5 亿关注用户，5 亿数据所有入库最快也要几十分钟。另外，因为咱们商户的数量不少，你们都争抢这个资源，可能会出现排队的状况。对于商户来讲，没法立马将活动触达到用户端，对于服务端来讲，消息多是如出一辙的，形成了存储浪费。即便是使用了缓存，整个索引也须要给每一个用户去存一遍，这对数据的 TPS 依然要求很是高。

为了解决以上问题，咱们升级成了读扩散的模式，把它抽象成关注关系，每一个商户抽象成 Topic，而后把全部数据放在 Topic 下面。由于用户关注的大 V 相对比较少，且大 V 生产数据的频率并不高，有效的数据集不是特别多，因此能够把超级大 V 的数据先放在缓存里面，而后经过二叉索引快速寻址用户下的关注关系，并经过原有的 SYNC 机制把增量数据推到客户端。这样，原来亿级的存储就变成了一条存储，原来几十分钟的响应时间变成了秒级，效率和体验都有了极大的提高。

早先，咱们作 SYNC 的时候是想让每一个业务都相对独立、相对隔离，计算也独立进行。当时的业务场景很少，可是后来接入的业务愈来愈多，将近有 80 个业务场景，且每一个业务都是独立计算。客户端是基于事件的，建连以后，须要进行 80 次业务独立计算，在大促一百万每秒的发送量的状况下，很容易就达到亿级，这对数据库、应用程序、缓存等的压力都是很是大的，同时这种方式也无法知足将来的持续发展。

为了解决这些问题，咱们针对原来的计算特性抽象出了几个分类。例如，基于用户维度、基于设备维度、基于一次性、基于多端同步、基于全局用户配置的几个大类数据，抽象成几个抽象模型。咱们姑且认为是有 5 个 bucket，全部的计算都基于 bucket 方式来作，若是有新的业务加入，那就根据它的特性把它归到某个 bucket 中。

另外，大促场景下会有高优先级的业务，因此须要作一些特定的限流策略。针对这种状况，bucket 能够动态的增减，业务进出 bucket 也能够随时切换。bucket 上线以后，当时咱们的计算量降低超过了 80%，在后面的 二、3 年中，业务从 80 个增长到 300 个，服务器也没有增长。总体来讲，对性能的提高仍是很是明显的。

2. 大促活动场景应对之道

前面的内容主要是移动接入方面的组件设计如何支撑亿级场景，下面咱们聊一下，如何切实的应对大促活动。

【大促活动场景应对之道：步法】

经过几年的大促经验，咱们在技术上提炼出了应对大促的几个步法：首先业务同窗设定业务目标，肯定业务玩法；技术同窗在收到大促介绍以后，开始分解技术指标，并根据各自系统的能力、流程和特性肯定相应的技术方案，肯定技术方案的步骤则主要为：链路分析、容量评估、性能优化、流控方案、预案策略以及肯定弹性流量规则。在肯定完成技术应对方案后，最重要的是进行全链路的压测，经过影子用户，影子表进行生产环境的全链路压测，每一个系统压测周期短则几天，长则须要数月。在不断的压测中发现问题，发现瓶颈，优化后再次进行压测，直到完成技术目标；在全链路完成压测指标后，进行多轮活动的演练，以模拟真实业务场景，并验证技术方案的准确性；此后，根据实际须要，择时进入大促阶段。在这个阶段，研发同窗主要工做是配合运维进行预案的执行、观察大促期间各类指标的变化，并根据监控确认是否须要应急。固然，应急方案在以前的演练中也须要进行验证。随后大促活动结束后，须要进行预案 & 应急策略的回滚和验证，这样大促活动才算真正结束。同时，更重要的是，咱们须要对每一年的大促进行复盘 review，以便发现不足，在后续的活动中加以改进。

【大促活动场景应对之道——流控】

在大促执行过程当中，最为关键的是流控。对技术同窗来讲，让系统在活动中活下来是对大促最给力的支持，流控是系统最有力的屏障。因为各系统在大促活动中发挥的做用、业务的紧急程度、集群的规模各不相同，所以大促中通常会牺牲一些特性来为主要链路腾出性能空间，好比流水日志、压缩阈值、消息顺序性等等。

流量的管控也会分多级，在最上层 LVS 会在 VIP 上进行数十亿级别的控制，到接入网关层则根据建连量、包数进行亿级流控，而 API 网关层则进行千万级别的控制。在这几层上，通常简单计数便可知足。而到业务层，特别是中低流量的业务层，通常采起的是令牌桶和分布式限流方式。而后，在 API 网关上，也能够作一些自定义的脚本，mock 返回结果来为业务系统抵挡住一部分请求。

【自动化真机测试】

除了核心链路以外，咱们也须要一些后勤服务。例如在测试过程当中，须要自动化，特别是真机模拟测试来抵消部分的人力劳动。咱们的机房中部署了上千台手机，一般都会进行一些自动化的运维检测，包括安装包的安装卸载、性能损耗、功能测试等。除了自动化测试，它还扮演着自动审批和服务巡检的角色，分别用来检测小程序和及时发现问题。经过自动测试平台能够节省 60% 以上的重复体力劳动消耗。

【客户端智能发布——确保客户端万无一失】

若是要确保客户端万无一失，那么最核心的就是灰度流程，灰度流程结束以后，咱们才能发布到生产环境中。

智能发布主要支持客户端各类的发布包，包括安装包、离线包、小程序包等。经过多年的发布，咱们也沉淀了一些模板，例如灰度用户、灰度覆盖率等等。灰度时咱们能够选择必定的模板，按照既定逻辑，使用自动化流程代替人工处理。

【舆情分析——及时获取用户反馈】

客户端发布以后，业务同窗必定很是关心用户心声和市场反应，技术同窗则但愿第一时间收集到用户的真实反馈。舆情分析系统就用来知足这些需求，舆情系统能够分为 4 大块：数据采集，主要采集渠道为各大媒体中心、应用市场评论、开会的反馈功能和客户满意中心的数据；数据内容则能够包含各类热点话题、热点事件和主要生产问题；数据存储，目前主要由 4 大块来支撑：元数据通常能够采用关系型数据库，文档数据使用的是 MongoDB，爬虫采集的条目经过 MQ 来传输，全部数据最终会落至 ES 中，用来作检索和基础分析；数据计算更多的是经过文件算法来对 ES 中的数据进行分析，最终产出各类趋势和各类事件、话题排行，同时针对每个用户反馈又能够实时通知到相关的负责人。

在这里咱们说的移动分析主要是基于客户端日志埋点的数据分析能力。客户端须要有标准的埋点 SDK 来采集 Native、H五、小程序的各类框架 & 容器埋点，也须要支持业务自定义的业务埋点。同时，为了在大促场景能有效的提高服务端性能，埋点的写入与上报也须要有一些措施来进行动态的控制，埋点在客户端完成后，在合适的时机就会上报给服务端的移动日志网关，（移动日志网关目前也已经逐步被归入到移动接入中进来）。当客户端日志上报到服务端以后，便可由日志网关输出到服务端日志文件或投递至消息组件，供其余的平台进行消费计算，这包括如 Jstorm、kepler、Flink 这样实时计算平台，也能够投递到 Spark、odps 等离线大数据计算平台来进行进一步分析。做为基础组件，移动分析除了日志采集和同步以外，也进行了一些框架输出日志的基本数据分析，行为分析（像日活、新增、流存在）、页面分析（停留时长，参与度）、闪退分析、卡顿分析，并提供了日志回溯和日志拉取等能力供研发同窗进行问题排查和分析。固然，这些数据能够用于各类业务分析，分析的形式彻底取决于业务方想如何使用。

3. 对外输出的基础服务产品

【技术组件产品服务输出：成熟一个，开放一个】

咱们的基础能力通过这几年的努力，也沉淀了很多技术产品能够输出出来。这些技术产品覆盖了从 APP 研发到测试到运维到运营的各个阶段，有客户端框架、客户端基础组件，有云端基础服务（像 API 网关、SYNC 数据同步、PUSH 通知这些），有开放工具，有插件，有伴随研发测试的研发协做平台来进行迭代管理、编译、构建、打包，真机测试平台，也有 APP 运维阶段所需的智能发布、日志管理、应急管理，还有用于 APP 运营的，各类数据分析和营销投放产品。这些能力目前已经输出到了蚂蚁国际（印度 paytm、马来西亚、印度尼西亚、菲律宾等）的多个合做伙伴 APP，公有云的上百个企业级 APP，以及私有云的数十家金融 APP。

咱们的宗旨是，成熟一个、开放一个，来与合做伙伴共建移动互联网的生态。

【一站式研发平台——mPaaS】

为了可以帮助合做伙伴快速、有效的建设本身的 APP，咱们也推出了一站式的移动研发平台——mPaaS。mPaaS 囊括了前面说到的各项基础能力，同时，支持公有云和私有云，mPaaS 不只仅是技术的输出，也是生产经验和运营理念的输出。

原文连接 本文为云栖社区原创内容，未经容许不得转载。