含ppt下载|解析支付宝移动端弹性动态架构

近日，蚂蚁金服开展了“共战‘疫情’，技术破局”数字课堂线上直播，咱们将系列演讲整理并发布在 “蚂蚁金服科技” 公众号上。 

今天，将为你们分享围绕支付宝在移动端如何实现轻耦合、弹性动态的开发模式，深度解析其技术选型及实战经验。演讲嘉宾是来自蚂蚁金服mPaaS客户端核心开发的温盛章，如下为演讲整理全文：

咱们提供了一个移动开发平台叫作mPaaS，如今在阿里上面已经正式的发布了。他首先是源自于咱们支付宝的一个移动端的组件，目的是为了打造快速迭代的架构和动态化的能力。它是一整套的方案，包括了移动端的开发SDK，而后移动端的构建工具和后端的一整套的服务和工具做为一个总体体系的产品。咱们主要要作的事情是使用移动开发平台mPaaS来打造一个性能更优的APP。今天咱们在这边直播分享的内容是，支付宝使用mPaaS的过程当中的一些动态化的实践。

弹性动态的端上架构解析

咱们在这边，首先要介绍的一个点是弹性动态端的能力。首先咱们在支付宝中面临的一些问题是有海量的业务，而后传统方面上的一些Hybrid方案，这是一个老生常谈的话题了。而后第二个是高可用和及时快速发布的监控运维体系，这里面包含了像局部条件、灰度的能力，而后快速回滚的能力和快速迭代的一些能力。而后第三点就是开放出来咱们的Hybrid的一些解决方案。

Part1：利用 Hybrid 架构应对海量业务需求

第一部分咱们介绍一下如何使用一个Hybrid的价格去应对海量的业务需求。咱们知道支付宝它是一个国民级的APP，它里面承载了很是多的业务，若是使用传统的迭代方式，确定知足不了咱们如今这些业务的需求，好比说我可能须要一个双11的活动，双十二的活动或者是一些别的运营活动的时候，咱们须要很是快速的一些迭代的能力，不只在IOS端和安卓端都须要有，并且也须要进行一些快速回滚。咱们目前的话，在移动的端上有4种这样的能力。这里是举个例子的4种能力，一种是Native，而后是Html5，ReactNative，Flutter是最新的一个跨端的解决方案，目前也是在咱们尝试的范围以内。

咱们能够看一下这4个能力，它的对比的状况是这样的。对于Native的开发同窗来讲，Native的开发成本是最低的，由于咱们出身于Native开发，因此基本上不须要去学习一些什么特殊的东西，因此咱们对整套的一个UI架构的体系和UI的API的调用之类的都是很是的熟悉，而后它的用户体验也是低的，咱们基于像iOS UIKit以及 Android一整套的UI架构，若是是使用原生方案的话，它的体验在目前的移动端的硬件能力上体验都是很是好的，可是他的动态性就变得很是的弱了。

咱们没有办法去下发新的Native一些能力，包括甚至去写一个营销组件，这样的方式也是作不到的。由此咱们再找移动端早期的时候，为了引用重大问题，咱们第一想到的就是Html5的方案。他的话是基于WebView的这么一个技术栈，而后把前端的页面写进来。同时为了和Native这边进行交互，咱们介入了当时讲了很是多的一个叫JsBridge的一些组件，IOS的JsBridge和安卓的JsBridge规律。基于两套的JsBridge的方案，咱们能够跟Native之间的能力进行打通，打通以后咱们能得到一些简单的交互上的简单的交互和复杂的运营的能力。

好比说这个时候咱们须要动态的下发一个运营页面，那么咱们可使用Html的写一个Html的网页，而后把它发布到咱们的平台上，而后这时候下发到Native端，快速的去渲染出这样的页面。在随着 Html5技术的发展，咱们开始去思考可否使用Html这种DSL去写，Html去写一些咱们想要的东西。在当时那个阶段的话，咱们就产生了像React-JS、React-Native这种这种方案。

