EMAS，一部淘宝十年移动互联网技术的演进史

导读

本文根据2018云栖大会深圳峰会·EMAS专场—移动互联的进化论，阿里巴巴高级技术专家泠茗《 EMAS全景介绍》的演讲整理而成，文中就EMAS的起源史及EMAS的五大移动研发场景解决方案进行了分享。

淘宝的移动互联网演进史

各位好，今天我想从阿里巴巴具备表明性的APP - 手机淘宝的互联网演进史看一下阿里巴巴移动团队在近10年的过程当中咱们所作的一些技术上的选择，咱们作的一些技术上的沉淀。手机淘宝近10年的移动互联网演进史，也是EMAS这个产品的起源史。

上面这两幅图画是阿里集团移动APP的产品矩阵，从这两幅图中你们也能够看到，阿里集团孵化了数十款千万级、亿级的APP，你们熟悉的有手机淘宝、天猫、支付宝、高德、钉钉、优酷、UC浏览器等等。阿里在移动互联网行业的技术积累从全球范围内看也是处于比较前沿的状态。

接下来咱们看看手机淘宝在近10年的发展历程中经历了哪几个阶段。咱们从2008年开始发布了手机淘宝的第一个版本，在最初的阶段咱们对手机淘宝的定位是一个工具型的APP，在这个阶段咱们主要是为了完成对商品的完整生命闭环的支持，从商品的搜索、浏览、下订单、支付、售后运维以及物流等等。在这个阶段咱们更关注这个APP基本功能的保障，以及这个APP基本性能的保障。

随着咱们整个手机淘宝业务不断地发展，咱们的整个体量也在不断地壮大，到了2.0阶段，淘宝逐渐成长为阿里集团内部的一个平台型的APP，咱们叫作航母级的APP，在这个阶段大量的阿里集团的其它的业务，比方说飞猪、天猫、聚划算等等都把相应的业务入口搬到了手机淘宝这个平台上来。因此手机淘宝每个大版本的迭代，它背后实际上是有大量的业务团队进行相应的协同来完成这样一次工做的，因此在这个阶段，咱们主要是关注手机淘宝这样一个航母级的平台总体的迭代的效率以及它的稳定性上的保障。

而后进入到第三个阶段，也就是咱们如今所处的阶段，咱们把本身定位为一个生态型的超级APP。怎么理解这个生态型的超级APP？你们知道去年双11整个阿里集团电商当天的GMV达到1670亿，在这样一个大型的商业活动当中，手机淘宝实际上是扮演了阿里集团业务运营中轴的角色，经过手机淘宝咱们来串联阿里集团内部，不只仅是咱们的电商体系，还包括大文娱、金融体系，你们一块儿协同共振来产生了这样一个很是了不得的成绩。因此在这个阶段，咱们更关注的是如何经过这些技术框架、技术能力去支撑上层的阿里集团的业务创新，以及在整个生态下各个板块之间的协同。

在手机淘宝的演进过程当中，咱们也遇到了大量的技术上的挑战，还有效率上、质量上以及性能上的挑战。首先是整个协同效率方面，手机淘宝早期的技术架构仍是一个单一工程的研发模式，这样一个研发模式随着客户端承载的业务愈来愈多，它的总体业务间的依赖关系也愈来愈复杂，系统的耦合程度愈来愈严重，比方说咱们每次开启一次迭代，多是不一样的业务方从他的主干分支拉一个分支代码进行独立的研发，到最后要进行分支结合的时候，由于业务耦合很是严重，每一个业务作的变动，相互之间匹配的时候都会有大量的冲突，这样的冲突就要求咱们协同大量的业务团队一块儿来进行冲突的解决，这样一种方式实际上是带来大量的协同上的问题。

