蚂蚁金服 mPaaS 模块化开发与架构重构深度解析

本文整理于蚂蚁金服无线工程师刺胃在 2019 安卓巴士开发者大会现场的分享《蚂蚁金服 mPaaS 模块化开发与架构重构深度解析》，经过“模块化开发架构设计”做为切入口，聚焦 mPaaS 如何深度应用与实践模块化开发架构，以及在架构重构中遇到了哪些挑战和具体解决思路。

内容概要

主要分为如下三个部分：

1. 支付宝在移动端的架构演进与思考
2. mPaaS 模块化架构及能力
3. 基于 mPaaS 架构的重构思考

支付宝在移动端的架构演进与思考

支付宝现状

根据 2019 年移动互联网最新的数据报告，目前支付宝全球总用户数已超过 10 亿人，月活用户数超过 6.5 亿，成为国内第二大 App。

在研发上面，支付宝的客户端研发人员超过 300+，总体工程数一样也是超过 300+，整体代码超过 200 万行，提供的服务超过 200+，而且总体的闪退率维持万分之五如下，那么支付宝是如何保证在如此庞大的研发规模下，保证服务的告诉迭代，以及应用的总体稳定性的呢？

三个阶段

支付宝作到今天，主要分为三个阶段：

1. 独木舟阶段

支付宝刚开始推出的时候，和不少简单的应用同样，都是一个单体应用，除了一些简单的公共组件被做为 lib 模块，其余大部分业务代码所有写到一块儿。这种单工程的轻量结构，对于当时的支付宝来讲，还算是能够知足需求，可是随着支付宝业务的迅速成长，问题开始暴露出来了，因为单工程，全部工程师代码都要合到一块儿，并行开发变得异常艰难，同时，因为发布时间固定，各团队匆忙合并代码，极可能出现代码覆盖、污染的状况，从而致使稳定性没法保证。这种开发模式，咱们称之为「串行开发模式」。

2. 战列舰阶段

为了解决独木舟阶段咱们存在的问题，在 13 年末，支付宝进行了一次完全的重构，基于 OSGi 模块化思想，推出了 Quinox 容器化框架。基于这套框架，支付宝完成了从单体应用到平台型应用的转变，从单工程「串行开发模式」变为了多工程「并行开发模式」。各工程之间只关注接口，不用在乎实现细节，页面间路由只需一个 id。代码彻底隔离，开发、发版效率有了明显提高。由于基于框架提供的 pipeline 机制，业务治理变得很是方便，使得总体应用的启动性能有了明显的提高。

3. 航空母舰阶段

时间来到了 15 年，在解决了协做效率、启动性能等问题后，随着移动支付的普及，业务的井喷，用户对应用体验要求的提升，弹性动态、高可用这两个变为了这个阶段的重点。为了解决这些问题，支付宝引入了 Nebula 容器、小程序、多维发布以及全链路的监控等组件，来保障转型成为超级 App。

架构升级技术挑战及解决方向

经过刚才咱们简要的回溯支付宝近些年的架构升级历程，咱们能够总结出，重构升级成超级 App，须要解决的几大块技术点：

• 协同开发，业务解耦
• 启动性能调优，业务治理
• 复杂业务动态化，多维发布
• 保证高可用，数据全链路采集，多维度修复

mPaaS 模块化架构及能力

带着上面提出的四个技术问题，咱们来先了解下 mPaaS 的总体架构图

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

• 框架层：最关键的部分，整个模块化的基础。提供微应用、微服务、pipeline、切面、监控等服务。总体模块化协同开发，都是基于框架层提供的能力，来达到「并行开发」的目的。
• 组件层：这一层提供的是客户端通用能力，如安全、网络、多媒体、存储这些，这些组件都是支付宝多年沉淀下来的经典组件，它们提供稳定的接口给上层使用者，做为客户端的基石，它们相当重要。
• 服务层：本层就是和支付宝相关的一些核心服务能力，咱们将他们抽取出来，进行服务化，服务 App 自己，也服务各个生态业务。
• 业务层：业务方和第三方服务提供者，只需专一于业务逻辑与界面的实现，调用总体框架提供的各类能力，最后经过总体应用的动态化能力进行多维发布。