而后React-Native是使用React的DSL而后去渲染出Native的组建的这么方案。对于咱们来讲，首先是须要对于Native来讲是须要学习前端开发的一些语言，可是他由于能使用前端开发的语言，绕过WebView同时又提供了一些动态化的能力，因此它的实际体验起来是像是与Native同样流畅。可是在这个问题上，又由于他为了兼容两端的特性，因此致使了他在处理的过程当中有发生了很是多的问题，那么咱们在这种问题的解决方案上投入很是多的精力，可是解决起来同时也不是很是的顺手。可是他的动态性倒是咱们很是看重的一个东西，由于首先它基于它的前端的和模型精简成了一个就flex这么一种模型。而后抛弃了原先的一些layout的一些系统的layout的管理工具。因此在这种阶段上，RN是咱们延伸出了很是多方案，淘宝这边也有像Weex这样的一个方案，而后最近Google发布了Flutter这个方案，其实算是完全颠覆了原先的Native的开发模式。其实它对于咱们来讲，全从头到脚都是新的。

像在Android上在IOS上都是基于canvas的一个从Native的角度去看，它是基于canvas的方案，他在canvas上进行绘制，而后同时去接管canvas的一些事件，而后在他本身的一个单引擎上去进行执行一些渲染的动做和响应，响应用户交互的一些请求。对Flutter来讲的话，首先咱们要去学习它的dart语言，这是第一个成本。dart语言学完以后，咱们还要去了解它整个Flutter引擎的工做流，这是第二个成本。以后，它对于动态性的支持，从官方正式的层面来讲，目前是处于一种放弃的状态。它并不打算说有动态下发的一种能力，它基于skia引擎的方案，skia由于是一个性能良好的渲染引擎，因此它的用户体验也是很是不错。这是咱们这4种能力的一个差异，这里是4个能力的对比。咱们看一下，基于H5的一个方案的话，提供了这么一个容器加离线包的一个架构。

在传统的H5页面里面，咱们只是一个在客户端自己接了一个WebView，而后提供了几个JS的API，日后但愿咱们的html页面再下载到咱们本地的时候，既能跟服务端进行通讯，又能得到一些本地的能力。可是咱们知道它的渲染性能，还有像首屏的白屏那种问题都是没有解决的，因此说咱们为了解决这些问题，使得它的体验更加靠近native体验的时候，咱们就提供了其当前的这种架构。咱们在这边使用，首先第1个解决的问题是在Android上使用UC内核的这么一个方案，由于uc内核对于咱们来讲，他能去铺平各个不一样Android的版本，各类不一样机型上的外部必有的差别的一些问题，这是咱们前端领域中最容易碰到的一个浏览器的兼容问题。

咱们在解决这个问题的基础之上，但愿赋予容器更多的能力，咱们首先要去统一掉容器的JS bridge的性能。这是当中这一层，第3层绿色的这一层的方案。咱们在这一层去铺平以后，那么对于前端来讲，他只剩下他的业务细节和具体的业务流程。咱们的容器有包含了一个离线包的拉取，离线包对于咱们来讲是一个解决首屏渲染问题最大的一个抓手。咱们使用把离线包的整个能力去集合在容器里面的时候，搭配咱们的像MDS的一个咱们这边叫作MDS的一个发布平台。

搭配发布平台的话，咱们就能很快的发布咱们的离线包到用户的手机上，那么在用户去打开咱们页面的时候，并不须要过多的时间就能够快速的打开咱们的页面。那么离线包的发布和离线包的更新都在咱们的管控之下。同时咱们能够基于一些算法，快速的先去预测用户是否须要快速的打开这项业务，若是须要打开这样业务，能够提早传到用户的手机上，而后用户在打开业务的时候，就能快速的使用离线包了。

