天猫双十一架构优化及应急预案

 每年的双十一，在整体架构上最依仗的是过去几年持续建设的稳定的服务化技术体系和去 IOE 带来整体的扩展性和成本的控制能力。

今年在架构上做的比较大的优化有三点：

第一是导购系统的静态化改造。今年淘宝和天猫都分别根据自身的业务特性进行了 Detail 页面的静态化改造，但核心的思路都是通过 CDN+nginx+JBoss+ 缓存的架构，将页面信息进行静态化缓存。这次的优化突破了现有系统在 Web 服务器和 Java 处理信息的 CPU 瓶颈，将访问最密集的 Detail 集群的性能提升了 10 多倍，极大程度的缓解了突发流量场景下的性能和成本压力。在今年的阿里技术嘉年华上，淘宝 Detail 团队的君山分享了淘宝静态化改造的一些经验。后续我们也可以安排天猫 Detail 团队的同学分享下在不同的业务背景下技术选型的思考。

第二是天猫优惠系统的架构改造，整体上的思路是规则中心化计算本地化。简单来说，将优惠规则的计算推送到所有需要展现价格的上层业务系统进行，而不再集中在后端进行处理。通过这样的方式减少了分布式的调用和计算单点的瓶颈问题。

第三是支付核心路径的异步化。支付环节的系统瓶颈一直在于后端的银行系统吞吐率无法跟上支付宝的处理能力，大量的线程阻塞等待银行系统的返回。今年支付宝的同学们通过一个高可用的队列，异步处理对关键支付路径的调用，这样做的好处一方面让支付系统的处理资源得到了释放，最大化系统处理能力，另一方面也支撑了更加灵活的限流控制。

有了以上的基础，接下来就是对突发情况的应急预案准备了，我们的做法通常有两种：

一是业务降级，即舍弃一些非核心的业务，确保核心业务的系统资源和稳定运行。举个例子，天猫的美妆类目交易流程有个特性，购买部分商家的商品会附赠小样。这部分逻辑是会给核心交易系统增加额外的系统依赖的，如果大促出现紧急情况，我们就会考虑砍掉这部分特殊的逻辑，确保核心交易的稳定。

二是系统限流，关键服务进行限流控制，保护核心集群的系统稳定。

这两点看似简单，却对系统和代码段之间的耦合性要求极高，我们前期也做了大量的工作尽可能将系统之间的强依赖变为弱依赖，避免因为某一系统的性能下降导致反向的雪崩效应。

另一方面，对于限流的阈值评估同样是一个难点，我们首先要从根据历年来的业务变化数据和运营计划估算一个可能达到的交易额以及 UV 数量。然后计算我们可能达到的交易笔数和访问峰值。

其次，分析出每笔交易需要跟多少个系统进行交互，计算出每笔交易会对后端的商品中心, 用户中心，库存中心，优惠，物流等要调用多少次，得出一个支撑一次访问或是一笔交易的合理系统消耗公式。再次，通过线上压测的手段对线上各个集群的极限能力有个准确的认知。

最后再根据业务峰值、系统消耗公式、压测数据，去准备扩容的机器数量和限流的具体阀值。

今年是双十一准备的最为充分的一年，前期的功能测试、容量评估、应急预案都比以往做的更加仔细，一共 700 多个应急预案，从 9 月开始就不断的进行系统演练，确保每个应急预案的准确和便捷执行。所以整的来说，当天各个系统表现还是比较淡定的。

突发事件虽然也有发生，还是做到了冷静处理，所有情况都在掌控之中。 当然，无论是限流还是降级，都是以牺牲用户体验作为代价的，我们内部也在反思和讨论，以后可以把流控做的更加有趣些，让大家买的开心，等的不无聊。