经过 Quinox 框架、微服务、微应用，便可实现上面的架构分层，接下来咱们将逐一介绍。

Quinox 框架

Quinox 客户端框架是类 OSGi（ like-as）框架的实现。Quinox 一词来源于著名的 OSGi 框架的实现 Equinox。

基于 mPaaS 的 App 研发，就像积木搭建（Bundle）同样轻松，天生具备如下优点：

• 灵活性：模块/组件可插拔，不影响编译
• 独立性：模块可由团队或我的独立维护
• 复用性：模块可被任意宿主程序所引用
• 隔离性：接口和实现分离，微应用路由跳转

微服务

mPaaS 框架提供微服务功能，该服务相似于 Android 原生的 Service，直接经过框架的方法，便可得到服务的实现。这种设计模式自己核心是控制反转，依赖注入的这种理念，减小各模块间的依赖，初始化等复杂的工做，完成解耦。
做为使用者方，无需了解实现细节，只须要提供参数，调用服务提供的接口便可得到服务。
做为开发者，只须要将服务接口注册到框架上，框架在初始化后，会自动去生成服务，控制服务的生命周期。

微应用

mPaaS 框架提供微应用功能，微应用咱们能够理解为 mPaaS 的路由。
做为使用方，经过惟一的 appId，进行不一样微应用之间的调用，使用者并不须要引用对方的 activity，也无需关注对方内部的跳转逻辑。
做为开发者，只须要将 appId 注册到框架上，当有业务调到该 ID 后，后续的操做彻底有开发者掌握，业务之间彻底隔离解耦。
微应用的概念不只适用于原生页面，一样也适用于H5和小程序。注册为H5或者小程序类型的应用 ID，框架会自动将启动过程delegate给H5或者小程序容器，而使用者彻底没必要关心应用 ID 对应的应用类型。
综上所述，微应用和微服务可使各个业务之间的耦合降到最低，你们都无需关注其余团队的实现，代码之间无侵染，这样总体的协做研发效率也就随之提高上来了。

Pipeline 机制及启动优化

上面的内容主要是讲如何高效的进行协同开发，接下来该第二个技术点，也就是 mPaaS 是如何对框架的性能进行治理的。对于性能优化，mPaaS 框架主要从业务和技术两个方面进行处理：

技术优化：

• mPaaS 经过黑科技，将启动时的 JIT 关闭，从而有效下降因即时编译致使的性能问题
• 经过关闭启动时的 GC，从而将启动速度提高到最快，当启动完成后，在进行一次较大的 GC。
• 提供各类切面及监控能力，全方面监控启动异常

业务优化：

• mPaaS 框架提供统一的启动流程、线程池、并发工具类等，能够有效的使业务规范化
• 而且，mPaaS 提供 pipeline 机制，能够根据业务优先级进行初始化调优，从而达到启动优化的目的。

动态化

解决了上面两个技术点，mPaaS 框架就已经具有成为战列舰的能力了，接下来，咱们看下如何更近一步，提供航空母舰的能力。
做为超级 App 的核心能力，就是如何构建生态。”快速起飞、降落，承载大量、不一样的舰载机“是其要解决的核心问题。解决这个问题的关键就是框架的 Hybrid 能力，mPaaS 上面，采用了支付宝多年积累下来的 Hybrid 经验，使用 Nebula 做为 H5 容器，同时承载 H5 离线包以及小程序。

H5 容器及离线包的特色：

• 全面兼容主流 H5 框架，迁移成本低
• 使用离线包技术，体验接近原生，网络请求走原生，高效安全。
• 提供统一 UC 内核，性能及稳定性有保障
• 离线包差量更新，节省流量
• 提供容错机制，下载失败后走线上 fallback
• 实时触达客户，经过推拉结合，下发离线包

H5 离线包做为动态化方案，有点多多，可是，其有一点不足就是没法管控质量，宽泛的前端规范让服务管控变得异常困难，若是全部服务都是咱们内部的业务还好说，若是开放给第三方，就须要有完整的规范来约束。这时，咱们就要引入小程序来规范化服务，提供给第三方。

