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

2021年11月23日 阅读数:3
这篇文章主要向大家介绍以小见大,见微知著——亿万级APP架构演进之路,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

文章来自阿里巴巴技术协会(ATA) git

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

 
如下是演讲实录: github

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

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

  • PC的业务大量迁徙&无线特点并行; 安全

  • 客户端愈来愈重,体系愈来愈复杂; 网络

  • 无线架构与PC架构的相关性与差别性; 架构

  • 愈来愈多的终端设备产生,碎片化严重; app

  • 愈来愈多的APP的产生,APP之间的链接、复用成为新的命题。 框架

手机淘宝技术之路

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

  

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

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

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

  

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

  

无线架构治理的思考

 整体而言,咱们对无线架构治理的一些思考可汇总为如下五点: 

  1. 部署模式的差别化。相对于服务端的时代,无线时代相似于CS架构模式,这个架构体系里基于无线操做系统的特性,如何保证动态部署、动态修复能力像PC时代同样更灵活,基于互联网模式实现更快速迭代 

  2. 系统架构的差别。碎片化的操做系统带来研发和测试体系的变革,如何更好的去支持核心的操做系统、核心用户群体,跨终端、适配问题,如何保证整个研发体系的多端兼容性,如何可以在效率层面保证跨端支持,用最小的开发效率和成本取得终端的支撑。 

  3. 逻辑层次差别性。如何考虑更好的富客户端自己架构的提醒,如何可以在富客户端架构体系中更好的去运用移动设备自己的硬件特性,带来和无线传统时代以及PC时代不同的性能。 

  4. 质量体系的差别。移动端质量体系考量的维度和传统的PC时代不同,今天须要综合考虑用户层面的流量、帧率、内存,用户自己对移动体验的诉求。 

  5. 用户行为自己的变化。服务端传统的服务调用模式是否适用于移动生态,是否适用于用户永远在线的特性。 

  

客户端重构:破然后立

从端的角度出发,咱们结合移动端的特性进行架构特征分 析和思考。咱们考虑架构设计的时候遇到几个挑战。对于这个过程当中咱们的解法是“破然后立”,今天打造超级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群的不断成 熟和壮大,同时也但愿经过手淘开源项目、阿里百川计划等技术结合商业手段的多样化方式,给移动第三方开发者更多的选择,以更快更好的构建本身的应用和用户 体验,实现移动价值。 

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

  

开放合做,反哺生态。

咱们如今在进行中的一些项目,都逐渐在实现开源,欢迎你们在github持续关注阿里开源社区。咱们7月份已经开源了安卓的动态AOP技术,支持动态模块部署和加载,包括热补丁方式的实现和应用,今天在线的故障能够基于这套框架来实现更加
灵活快速的修复。