北京华网天下

支付宝移动端高可用Hybrid方案解析：从单体应用到月活6.6亿的技术演进

2025-01-13

来源：网络整理

关于作者

（王磊）是蚂蚁金服高级无线开发工程师，也是容器和离线包的核心开发人员。目前专注于支付宝原生解决方案的输出解耦，并根据各种业务场景进行持续迭代和优化。

2013年到2019年，支付宝从单一的应用工具APP发展成为承载众多生态系统、月活6.6亿的国内TOP2应用。面对海量业务，支付宝如何选择技术？如何实现业务稳定运行和快速迭代？

在2019软件绿色联盟开发者大会跨平台分论坛上，阿里巴巴蚂蚁金服高级无线开发工程师王磊分享了支付宝移动高可用解决方案的分析。

2013年之前，支付宝是淘宝的担保交易工具，是单一应用的工具型APP。随着2013年余额宝的推出，支付宝逐渐转型为平台型APP，具有服务化、模块化、工具组件化的特点。到2015年，它已经成长为超级APP，承载了阿里巴巴生态系统中更多的内容，如淘宝、饿了么、美团、外卖等。这个阶段，客户和业务大量爆发，面临着活力和高可用性。到了2018年，支付宝作为国家级应用，不再仅仅承载阿里巴巴应用，还包含了众多第三方生态。支付宝也进入了一个新的阶段。

如何利用架构应对海量业务需求？

支付宝不仅涵盖阿里巴巴的业务，还包括大量的外部合作伙伴。经过综合比较，它采用了一种架构来处理这些业务需求。

1、技术方案选择

在选择技术方案时，核心要求是快速开发、动态发布。因此，我们主要考虑开发成本、用户体验、动态三个方面，重点关注技术选型。

首先，从开发成本来看，两端都需要开发，成本最高； H5技术相对成熟，很容易完成一个业务开发，而且成本最低；需要一些双端适配，有时多端适配有一定的开发成本；最近很流行。优点是两端体验一致，开发成本比较低，但有一定的学习成本。

从用户体验的角度来说，是最好的，能够满足产品经理的工作需求，并且有良好的用户体验； H5是最弱的。由于H5是纯前端技术，从交互角度来看体验较差；由于一些控件优化不到位，导致APP出现卡顿问题，用户体验不佳；就其而言，处于中间状态，比H5稍好一些。

动力学方面比较弱，只能通过其他方法进行优化； H5的动力是最大的优势； H5的动力也比较强；由于平台政策限制，动态低于H5。

在综合比较各种技术类型的特点后，结合支付宝的背景，最终选择了H5解决方案。

1.2 H5容器&离线包架构

H5容器架构从下到上主要分为五层：支付宝底层、中间件层、容器逻辑&定制内核、包管理、H5代码。

1.3 H5混合架构通信

混合通信使用通道进行双向通信。 Web 有许多端到端方法。支付宝使用JS。与其他解决方案相比，它的优点是不占用系统和浏览器进程，不会生成一些虚拟弹窗。上Web比较简单，运行JS即可实现。

1.4 完善 Web 体验

前面提到，由于H5容器在体验方面较弱，支付宝对其进行了多方面的优化，以提高体验。

1.5 容器扩展性 H5容器提供了三个方向的扩展方式：容器插件和切换配置。

1）：开发传统H5应用时也会用到。提供H5代码调用能力，如数据存储、全局广播等，同时还提供自定义扩展；

2）容器插件：容器是一个相对封闭的整体容器，提供事件监听机制，打通H5容器生命周期。它还提供了自定义机制，可以自定义H5生命周期中的配置，例如页面导航栏等，通过实现插件满足定制化需求；

3）开关配置：容器提供了丰富的开关配置供用户手动调整容器特性。 H5容器可以通过交换机配置进行扩展，并根据需要动态下发，满足定制化需求。

1.6 H5容器稳定性

支付宝是基于统一内核开发的，因此与传统相比，崩溃率和卡顿率明显降低，而且由于使用相同的内核，解决了整体体验不一致的问题。

高可用、即时、快速发布监控和运维系统

经过上述的技术选型、整体架构、打磨体验、稳定性之后，就发布了完整的解决方案。其次，需要一个完整的发布平台来保证在线环境下高效、稳定的开发。发布。支付宝主要通过监控+发布平台来满足业务稳定运行和快速迭代的需求。

2.1 快速发布平台