第二方面，随着咱们整个业务之间耦合不断地提高，系统的复杂度不断地提高，后续整个系统的扩展、业务的扩展，咱们须要新增一些业务到APP体系当中的时候，你会发现你的历史包袱愈来愈重，也为后续APP的迭代带来大量的成本，这是协同方面带来的一个问题。

另一方面就是手机APP的发版模式，跟咱们传统的B/S架构的应用有很是大的不一样。B/S架构的应用，你在后端随时能够控制它的系统的升级，应用可控性是很是强的，可是像APP这样一个C/S架构，一方面你的APP的发版是须要经过应用市场进行审核发布的，另外一方面客户端的更新也是由客户进行控制的，这样的发版方式也限制了咱们业务应对市场的变化的响应速度和相应的业务创新的灵活性。

刚才提到的是效率上的问题，咱们面对不一样业务之间的协同上而带来的牵一发而动全身，整个业务的迭代不够敏捷，成本很是高昂。

除了效率上的问题，第二个就是质量上的问题。由于手机淘宝移动APP，做为整个集团业务运营中轴的角色，要求咱们在应对市场变化的时候有很快的响应的速度，而且移动业务自己也是一个迭代频度很是高的场景。在这样的场景下怎么保证APP的质量，也是咱们当前遇到的一个很大的挑战。由于一旦一个事物变化的频度加快的时候，它的容错率就下降了，因此怎么样在业务快速迭代过程当中保障这样体量的一个APP的高可用，也是咱们在演进过程当中遇到的一个很大的问题。

第三个就是网络层面的问题，由于移动业务是一个在线属性的业务，所谓的在线就是对网络的依赖。移动网络对比有线网络是有很是多不一样的，它多出了一个移动链路的环节，总体的稳定性、连通率对比有线网络都有必定的不足，怎么解决网络层面通讯效率的问题，怎么解决网络安全的问题，这些也是咱们在业务演进的过程当中所面临的挑战。

面对这些挑战咱们作了什么事情，首先是关于整个协同效率方面，为了解决协同上的问题，为了解决整个APP架构的优雅设计的问题，咱们也是开发了一个应用容器，这个应用容器本质的原理就是指望能把一个APP内部全部的业务模块拆分为一个一个独立的业务板块，这些业务板块之间咱们经过标准的协议进行通信的，这样的方式能够确保每一个业务模块独立并行往前走，每一个业务模块最后对应的是一个独立的工程，工程和工程之间拆分出来了，不一样的业务模块之间就不存在任何的耦合关系，经过这样的方式咱们能够大幅提高不一样业务团队之间的协同效率。

另一方面经过这个应用容器，咱们会负责托管整个业务组件的完整生命周期，经过这样的方式好处在于当你的业务组件出现问题的时候，咱们能够经过容器在内部消化这个问题，避免这个问题会影响到全局APP的质量。另一点，由于咱们的容器托管了业务模块的一个完整的生命周期，因此咱们能够实现每一个业务模块动态部署的能力。这一点咱们有一些在APP上使用上的业务模块，我在一开始打包的过程当中就能够把这些业务模块，不须要加在最终的二进制的包里面，能够减小APP的包大小，当这个APP处于运行时的时候，我再经过这个容器去进行一个动态的加载，经过这种方式进行动态部署。另一个，这种动态部署能力也意味着当线上出现一些问题的时候，能够经过动态部署的能力尽快完成线上问题的即时修复。

围绕刚才说的质量的问题，咱们也是沉淀了一套泛质量管理的体系个，一个是基础设施层面，一个是流程层面，基础设施层面咱们有很是好的实验室，针对解决如何提高移动应用线下测试的效率，如何提高它的自动化的程度，自动化的UI的测试，自动化的性能测试等等，去提高总体的Bug检出率，替换原先人工的黑盒测试的模式。进一步咱们也沉淀了大量终端的能力，如何解决远程调试，当端上出现问题的时候，是否是能经过一些远程调试设备帮你解决问题，如何进行端上移动日志的管理，如何实现端上热修复的能力等等。

