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去支撑上层业务的快速创新。

详情请阅读原文

---

移动研发平台（Enterprise Mobile Application Studio，简称EMAS)，面向企业服务市场，期望把阿里巴巴近十年在移动互联网行业沉淀的DevOps研发支撑能力、移动App基础中间件能力开放给客户，帮助传统企业快速完成业务移动化的转型升级目标。

---

原文链接

本文为云栖社区原创内容，未经允许不得转载。