以小见大，见微知著——亿万级APP架构演进之路

该文章来自阿里巴巴技术协会（ATA）

7月24日，2015WOT互联网开发者大会在富力万丽酒店隆重召开。阿里巴巴/高级无线技术专家徐昭（花名：长恭）带来的主题演讲《以小见大，见微知著 —— 亿万级APP架构演进之路》。

以下是演讲实录：

我是来自阿里巴巴无线事业部的徐昭，今天我演讲题目是以小见大，见微知著，和大家分享阿里巴巴以手机淘宝为代表的移动架构体系的演进过程和背后的思考，以及这其中大家最感兴趣的在大规模复杂应用场景下的关键架构技术。

手机淘宝是诞生于移动互联网时代的一个超级APP，并已成长为日活上亿级别、全球最大的移动消费生活平台。以之为代表的阿里无线应用体现的是一个高度多样化的生态，承载了大淘宝业务群之中几乎所有的业务形态。可想而知，在小小的屏幕背后，手淘面临着怎样强大的技术挑战：

PC的业务大量迁徙&无线特色并行；
客户端越来越重，体系越来越复杂；
无线架构与PC架构的相关性与差异性；
越来越多的终端设备产生,碎片化严重；
越来越多的APP的产生，APP之间的连接、复用成为新的命题。

手机淘宝技术之路

2009年手机淘宝更多偏向于APP的简单辅助工具，更多承载PC核心主链路的功能。2010年安卓、苹果操作系统生态成熟，基于Webview的技术能够在两端实现更多的业务场景。随着2012年整个生态成熟演进，最终整个团队规模增长到100多人，我们支持客户端层面有专职的安卓、iOS研发团队，在 2014年随着业务增长，增长至上亿级别用户规模，研发模式进行了统一拆分，配套的研发体系和工具平台也进行了针对性改造和进化。

这个过程中在前期阶段随着客户端模式的变化，以及PC业务的无线化迁移过程，经历了从工具到应用到平台的逐步演进。过去一年多来阿里无线PC业务迁移过程中遇到的挑战包括：

第一，PC业务大量迁徙和无线特色并行，这个过程中如何更好地的和无线特色结合，发挥移动端的特性是一个重点。

第二，今天客户端承载的架构体系越来越重，原来服务端的PC模式是否适合新的无线架构，无线架构和PC架构的差异性到底在哪里？

同时，随着体量增大，我们在越来越意识到今天整个移动设备市场的碎片化是非常严重的。如何更好地的适应多端支持、跨端的适配？如何从APP单一入口，进行APP群之间的连接和互通、互用？如何适应技术体系从工具到平台进而到APP开放生态群的支撑和进化？手淘技术团队围绕这些进行了大量的思考、研究和尝试。

无线架构治理的思考

总体而言，我们对无线架构治理的一些思考可汇总为以下五点：

部署模式的差异化。相对于服务端的时代，无线时代类似于CS架构模式，这个架构体系里基于无线操作系统的特性，如何保证动态部署、动态修复能力像PC时代一样更灵活，基于互联网模式实现更快速迭代
系统架构的差异。碎片化的操作系统带来研发和测试体系的变革，如何更好的去支持核心的操作系统、核心用户群体，跨终端、适配问题，如何保证整个研发体系的多端兼容性，如何能够在效率层面保证跨端支持，用最小的开发效率和成本取得终端的支撑。
逻辑层次差异性。如何考虑更好的富客户端本身架构的提醒，如何能够在富客户端架构体系中更好的去运用移动设备本身的硬件特性，带来和无线传统时代以及PC时代不一样的性能。
质量体系的差异。移动端质量体系考量的维度和传统的PC时代不一样，今天需要综合考虑用户层面的流量、帧率、内存，用户本身对移动体验的诉求。
用户行为本身的变化。服务端传统的服务调用模式是否适用于移动生态，是否适用于用户永远在线的特性。

客户端重构：破而后立

