如何迅速开发一款移动App?蚂蚁金服mPaaS已帮你写好答案
2020-06-15 13:38 收藏(0) 阅读(2295) 评论(0)

时间倒推到两三年前,大家可能对刷支付宝乘公交车和地铁还感到惊奇。但如今,一个外来游客要是来到北上杭这些城市旅游的话,再也不用浪费时间在各个地铁票售卖处排长队买地铁票了。无论是用支付宝扫码进站,还是打开像上海地铁的“METRO大都会”这类App,这些应用的出现和存在最终都是为了方便消费者的日常出行体验。

与此同时,现在的年轻人可能对银行线下网点和人工柜台的服务越来越陌生,因为越来越多的转账、汇款等交易都发生在了线上。多年前春运期间一大清早去火车票网点排队购票的场景也逐渐消失,人们已经习惯用互联网来搞定一切,并习以为常。 

但这也变化也不是一夜之间一蹴而就的,那些我们吐槽部分App和线上业务体验不佳的日子似乎还并不遥远。而这些体验的摩擦与交融可以说是各行各业走向数字化转型的一个缩影与阵痛。或许很多年之后回望2017年,人们会认为此刻是一个时间节点。在这一年,传统金融机构以及非金融行业都在纷纷发力开发或者革新自己的App,以更好地适应互联网时代下用户的需求并提升用户体验。这些状况在不久之后就会得到改变,而这些改变背后少不了今天故事的主人公——蚂蚁金服移动开发平台mPaaS。

潜心练功,mPaaS的诞生与成长 

mPaaS 是 mobile Platform-as-a-Service的简称。如果你熟悉云计算的话,对PaaS这个概念一定不会陌生。如果你采用PaaS的服务,那么意味着你既不需要买服务器,也不需要自己装服务器软件,即可利用这个中间件平台进行定制化研发,开发自己的应用。 

而mPaaS这个概念则由蚂蚁金服独创。它是在PaaS的基础上衍生出移动的平台概念,其中m代表的就是mobile(移动)。类比与PaaS的概念,mPaaS更专注于移动端的研发平台服务。开发者能够利用蚂蚁金服移动开发平台mPaaS做好移动App的开发、管理、发布,并做好App全生命周期的管理,其中包括了开发期的研发测试、打包构建、发布管理,还有发布之后的用户行为分析、闪退分析等。如果说PaaS平台是对企业后台服务的生命周期的管理,包括研发、发布、监控这一套流程,那么mPaaS就是对移动应用App一整套全生命周期的管理服务。 

事实上,当传统金融行业将目光投向移动App开发的时候,前面是一条看似平坦却暗藏坑洼的一条路。而支付宝早在2013年以前,就开始了这趟淌坑之旅,并逐渐摸索出一条明路,最终基于mPaaS平台对外开放。这就像你刚开始准备学习这门课程,学霸支付宝同学已经早在几年前就学完并替你总结了一套学习方法和快速学习平台。可以说,目前mPaaS的所有技术服务和组件都是源于支付宝,并在支付宝的各种高并发等极端条件下和实际业务场景中经过重重检验的。 

为了让你更好地理解mPaaS的过人之处,我们要先从支付宝这个国民级App的开发历程开始说起。2013年开始,支付宝开始了All In无线战略。在那之前,支付宝还是一个单体应用的支付工具,只拥有一些非常基础的模块和工具库。2013年,随着支付宝的All In 无线战略之后,业务快速发展,支付宝App里所能提供的功能和应用也开始井喷式的发展。与此同时,支付宝APP用户数也开始指数级的增长,其后台支持的开发团队也日益庞大。这么一个数量庞大的开发团队如何高效地进行开发协作呢?这对支付宝App开发架构的设计的合理性提出了很高的要求。

图片1.png

在2013年到2015年期间,蚂蚁金服就对支付宝做了一个架构治理,整个支付宝App的开发架构被做了分层,支付宝App被改造成了一个平台型App,它集成了各个应用,并实现了应用的服务化、模块化,开发工具走向组件化。这样一来,基于支付宝App上的每一个应用都可以独立的由一个团队来开发,而整个支付宝则用一个通用的底层平台框架进行管理。如此,支付宝App就从架构上允许支付宝能够快速扩展业务,每上一个新业务就相当于开发一个新的模块,只需要将新的模块插到这个框架里就可以运行了。 

在这个期间,支付宝的开发团队还沉淀了模块开发的很多通用的能力,包括像消息推送、分析、网关等等。而这些通用能力几乎所有业务场景里的应用都会需要。与通用技术能力伴随而生的另一个简单的理念就是:我们能不能将在支付宝架构上沉淀的这一套经验和能力更好地对外输出,以服务更多的金融机构? 

