手机淘宝构架演化实践

2014年12月19日~20日，ArchSummit北京2014大会顺利举行。“移动互联网，随时随地”是非常火爆的一个专题。阿里无线事业部技术负责人庄卓然（花名南天）任出品人。来自阿里无线事业部的高级专家李敏分享了《手机淘宝架构演化实践》

李敏主要负责淘宝无线客户端和无线网站基础服务、购物主链路的架构、研发方面的工作。从09年开始参与手机淘宝研发团队的组建和线上产品研发，先后负责过无线部门的社区、会员、营销、交易等多条产品线的技术工作，构建和发展了阿里无线技术体系中包括交易链路、百亿级别高性能API网关、WebApp平台等多个重要技术产品，经历和见证了阿里巴巴无线从开始之初到成为日活上亿级别电商应用技术变迁和积累。

本文即根据李敏的演讲整理而成。

发展阶段

从2009年开始，DAU从100万增长到超过1亿，面临的问题、包括研发支撑所需要解决的事情各不相同。在用户量和业务复杂度的线性递增下，架构也进行了相应的演进。如下图所示，具体可以分为四个阶段：

第一阶段，手淘的前身WAP网站，业务初立、变化快，需要快速发布，采取HTML模板和单一应用，最大程度满足快速发布和修改的需要；甚至不需要改动后端的业务代码，在前面的模板上做一些修改就可以了。 第二阶段，DAU的快速增长，WAP/Android/iOS多个平台的业务起来了，需要在多个平台上进行快速的业务复制和业务管控，统一API网关出现。 第三阶段，DAU进一步增长，线上系统越来越多，业务的多样性需求更多的体现出来，基于HTML5的一整套解决方案上线，更多的HTML5和Native混合的业务形态，API网关进行进一步优化和扩展，更方便的接入方式。 第四阶段，当DAU达到100M的时候，全集团的业务都需要在手淘透出，API网关被

部署到更多的IDC机房，如何更有体系化的进行有效的研发、接入更多业务、并进行更有效的业务监控，需要更加体系化的架构治理。

API网关

做WAP的时候没有所谓的API网关，为什么要用API网关呢？

随着应用数量的增多，每个应用分别暴露的API出口很多，修改的话逻辑很复杂，这时候应该引入一个统一的网关。 但随着

DAU的增长，API网关会成为一个单点。开发团队在中间做了很多技术和架构上的努力，主要有几个关键点。一是后端接入很多应用，其实API网关只是通路，理论上不存在调用的上限，只要内存够大，包括网卡的流量够的话都可以上来。二是有必要的机制做到宽阔的调用网关。还有一点，当后端业务要经过API网关时，其实现在业界很多都是典型的RPC的模式，RPC的模式有一个绕不开的问题，就是可能要设定一些东西，这时后端服务跟API会有一定程度上的耦合。现阶段要接入服务，后端服务器随时都会变化，不可能后端服务变化的时候都对API做相应的发布，这是不现实的。所以有一套自己的RPC机制，解除了这种强类型的约束。

此外，可以在网关上附加很多功能，比如安全、审计，还有一些日志、审查等。

到了现在这个阶段，要进行异地部署，很多IDC，这样的话引入API网关很可能会带来问题。包括今年的双11或者是双12，要在多个异地机房支撑手机淘宝的业务，会有很多API网关。

比如说像APP可以在中心网关上面询问，应该去哪个真正的API网关。然后中心API网关会告诉它结果，它再连接到所在地的API网关上，然后再向后端API发起调用，所有API的服务网关都受管控中心统一管控。比如说增加一些新的功能，上线一些新的API，包括一些引流、切换，这些指令都会在管理平台上向各个API网关发送。

手机端

1.Bundle