而后在容器如下的这几层的话，咱们跟原先的Native的能力作了一层打通，就是封装了相同的一些API接口，好比像网络、多媒体，Push。而后容器自己是能够快速升级的。咱们在下发的过程当中，能够把最新的优点内核给分发到用户的手机上，用户能够无感知的升级它的uc内核，去体验最新的一些功能。那么在这之上，咱们把每个的业务叫作一个应用。

那么咱们这里面有ABCD好比说到N个业务，那么每个应用都是在咱们这都是一个业务级的概念。那么业务和业务之间是挺隔离的，在隔离的状况下，咱们就能够很好的对发板和rollback作一层控制，这样子就能更好的控制故障的发生。整个H5的应用的启动流程的话，咱们大概有分为这么好几层。首先的话，他的入口部分可使用URL，或者说Native的一些按钮去启动。那么对于咱们每一个H5的应用来讲，咱们都给他都给它抽象成一层叫作APP的概念。

在入口的地方，咱们能够传入一些咱们启动的参数，而后传给咱们的H5的容器叫作Nebula。那么启动了应用以后，咱们这里面就会有一些像框架的生命周期的回调。MicroAPP的话对咱们来讲就有 onLaunch,onStart,onStop之类的生命周期的回调。那么Native这一层的话，像Android的这边就会有一个Activity像跟Manager和Fragment之间的被调用，而后调用完以后就会建立一个页面，这个页面的话就是咱们的H5的容器的页面，而后它会有一些像脚本加载，像咱们内置写的一些插件的加载，好比说你要对于一些请求，对一些业务的指标作一层监控的话，在这边写一个插件是一个很是不错的选择。

咱们对于外部的容器作的更多的事情，是但愿咱们的Native和外部之间有畅通的通讯通道。在这里的话，咱们演示PPT里面讲的就是一个JS Bridge概念。咱们Native会使用EvaluateJavascript的方式，把JS的代码传到外端，web的这边会使用console的一些消息，把消息发回到Native这边，咱们但愿把web的体验作到一个极致，web体验无非是几个概念，首先是一个首页的加载问题，而后是不一样平台之间的差别问题。最后是一些离线资源的缓存的问题，那么在这些问题之上，咱们提供了这么多的解决方案。

首先第一点，咱们把网络请求这一块的东西，从WebView的那一层去提炼到咱们的Native的那层，由于咱们native对于网络有更好的一些能力，好比说咱们可使用除了HTTP和websocket之类的协议之外，作一些其余的协议的构建，那么同时也解决了一些跨越的问题。由于 APP是受咱们管控的，因此说咱们对于访问的域名也能够作一些管控。那么在这个基础上，咱们就能够解决一个先后端分离的问题。页面资源的话能够提前的去加载，那么对于前端来讲，前端只关心了他的业务数据的沟通。

第二点的话，咱们提供了一个差量更新的一个能力，差量更新的概念是什么？好比说我此次去下发了一兆的离线包，而后我发现以离线包里面有一些bug，那么对它作了一个修复，好比说发布了一点1.0.1版本，那么两个离线包的改动可能很是的小，好比说只有一个字符串改动或者说几行代码的改动，这个时候就可使用差量更新去把只有改动的部分提交到咱们的MDS发布平台，那么MDS会在合适的时机把这一部分差量的数据量下发到咱们的端上，那么端上根据差量就能够自动合并出一个新的离线包。

那么，用户在下次打开的时候，你的离线包已经被更新了，那么这个过程既可使得流量的使用量变得很小，同时又能快速的响应业务端的需求。

第三点咱们讲的是一个推拉结合的概念，其实仍是蛮有意思的一个点。由于咱们在传统的HT模型里面，咱们永远是一个拉的概念，我在客户端提起这request，而后服务端去返回response，固然http2的话是有了serverpush的一个概念，那么咱们不是说是在serverpush上作了一个增强，咱们自己有一个组件叫作sync，对于mPaaS平台来讲，它就是一个稳定的长链接。那么，那么服务端能够经过长连接、提早的向端上去发一些想要的东西，好比说提早去发送离线包这样的概念，或者说其余的一些数据，特别是基于事件的一些数据。