2015年9月14日,蚂蚁金服宣布启动“互联网推进器”计划,计划将在5年内助力超过1000家金融机构向新金融转型升级。蚂蚁金服作为“互联网推进器”将推动平台、数据和技术方面的能力全面对外开放。同年10月,mPaaS 1.0版本正式面世。

图片2.jpg

1.0时期的mPaaS功能比较简单,主要包括三大核心功能:网关;用户行为分析;消息推送。在这一时期,mPaaS就服务了网商银行和天弘基金两大客户。 

很快到了2016年底,mPaaS 2.0 版本开始酝酿。mPaaS 2.0 最重要的特征是往共享的方向发展,并实现了框架和模块的拆分,即mPaaS上提供的功能都可以单独输出,这意味着客户可以比如只使用单项功能(如消息推送)而完全不用其它任何服务。共享模式也可以说是多租户模式,就是说开发者在公有云上可以拥有不止一份mPaaS,不同用户可以通过逻辑隔离来用同一份mPaaS,这可以有效的降低公有云上的使用成本。

图片3.png

此外,2.0时期的mPaaS具有着更丰富的功能:一个是MDS功能,即发布功能,它可以在APP里提醒用户下载、升级新版本;另一个是热修复功能,热修复功能通过MDS发布到客户端,并在紧急情况下,如果代码有问题,开发者可以在不发布新版本的情况下,在运行期就将问题修复。 

热修复功能一经推出即受到了市场的热烈欢迎,在这之前和之后,市场都很难找到同样提供同类服务的产品。2017年1月,mPaaS 2.0出现在了众人的视野里。这一次它服务的客户进一步扩展,除了苏宁金融这类金融客户之外,有了更多非金融行业的客户的加入,包括阿里健康、OFO等等,还有我们前文提到的上海地铁。 

2017年5月,蚂蚁金服mPaaS技术团队开始进驻上海地铁,到10月份上海地铁“METRO 大都会”App正式上线,并在上线一周以内该App注册人数超过百万,这背后所支撑的不过十几人的开发团队。上海地铁“METRO 大都会”App加入了扫码进站的功能,这意味上海的用户不再需要在高峰期花半小时排队买地铁票。 

在“METRO 大都会”App的上线过程中,mPaaS 2.0新上线的“热修复”功能还经历了一次生死时速的考验。为了做好App的数据运营和监测工作,该App开发时即使用了mPaaS的各项能力,在App上线之前就做好了全方位的埋点监控,相关人员能够密切关注用户的使用情况,这样能在出现任何问题的时候也能第一时间发现并修复。果然,在该App刚上线一周的时候,技术小哥敏锐地注意到,部分机型无法顺利的完成用户注册。在发现这个问题的一天之内,技术小哥们迅速的解决了这个问题,并利用接好的热修复功能快速修复,最大程度上保证用户的体验不受损害。想象一下,要是没有热修复功能,而是等到各个手机应用市场重新发布新版本的话,这其中所耗的审核和上线时间不可估量,而最终影响的用户也可能难以计数。

地铁,春运,银行—— mPaaS接受挑战并完成到绝世高手的蜕变

2017年10月开始,mPaaS 开始向3.0阶段蜕变。mPaaS 3.0开始支持私有云,并推出了数据同步服务。数据同步是一个保持mPaaS跟客户端常连接的服务,该服务能够确保一些关键信息可以在秒级触达所有的在线用户,时效性和稳定性都得到了改善。 

同时,mPaaS小程序的功能也在3.0版本中被抽离了出来,做成了一个纯技术的方案,这意味着mPaaS的开发者可以利用小程序技术为自己的App开发小程序。以上海地铁为例,该App支持其他开发者、ISV或商户能够围绕上海地铁开发更多小程序,并且这些小程序可以既运行在上海地铁里面,也可以运行在支付宝里面,为开发者们带来更多的流量和福利。 

在向3.0过渡的2017年9月底,mPaaS开始与12306展开合作。当时这支mPaaS开发团队还不知道就在短短3个月后,他们就要拿出一个新的产品,也就是部署并开发一个新的12306 App来应对一个巨大的难题——春运。

可春运作为一个老大难问题,按照mPaaS开发团队的话讲:“并不是开玩笑的”。事实上,做12306 App这么大的产品一般正常的开发周期要一年以上,而mPaaS技术团队面临的状况是在9月底进场,12月份上春运,如此高的强度和如此难的技术挑战,在国内外都是没有先例的。 

