共计 5782 个字符，预计需要花费 15 分钟才能阅读完成。
EMAS 的整体定位是阿里巴巴移动技术对外输出的主窗口，沉淀了阿里巴巴近 10 年在移动互联网技术架构上的积累以及在一系列垂直场景中所实践的核心技术能力。一方面，EMAS 希望为广大开发者提供安全、稳定、快速、弹性的移动应用基础设施，另一方面也希望帮助广大中小企业、初创团队以及处于“互联网 +”转型阶段的传统企业构建工程化、系统化、智能化的企业级移动互联网研发体系，并将近十年来阿里巴巴在移动互联网总结和沉淀的一系列方法论分享给业界。
从 2015 年第一个产品公测开始，到目前为止 EMAS 总共服务了近 14 亿移动终端设备、20 万 App 以及 10 万移动开发者，在一定程度上也影响了整个国内移动开发生态的发展。
随着技术形态的不断演进，移动互联网已经成为全球商务生态系统当中不可或缺的一部分。用一句话形容 EMAS 的愿景就是“30 天和你一起再造一个手机淘宝”。这背后的含义就是无论规模多小的创业团队都可以基于 EMAS 的服务快速便捷地拥有像手机淘宝、支付宝一样完善的基础设施，可以低成本地拥抱移动互联时代。当前 EMAS 处在快速向前迭代发展的阶段，未来也会有越来越多的阿里巴巴集团内部优秀的移动基础服务通过 EMAS 平台对外开放。目前 EMAS 开放了一个研发支撑平台、九大公共云产品服务、五种场景解决方案以及两种专有云产品服务。
EMAS 将整个移动应用开发划分成了 5 个职能域：项目域、工程域、构建域、运维域和运营域，并且面向这 5 个职能域形成了移动中间件基础解决方案。
在解决方案环节，阿里巴巴已经开源了面向 Android 的应用容器 Altlas 以及跨平台的 UI 开发框架 Weex，围绕这些开发框架也会提供相应的商业化版本解决方案，帮助开发者更便捷地完成 App 的创建和管理。通过端 + 云的紧密配合为移动开发者提供全链路端到端的移动研发解决方案。在专有云环节提供了面向传统企业开发企业级应用研发服务 EMAS，希望打包整个阿里巴巴集团近 10 年移动互联网研发体系的积累，并以 SaaS 化的服务形态一键复制我们的能力、经验，我们的流程、机制和方法论，希望帮助更多的传统企业快速地完成业务移动化的转型升级目标。
基于上述提到的这一套端到端的全链路移动应用研发体系，阿里巴巴也提出了一种新的移动 App 研发范式——Cloud Native App。
传统的 Cloud Native 概念主要是面向后端应用的，利用容器、微服务、持续集成、持续构建以及 DevOps 这一套云化的架构来构建应用，其本质则是一套应用构建的方法论，怎样充分地利用云计算服务模型的优势来低成本、快速地构建弹性的应用，这样一套方法论在移动 App 场景中同样适用。比如基于面向移动端 Serverless 的架构实现 App 运行环境的透明化和按需扩展，基于云上开放的移动 App DevOps 实现研发流程流水化，支撑应用的高效交付，基于云上的移动中间件体系实现所有的基础设施服务化，按量付费，基于 Weex/Atlas 赋能应用，真正实现大型 App 组件化和跨平台的能力。这样一套 Cloud Native App 研发范式能够真正帮助开发者去降低业务本身的技术风险，把自己有限的资源投入在和本身业务快速增长的工作上。
接下来分享阿里巴巴在移动 App 的研发关键路径上所开放出来的一系列的核心能力，主要分为了几个关键环节：网络、消息与数据、应用质量和高可用以及企业级移动应用研发服务 EMAS。
（一）网络
网络是所有移动 App 非常关键的基础模块。Google 之前对搜索系统有做过相应的统计评测，搜索系统延迟每上升 400 毫秒，搜索量业务量就会降低 0.59%，虽然这一相对值看似比较低，但是在 Google 搜索体量背后也是非常大的损耗。雅虎整体 Web 系统的延迟每上升 400 毫秒，流量就会下降 5% 到 9%；Bing 延迟每上升 2 秒，整体收入下降 4.3%；而对于 Mozilla，延迟每降低 2.2 秒，下载量就会提升 15.4%。所以说网络这个环节不仅仅和移动端体验息息相关，同时也直接决定着产品的核心商业指标情况。
在网络环节，阿里巴巴也有非常深厚的沉淀。首先从网络最开始的阶段、最前置的环节来看就是流量调度和域名解析。传统 DNS 解析体系存在很多问题，比如域名劫持的问题，以及由于本身的调度精准性带来的网络访问质量降低的问题，还有在移动场景本身域名解析的延迟有 200 毫秒左右，而这样的延迟对于本身用户网络访问也会带来一定的体验上的损耗。传统基于 B / S 架构浏览器的 Web 应用，对于开发者而言都是黑盒，很难针对网络环节进行优化，到了移动互联网时代，移动 App 基本上以 C / S 架构形态构建的，这样一个形态和架构特性意味着有更多的针对客户端的定制和优化的空间。在这样的背景下，HTTPDNS 应运而生，它替代了传统 DNS 解析路径的服务质量最不可控的 LocalDNS 环节。
HTTPDNS 有以下几个特性：
• 防劫持，因为 LocalDNS 环节往往没有商业化的 SLA 保障，而通过这样的方式可以彻底地规避域名劫持问题。同时基于全网的 BGP Anycast 的部署可以实现全网客户端就近接入的能力，同时通过遍及全网的多机房的容灾可以保障商业化的服务 SLA。另外一方面，HTTPDNS 和权威 DNS 之间也是通过 EDNS 进行直连的，这意味着可以基于客户端 IP 进行精准调度。在传统的 DNS 体系中，一般权威 DNS 进行调度的时候是基于 LocalDNS 代理节点进行调度的，一旦 LocalDNS 的分布不是很均匀，就会降低 CDN 域名解析等的精准性。
• 0 延迟解析，因为移动 App 是 C / S 架构的，所以在端上会提供 SDK，可以通过像预解析、智能缓存、懒加载等特性把每一次 DNS 解析延迟从用户网络请求当中抽离出来异步地在后台进行实现，这样可以在真正意义实现零延迟解析，进而降低每次网络请求的延迟开销。
• 解析变更秒级生效，由于 HTTPDNS 和权威 DNS 之间是存在相应的交互的，解析域名的实时变更可以同步到 HTTPDNS 这边，这样全网变更秒级生效在传统 DNS 体系下是无法实现的，这是因为 LocalDNS 本身会进行 IP 缓存，很多时候对于 IP 缓存并不遵循标准 TTL 协议，所以会导致了变革在全网生效有很大的延迟。
• 软件定义解析能力，通过这个能力用户可以基于自己业务诉求来进行自定义的流量调度，这样的能力在 A /B Test、版本灰度以及安全流量调度等场景下都有很大的利用空间。
• 基于现在对于网络流量数据的评测，HTTPDNS 已经成为整个移动互联网中非常重要的域名解析和流量调度的基础设施。
域名解析之后就是网络请求的主体环节。对比有线网络，移动网络一个很重要的特点就是多了一个移动链路环节，其整体丢包率、稳定性以及延迟对于有线网络都有所不足。通常称这个链路为 Lastmile，如何解决 Lastmile 通信效率的问题也是移动网络优化最为核心的课题。对于普通的开发者而言，整个网络链路是以黑盒形态存在的，所以开发者针对网络形态所能做的网络优化的空间是非常有限的，如果需要专门针对移动网络进行优化则需要聘请相应的专家针对协议层面进行相应的优化，所以整体资源的投入和维系的成本以及门槛也是比较高的。基于此，阿里巴巴也会开放内部的网络优化体系——移动加速服务，希望能够从端、管、云三个层面帮助开发者完成 App 网络整体立体式优化。
传统的 App 网络访问链路从客户端发出请求是通过公网路由进行原站访问的，而通过移动加速，App 发出网络请求首先会就近接入遍及全网的加速节点，通过加速网络进行快速的路由选择再回原站访问。这样的整体收益就来自以下三个方面：
• 在“端”方面，移动云会提供网络托管 SDK，通过托管 SDK 和加速节点配合，真正意义上构建双端加速模型。传统 CDN 是典型的单端加速模型，而双端加速模型的一个很重要的优势就是从客户端到加速节点之间的链路由于双端都有控制，可以进行传输协议的协商和实现。在这样一个双端加速模型上可以针对传统四层的 TCB 协议的一些缺陷进行深度优化定制。
• 在“管”方面，移动云拥有遍布全网的海量就近接入节点，在带宽以及链路等方面质量都是非常优异的。同时，传统 CDN 是短连接的形态，每次发起的业务请求在结束之后可能就被释放掉了。而在移动加速场景下，从客户端到加速节点到原站之间实现了全链路的长连接，可以大幅度削减在网络通信过程中的三次握手以及安全握手等冗余的开销。另外在动态路由方面，全网会有海量的加速节点，通过这些加速节点可以实时地、智能地去计算从就近加速节点到用户原站之间应该通过怎样的路由使得整体的延时更优化，进而降低每次网络访问的延迟。
• 在“云”方面，传统 CDN 实现的功能是静态资源的缓存、分发能力，同样的移动加速会继承传统 CDN 静态资源缓存分发能力，同时对于像 HTML、JS、CSS 等面向 Web 化的资源也会进行动态的资源优化，进一步压缩链路上网络带宽的诉求，提升网络访问的效率。
对比于传统的 CDN，移动加速就是 CDN 面向移动场景的解决方案。在双端加速模型，的背景下，可以针对访问链路进行协议定制优化，同时在连接层面可以实现真正意义上的全链路的长连接，大幅削减安全握手、三次握手等冗余开销。加速网络内部在端上引入机器学习的元素，可以通过智能判断分析对于当前的客户所处的当前环境到底应该选择使用加速链路还是公网路由。基于双端加速模型，可以进行优化定制，对于 HTTPS 的加密协议也可以进行深度定制，可以实现效率上的提升。
除了域名解析和网络优化之外，移动网络还有非常多的场景诉求，比如说网络拨测、网络体系监控、资源上传、远程调用、网络诊断等，移动网络本身是内聚性非常强的闭环场景。App 对网络诉求可以用四个关键词概括：高速、稳定、可控，可视。
（二）消息与数据
移动互联网进入到下半场，人口流量红利也在慢慢退去，如何实现更精准的客户触达和留存成为每一个产品最核心的运营指标。如果说大家之前有关注过手淘的“双 11”会场页面会发现手淘已经实现了“千人千面”能力，同时基于数据智能消息推送系统在线上运转多年并且取得了非常好的成绩。现在阿里巴巴也会把这些产品能力背后的核心技术开放出来，帮助大家实现对于客户的拉新、促活、留存和转化。
面向运营域，阿里巴巴会开放经历多年“双 11”历练的消息推送系统。在送达方面开放整个阿里系共享的消息推送通道，结合厂商合作伙伴提供的基于多消息推送通道的通送解决方案保障整体送达效果。延迟方面，会针对移动网络场景进行深度优化和定制，同时面向 IOS 推送场景提供相应的中美高速通道专线，保障每一次任务的及时下发和网络秒级应答。在流量方面，每秒百万级别消息设备的吞吐率意味着在面对类似“双 11”这样的强脉冲计算的场景下，也能够及时地对于推送业务进行应答。
除了传统 PaaS 层推送通道之外还会进一步开放复合推送的能力，基于移动推送 + 短信推送组合面向客户提供更弹性的触达终端用户的解决方案。在复合推送的模型下，优先通过应用链的消息推送进行客户触达，在消息推送没有办法触达客户的情况下就通过短信推送进行补偿。一方面可以利用短信推送的高触达率保障营销任务的触达效果，另外一方面也可以利用消息推送本身的低成本进一步地降低营销任务背后的成本开销。
阿里巴巴也会进一步开放集团内部的基于大数据的智能推送的能力，基于个性化推荐引擎可以构建企业完整的用户画像，基于用户画像标签、终端用户地理位置信息、终端状态信息以及每一次推送具体的内容等多个输入源进行智能的设备圈选，有效地提升推送的精准度，能够帮助客户实现真正意义上基于大数据的精准定向营销。
（三）应用质量和高可用
移动互联网发展到今天已经累积了几万款移动终端设备，海量的机型和操作系统以及分辨率构成的配置组合给移动应用本身的质量保障带来非常大的挑战。
传统测试模式基于人工，不管在测试覆盖度、测试效率，还是 Bug 检出率方面已经无法完全应对测试本身复杂度的指数级增长。基于这样背景阿里巴巴开放了内部的真机测试服务平台——移动测试服务，其包括了真机适配、功能自动化、云端调试、在线录制、性能测试以及 H5 测试等方面的能力，希望能够从公共云和专有云两个渠道帮助不同诉求的客户一起保障移动 App 高质量的交付。
移动云面向移动 App 还推出了线上问题一键热修复的解决方案 Sophix，针对 Native App 发版节奏慢，更新周期长的问题提供端到端一体化的热修复解决方案，Sophix 可以面向代码、资源、SO 文件三个维度进行修复，接入成本非常低廉，对应用没有侵入，几行代码可以完成整体接入，补丁包采用差量技术进行更新，从 Patch 生成、灰度、线上发布和统计能够帮助开发者实现一站式线上故障应急处理的解决方案。
移动应用质量管理高可用这个体系类似于上述的移动网络体系，也是内聚性非常强的闭环场景，在这样的场景内阿里巴巴沉淀了非常多的能力，比如数据挖掘、分析梳理、面向终端日志采集分析处理等等。
（四）企业业务移动化
除了上述提到的公有云开放的几个场景能力之外，面向专有云、传统企业、面向企业移动化浪潮，阿里巴巴也会开放相应的解决方案。
传统企业进行业务移动化过程中会面对各种各样的研发协同挑战，存在着很多面和点的问题，为了应对这些问题，阿里巴巴开放了企业级移动应用研发服务 EMAS。对于传统企业而言企业“互联网 +”的标志是研发体系的互联网化，单纯在资源层面通过云上虚拟机替换传统的物理机并不能带来本质的变革，只有真正实现了传统体系内部研发体系的“互联网 +”的升级，才能够真正为传统企业内部研发效能的提升带来质的变化。EMAS 希望打包整合阿里巴巴近十年研发体系以及能力、经验的积累，希望帮助更多的传统企业快速构建工程化的移动应用研发体系，完成企业业务移动化的转型升级目标。
EMAS 研发支撑平台覆盖从研发管理到持续集成、自动化测试、版本管理、灰度发布、监控大盘、系统运维、用户运营等完整的全流程生命周期管理，是移动互联网沉淀的这套流程、机制、方法论很重要的载体。同时配合在云上提供的移动中间件基础服务体系，可以从真正意义上面向开发者提供移动应用研发全栈解决方案。
上图所示的就是完整版的 EMAS 能力交付的全景图，除了刚才介绍的传统从端 + 云 + 数据这样一套能力栈中轴之外，也会开放阿里巴巴沉淀的软能力，帮助研发者构建软硬一体化完善的研发体系。
原文链接本文为云栖社区原创内容，未经允许不得转载。
