高可用、弹性动态的金融级移动架构在蚂蚁金服的演进之路

摘要： 支付宝做为国民级应用，当前全球用户已经超过 10 亿，提供了超过 200 项以上的服务，而崩溃率始终维持在万分之五如下，并且天天支付宝都上线新的功能和改进。作到今天这样的成绩，并不容易，是通过长时间的实践经验积累下来的。

导语

本文基于重岳在 2018 年 Arch Summit 北京站的分享内容进行总结，但愿经过本篇文章介绍近些年来支付宝在移动端架构的上演进和思考，期冀能给读者们带来些许帮助。

支付宝做为国民级应用，当前全球用户已经超过 10 亿，提供了超过 200 项以上的服务，而崩溃率始终维持在万分之五如下，并且天天支付宝都上线新的功能和改进。作到今天这样的成绩，并不容易，是通过长时间的实践经验积累下来的。
支付宝的架构演进主要经历了三个阶段，若是用比喻的话，能够分为独木舟、战列舰和航空母舰三个阶段。

独木舟时代

支付宝刚推出移动端时，它的结构很是之简单，除了一些工具组件被划分为模块，业务代码都是糅合在一块儿。刚开始并无太大问题，可是当咱们的研发人员迅速增加时，问题开始变得棘手起来，仅仅举几个例子即可见一斑。

1. 研发同窗晚上提交的能够运行的代码，到次日早上来更新一下就彻底不能用，缘由是其余不相干团队提交代码覆盖或者污染了本身的代码。
2. 临近发布点的时候，一般是最忙的，但不是忙着赶功能，而是忙着解决合并代码产生的各类问题，不只浪费时间，还耽误测试同窗的宝贵时间。
3. 即便最后勉强发布了，稳定性和性能也是很是糟糕的，由于各个模块只管本身的，没有统一的规范，也缺少统一的监控。
4. 最令 Android 开发头痛的是 65535 的问题，彼时 Google 尚未推出 multi-dex 的方案。

这些严重的问题让咱们的产品研发迭代变得没法持续下去，所以咱们决定来一次完全的重构，因而步入了战列舰时代。

战列舰时代

当设计新一代的客户端架构时，咱们从三个方向进行思考：团队协做、研发效率、性能与稳定。

团队协做方面，咱们但愿整个架构分层合理，基础层面，将通用能力下沉，为更多的上层业务服务，避免重复创造轮子；业务层面，各个业务团队可以独立开发管理，不会对不相关的业务形成影响。基于这个初衷，咱们造成了下图这样的架构：

整个客户端架构总共分红四层：业务层、服务层、组件层、框架层。

• 业务层：只需专一于业务逻辑与界面的实现，当须要调用如支付这样的通用能力时，研发同窗直接使用下层提供的服务能力，不需本身开发，如此可以保证核心能力有收口，方便监控。
• 服务层：经常使用模块，如登陆、支付、营销等，它们不只本身是业务，也向其余业务提供本身的服务，咱们将此类模块归类到服务层。
• 组件层：这一层提供的是客户端通用能力，如安全、网络、多媒体、存储这些，它们提供稳定的接口给上层使用者，同时不断优化自身内部的性能和稳定性，做为客户端的基石，它们相当重要。
• 框架层：最为关键的部分，包括容器、微应用、服务框架以及 Pipeline，客户端的微应用化、启动管理都依赖框架层的运做。

咱们将服务层、组件层和框架层合称为 mPaaS，即移动端上的 PaaS 服务。这些 PaaS 服务能够复用，咱们不只在支付宝里使用它们，也在其余集团应用，如蚂蚁财富、网商银行等中使用。

业务分治

要实现业务分治，最好的方式就在代码上可以进行隔离，你们没必要在同一个 Codebase 中开发，避免代码合并冲突的现象，这个一般在 Android 上一般能够 aar 的方式来实现，可是惋惜的是咱们重构的时候 aar 还没出来，并且即便有 aar，也存在打包时间随代码体积增大线性增加的问题。

咱们的解决方案借鉴 OSGi 的概念，将整个客户端以 Bundle 为单位划分，每一个 Bundle 能够包含本身的代码、页面和资源。读者可能会想，这究竟和 aar 有什么分别呢？其实区别很大！