去年下半年，开发团队对整个手机淘宝的架构做了比较大的调整，如下图所示，左侧是运行时的架构分布，右侧是工程代码级别的分布。在运行的时候，其他的业务团队提供的都是一个个的业务Bundle，这是可部署的单元，包括UI、服务和标准中间件的调用代码，下面有一个总线程，负责管理和开发好统一的UI服务，包括消息服务的总线。再下面是运行容器，

上面跑的的是所有的Bundle的东西，对应运行时的东西，右侧是真正在开发时候的结构。比如说聚划算，它要开发它的业务，

就做一个单独的工程，然后去开发；

它只用开发自己的，开发到差不多的时候，就将其代码打成一个Bundle提供过来，然后一起打包发出去。

2.WebApp

下图是现在手机淘宝上关于HTML5的整体框架图。手机淘宝上的方案大致分为两部分，中间那一部分是手机淘宝自己开发的HTML5的运行容器，它负责在上面跑各种各样的

WebApp，在线上有一个统一发布管理系统，它可能对性能进行检测，包括CDN是否符合规格，HTML本身有没有异常等情况，经过这些必要的检测，包括审查之后，它统一发到CDN上。容器本身其实也会接受运行时的信息，容器接收到这两边的指令之后，它自己会做一些更新配置，也可能会装载运行，从线上系统下发新的WebApp。此外，还可以运行WebApp或者是做URL的导航拦截，甚至做一些交互。

3.PackageApp

这是今年新的建设，整个系统是基于前面整个体系来做的，称之为PackageApp。

这个跟前面最大的区别就是让用户感知不到前面同步下载的过程，大概的做法是：把HTML5以及WebApp在发版之前先做一些预知放到客户端里面，前面会做两件事情，首先按照原来的逻辑运行，其次就是在右侧的蓝图里面，它会去做一些UI的拦截，发现用户点击的icon进去之后，整个URL是符合用户规范的，它会启动检测机制去检查线上是不是有新的版本需要下载，如果有的话会启动异步更新模块，从CDN上拉取新的WebApp版本，否则会走到原来的地方，最后既不影响用户去使用WebApp，又能把自己最新的版本更新到所期望的版本，这由统一的管理平台去发布。

在方案设计之初，还思考了三个方面，首先它是标准的URL，在点击进去之后是导航的URL，对于前端工程师来说，他设计研发WebApp跟客户端或者是线上跟HTML5的网站是一致的。其次，手机淘宝自己的容器，制定了自己的规范，在底层的容器上面可以实现手淘定义的规范。第三，“不同网络、全量、差量更新”，这点很重要，在移动互联网场景下，到底要发起几条链接拉取资源，在WIFI下怎么拉取资源，其实都是不一样的。在不同网络下面，对策都不太一样。

下面是采用PackageApp后业务模块LoadTime对比图：

支撑体系

除了前面介绍的内容，比较大的电商App，还需要一个很完备的支撑体系。如果没有的话，在线上运行的情况是不可感知的。手淘在不同的维度也做了很多支撑的工具。

1.研发支撑

在研发支撑上面，像传统的Reivew代码，特别是做客户端的同学几乎都会做统一的UI库，大家会设计模板，比较典型的，会有所谓的日常预发、线上染色等等。它的集群数量跟能够进来的用户是很有限的，通过这个环境来确认所开发的代码发布到线上可能会有什么问题。一套代码经过预发之后再发布到线上去，最后有一个染色环境，比如说用户打电话反馈遇到的问题，比如说下单下不了或者是搜索无结果，这时会有一个染色集群，把用户定位到染色集群上面，对用户专门进行一些分析，现在还没有做到直接在用户机器上做调试，但是用户到了染色集群上面，整个调用的链路会剥离出来，比较好分析用户到底发生了什么事情。

2.测试支撑

App的测试很重要，除了比较常规的单元功能测试，还有很重要的像稳定性跟性能，以及自动化这些都是很重要的。像手机淘宝差不 …… 此处隐藏：3002字，全部文档内容请下载后查看。喜欢就下载吧 ……