专访蚂蚁金服 mPaaS | 移动下半场，不仅仅是技术能力开放

小蚂蚁说：

mPaaS 是 mobile Platform-as-a-Service 的简称。如果你熟悉云计算的话，对 PaaS 这个概念一定不会陌生，而 mPaaS 这个概念则由蚂蚁金服独创，沉淀于蚂蚁金服多年移动端技术实践和高并发业务体量锤炼。

mPaaS 除却传统金融案例外，更在深度赋能 12306、上海地铁等在内的民生项目完成架构升级，真正将移动技术应用到业务场景中，实现“微小而美好的改变”。

Q1：您好，可否先介绍一下蚂蚁金服移动开发平台 mPaaS？

张亮：好的，我叫张亮，我是蚂蚁金服移动开发平台 mPaaS 的产品负责人。mPaaS，即 mobile PaaS，简单来说它是源于支付宝技术的一个移动开发平台，包含了移动开发、测试、发布、分析、运营各个方面的云到端的一体化的解决方案，展开来讲可以分为三个产品维度：

第一个维度

「客户端能力」，丰富的前端模块加速开发，处处动态，千人千面。

主要是基于加速移动 App 开发，让开发者高效开发 App 所需的相关技术：

这一层是通常所理解的移动开发能力，主要包含了三部分：开发框架、UI 库、还有工具类的 SDK。

开发框架

1、Native 开发框架，也就是原生的 iOS 和安卓开发框架；其拆包理念适合大团队协同开发，可以有效的提高开发效率和 App 的整体架构合理性

2、H5 开发框架，支持混合开发的模式。与 mPaaS 离线包，发布服务，UCWebView 完美结合提供极高的灵活性和性能体验

3、支付宝小程序开发框架。面向未来的开发框架，可以围绕自己的 App ，开放业务接口，构架开发生态。

UI 库

mPaaS 统一组件库（AntUI）以标准化的视觉规范为基础，将抽象的视觉规范概念转化为控件实体。作为开发人员，通过使用统一组件库，可以在接入控件时，实现客户端视觉规范的统一。AntUI 支持 Native 和 H5。AntUI 目前支持 41 种空间类型，128 个控件

客户端 SDK

mPaaS 还提供了丰富的客户端 SDK，例如扫码，本地缓存，客户端埋点等 20 多个组件，可以让开发者快速接入搭建 App 所需要的基础能力，专注业务逻辑的开发。

第二个维度

「移动中台」，坚实的中台运行期管控，支持端上业务的快速变更，创新。

除了客户端开发之外，还提供了移动中台中台能力，来对 App 的整个生命周期进行管理，包括 App 研发、测试、发布、分析、运营在内的各个环节。

- 研发阶段：

提供的“研发协同平台”能够和底层的开发框架相结合，让开发者进行协同研发、持续集成，持续发布，最终让代码转换成能够安装到手机本地的包；

- 测试阶段：

熟悉安卓市场的人都知道，在中国，安卓市场碎片化比较严重，需要确保 App 能够运行在大部分的安卓机型上面，避免上线后发生严重的闪退等问题。这就意味着我们必须要在上线之前对 App 进行全面，统一的测试，来验证 App 的兼容性、功能性以及稳定性，如果没有问题我们才可以进入到下一阶段。“真机云测”提供了包括测试框架，真机管理，测试用例管理，测试结果报告等能力

- 发布阶段：

测试完成一般就可以进入发布阶段了，支付宝在经过多年的实践之后也总结了一套发布的方法论，并融合了到 mPaaS “移动发布服务”中：

首先是白名单发布：当开发完毕后，开发者可以在“移动发布服务”中配置发布白名单，优先在自己的手机上完成发布测试；

其次是内部灰度测试：在这个阶段，可以把白名单扩大到更大的范围，对内部员工或者其他比较安全的群体进行发布；