小程序特色：

• 统一的小程序架构，可在任意基于 mPaaS 架构开发的应用上进行投放
• 强大的 Web 渲染引擎
• 提供丰富组件，快速实现业务
• 整合离线包技术，能够复用 H5 插件
• 完善的生命周期管理

当咱们解决完动态化的技术点后，应用将会有如下四点优化：

• 包尺寸有效减小，节省流量和存储。
• 服务再也不受发版所限制，快速发布，快速迭代。
• 业务开发效率更加优秀，一次开发，多端运行。
• 应用升级为平台，提供优质服务并按需加载。

多维发布

做为一套完整的动态化方案，光有容器实际上是不够的，咱们还须要有多维触达用户的手段，将各类服务发布给用户，接下来，咱们就聊聊 mPaaS 多维发布都具有哪些能力。
经过 mPaaS 发布平台，咱们能够轻松地将咱们的 App 新版本、H5 离线包、小程序包、热修复包以及开关配置进行下发。
同时发布平台提供了正式发布和灰度发布，经过灰度发布，咱们能够有效的验证待发布的内容，检查是否有潜在的风险，若灰度发布时出了问题，可进行及时回滚，减小覆盖面，有效的下降了正式发布的风险。
另外发布平台还提供不一样的纬度，包括白名单、机型、城市、系统版本等，这些纬度可使发布能够更具备针对性。

运维体系

上面解决了协同开发、性能优化、动态化等技术点，最后一个技术点就是如何保障高可用，确保应用的稳定性。
mPaaS 提供一套完整的运维体系来保证线上 App 的稳定。

1. 开发测试

经过接口实现分离，各模块充分进行单元测试，集成以后进行联调测试，联调测试以后，交给 mPaaS 云测平台，进行稳定性测试以及功能测试。充分的测试，能够将 80% 问题发现出来，并在发版前及时修复。

2. 灰度发布

结合上面提供的灰度能力，进行灰度发布。对于客户端来讲，有些问题，模拟测试环境是很难测出来的，那么这个时候，真实的线上灰度环境就是预防风险的重要手段之一了。经过灰度发布，逐步放量，不断扩大灰度范围，直到闪退率、卡死率等指标符合发布标准后，再进行全量的发布。

3. 实时监控

全方面监控各类纬度的 App 数据，如闪退、卡死、卡顿、电量、流量等。指定必定的异常规则，有问题及时进行报警。这些诊断数据是会周期性的进行上报，不过当有些特定机型或者特定用户出现没法复现的问题时，咱们还能够经过捞日志的方式，将指定设备的开发日志上报给服务端，进行分析排查。

4. 动态修复

最后，当问题发现并解决后，能够经过上面提到的发布平台，将修复后的配置、离线包、小程序、热修复 patch 包等，下发到对应设备上，进行容灾修复。

基于 mPaaS 架构的重构思考

上面介绍完了 mPaaS 的能力，接下来咱们聊下基于 mPaaS 的重构思考，本章会从五个维度来考虑重构。

架构重构

当咱们决定架构重构后，通常会有两种选择进行重构，一种是所有推倒重来，还有一种是融合迁移。

这两种方案，咱们能够比喻为一架比较老的飞机，已经不足以知足如今的飞行任务，第一种方案就是将飞机飞回机场，从新拆掉，结合新的设计架构重新组装。第二种方案是在执行飞行任务的过程当中，咱们逐步去替换发动机、替换不知足架构的地方，直至飞机知足最新的任务需求。
不管咱们采起哪一种方式进行重构，首要的工做就是梳理现有业务，将总体结构进行模块化拆分，同时对咱们总体的架构进行合理分层。

