在 24 小时之内实现 30 亿美元的销售额，中国的电商巨头阿里巴巴最近做到了这一壮举。天猫和淘宝在处理这种规模的负载时遇到了哪些挑战，又是如何应对这些挑战的呢？InfoQ 有机会就此向天猫和淘宝的架构师庄卓然和优昙请教了一些问题。
天猫是中国领先的 B2C 电子商务网站，而淘宝是中国最大的 C2C 在线购物平台，二者都是阿里巴巴集团的子公司，总共有超过 5 亿的注册用户。双 11 大促活动今年已经是第 4 年，UV 数总计达 1.47 亿，实现总商品价值量（Gross Merchandise Volume）191 亿元人民币（大约 30 亿美元）。
面对“中国规模”电子商务的挑战：
在 2012 年 11 月 11 日双 11 大促当天，天猫和淘宝迎接了 1.47 亿的用户访问，3000 万人的购买，产生了近 1 亿笔支付订单。在零点的一瞬间，并发在线的用户数超过了 1000 万。除了满足双 11 的各种功能需求之外，如何在前期准备过程中对系统有一个完整准确的评估，如何有效推进各种优化和容灾预案，如何在活动当天各种紧急情况下正确决策，以及如何保证在顶级流量的冲击下整个网站的稳定、性能和用户体验，这是对技术团队的极大考验。
双 11 当天，天猫交易系统的峰值发生在第 1 个小时，当时系统每秒成功处理了 1.3 万的下单请求。系统峰值 QPS（每秒查询数）为 4 万 / 秒，系统的平均响应时间在 200 毫秒。天猫的商品详情页面当天的系统访问数高达 16 亿次，峰值吞吐率达到了 6.9 万次访问 / 秒，并且在峰值时还保持了 12 毫秒的高响应能力。天猫搜索双 11 当天 PV 高达 5.9 亿，峰值吞吐率达到了 1.4 万次访问 / 秒。
庄卓然解释到，从应用层面上讲，天猫和淘宝的应用都构建于自主研发的服务化架构以及 MVC 框架和 Spring 之上。这是由分布式文件系统、分布式缓存、消息中间件和 CDN 网络带宽支持的。核心数据库可以通过自主研发的数据访问中间件访问，底层数据库的水平拆分和数据搬运对应用是完全透明的。
基于这种水平扩容架构，面对促销活动引起的流量压力，天猫和淘宝的系统可以灵活地添加机器来应对。
前期我们花了很多时间进行容量计算，对于网站所有应用之间的依赖关系、流量分配比例和应用内部的调用链路做了深入的分析，通过在线的压力测试对各个应用单机的 QPS 进行准确评估，从而达到对网站目前集群处理能力的客观判断。这个过程操作起来实际上是非常有挑战的，因为天猫和淘宝本质上不是一个耦合性很弱的系统，通过单一系统的压测不能很好地反映系统的瓶颈。同时，我们也不可能完全照搬线上的环境和配置一套完整的压力测试环境。所以会更多地依赖线上的压力测试，真实地反映系统的短板。
最后，则是根据网站的自然增长趋势和双 11 的历史数据，评估当天有可能达到的业务指标，再从这些业务指标对各个系统扩容目标进行准确地计算。
当然，仅仅依靠水平扩容方式，对于大促高峰过后的机器利用率是存在弊端的，同时也会大量依赖运维人员的灵活调配能力。因此，今年我们在以聚石塔（ http://cloud.tmall.com ）为代表的一些应用中也尝试了大量的弹性计算框架，在塔中很多商家的不同应用共用一个集群的系统资源。双 11 当天弹性升级带宽、VM 和存储资源。同时，我们的很多内部应用也采用了这样的机制。这也是今年在双 11 准备过程中我们在技术上的一个突破。
在双 11 大促的准备过程中，淘宝和天猫的团队对系统进行了针对性的优化，包括 SQL 和缓存命中率的优化、数据库连接和应用服务器参数的调整、JVM 参数的配置、代码的复审和梳理等等。此外，大量固态硬盘（SSD）的使用也提高了数据库存储的整体性能。
为了在负载超过预期时关闭非核心操作，团队也准备了业务降级和限流预案。
所谓业务降级，就是牺牲非核心的业务功能，保证核心功能的稳定运行。简单来说，要实现优雅的业务降级，需要将功能实现拆分到相对独立的不同代码单元，分优先级进行隔离。在后台通过开关控制，降级部分非主流程的业务功能，减轻系统依赖和性能损耗，从而提升集群的整体吞吐率。
当出现了降级还无法缓解的大流量时，就要通过限流的方式来应付。首先从最前端的 Web 应用进行排队，控制流入应用的流量，也就是通过 Web 服务器的定制模块来实现 QPS 限流功能。根据被保护的 Web 服务器所能承受的最大压力做强制的 QPS 流控，超出 QPS 上限的用户进入排队等待页面。另外，为了避免前端某个 Web 应用出现大规模流量激增时造成后端服务无法承载的雪崩效应，后端的服务会针对低优先级的业务进行限流，以确保不同来源的业务压力不会压垮后端服务，保障核心业务的访问。
针对 2012 年的双 11，天猫和淘宝总共准备了 400 多个系统降级预案。 为了保证所有降级和限流预案的准确执行，我们在前期做过了大量的预案演习，所有的应急预案虽然原则上我们一个都不希望使用，但是必须确保每个预案执行的准确性和便捷性。
应急决策过程：
双 11 当天，我们有近 400 多位工程师集中办公，确保整个活动的顺利进行。整体流程上我们的目标是希望实现决策的最短路径，并且保证信息传达的简单有效。那么怎么实现呢？首先我们会有一个战地情报分拣中心，负责从客服、运营、安全、产品和商家等不同的信息来源收集和汇总各种用户反馈，剔除重复和无效的反馈，确保不会出现技术团队的信息爆炸。
其次，虽然我们会有一个战地指挥部，但是应急决策的决定权大多数还是交由一线开发工程师的。所有集中办公的工程师分工明确，每个应用都有 1-2 个核心负责人，他们会根据监控中心的各种系统指标变化情况，快速做出应急决策，确保响应的及时性。只有当涉及到对业务影响较大或是对用户体验伤害较大的时候，才会升级到指挥部来进行判断。
淘宝和天猫也有一个有效的开源策略，大量代码都在 http://code.taobao.org 开源了。包括远程通信框架 HSF、消息中间件 Notify 和数据访问中间件 TDDL 在内的一些框架已经开源。
评论