首先，Bundle 里的代码部分是已编译的 dex，当编译 apk 时，咱们只须要合并 dex 便可，不须要像 aar 那样将 class 编译成 dex 再进行合并，这样大大节省了打包时间；其次，Bundle 是能够独立运行于本身的 ClassLoader 中的，而且咱们能够经过壳代理的方式加载 Activity 等基础组件，使得动态下发业务成为可能；最后，Bundle 里还包含微应用、服务和 Pipeline 相关的配置信息，框架会根据这些信息启动相应的组件。

mPaaS 的服务，即 Service 相似于 Spring 框架中的 Service，它对外提供接口服务，而使用者不须要知道如何初始化服务的实例以及生命周期管理，这些彻底由框架来托管。使用者只须要知道目标服务接口类的方法参数便可，调用时经过框架提供的 API 来获取实例。

对于服务的发布者来讲，他在本身的 bundle 中声明接口类以及实现接口类派生的实例类，并注册相关信息到 bundle 的 manifest 文件中。这种作法的本质思想是 Inversion of Control，减小类之间的复杂依赖，避免繁琐的初始化工做。以依赖接口的方式进行开发，可以解除服务使用者对服务提供者的依赖，在服务提供者还没有彻底开发完成时，使用者能够彻底以 mock 的方式来模拟服务，而不须要修改本身的业务代码，固然，前提是双方协商好服务接口的协议。

支付宝中的页面很是多，直接启动 Activity 或者 ViewController 对咱们来讲远远不够，咱们选择在它们上面增长 MicroApp，即微应用的概念。微应用具有惟一的应用 ID，在框架中标识本身的存在。微应用具备统一的入口，根据使用方传入的字典参数来管理 Activity 或 ViewController。这样可以带来不少好处：

1. 只要应用 ID 和参数协议不变，使用方不需担忧目标应用内部重构带来的影响，直接使用 Activity 或者 ViewController 类名形成的引用泛滥的问题不复存在。
2. 微应用的 ID 和字典参数特性，很容易生成 URL，从而实现外部应用使用 URL 跳转应用内页面。
3. 从数据的角度，咱们能够按业务维度来统计用户行为数据。
4. 微应用的概念不只适用于原生页面，一样也适用于 H5 和小程序。注册为 H5 或者小程序类型的应用 ID，框架会自动将启动过程 delegate 给 H5 或者小程序容器，而使用者彻底没必要关心应用 ID 对应的应用类型。

综上所述，微应用化和服务接口所赋予的特性极大提升团队间协做效率，各研发小组之间的依赖更加简单，能够各行其道，更关注于自身服务的打造建设。

性能优化

咱们一方面在架构上做出重大改变来提升研发效率，另外一方面也在不断的进行性能优化，改善用户体验。咱们主要从三个层面来着手：

框架层面

1. 制定统一开发规范，业务方使用统一的线程池、存储、网络等组件，并按需进行加载，避免没必要要的启动和耗时操做。
2. 引入 Pipeline 机制，业务模块如需在应用启动时进行初始化工做，必须使用 Pipeline。框架依据业务优先级肯定业务初始化实际。
3. 利用 AOP 切面，对经常使用路径进行耗时统计，追踪性能瓶颈。

基础指标

对于经常使用指标，如闪退、ANR、内存、存储、电量、流量等，进行长期追踪。咱们可以明确获悉每一个版本之间这些指标上的差别，并进行采样分析，定位并解决问题。

向下突破

咱们不只仅在应用层面进行优化，同时也向下探索性能提高的可能性。在这方面，咱们也收获颇丰，好比在 Android 上某些系统版本，经过在启动阶段禁用 GC 的方式得到 20%~30% 的启动时间缩减；在 iOS 上，利用系统自己的 Background Fetch 机制提升进程活跃时间，实现应用秒起。

航母时代

随着移动支付的不断普及，面对海量的用户和业务需求，高可用、弹性动态成为支付宝客户端更为艰巨的挑战。支付宝做为集支付、金融、生活为一体的服务平台，须要可以快速稳定的发布服务和引入第三方服务，同时对于用户的反馈和诉求必须可以积极迅速的响应。