而后第四点的状况就是当咱们的离线包发布若是失败的状况下，咱们能够设置一个fallback走线上的一个流程。这个流程的话是防止咱们的离线包下载失败的时候所作的事情，这一点是为了作正确性的事情。而后一个是我讲过的独立浏览器内核的问题，可能在以前咱们遭遇的状况比较多一点，如今的咱们这边的话支持的版本仍是在4.3, 4.4以上，还会存在一些问题，那么咱们的离线包，咱们的UC WebView是实时动态更新的，他并不跟着安卓系统走，因此咱们提前下发的更新能够帮助用户更好的去稳定他们离线包的体验和减小前端bug的产生。

后面一点的话，咱们讲的是一些深度自定义的组件，这一块的话，咱们有提供了Ant Design之类的一些方案，可让用户快速的介入去构造一个页面。那么最后一点是监控。其实监控是在这边最枯燥乏味，可是是最重要的一个环节。由于咱们须要对于业务稳定性和自己的业务点作一些监控，那么这些监控作完以后，咱们就能够快速的响应用户的需求，去解决用户碰到的一些问题，同时咱们能够收集一些运营的数据，而后对下一次产品的改进和bug修复作提供很是有效的帮助。

咱们H5的容器包含了很是巨大的扩展性，咱们首先提供了一些JS的API，可使H5的代码有调用，Native的能力在前面已经说过了。他不只是一些普通的能力，还包括像数据存储、全球广播，而后还能自定义的扩展API，而后咱们在Nebula容器上提供了一些容器的插件，容器插件的话，它是基于事件去响应的，咱们在这边H5里面有提供了一系列的容器上的生命周期，那么当生命周期回调响应的时候，咱们就能够在插件中收到这块生命周期的事件。

那么，基于这个事件，咱们能够去作出各类各样功能，而后开关这一块实际上是作ABTest之类的需求是最好用的一块功能。那么咱们能够在特定的条件下作一些开关的配置，好比说以人群，以机型，地域之类的方式去作这些开发配置，那么咱们能够给特定的地域、特定的人群作提早的灰度，或者说AB的能力。咱们的H5的容器最显着的一个特性，是要比原生的WebView的稳定性要高出不少。这边咱们有两个指标，一个是PV的崩溃率，一个是PV ANR的几率，那么崩溃率就是Crash率，那么咱们这边的话比传统的容器要高一倍以上，那么ANR的概念就是你在划的过程当中卡死的几率，咱们这边主要核心解决的两个问题，是WebView稳定性和WebView体验不一致的问题。

Part2：监控+发布平台，知足业务稳定运行、快速迭代

而后讲一下咱们的监控和发布平台，由于这块是围绕着咱们H5容器的生态，须要去作到的一个很是大的后端能力。首先第一点，咱们须要有快速发布的能力，由于咱们知道基于原生的H5页面，其实它是自己就具备实时发布的，实时发布的概念就是你本身若是拥有一台服务器，那么你去发布你的前端页面的时候，它是实时更新的。若是使用离线包的话，他的确是丧失一些快速发布的能力，可是咱们在这里须要把快速发布的能力给他补偿回来。

因此咱们首先去接入咱们的MDS的时候，咱们的离线包首先是发布的MDS上，那么MDS会根据你以前配置的一系列的东西，去把咱们的离线包发布到CDN上，而后根据咱们以前客户端上的一些条件，好比说你是否打开了灰度开关，或者说是全网Release，若是是灰度开通开关的话，还须要根据你灰度的一些配置，而后经过客户端和服务端这些客户端和MDS之间的一些请求，而后把咱们的离线包的地址下发到客户端上，那么客户端会拿到这个地址，从CPN上把咱们的离线包下载过来，这是咱们的提供的一个快速发布的能力。那么快速发布既要拥有智能灰度的能力，同时也须要提供增量拆分离线包的能力，这个能力对于客户来讲是不可见的。由于客户只用把两个版本的离线包上传到咱们的服务端，咱们服务端自动会算出这两个离线包之间的差别，而后把差别下发到客户端，咱们同时须要保证咱们的MDS的性能须要达到很是高的要求。那么咱们的MDS的性能QPS能够达到5万每秒，那么对于端的一个触达率有达到99.99%。