再往下咱们有面向移动大数据处理的平台，如何采集来自不一样数据源的数据，如何去作交叉分析、聚合分析，如何去发现潜在的一些风险，如何去智能地感知线上的一些问题。在流程方法论方面，手机淘宝也沉淀了一套高保障的机制，咱们大概划分为三个阶段：

第一是研发测试阶段，咱们经过静态扫描、真机服务，保障在研发测试阶段的代码质量，在阿里集团内部咱们有一整套统一的移动应用质量质量基线的定义，当第一个阶段你的整个静态扫描也好，你的真机测试也好，评测下来的结果符合咱们的质量标准基线的时候，咱们进入到第二个阶段。

第二个阶段是几轮的灰度发布的阶段。由于线下的真机测试，毕竟它能覆盖的样本数，可以覆盖的场景仍是相对比较局限的，因此是须要线上必定量的灰度量，可以把一些边角的案例可以覆盖住。

灰度发布阶段，咱们也能基于大量的设备画像进行很是细粒度的定向的灰度发布，通过灰度发布，经过咱们的整个质量基线的评测以后，咱们会进入到正式发布的阶段，在正式发布阶段，咱们也会经过咱们的APM的能力，舆情管理的能力，进行实时线上的质量大盘的监控。当发现问题的时候，咱们会经过远程调试的能力，经过终端日志的能力去快速地进行问题的发现，而后快速完成线上问题即时修复。

经过这样一整套的流程机制，确保像手机淘宝这样一个超级APP，这样一个生态型的APP，在运行时可以始终保持一个高可用的状态。

第三部分是关于性能网络方面。性能网络方面其实咱们主要解决的问题是两个，第一是移动业务场景下，有大量的业务场景对网络是强依赖的，比方说咱们的移动API服务，比方说消息推送、即时通信、数据同步、远程配置等等，对网络都是一个强依赖，假如说每一个业务团队都本身来负责网络层面的研发，这个成本实际上是很是高昂的，咱们知道网络自己实际上是一个相对比较窄，具有必定门槛的基础领域，若是每一个团队都去维护这样一个网络专家团队的话，一方面你的技术研究周期比较长，和你的业务快速迭代是有必定冲突的，因此整个网络层面的研发成本仍是很是高昂的，怎么样去解决这方面的问题，在阿里内部咱们是把全部的无线端的网络都统一到一个团队来解决，而后也提供了统一的无线网络接入的体系。

面向终端，咱们是提供统一的SDK，承载不一样业务场景的网络接入。在后端咱们有一个接入网关，解决流量调度、APP管理、网络优化等等，和上层解偶的网络基础设施的建设。而且咱们有专门的团队作底层协议的持续优化以及和移动网络适配，经过这样的方式能够去解决在移动网络场景下，网络劫持、安全加密，以及网络通信效率等等方面的一系列的问题。

企业级移动中台EMAS

刚才说到的围绕效率、质量、性能，其实沉淀的仍是比较典型的几个案例，但在近10年的发展历程中，咱们也沉淀了大量的基础设施，今天这些基础设施在阿里内部咱们是由EMAS移动中台来统一承载的，而且经过EMAS这个移动中台来支撑整个阿里巴巴上层大量的移动业务的快速创新。今天咱们也指望经过阿里云这个口子可以把咱们的移动中台对外输出，帮助客户快速地完成数字化、移动化的转型。

这幅图是EMAS的产品全景。EMAS包含三部分，第一是基础架构层，咱们叫EMAS Infrastructure，这是提供面向APP开发域的，咱们会提供大量的功能组件、服务组件、移动端的中间件、推送、移动网关、APM、舆情分析等等相关的中间件。而后是下面的架构层，咱们有跨平台的开发框架和移动端的应用容器，帮助你们构建一个更加优雅、科学的APP底层架构。