基于第一种方案，咱们首先须要基于 mPaaS 架构搭建一个全新的框架，同时，因为咱们是推倒重建，因此咱们须要尽可能减小在此阶段提的新需求。等当总体架构完成后，再增长新需求。框架搭好后，咱们须要将各项业务也进行重构，并逐个插到 mPaaS 容器化框架上来。最后当全部业务所有重构完成后，咱们再进行全量的回归测试。
这种方式的优点和劣势都很明显，优点就是彻底基于新的架构来实现，抛弃原有的包袱以及不合理的地方，可是劣势就是，彻底重构所须要的工做量是巨大的，同时有些企业可能没法接受如此长的时间不能或只能少许的更新需求。

基于第二种方案，第一件事情就是将 mPaaS 架构接入进咱们原有的工程中，而后再对原有框架进行融合适配：好比开发一个兼容新老框架跳转的路由，兼容新老 H5 容器的原生插件等等。兼容工做完成后，咱们就要对原有业务进行改造升级，咱们能够将业务逐渐的拆分出来，跑在新的框架上。每完成一点，咱们均可以进行一次迭代发布，测试的压力也会比较小。
这种方式的好处就是整个重构过程是一个持续性的过程，每一步均可以有产物输出，小步快跑，持续迭代。可是劣势就是，可能最终的版本，会有融合的痕迹存在，一些历史包袱也可能没法很好地甩掉。

固然，这两种重构方式没有谁好谁坏，根据业务自身的需求来选择本身合适的方式才是最好的。

能力重构

上面咱们介绍了架构重构以及相应的方式，接下来咱们来聊聊能力重构。
所谓能力重构，就是咱们但愿经过整合整个架构，在基础层面，将通用的组件下沉，避免重复创造轮子，同时标准化服务接口，为更多的上层业务提供优质、稳定且标准的服务。
那么咱们就须要从两个方面来处理这个事情。

基础组件

咱们在开发过程当中可能会存在这样一个问题，就是两个团队协做开发，可能你们有本身的一套存储逻辑、网络请求、工具库或是其余冗余重复的代码，这时候咱们就须要将重复的部分，进行合并，沉淀，经过公共 bundle 的形式，对其余团队提供能力。
固然，mPaaS 框架自带了很是优秀的网络、安全、存储、多媒体等 App 开发过程当中都须要使用的组件，供开发者直接调用。

核心能力服务化

组件沉淀后，对于一些核心的业务能力，咱们须要将这部分能力进行服务化，抽象出标准的服务接口，供其余团队或是第三方生态调用。好比说支付宝的支付服务、芝麻信用服务等，都是依托于服务化，最终良好的为其余业务提供服务的。

业务重构

在咱们完成框架重构和能力重构以后，总体的骨架和能力就已经具有了，剩下的就是基于这套框架，将咱们的业务界面进行重构，在这里，咱们建议你们参考如下原则：

核心业务微应用化
针对一些很是核心的业务逻辑，好比支付报的支付，以及一些对性能要求比较高的业务，好比首页，亦或是一些特殊交互的页面。一般咱们是但愿经过使用原生页面，并将页面打成微应用的形式进行重构优化。由于这些页面，一般不会有大改，因此对动态化能力要求不是很严格，同时原生又能知足这些页面多种多样定制化的需求。

复杂业务 H5 化
对一些复杂的二级业务，可能业务自己会频繁的进行迭代，那么对于原生 native 将会是灾难般的开发体验，这时候，咱们需将这部分业务剥离出来，经过前端技术将业务打成 H5 离线包，再经过发布服务将离线包发布到应用上。这样，就知足了咱们业务复杂多变的场景。

三方生态小程序化
咱们不只自身提供各类各样的服务，也须要引入第三方服务来服务更多的人群，传统的 H5 页面因为过于宽泛的前端标准，加上有必定的技术门槛，这里就不如规范、简单的小程序了。因此，通常第三方的服务，咱们但愿将其小程序化。

发布重构

当一切开发工做都 OK 以后，咱们是否可以说，本次的重构就完成了呢？答案是否认的。重构，不只仅是针对代码层面的重构，基于新的架构以后，总体的发布、运维理念也须要进行重构。

如上图所示，咱们从新定义了研发模式与发布流程，Native 应用、H5 业务、小程序，均可以有本身的发布流程，无需阻塞等待其余团队。各业务团队进行彻底拆分，每一个业务独立演进，独立发布。