而后接下来说的是一个监控和诊断，那么监控实际上是咱们一个很是须要重点关注的维度，由于咱们把业务开发完毕，去下发到用户端的时候，若是用户体验很是很差的话，那么咱们的留存率是很是低的。因此说咱们须要针对于闪退、流畅度、电量，流量之类的，还有不可用的一些一些业务都须要作一些埋点。咱们去埋点以后，就是收集完用户的一个使用状况的时候，咱们须要去上报。那么若是作到实时上报的话，这个上报的策略实际上是不合理的。

由于第一会影响用户的体验，由于实时上报的话，咱们可能一直开着一个进程，或者说还有一条线程去上报。第二，对于用户的流量也会有很是大的影响。那么同时咱们还须要考虑用户在使用咱们APP过程当中的一个的状况，好比说作一些定制化的开关，或者说须要作一些特殊的一些采样。好比说若是这个时候一个用户跟咱们去报他使用APP的过程当中产生的Crash，那么咱们并不须要收集全网Crash状况，由于用户他本身的使用场景可能会比较特别，因此说咱们须要有对于特定的用户有一个固定抓取的能力。

而后咱们上报的方式有有三种，第一种就是自动上传，第二种是周期性的检查上传，好比说每隔一小时或者每隔一天。第三点是诊断指令驱动的上传，这个意思就是我刚刚说的一个场景，一个用户报Crash了，那么咱们须要用户好比说上报一下他的邮箱，或者说帐号名字之类的，那么咱们能够精准的在用户手机上去抓取一段日志。那么咱们根据用户上传的一些日志，咱们能够进行进行页面的一个跳转路径的分析，而后还有APP本身产生的一些日志作一些分析，那么分析完以后，咱们就能够作出一些决策，好比说该怎么优化这些东西，那么若是咱们的Crash去和ANR的率到达了必定程度的时候，咱们须要有熔断的一些措施，好比说把离线包的页面或者禁用掉，那么或者说走fallback，或者走修复这三个流程。

这个是咱们提供的四个能力。首先第一点的话是故障隔离，就是说若是咱们发现这个页面产生了一个故障的话，咱们须要提早的去开启某个开关，若是它是一个新业务的话，好比说他开关是开着的状况下，咱们须要当即把它关掉，而后屏蔽掉以后，进行一个止血的过程。

那么第二点，若是咱们的闪屏页面发生过程，由于这个时候用户可能进不了咱们的APP,那么须要咱们去进一个安全模式，这个时候须要对安全模式里面的一些数据进行一些诊断上传。而后把咱们的APP里面的一些数据清除掉，而后再从新开启。这个是一个自动恢复的能力。

第三点，咱们是须要进行一些流量的熔断，好比说咱们的网络调用到达必定请求或者说必定程度大几率是出如今好比说咱们这边的服务器或者说客户这边的APP端业务端受到一个DDOS的一个场景，那么这个时候咱们须要对流量作声作成一个熔断。

第四点就是咱们一个很是重要的动态化能力的修复。那么这里面包含了好几个内容，第一点是刚才以前说的开关。第二点是离线包的一个版本更新，咱们好比说前面的离线包发生了一些问题，那么咱们须要及时的修复、去上传，而后快速的全网发布。而后第三点是基于原生代码的一个Hotpatch，那么安卓上的Hotpatch的话，咱们仍是使用的是DexPatch的方案，那么能修复Native上的Java代码，而后他同时能够作到监控，能够回滚，在咱们的mPaaS后台去点击一个回滚的按钮，那么咱们快速的把这几个下发的新的东西作一个回滚，由于谁也没办法去保证本身下次写的代码没有bug。

