个人网站备案入口,旺道seo优化,设计师每天都上的网站,夏都西宁吧5 月 6 日#xff0c;InfoQ 主办的 QCon 2019 全球软件开发大会在北京举行。蚂蚁金服技术专家吕丹#xff08;凝睇#xff09;在大会上做了《蚂蚁金服面对亿级并发场景的组件体系设计》的分享#xff0c;我们根据演讲整理如下#xff1a;
今天#xff0c;我主要想和大家…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 不仅仅是技术的输出也是生产经验和运营理念的输出。
原文链接 本文为云栖社区原创内容未经允许不得转载。