但最后mPaaS团队还是接受了这任务,10多个人的团队再加上铁道部派来的团队加班加点,终于在1月3日,通过各轮的测试、压测后上线。最终12306的线上App很顺利的支持了春运,为国人顺利回家过年出了一份力。

图片4.png

此外,在2.0到3.0期间,mPaaS还帮助苏州银行顺利完成了云端的部署,为直销银行多样化场景提供了强力的支撑;通过mPaaS离线包帮助广发银行提升了APP性能,使其“发现精彩”的启动时间从降低近70%;印度的Paytm则利用mPaaS的这套能力更好的对在即的App内部进行数据监测与统计,从而更好地优化用户体验…… 

而至此,mPaaS也完成了自己的蜕变,就App开发领域的某个单个问题的解决而言,或许还有一些对手能够与mPaaS勉强抗衡,但就客户端App移动维度的一个整体解决方案而言,金融行业已不再有对手能跟mPaaS相提并论。而mPaaS基于支付宝的能力沉淀而来,使得它更适合如出行类的高并发需求;或是金融行业所要求的强容灾和安全性。

承担责任,迎接新挑战的mPaaS 3.0 

图片5.png

回过头来看mPaaS的成长与蜕变,我们会看到mPaaS依托于支付宝掌握了如下关键技能: 

1.依托于支付宝长期发展而积累下来的业务场景,成长为做2C端产品运营的大师。 

很多传统金融,非金融机构也许并不知道应该如何做一个成功的面向大众消费者(to C)端的产品,更是在如何做业务运营,营销上缺乏经验。对于传统行业来说,无论是交通出行行业还是银行等金融机构,由于没有相关背景,即便将业务外包,当涉及到数字化转型这样大的场景需要成体系方案时,外包公司多由于没有能力给出完整方案而让传统行业继续面临困境。 

mPaaS由于依托支付宝这个经过长期技术积累,实力雄厚,有历史,技术经得起最各种极端挑战,并逐步成长为能够给出有前瞻性的解决方案来解决潜在的未来问题的专家,它能给传统行业提供完整的生命周期性的整套数字化解决方案。而这,形成了mPaaS和其他同类产品的代差。 

2.从开发框架维度支持团队协同开发,效率更高。

回顾mPaaS的诞生历史,一开始它的出现就是为了服务各个团队协作而产生的,从而更好的支持业务的快速扩张和团队协作。此外,mPaaS提供了很多现成的开发组件和模板,不用重复造轮子,进一步提升了开发者开发App的效率。这一点在12306的3个月快速开发案例上就是一个很好的例证。 

3.强大的App性能优化能力,保证用户体验。

关于“如何实现App的秒开,缩短用户的等待时间”这一问题的探索,支付宝技术团队的钻研之深远超你想象。如今,借助mPaaS平台,支付宝将这一技术贡献给大家,让各位开发者们也能开发自己的高性能应用。目前,经过mPaaS优化过的银行类App打开时间由原来的十几秒到秒开,这与其背后的技术经验密切相关。

 4.从小程序到人脸识别技术,支付宝的创新技术加持

目前mPaaS团队还在不断为在目前的基础上对外开放更多的功能。从当下几乎各个金融类App必备的人脸识别技术,到能够更好构建自身生态的小程序技术。这些你能想象到的前沿技术热点都在mPaaS上逐步实现,而未来基于蚂蚁BASIC技术战略的区块链技术等等,更是值得期待。 

5.不仅是技术的输出,更是经验的输出,推广先进的经验从根本上改变研发方式

mPaaS 离线包,热修复,App 灰度发布,小程序等可以从根本上改变研发,发布方式,提高效率。比如离线包彻底解决了H5加载的性能问题及对网络的依赖,开发者可以更多的去关注业务逻辑而不必太过关心性能。下面是在某银行 App上线灰度过程中,一线的运维工程师对灰度发布经验的高度认可,也是mPaaS 对外服务的初衷。

一年前,全球知名管理咨询公司麦肯锡发布了报告称,在互联网时代,随着中国经济增长进入新常态,传统银行的经营环境日益严峻,大量金融科技公司正在各细分领域威胁传统银行的核心业务。传统银行面临着前所未有的机遇和挑战,数字化转型迫在眉睫。那么在这样的大背景下,各个组织机构如何做好自己的数字化转型呢?数字化转型的敲门砖——移动App的开发又应该如何起步呢?蚂蚁金服mPaaS已经给出了它的答案。