因此说只要咱们若是验证没有问题，那么咱们的修复能够发放，若是说热修复是有问题的，那么我还要作到一个快速回本，去发一个新的Patch，那么对于咱们来讲的话，咱们的Native发板可能会作得比较慢，那么若是在咱们上了H5的方案以后，那么咱们H5的发版确定是比Native的发版要走得快的。假设说咱们在一个APP里面有N个产品，那么他们之间的发展节奏像是这个样子，那么他们的整个产品的一个生命周期是左边的一个环形的架构，其实仍是蛮传统的一个交流，首先的话是业务这边去制定目标，而后开发这边进行代码构建，而后咱们进行一个灰度持续的监控，最后正式发布完以后，咱们进行一个运维的监控，运维监控以后，咱们再作一个灰度的验证，而后制定一个新的目标。

对于不一样的版本的话，这里面重点讲的是一个灰度的概念。对于灰度来讲，咱们须要知道用户这边的一些条件，好比说咱们此次须要作一个基于安卓手机的性能优化的方案，那么咱们须要去用条件去筛选出咱们安卓里面，好比说CPU是骁龙600系列或者500系列的一个低端的CPU的话，而后去验证咱们的这一次的性能修复的包的表现。

Part3：更优异的 Hybrid 方案，HTML5 与小程序差别化解析

咱们这边须要去讲一下最近很是火的小程序的方案，小程序是在H5发解决方案之上更加升级的一个架构。

首先小程序是一个基于Web技术，而后又集成了原生能力的一个新的移动应用格式。那么对于小程序来讲，跟H5一个最大的不一样是H5自己实际上是技术是开放的，但小程序就等因而给了一套完整的开发框架。那么你继续跟着开发框架和DSL编写出了相应的业务代码以后，而后编译成一个小程序的包，而后发到相应的平台上，平台能够根据你这一套DSL去渲染出它的一个页面，固然它的渲染引擎是能够随时更换的，不必定是WebView的渲染引擎，他好比说能够根据 skia的渲染进去写一套基于skia渲染去作。那么小程序的优点有四种，一个是获取便捷，好比说扫二维码就能直接去打开，他不须要你去架设服务器，不须要去考虑CDN之类的一些东西。第二个就是小程序和小程序连接的一个能力。而后还有小程序跟Native之间的一些链接的能力。第三个的话小程序的安全性和可靠性是由各个大平台去保障。第四点小程序的渲染，它是由你各个去指定的标签去决定的，好比说我可使用原生的组件去渲染小程序上一些DSL的组建，在这种状况下，它的渲染能力反而是会比H5的渲染能力会更高一点。那么整个小程序的架构是像图上这样子，小程序的渲染层和逻辑层是完全分开的。

你们能够认为渲染层里面是有一个WebView有选择，那么渲染才是WebView，那么实际上它的一些事件执行，像一些逻辑的执行，是开了另一个JS引擎去作这个事情。那么它们之间经过Native层的一层JS Bridge进行通信，那么每次逻辑层把须要更改的配置的一些信息去成立到Native层，Native层获取到渲染层里面已经渲染了的DOM信息，而后计算出差分逻辑，最后下发到咱们的渲染层。那么渲染成每次去更新UI的时候，都是会把差别化的一些数据把它给渲染出来。那么在这种状况下，咱们的渲染层和逻辑层之间的执行是彻底隔离的，这个是咱们所讲的小程序双线程的一个概念。同时小程序由于有平台的容器做保障，因此说咱们这边能快速的打通Native层的一些存储网络多媒体的能力。在这种状况下，咱们使用小程序开发的时候，能够用最少的成本去开发出性能最好，动态能力最强的一个框架。

