含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