从端的角度出发，我们结合移动端的特性进行架构特征分析和思考。我们考虑架构设计的时候遇到几个挑战。对于这个过程中我们的解法是“破而后立”，今天打造超级APP，重要的一点是如何利用技术手段提供持续的交付能力，目标是让大象能跳舞。小团队研发团队类似田园式的自主研发模式，对比超级APP和超大规模团队研发，后者这只大象的转身非常缓慢。这个过程中我们拥有的架构体系，如何将不同的业务体系进行更好的隔离，技术在业务间更好复用，业务与业务和技术与技术间如何减少紧耦，手淘团队从不同的技术路径尝试给出相应的解法。我们对整个开发模式、工程结构、架构模型进行了彻底的改造和深入探索：一是围绕容器架构为核心出发做了深度改造。基于在移动端上的最小部署单元我们归一化统称为“组件”，包括相对独立的Libraries也可以是其他的独立部署业务/UI模块。我们能够支撑这些单元以动态灵活的方式加载，并以统一的方式管理其生命周期，使得每个组件可以独立的开发、独立的部署、独立的调试、独立的发布。底层采用总线方式支撑这样的模式，分别在UI、服务、消息的层面上提供总线机制。从而在UI层可使用统一的方式进行跳转管理、横向拦截以及统一降级策略；在消息层面基于系统本身机制，构建不同模块之间通讯能力，保证每个独立的组件单元可被感知和彼此交互。

沿容器化思路，基于组件的研发体系本身也发生了相应变化。在工程角度，对于手淘工程进行相应解耦，按照业务、单元归属不同的研发团队拆分成具体的组件模块。在容器化支撑下，我们做到模块单元的动态部署、动态补丁能力，将不同的业务、技术模块充分解耦，以适应更灵活、更合理的迭代演进节奏。

在管道层面，我们对网络层进行针对性优化。首先在接入层统一了阿里移动端接入体系。针对设备和web接入提供了更高效，更规范、高可用的接入层。针对内部云端服务，基于API网关我们提供了统一接入模式，并充分复用长连通道，整合业务层对RPC、IM、PUSH几种数据消费模式提供完整的客户端消费模式支持。

此外，很多移动开发者关心具体的UI层技术，以及最终的业务功能开发框架，我们也进行了不一样的探索。面对H5灵活性，以及Native的用户体验，到底是选择研发效率、降低成本？还是提供适应原生平台本身的用户体验，用户为先？技术界一直存在各种争论。我们认为：只有最适合的技术，针对合适的场景做最佳的选择。在H5以及Native两个模式下，我们都做了很多有益并且领先业界的尝试。

H5方面，我们构建了平台化的研发和工具后台体系。依托阿里的整个研发和运维能力，将移动端Webapp的发布机制、缓存部署、控制策略等集成在统一的后台，使得H5研发效率得以标准化和高效保障，并进而采用PackageApp的方式支持离线化的web应用模式，大大提高用户体验。Native方面，我们自主创造了一个动态化的UI渲染框架，基于自己设计的一套数据协议，配备相应的可视化工具，可以满足后台编辑模块化的页面，并指定绑定数据源，以模板数据方式推送给客户端。客户端则动态接收和实时加载、渲染，动态进行数据变更。一套数据，iOS/Android/H5三端复用，动态输出。在手淘移动端看到的(装修过的)店铺和宝贝详情等场景就是基于这套框架实现的。

最终整个技术手段的目标是拓展商业边界。这个过程中我们所有演进过程都希望构建业务，迁移商业形态的同时，更多将技术和商业形态本身开放给开发者。在这个过程中我们看到阿里无线也提供了相应的技术和业务开放平台，我们通过前面所说的技术输出，今天能够支持到阿里的商业服务市场中整个店铺的模板、互动游戏，都可以用开放的方式支持第三方应用者开发，并无缝的接入到淘系移动业务。移动小屏幕代表了很大的技术和商业生态。商业变现过程中，技术起到核心重要的作用。今天手机淘宝代表了阿里整个电商生态的旗舰产品，未来我们希望随无线技术体系的进一步开放，逐步构建和孵化一个新的无线开放生态。其底层的核心技术一方面支撑阿里内部包括天猫、聚划算等等APP群的不断成熟和壮大，同时也希望通过手淘开源项目、阿里百川计划等技术结合商业手段的多样化方式，给移动第三方开发者更多的选择，以更快更好的构建自己的应用和用户体验，实现移动价值。

展望未来，概括一下我们对移动技术体系的思考，对于移动架构的思路，概括的说就是云、管、端一体化。云、管、端一体化的架构思维也可以从安全、性能、可运维等多方面全面为移动电商业务保驾护航。具体而言，类似网络的模型可被拆分成七个层次，在每个层次上以更聚焦和更标准化的方式提供最佳实践，并在纵向上各层次打通以支撑上层多样的业务形态。