在发布过程当中，要遵照如下流程：

1. 指标线性，定义每次发布的业务和性能指标
2. 智能灰度，内部灰度、外部灰度、指定灰度
3. 实时监控，修复循环
4. 线上运维修复手段技术兜底

运维重构

在上面咱们也讲到了运维理念的重构，在这里，咱们要介绍下 mPaaS 架构是如何保障线上应用的质量的呢？
咱们引入了多维度运维的概念，如图所示

最上面一层是开关。经过开关，将一些咱们新开发的，或者是将稳定性不太肯定的代码包起来。这样，若是真的线上发生故障，咱们能够及时经过服务器推送开关，将故障代码关闭，这种方式是推拉结合的，即时到达率 100%。
第二层纬度就是经过 H5 离线包。若是某些故障是发生在离线包内，那么咱们能够定位到问题，直接再发送新的版本便可，这种方式也是推拉结合，但因为离线包须要下发，因此不如开关那么即时，不过在 1 分钟以内也能覆盖 99% 以上的用户
第三个纬度就是小程序。若是故障发生在小程序上，那么同离线包，咱们只须要从新修改小程序，从新发布，不过这里可能会涉及到审核问题，效率比离线包要略慢一点。
在下一个纬度第四个纬度是咱们的热修复。不到万不得已通常不会进行热修复，这是一个原生 Native 兜底的手段，经过热修复补丁包的下发，咱们来弥补咱们的缺陷，通常成功率会在 95% 以上。

最后若是以上手段都没法修复，那么咱们会启动紧急发版流程，发布新的版原本覆盖故障。

重构案例

12306

2017 年末经过 mPaaS 进行了系统的重构，使用了 mPaaS 框架以及多项组件及服务，解决了 12306 移动端开发多年的痛点。好比 12306 的弹性动态化，以前会有在启动页面强制更新下载的状况，用户体验不太好，经过 mPaaS 优化后，进行了无感知更新，用户体验提高了一个台阶；还有就是 12306 使用了 mPaaS 的网关，其服务安全性获得了质的提高，也使得正经常使用户的总体购买流程获得了好的体验优化。
做为开发角度，客户表示当年是移动端开发、运营最轻松的一年。做为使用者角度，多数用户也表示使用体验改善了不少。

广发银行

广发银行以前采用其余移动端研发平台，性能一直是瓶颈，尤为启动时间，在部分低端机型上体验不太友好，使用 mPaaS 重构后，平均启动性能有了质的提高。
广发银行是“发现精彩”与“手机银行”两款 App 前后完成上线，两个 App 均使用 mPaaS 框架进行重构。其内部有多个模块的功能是重叠的，经过 mPaaS 模块化架构拆除可复用的微服务、微应用以及离线包，使得开发后的手机银行客户端在研发工时上节省了大龄的研发工时。

针对移动端架构设计和重构实践，相信你们也有本身相应的思考，以及实际开发过程当中遇到的相关问题和痛点，欢迎你们添加钉钉群“23124039”和咱们互动交流。
目前“消息推送”、“热修复”、“移动分析”三款组件也已面向我的开发者正式放开体验资格，诚邀你的体验反馈，点击“阅读原文”当即跳转开通地址。

| 移动开发平台 mPaaS 三款组件重磅上线蚂蚁金服开放平台：

• 公测期，欢迎体验试用。支付宝扫码或登陆开放平台

往期阅读

《开篇 | 蚂蚁金服 mPaaS 服务端核心组件体系概述》

《蚂蚁金服 mPaaS 服务端核心组件体系概述：移动 API 网关 MGS》

《蚂蚁金服 mPaaS 服务端核心组件：亿级并发下的移动端到端网络接入架构解析》

《mPaaS 服务端核心组件：消息推送 MPS 架构及流程设计》

《mPaaS 核心组件：支付宝如何为移动端产品构建舆情分析体系？》

《mPaaS 服务端核心组件：移动分析服务 MAS 架构解析》

关注咱们公众号，得到第一手 mPaaS 技术实践干货

钉钉群：经过钉钉搜索群号“23124039”

期待你的加入～