从快速发布服务架构图可以看出，从客户端到MDS中心再到最终的下载服务，其能力主要包括三点：

1）智能灰度能力：我们可以通过一些内部灰度策略、外部灰度策略，以及人群区域、机器模型网络等各种条件来进行灰度过滤；

2）增量差分离线包更新能力：众所周知，更新版本的大小越小，到达率越高。因此，必须减少数据冗余和设备带宽，才能在移动网络条件不稳定的场景下发挥优势；

3）系统高性能保障：如上所述，为了优化体验，支付宝会分发一些线下套餐，并结合推拉方式，保证到达率能达到99.99%。

2.2 监测与诊断

线下包交付后，将进行监控诊断，确保业务稳定运行。监测诊断主要通过监测指标、报告策略、报告方法和诊断分析四个过程进行。

1）监控指标：通过采集崩溃、流畅度、电量、流量、不可用埋点等指标运行状态进行监控；

2) 报告策略：根据既定的监测指标制定报告策略。上报策略会区分级别，按照优先级实时上报，通过单独的轻量级流程上报，不影响主流程。同时每个埋点都会有一个开关，保证流量的稳定性；

3）报告方式：有自动上传、定期检查上传、诊断命令驱动上传三种报告方式。每次触发崩溃时都会自动上传；定期检查上传是指按照一定的周期比例定期上传部分指标；由于开发过程中有大量的开发日志，不可能每次都上报，所以会有驱动指令。上传问题的开发日志，以便进一步分析；

4）诊断分析：首先，有一个公共崩溃分析市场。其他业务指标如不可用的埋点可以通过定制市场进行分析。

2.2.1 熔断与修复

诊断分析后，下一步是进行断路器和修复。以下是四个主要策略：

1）故障隔离：业务发生故障时，通过预设开关立即推送配置，隔离有问题的代码，及时止血；

2）流量熔断：统一的网络调用可以在网络异常时自动熔断，并在不同策略下达到阈值时自动触发异常上报或熔断；

3）自动恢复：当客户端在启动阶段监测到死锁、崩溃、首屏加载异常时，客户端启动自动恢复机制，重置并清除异常信息，以干净的形式重启。

4）动态修复能力：当其他方法无法解决问题时，可以通过动态修复能力来解决，例如发布开关、及时快速更新离线包版本、修复原生代码等。

2.3 H5应用发布实践

从下面的H5应用发布流程图可以看出，一个H5应用的发布需要几个流程：编码构建、设定指标、发布平台灰度验证、持续监控、正式发布、运维监控。每个流程出现的所有问题都可以使用上述解决方案来解决，形成闭环，保证产品的稳定发布。下面我们就几款产品的发布情况进行说明。每个应用都有自己的发布周期，比如口碑、蚂蚁森林、支付宝等，每个应用独立控制发布周期，不会耦合在一起。

开放生态App：小程序

本文主要讨论小程序如何契合支付宝开放的生态背景以及基于小程序的解决方案未来将如何发展。

3.1 小程序定义

这里我们先了解一下小程序的定义以及我们对它的一些要求。

小程序是一种依托Web技术、集成原生能力的移动应用新业态。

我们对小程序的需求主要分为四点。首先，它们需要方便、易于使用和携带；二是要连接，即业务和能力的连接；第三，需要安全、可靠、可控，确保用户搜索的每一条小程序都是安全的；最后一点是小程序比其他原生程序有更好的性能。

3.2 小程序架构

小程序的架构分为渲染层和逻辑层。这是一个双线程渲染和逻辑分离的架构。下面是pass层。一个小程序需要有APP描述文件、APP逻辑文件、多个页面和签名文件。

在渲染过程中，小程序代码会先转换为虚拟DOM，然后进行渲染。目前，虚拟DOM是通过浏览器渲染的。有了虚拟DOM，任何框架都可以在没有任何感知的情况下被替换。优点是比较标准化，还可以进行代码扫描，潜移默化地取代底层渲染框架。

每个触发的逻辑都会同步到渲染层。当页面有一些操作时，比如点击事件，首先会发送到相应的逻辑。经过逻辑处理后，数据将被绑定，然后通过消息通道返回到特定页面进行渲染，完成整个过程。如果需要调用能力，则需要逻辑层调用消息通道，然后调用JS层提供的底层能力。

3.3 小程序优化

小程序优化主要从预加载、小程序保活、渲染优化、逻辑引擎优化四个方面进行。