第二层是研发支撑层，EMAS DevOps，这主要是围绕一个APP完整的生命周期，从你的代码管理到你的静态扫描、编译、构建、灰度发布、正式发布、运营这样一个完整的生命周期，提供阿里巴巴的工做体系，来进行闭环的管控。

第三层是工程理念层，EMAS Philosophy，也一层咱们但愿EMAS不只输出阿里巴巴沉淀的一些硬的基础设施，咱们还但愿把阿里巴巴沉淀的一些软实力，咱们的Android、IOS的研发规范、火车式的版本发布机制、APP性能指标基线、质量指标基线，甚至是说不一样的开发者可能处于不一样的阶段，在不一样的阶段你的整个移动互联网研发团队的组织架构如何去构建等等这方面的经验，咱们也指望可以把这些软的东西、软实力的沉淀经过EMAS的平台开放出来。

这张图是整个移动中台EMAS在阿里巴巴的技术栈全景当中所处的位置。咱们一直在说阿里巴巴是一个很典型的大中太、小平台的业务体系，上层的业务很是多，要支撑这些上层业务的快速变化，须要有大中台支撑。在大中台中咱们有业务中台、数据中台、互联网中间件、基础设施、IaaS层的资源等等，移动中台也是其中很重要的一部分，如何去支撑上层的业务在移动层快速的业务创新。

5大移动研发场景解决方案

接下来咱们就一块儿看一下基于EMAS的产品能力，咱们面向移动研发的几个比较典型的痛点场景，咱们所沉淀出来的解决方案，包括持续交付、组件化、跨平台、泛质量管理以及网关统一接入。

首先是EMAS的持续交付解决方案。在EMAS平台上咱们也支持三种研发模式，包括传统的Native方式，以及跨平台方式，基于WEEX的跨平台开发框架，第三是混合开发，所谓混合是Native加上WEEX的方式。咱们也指望经过EMAS输出三项IT效能指标的参考体系，包括围绕效率咱们怎么样定义一个研发团队的研发效率，包括咱们怎么定义一个应用的质量基线，包括咱们怎么定义一个应用的性能体验的基线等等，咱们会把阿里巴巴内部的这一整套的基线体系输出出来。

持续交付也会覆盖咱们所谓的五大职能域，从研发、测试到发布、运维、运营。在这五大职能域，咱们也沉淀了大量的基础设施和工具服务，比方说构件阶段，咱们会借助依赖管理、编译缓存、构建集群等等，大幅提高Android、IOS打包的效率，而后在测试阶段，咱们会提供大量的私有API的检测、包大小的检测，基本的安全属性的检测，包括咱们会把Android、IOS研发规约最终实体化为一个静态代码检测的脚本，经过这样的方式把规范提到平常实践当中。在发布阶段，咱们有很是细粒度的灰度发布的能力，在运维阶段咱们有基于端上的全景监控体系，能够全盘监控整个端上的性能质量状态。再到运营阶段，咱们有相应的舆情管理，以及相应的消息推送能力，可以实现更快速、更实时的用户的处理。EMAS的持续交付就是经过EMAS DevOps进行五大职能域的工做串联，帮助开发者真正实现一个一站式、一体化的应用迭代的管理。

EMAS持续交付解决方案带来的价值，能够从手机淘宝的版本发布频度去看它的效果。最先以前手淘的版本多是一个月才发版一次，如今咱们平均天天发版次数是1.7次，这样一个频度可能你们会有疑惑，为何你的版本发布这么频繁，这也跟我接下来介绍的组件化解决方案有关系。

组件化解决方案本质上是经过咱们的应用容器来实现APP架构的优化，实现APP架构内全部不一样业务模块之间的解耦，经过这样的方式，咱们能确保咱们的每一个业务模块相互之间是彻底独立的，是单一工程能够并行研发的，另外咱们也能够实现这样一个基于容器动态部署的能力。每个业务模块，它单独的动态部署都意味着咱们这个APP发生了变化，因此为何咱们刚才提到手机淘宝天天大概有1.7次的发布，这是由于每一个业务模块发生一次动态部署，我都认为是一次APP的发布，这就是为何咱们发布频度这么高的缘由。