那么同时咱们小程序提供了一个ID构建和发布的一个能力，ID构建的话，咱们如今支付宝这边有提供小程序的IDE，同时开发支付宝小程序，淘宝小程序，还有mPaaS小程序，它们三者之间虽然技术架构不太同样，可是它们之间的DSL是相同的，你可使用同一套代码去开发。那么Native这一层，首先先对你传递的参数作一层解析，解析完以后去提早加载小程序的资源，而后去建立一个渲染页面，好比说这里面Render我讲了，目前来讲是基于UC WebView，可是它同时也能够不基于UC WebView，这个对于业务来讲是彻底没有感知的，那么在渲染层初始化完毕以后，咱们这边会建立了一个JS的worker，那么这个worker就是咱们刚刚讲的逻辑层的一个概念。worker建立完以后，会对于原先小程序里面执行的小程序JS代码里面执行的一些事件作监听，那么会回到小程序里面的一些事件的callback，而后小程序的JS引擎里面，对于业务代码层面上对这些callback作出一些响应，好比说Set Data之类的回调。调完以后，会传递到Native这一层，Native这一层把原先去更改的一些数据传递给渲染成层，而后渲染层在下一次事件循环中，把此次传的数据作一个差分的渲染，而后作完以后，咱们就能看到咱们想要的一个产品，那么这个就是咱们刚说的小程序的双线程的概念。逻辑上在worker这边，而后渲染层在Render这边。

小程序的特征是很是规范的提供了这么几个能力，首先第1个包体的构造是在一个标准要求之下的，咱们必须提供这样的一个包体的结构，而后UI组件和API是另外提供的一个能力，而后入口规范的状况下，咱们能快速的把咱们小程序的内容和小程序的总体的页面的管控，收敛到一个比较小的口子上,那么能最大的防止各类风险。 

同时它的安全和隐私的管控，在于咱们的Native的容器里面已经包装好了，好比说小程序想得到一些隐私相关权限的时候，须要咱们的Native这边在UI层面上做出一些响应，好比说想要得到用户定位的能力，或者说想去得到用户的手机号，这些东西咱们都须要在Native这一层去向用户去申请权限。而后同时咱们又提供了一些小部件，小部件到是一个能够认为是插件，或者说是像UI组件这样的一个东西。

而后咱们的小程序的整个生态，目前来讲，支付宝的mPaaS小程序有在各个地方都使用，好比说像饿了么、高德，淘票票之类的东西都在用。

在这种状况下，咱们把咱们整个小程序能力作了一个封装，经过mPaaS的一个方式去去分发给各个用户。那么用户去集成了咱们mPaaS的容器以后，也能基于这一套生态去开发出本身想要的小程序，而后在本身的APP上进行运行。咱们但愿咱们正常开放的生态环境，但愿能让用户由于小程序而受益。而后也能拥有本身的一个动态化能力。咱们但愿能提高用户的粘性，而后链接海量的服务，而后服务的话，但愿能快速的触达到多端。

而后咱们mPaaS是支付宝里面整合出了一套完整的引擎，那么咱们mPaaS就提供了好几种从服务端到客户端的完整方案，那么对于客户端来讲，有提供客户端的SDK和客户端的框架。那么，客户端和服务端之间的链接，经过咱们自定义 RPC协议，包括推和拉结合，推的话，刚刚说的Sync组件，拉的话我自定义的HTPR的一些协议，那么mPaaS的中台还有提供网关，而后把用户的一些行为数据进行分析，而后还有消息推送，而后发布，还有开关等等。

后端的mPaaS的话是有一些计量计费的管控，而后多租户的管控，这一块是咱们这边本身的一些能力。而后总体的话咱们mPaaS如今是基于阿里云去作的。

目前，mPaaS已经上架到了阿里云对外输出了，欢迎你们试用。

PPT获取地址：https://files.alicdn.com/tpsservice/45b8e88badbc2a652216ec49d0740811.pdf