再接着是外部灰度测试：这可阶段就可以对外了，但只针对一小部分用户，“移动发布服务”可以根据用户，设备属性属性对用户进行分组，比如可以定向给在某个省市的华为的某个机型进行外部灰度发布，并进行实时发布监控，发现问题

最后，如果外部灰度测试没有问题，一般来说就可以判断新版 App 已是趋于稳定的版本，那就可以把进行全网发布了。

- 分析阶段：

完成发布工作后，App 已经运行在了客户的手机上，接下来我们还需要对 App 的日常运行进行实时监控和分析，包括用户行为轨迹追踪和 App 性能分析：

• 用户行为分析：包含了实时大盘，用户行为，留存分析，设备分析，页面分析等

• 性能分析：包含了，闪退分析，卡顿包括，卡死报告等

• 自定义分析：自定义事件分析，自定义漏斗分析，自定义大盘

• 日志管理：按照用户或设备 ID 纬度对原始日志进行查询

以“上海地铁”举例，基于 mPaaS 平台，“上海地铁”有能力针对每一条线路上每一个用户从扫码到进站具体花多少时长完成实时统计分析，从而优化后期的资源调度。

• 运营阶段：

随着面向业务场景的分析能力深度应用，一方面运营方能够提前预测潜在业务风险，另一方面即使有业务需求，也具备针对性运营的能力。mPaaS 提供了：

• 智能投放：对 App 内的营销内容进行统一管理，包括了展位管理，素材管理，活动管理（人群定向，展示频率等），活动分析等能力

• 消息推送：绿色消息推送能力，接入了小米，华为等系统推送能力，高达到率，低资源消耗

• 舆情分析：对 App 内反馈，外部媒体报告进行统一管理，即时发现舆论方向，并可以进行报警

移动中台是 mPaaS 的一个重要的特色，在研发测试期提供给了工具和支付宝的最佳事件经验，提高开发效率，强化流程管理。在运行期，提供了灵活的管控能力，可以动态控制 App 的行为。在分析，运营期，提供了多种工具，全面了解 App 的运行状况，并有针对性的进行运营。

第三个维度

「后台连接」，延展上层业务能力。

客户端开发和移动中台能力都是针对 App 本身，但一个完整的 App 仍需要通过服务端来获取更高阶的能力，比如转账，单纯靠 App 自身无法完成数据同步，需要调用到服务端数据。在支付宝的场景里，我们通过 API 调用统一的网关服务来实现。

其次，我们也开放了大数据通道（多媒体通道），能够支持 App 间文件断点续传，分片下载等，可以有效的提供下载速度和成功率。

因此，mPaaS 主要包含了客户端开发、移动中台管控、后台连接服务三层能力。

Q2：谢谢对 mPaaS 详细的介绍，我们也非常好奇这个产品在蚂蚁金服内部孵化的背景是什么？为何 mPaaS 的诞生是一件必须的事情？

这是一个很有意思的问题。

从行业趋势看，蚂蚁金服在过去几年高速发展，因此普惠金融、互联网金融的概念已经深入民心，越来越多传统金融公司开始重点发展互联网金融服务，因此整个行业的技术创新氛围是非常活跃的；

从蚂蚁自身业务看，蚂蚁金服在继支付宝之后还推出了网商银行、口碑 App，同时扩展了包括支付宝香港版、印度 Paytm、印尼 Dana 等在内的海外业务，需要快速对新的业务进行技术赋能，而这恰好也成为了技术持续迭代的驱动力。

其次是蚂蚁金服移动开发技术的能力的成熟：

在过去几年，经过双 11、双 12 高并发业务的检验，目前支付宝在复杂的业务场景中支持了亿级日活用户，同时结合日益丰富的业务场景锤炼，我们已具备了对外输出技术能力的条件。

最后结合蚂蚁金服“为世界带来微小而美好的改变”的愿景：