这幅图是手机淘宝的一个组件化的案例，在手机淘宝体系内，像你的首页、搜索、评价、支付等等，背后其实都是一个个独立的业务模块，经过咱们这样一个容器框架能够实现不一样模块的解耦，上下会用统一的基础设施的中间件，经过这样的方式，咱们可以完全的从一个单一工程开发的模式转化为一个多功能运行开发、协同开发的模式。

组件化解决方案带来的一个优点是说，原先的这种单一工程、强耦合的架构其实类比于两人三足的协同模式，一旦某个模块出现问题，就会致使整个队列被那我的阻塞住，须要整个队列协同起来才能往前走，这样协同的成本是很是高昂的。经过咱们的组件化的方案，总体的架构能获得有效的优化。在手机淘宝内部咱们的版本发布是遵循一个班车制发布的原则，咱们在一年作规划的过程当中，咱们就会确立接下来一年每月大版本发布的时间点是何时，而且这个时间点是不会发生变化的，假定某个模块须要跟随这个大版本的发布，通过个人买票上车的环节，就是经过个人静态检测、真机测试，知足了个人应用质量基线标准以后，跟随我这一次的大版本的发布。
假如没有知足，没有关系，由于咱们具有动态部署的能力，因此当你达到了这样一个发布的状态的时候，你能够基于咱们应用容器的动态部署能力，去完成本身的应用迭代，从这样一个方式，咱们能够完全地从原先的多方捆绑的方式，转化到业务发布按需发布、想发就发的状态，整个业务的效率获得大幅提高。

还有一块就是咱们的跨平台解决方案，它主要想解决的问题就是但愿可以同时继承各类研发模式各自的优势，经过这样的方式，一方面能够实现快速研发，研发团队维护成本低，同时它的性能体验是基于原生的渲染引擎进行渲染的，因此它的体验都会比较优异。

经过跨平台的解决方案，也推进咱们在组织架构上进行改变，随着跨平台解决方案的出现，咱们的平台慢慢的演化为一个一个独立的工做组的模式，跨平台我只须要有几个前端的开发人员，就能够帮助我完成多平台的业务快速的开发，研发团队的维护成本会很是低，每一个业务团队慢慢的演化为这样一个独立的工做组的模式，可以闭环的完成业务的快速迭代。而咱们原先的客户端团队就慢慢的下沉，变成咱们一个基础支撑的团队，如何去更好地把底层的能力封装成JS API，向上层去暴露出来，经过这样的方式咱们也大幅地提高了内部不一样团队之间的协同效率，以及支持了这些业务的快速创新和迭代。

跨平台框架在阿里双11的大型商业项目中，一些大型的运营项目中，WEEX框架也是发挥了重要的做用，像2017年双11当天，整个框架承载了16万+页面的渲染。除了阿里体系内其它一些大型的APP以外，在整个社区也有大量的社区基于WEEX开发框架作混合开发。

另一部分是泛质量管理解决方案。刚才提到手机淘宝围绕质量问题实际上是沉淀了一整套很是体系化的泛质量管理的体系。这一点咱们主要是为了解决三个问题，第一是传统的APP很依赖发布前的人工黑盒模式的测试，而这样一种测试模式成本很是高，可是由于是须要人工去进行单点测试的，因此它可以覆盖的环境、场景也是很是有限的，效率很是低，应该说是一种很典型的单点式保障的模式。