动态研发模式

咱们在研发模式上做出改变以业务快速迭代的要求，业务逐步由原生页面向 Web 混合页面迁移。原有的研发模式可以很好的知足团队协做的要求，可是随着业务规模的不断增大，代码量相应膨胀致使安装包太大，在iOS上一度超过代码段上限，没法经过 AppStore 审核，另外基于集中时间点的迭代发布，一般是一个月发布一个版本，远不能知足业务的更新速度要求。相较于原生应用开发，Web应用的优点很是明显：

1. 只须要一套代码，Web 应用能够在 iOS 和 Android 客户端中运行，可以相对减小人员的投入。
2. 每一个用户平常使用的功能仅仅是支付宝庞大平台中的一小部分，H5 应用能够作到动态下发，所以能够消除冗余的存储，下降包大小。
3. 近些年来 React Native，Weex 等动态渲染引擎在社区很是活跃，但通过小范围的应用以及考虑到 Web 技术的不断发展以及其在业界公认的地位，咱们最终仍是选择 Web 技术做为动态研发模式的基础。
4. Web 应用迭代摆脱了客户端集中时间点发布的束缚，各业务线迭代计划变得自主可控。

打磨 Web 体验

尽管 Web 应用优点明显，但在移动端上的短板也是显而易见的，它提供的用户体验、性能以及能力上的限制与原生应用有至关大的差距。为了弥补这些差距，咱们作了大量的改进，主要在如下几个方面：

1. 先后端分离，咱们将页面资源离线化，这样节省了资源请求消耗的时间，使得页面打开速度提高明显，解决了在网络环境较差下容易出现白屏的问题。同时，数据请求使用 native 网络通道，可优化的空间更大，安全性更高。
2. 差量更新，客户端更新某业务应用版本时，不需下载完整的新版本资源包，而是下载由发布平台根据客户端本地安装版本计算生成的体积更小的差量包，这样不只可以节省带宽和流量，也提高了业务更新的速度。
3. 推拉结合，解决业务最新版本覆盖率的问题，每次发布新版本时，业务可主动触发消息到客户端，客户端收到通知后会更新该业务应用版本。同时，客户端会定时去检查服务端是否有版本发布，这样可以保证版本发布后大多数用户在短期内得到最新的应用。
4. 容错补偿，客户端可能因为网络、安全或者存储权限等缘由，不能使用或者及时得到离线包，这种状况咱们也考虑进来了。咱们在发布离线资源时，发布平台会自动生成对应的在线 URL 并配置到应用信息中，当客户端加载 Web 应用时发现离线包不可用，会马上启用该url加载内容，可以最大程度保证业务可用性。
5. Android 独立浏览器内核，Android 碎片化的问题自其诞生之初业已存在，并且目前看上去没有得以解决的迹象。不一样系统、不一样厂商中的浏览器内核一样存在差别，这致使层出不穷的兼容性问题令研发同窗头疼不已，这也违背 Web 一统天下的愿景。为了完全解决并掌控这些问题，咱们引入了独立的 UC 浏览器内核并集成在应用中，这样全部的问题都集中到UC团队解决，变得很是可控，根据数据统计，使用 UC 浏览器内核后浏览器相关的闪退和 ANR 有明显的降低。同时，安全上出现的漏洞，咱们能够在第一时间修复并发布，远比厂商升级更有效率。
6. Web 应用全方位监控，资源加载异常、JS执行异常、白屏、加载耗时等性能数据会被收集上报至后台，能够及时发现异常。

小程序

咱们不只自身提供各类各样的服务，也须要引入第三方服务来服务更多的人群，以往咱们只能引入简单的第三方 H5 页面，它们只能使用支付宝提供的少许功能，并且开发人员能力的差别致使用户体验不是很理想。小程序将支付宝的能力全面开放出来，从开发到测试皆有完整的 IDE 等工具链支持，同时 DSL 简单易用，对于第三方来讲，可以快速开发上线一款体验和功能比以往更强大的小程序。

---

本文做者：josephjin

阅读原文

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