蚂蚁金服 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、切面、监控等服务。整体模块化协同开发，都是基于框架层提供的能力，来达到「并行开发」的目的。