在 2015 年 9 月份支付宝便提出“互联网推进器”计划，开放蚂蚁的成熟技术来服务更多的金融机构，帮助他们完成业务升级，普惠金融，与全行业一起做大市场，给中国的老百姓带来实实在在的优惠。

所以，技术条件成熟，市场需求旺盛，公司发展战略的驱动，这一切都促进了这个产品的落地。

Q3：通过蚂蚁金服的技术和经验积累能够帮助开发者释放很多生产力，因此可否聊聊 mPaaS 这款产品在定位和理念设计上有哪些独到的思考？

这是一个很好的问题，我认为一个优秀的产品肯定离不开先进的理念来支撑，否则这个产品就是一个没有灵魂的产品。

比如 mPaaS 第一个维度的开发框架，我们便植入了很多先进的产品理念，比如拆包能力。

什么叫拆包能力？在蚂蚁金服内部，一款 App 开发的过程会拆成业务独立的不同 bundle，或子 App,然后由各个团队独立进行开发，由框架管理子 App 之间的依赖和生命周期，并最终合并成一个面向用户的 App，这样可以有效的提供研发效率，降低新功能上线的周期。

还有低耦合性，mPaaS 所有的能力和框架都可以单独接入，并不强制要求用户全部使用。所有的能力和框架都可以单独接入，但如果能互相配合，显然会有更好的便利性：

移动中台的定位和概念，也是业界相对先进的一个产品理念：通过中台确保 App 在运行期的稳定性和动态化更新。

比如在双 11 双 12 大促前，当我要确保支付通道的足够稳定时，用户具体访问、点击行为的追踪分析显得没有那么重要，那么我可以通过中台下发指令让所有客户端无需再上报用户行为日志，由此能够确保主链路的高可用和稳定性。不仅是日志行为可以得到控制，包括离线包、热修复、动态开关等能力，通过 mPaaS 移动过中台得到动态调控，给后期业务运营提供非常大的灵活性和便利性。

前后端分离，mPaaS 通过统一的网关服务来管理所有访问请求，因此前后端在网关定义的接口可以单独调用、配置、更新，从而确保前后端的开发完全分离。同时，在双 11 大促期间，通过网关层可以进行集中式管控，当后台系统达到峰值极限时，能够有效限制拒绝其他访问，避免系统崩溃。目前，网关能力在支付宝网络环境里可保持 99.999% 的可用率。

Q4：在开发 mPaaS 这款产品期间有无遇到什么困难和挑战，又是如何解决的呢？

跟传统 IT 企业不同，蚂蚁金服的产品都是先经过内部业务验证过，再对外输出。这是我们的优势，当然这种新的模式也带来了一些挑战：

• 内部产品比较多，我们应该以什么样的顺序对外输出，这是我们当初面临的一个比较实际的问题。

mPaaS 1.0

首先回到用户的需求，我们针对 App Store 上的金融类应用开展了深入的市场调研，了解这些应用的实际用户反馈了哪些需求，在实际体验中遇到了哪些问题。最终，调研结果指向了“稳定性能”和“流畅体验”两个要素。

显然，目前具备 App 开发能力已不是问题，但如何开发一款高质量的 App 才是核心痛点。因此，mPaaS 1.0 首先开放支付宝的底层开发框架、UI 库、网关服务以及移动分析能力，只有具备实时监控分析产品性能的能力，才能持续针对性地提升 App 性能。

mPaaS 2.0

随着 mPaaS 有越来越多的客户接入，他们对业务创新、对开发效率提出了更高要求：

于是 mPaaS 2.0 逐步开放发布平台、热修复、离线包、数据同步等能力，更深入地改变了传统金融机构的研发模式。

mPaaS 3.0

接下来我们再更进一步地贴近业务，从一个技术开放平台往业务中台进行过渡，接下来我们会推出营销管理，舆情分析等能力，这是 mPaaS 3.0 的核心理念。

