作者 ：吕丹（凝睇），2011 年加入支付宝，先后负责了支付宝 Wap、alipass 卡券、SYNC 数据同步等项目，并参与了多次双十一、双十二、春节红包大促活动，在客户端基础服务方面有一定的项目实践经验与积累。目前负责蚂蚁金服移动开发平台 mPaaS 服务端组件体系优化与架构设计。
5 月 6 日，InfoQ 主办的 QCon 2019 全球软件开发大会在北京举行。蚂蚁金服技术专家吕丹（凝睇）在大会上做了《蚂蚁金服面对亿级并发场景的组件体系设计》的分享，我们根据演讲整理如下：
今天，我主要想和大家分享一下移动领域基础组件体系，内容大致可以分为四大块，第一块是标准移动研发所需的基础服务体系，第二块是支撑亿级并发的核心组件“移动接入”的架构演进过程，第三块是双十一、双十二、新春红包这种大促活动的的应付方法，最后一块是目前已经对外输出的基础服务产品。
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%，在后面的 2、3 年中，业务从 80 个增加到 300 个，服务器也没有增加。整体来说，对性能的提升还是非常明显的。
2. 大促活动场景应对之道
前面的内容主要是移动接入方面的组件设计如何支撑亿级场景，下面我们聊一下，如何切实的应对大促活动。
【大促活动场景应对之道：步法】
通过几年的大促经验，我们在技术上提炼出了应对大促的几个步法：首先业务同学设定业务目标，确定业务玩法；技术同学在收到大促介绍之后，开始分解技术指标，并根据各自系统的能力、流程和特性确定相应的技术方案，确定技术方案的步骤则主要为：链路分析、容量评估、性能优化、流控方案、预案策略以及确定弹性流量规则。在确定完成技术应对方案后，最重要的是进行全链路的压测，通过影子用户，影子表进行生产环境的全链路压测，每个系统压测周期短则几天，长则需要数月。在不断的压测中发现问题，发现瓶颈，优化后再次进行压测，直到完成技术目标；在全链路完成压测指标后，进行多轮活动的演练，以模拟真实业务场景，并验证技术方案的准确性；此后，根据实际需要，择时进入大促阶段。在这个阶段，研发同学主要工作是配合运维进行预案的执行、观察大促期间各种指标的变化，并根据监控确认是否需要应急。当然，应急方案在之前的演练中也需要进行验证。随后大促活动结束后，需要进行预案 & 应急策略的回滚和验证，这样大促活动才算真正结束。同时，更重要的是，我们需要对每年的大促进行复盘 review，以便发现不足，在后续的活动中加以改进。
【大促活动场景应对之道——流控】
在大促执行过程中，最为关键的是流控。对技术同学来说，让系统在活动中活下来是对大促最给力的支持，流控是系统最有力的屏障。由于各系统在大促活动中发挥的作用、业务的紧急程度、集群的规模各不相同，因此大促中一般会牺牲一些特性来为主要链路腾出性能空间，比如流水日志、压缩阈值、消息顺序性等等。
流量的管控也会分多级，在最上层 LVS 会在 VIP 上进行数十亿级别的控制，到接入网关层则根据建连量、包数进行亿级流控，而 API 网关层则进行千万级别的控制。在这几层上，一般简单计数即可满足。而到业务层，特别是中低流量的业务层，一般采取的是令牌桶和分布式限流方式。然后，在 API 网关上，也可以做一些自定义的脚本，mock 返回结果来为业务系统抵挡住一部分请求。
【自动化真机测试】
除了核心链路之外，我们也需要一些后勤服务。例如在测试过程中，需要自动化，特别是真机模拟测试来抵消部分的人力劳动。我们的机房中部署了上千台手机，通常都会进行一些自动化的运维检测，包括安装包的安装卸载、性能损耗、功能测试等。除了自动化测试，它还扮演着自动审批和服务巡检的角色，分别用来检测小程序和及时发现问题。通过自动测试平台可以节省 60% 以上的重复体力劳动消耗。
【客户端智能发布——确保客户端万无一失】
如果要确保客户端万无一失，那么最核心的就是灰度流程，灰度流程结束之后，我们才能发布到生产环境中。
智能发布主要支持客户端各种的发布包，包括安装包、离线包、小程序包等。通过多年的发布，我们也沉淀了一些模板，例如灰度用户、灰度覆盖率等等。灰度时我们可以选择一定的模板，按照既定逻辑，使用自动化流程代替人工处理。
【舆情分析——及时获取用户反馈】
客户端发布之后，业务同学一定非常关心用户心声和市场反应，技术同学则希望第一时间收集到用户的真实反馈。舆情分析系统就用来满足这些需求，舆情系统可以分为 4 大块：数据采集，主要采集渠道为各大媒体中心、应用市场评论、开会的反馈功能和客户满意中心的数据；数据内容则可以包含各种热点话题、热点事件和主要生产问题；数据存储，目前主要由 4 大块来支撑：元数据一般可以采用关系型数据库，文档数据使用的是 MongoDB，爬虫采集的条目通过 MQ 来传输，所有数据最终会落至 ES 中，用来做检索和基础分析；数据计算更多的是通过文件算法来对 ES 中的数据进行分析，最终产出各种趋势和各种事件、话题排行，同时针对每一个用户反馈又可以实时通知到相关的负责人。
在这里我们说的移动分析主要是基于客户端日志埋点的数据分析能力。客户端需要有标准的埋点 SDK 来采集 Native、H5、小程序的各种框架 & 容器埋点，也需要支持业务自定义的业务埋点。同时，为了在大促场景能有效的提升服务端性能，埋点的写入与上报也需要有一些措施来进行动态的控制，埋点在客户端完成后，在合适的时机就会上报给服务端的移动日志网关，（移动日志网关目前也已经逐步被纳入到移动接入中进来）。当客户端日志上报到服务端之后，即可由日志网关输出到服务端日志文件或投递至消息组件，供其他的平台进行消费计算，这包括如 Jstorm、kepler、Flink 这样实时计算平台，也可以投递到 Spark、odps 等离线大数据计算平台来进行进一步分析。作为基础组件，移动分析除了日志采集和同步之外，也进行了一些框架输出日志的基本数据分析，行为分析（像日活、新增、流存在）、页面分析（停留时长，参与度）、闪退分析、卡顿分析，并提供了日志回溯和日志拉取等能力供研发同学进行问题排查和分析。当然，这些数据可以用于各种业务分析，分析的形式完全取决于业务方想如何使用。
3. 对外输出的基础服务产品
【技术组件产品服务输出：成熟一个，开放一个】
我们的基础能力经过这几年的努力，也沉淀了不少技术产品可以输出出来。这些技术产品覆盖了从 APP 研发到测试到运维到运营的各个阶段，有客户端框架、客户端基础组件，有云端基础服务（像 API 网关、SYNC 数据同步、PUSH 通知这些），有开放工具，有插件，有伴随研发测试的研发协作平台来进行迭代管理、编译、构建、打包，真机测试平台，也有 APP 运维阶段所需的智能发布、日志管理、应急管理，还有用于 APP 运营的，各种数据分析和营销投放产品。这些能力目前已经输出到了蚂蚁国际（印度 paytm、马来西亚、印度尼西亚、菲律宾等）的多个合作伙伴 APP，公有云的上百个企业级 APP，以及私有云的数十家金融 APP。
我们的宗旨是，成熟一个、开放一个，来与合作伙伴共建移动互联网的生态。
【一站式研发平台——mPaaS】
为了能够帮助合作伙伴快速、有效的建设自己的 APP，我们也推出了一站式的移动研发平台——mPaaS。mPaaS 囊括了前面说到的各项基础能力，同时，支持公有云和私有云，mPaaS 不仅仅是技术的输出，也是生产经验和运营理念的输出。
本文作者：josephjin
阅读原文
本文为云栖社区原创内容，未经允许不得转载。