每年的双十一，在整体架构上最依仗的是过去几年持续建设的稳定的服务化技术体系和去IOE带来整体的扩展性和成本的控制能力。
今年在架构上做的比较大的优化有三点：
有了以上的基础，接下来就是对突发情况的应急预案准备了，我们的做法通常有两种：
一是业务降级，即舍弃一些非核心的业务，确保核心业务的系统资源和稳定运行。举个例子，天猫的美妆类目交易流程有个特性，购买部分商家的商品会附赠小样。这部分逻辑是会给核心交易系统增加额外的系统依赖的，如果大促出现紧急情况，我们就会考虑砍掉这部分特殊的逻辑，确保核心交易的稳定。
二是系统限流，关键服务进行限流控制，保护核心集群的系统稳定。
这两点看似简单，却对系统和代码段之间的耦合性要求极高，我们前期也做了大量的工作尽可能将系统之间的强依赖变为弱依赖，避免因为某一系统的性能下降导致反向的雪崩效应。
另一方面，对于限流的阈值评估同样是一个难点，我们首先要从根据历年来的业务变化数据和运营计划估算一个可能达到的交易额以及UV数量。然后计算我们可能达到的交易笔数和访问峰值。
其次，分析出每笔交易需要跟多少个系统进行交互，计算出每笔交易会对后端的商品中心,用户中心，库存中心，优惠，物流等要调用多少次，得出一个支撑一次访问或是一笔交易的合理系统消耗公式。再次，通过线上压测的手段对线上各个集群的极限能力有个准确的认知。
最后再根据业务峰值、系统消耗公式、压测数据，去准备扩容的机器数量和限流的具体阀值。
今年是双十一准备的最为充分的一年，前期的功能测试、容量评估、应急预案都比以往做的更加仔细，一共400多个应急预案，从9月开始就不断的进行系统演练，确保每个应急预案的准确和便捷执行。所以整的来说，当天各个系统表现还是比较淡定的。
突发事件虽然也有发生，还是做到了冷静处理，所有情况都在掌控之中。 当然，无论是限流还是降级，都是以牺牲用户体验作为代价的，我们内部也在反思和讨论，以后可以把流控做的更加有趣些，让大家买的开心，等的不无聊。