• 还有一个问题是 mPaaS 如何做到能力的通用性，一方面我们要做到研发能力的通用性，能够应对不同业务类型和场景；另一方面如何能够深入业务场景传递蚂蚁的经验和想法。mPaaS 不断梳理自有的产品逻辑，并将产品高度地抽象化，做到普适性，同时能够在核心的产品能力矩阵和使用流程中保留蚂蚁先进的经验和技术，从而达到比较好的平衡状态。

举个例子，mPaaS 智能投放平台，我们优先抽取了产品的核心能力，即根据用户性别、地域、机型等标签，进行定向投放；同时我们在基础能力之上构建插件化扩展能力，比如投放的人群定向分类管理、投放和展示频次等，可以根据 mPaaS AI 平台做更深度智能的决策。

先释放核心的能力，让客户能够基于核心能力深度应用，此后延伸出来更细化的需求，我们可以通过插件的形式不断丰富和完善功能，这也是我们平衡产品需求和开发资源的一个做法。

Q5：显然一款技术产品需要结合行业特征，深入业务场景才能最大化技术价值，可否结合上海地铁、12306 等案例，展开聊聊 mPaaS 如何做到技术赋能，同时又影响我们普通人的生活？

mPaaS 正式推广是在 2017 年下半年，主要围绕公司战略，一方面助力金融行业的升级转型，目前主要面向的是股份制银行，和城商行，例如广发银行，华夏银行，苏州银行，西安银行，常熟银行，助力金融机构做互联网金融升级，一般以直销银行，手机银行体验升级，智慧银行，移动开发平台建设等项目居多，大家感兴趣的话可以关注我们蚂蚁金服科技公众号，了解一些有代表性的项目。

另外一方面蚂蚁金服一直致力于为人们生活带来微小而美好的改变，这方面主要是跟蚂蚁开放平台客户一起服务生态，比如上海地铁，12306 等：

目前上海地铁日均轨道交通客流已超过 1100 万人次，在一些重要的站点比如虹桥火车站，流量疏通的压力依旧非常大。因此，2017 年上海地铁策划了手机扫码进站的功能，并与蚂蚁金服，mPaaS 团队进行了深入的合作，推出了“Metro 大都会 App”，和核心扫码进站能力。项目中，mPaaS 除了输出了开发框架，网关，离线包，热修复等能力，还是一次大规模的业务能力输出的尝试，通过了 AlipayInside 输出了码能力，支付能力等，可以很方便的以 SDK 的方式集成到 App 中。“Metro 大都会 App”的扫码进站能力，切实的解决了排队买票的问题，提供了地铁运营的效率。

除了城市轨道交通，每年的春运同样给铁路运输容载能力提出巨大挑战。据悉，2018 年春运售票线上渠道占比 77.7%，其中移动端购买占比 55.3%，且售票体量已达到日均千万级。12306 团队在 2017 年希望能够针对原有的 App 完成一次大规模升级，以应对高并发、大体量的业务挑战。mPaaS 团队在 2017 年 8 月介入项目，在不到三个月的时间，帮助 12306 App 完成重构，且在 2018 年春运期间没有发现任何影响用户购票体验的重大问题；同时借助 mPaaS 众多产品组件，12306 App 后续开发效率，性能和体验都有了显著的提升。

未来，mPaaS 团队会继续深耕更多行业，帮助更多行业创造“微小而美好的改变”，从而提高大家的生活质量，请大家拭目以待。

结语

结合蚂蚁金服“为世界带来微小而美好的改变”的愿景，mPaaS 不仅仅只释放移动技术能力，更希望能够和行业一起，深入垂直场景，思考背后的业务痛点和产品逻辑，充分把技术沉淀和产品力结合起来，这不是简单的重复造轮子，而是希望真正地做到技术驱动业务创新、业务带来美好体验。

本文转载自公众号蚂蚁金服科技（ID：Ant-Techfin）。

原文链接：

https://mp.weixin.qq.com/s/R6PdRBASbgAdgvlcqoi1ng