另一个问题就是绝大多数的APP都缺少主动的问题感知以及智能的问题感知的能力，每每是被问题推进走，拆西墙补东墙的模式。同时还存在一个问题，当线上出现问题的时候，不少时候仍是靠线下猜想问题的缘由，缺乏一系列的数据和工具来支撑，如何提高定位问题，以及解决问题的效率。咱们是但愿经过泛质量管理的解决方案，一方面整个质量管控是从测试域扩展到研发域，扩展到运维域、运营域，如何经过这样一个全链路的链式的保障来实现咱们的总体质量管控。另一方面咱们也但愿经过咱们的全链路的核心指标的监控体系去实现多个数据源的数据聚合、交叉分析，去尽量实现智能的一些问题的感知和一些风险的预判，而后经过咱们的全链路的排查工具，终端日志的能力、远程调试的能力，如何去提高定位问题的效率，如何经过咱们的热修复的能力，快速的实现线上问题的即时修复。

这幅图是手机淘宝高可用保障的流程方法论，在EMAS平台上咱们经过EMAS DevOps的工做流体系把咱们平台上的组件服务，像咱们的静态检测、移动测试、APM、移动日志、用户反馈、灰度发布、云构建、热修复等等，把他们的流程、数据所有贯穿起来，而后提供给开发者一体化的开发体验。

这里能够看到咱们的几个核心指标，包括线上故障数的指标、线上故障修复的指标，经过这种开发方式都大规模的减小。

最后一部分是网关统一接入的解决方案，这里咱们但愿提供的能力。大量无线端的业务对网络是强依赖的，咱们但愿这里有一个统一接入的解决方案，去解决API管理、限权限流、安全加密、流量优化等等，这些自己和业务解耦的网络基础设施的优化。包括咱们在集团内部有专门的网络专家团队来进行深度的面向移动场景的优化研究。

而后包括像移动端的API网关，其实也是一个移动应用很是核心的基础设施，在咱们这个网络解决方案里面，咱们面向API也提供了一键编排的能力，从建立一个API到这个API在API网关的实时发布，再到你的终端API的生存，再到你的API网关和数据的交互，经过这样一个平台，可以实现一键的部署。同时围绕这个API的统计分析，限权限流、版本管理等等，都能在这个网络解决方案里面完成闭环式的管控。

咱们但愿EMAS为开发者从两个维度提供真正的业务价值，也就是团队方面和业务方面。在团队方面，咱们但愿经过EMAS一键复制阿里巴巴所沉淀的实践标准，咱们的流程、方法论，帮助咱们的开发者尽可能少走弯路、错路。本质上仍是但愿经过这样一整套解决方案，帮助开发者去提高企业内部的人均效能。在业务的视角来看，咱们也但愿经过咱们这样一整套的基础设施，帮助开发者快速、高效地去构建一个高质量、高性能的移动业务。另一方面就是经过咱们的架构层面的能力输出，帮助开发者去真正地构建一个优雅的APP底层的架构设计，避免在后续的业务迭代过程当中，这个业务会过于臃肿、庞大，而后会走样、变形等等。

咱们提倡的理念是：企业互联网+真正标志是研发体系互联网化。如今说的云计算，你们更多理解为IaaS层的服务，可是单纯经过虚拟机替换原来的物理机，这样的动做仅仅是资源层面的替换，并无办法为企业的研发效能提高带来质的变革，而只有你真正实现了企业内部研发体系的互联网+的升级，才能为你企业内部的研发效能的提高带来一个质的变革，而EMAS就是整个阿里巴巴近10年移动互联网研发体系的具像化的载体。

今天在EMAS平台上，已经有大量的行业客户，与咱们并肩同行，将来咱们也但愿有更多的客户可以加入到咱们的研发生态当中。今天应该说移动互联网已经事实上成为整个社会最核心的基础设施，因此咱们也但愿经过EMAS这样一个移动中台，可以真正地赋能客户，帮助他们去实现企业数字化、移动化的转型，帮他们去构建这样一个超级APP、业务运营的中轴，经过EMAS去支撑上层业务的快速创新。