每年双十一，对于买家来说是一年一度的购物狂欢，可是对于电商公司的技术人员来说，却是一年一次的大考。如何用更少的预算完成指定当前业务规模的流量高峰，是技术的永恒主题。
有赞在双十一之前完成了全链路压测方案，并把它用于大促的扩容和容量验证，取得了不错的成果。
在电商公司待过的技术同学都知道，在大促来临时，整个集群的最高峰压力将是正常时间的几十倍，最高峰持续的时间会特别短，然后回落到正常水平的几倍。所以，我们可能会自然而然地想到，把整个集群扩容几十倍的机器，在双十一当天应对几十倍的流量，然后第二天减至正常量，就可以完成大促的考验。事实情况是否真的这么简单？
大促保障的困难
用户购买商品的链路是一条很长很复杂的系统集群，中间会涉及到店铺、商品、会员、营销、交易、支付等 6 大核心模块，每个模块又会涉及到多个不同的服务化系统单元，我们把这一条骨干的链路就叫做核心链路。
大家都知道，双十一当天，真正爆增的其实是买家的购买量，像开店 / 商品上架等功能，其实并发量没什么变化。也就是说，真正的压力其实是在核心链路上面，如果把所有的系统都扩容几十倍，本身就是一个很大的浪费。正常来说，一个稍有规模的电商公司，日常有几千台机器维持正常的运转，本身就是一个较大的开销，如果突增几十倍的系统开销，对于公司的财务也是很大的压力。所以，一个较理想的方法，是只把核心链路的系统扩大几十倍的系统吞吐量，就可以达到目标。
困难一
大型的分布式系统其实错综复杂，公司需要维持成百上千的服务化系统。理论上来说， 只有少部分系统是核心链路的系统。但是在实际情况下，因为公司人员的关系，可能会把某些非核心系统，不知不觉加入到了核心链路中。所以，第一件要做的事情，就是把非核心系统从核心链路上剔除。
困难二
一般公司都会在线下搭建性能测试环境，在该环境下，我们的测试同学可 以借助一些测试工具，去压单机单接口的性能。假如，店铺的首页面，我们在性能测试环境下，得出单机单接口的 QPS 峰值是 500，这是否意味着， 要达到 10w 的 QPS，我只需要设置 200 台机器就可以了呢？答案当然是否定的。因为任何的页面接口都不是单独存在的，都会受到公共资源的制约，如：DB、Redis、MQ、网络带宽等。比如当店铺首页达到 10w QPS 的时候，商品详情页可能要达到 8w 的 QPS 了，也会消耗公共资源。当公共资源的能力下降时，势必会影响所有的系统。所以，通过单机性能算出来的理论值，跟实际情况会相差很远。
困难三
正常来说，任何大促都会有业务目标，这个目标一般是拿 GMV 进行评估。但是我们在进行系统容量评估的时候，一般会想扩大多少台机器。那么 GMV 跟核心链路各个系统之间的机器数量的转化关系是什么样的？
困难四
做过大型分布式系统的同学，可能都知道一个事实，即整个集群的性能其实取决于接口的短板效应。而这个短板的接口，在正常的流量下，是不会显现出来的。只有集群的整体压力达到一定值的情况下，才会偶尔显现， 然后造成雪崩效应，拖累整个系统集群。所以，如何在大促之前找到这些短板，然后把它们一个一个优化，这件事情就显得非常重要。
困难五
应用系统的扩容相对而言是比较简单的，完成大促之后，可以很容易归还。但是 DB 等核心资源的扩容其实并不容易，而且资源不可能归还（数据不不可丢失）。
事实是检验真理理的唯⼀一标准，上面提到的五个困难，其实都可以用线上真实压测的办法去检验。业内大型电商公司，会用全链路压测的方案去指导扩容的进程，有赞也不例外。今年双十一，有赞用该方案完成了对核心链路 20 倍的扩容，但是整个集群的规模只是扩大了了一倍多一点。
全链路压测的目标是让双十一要发生的事情提前发生，并验证在该情况下系统表现良好。做线上压测，有一个很重要的原则：线上系统是不允许有脏数据的。
有赞的压测设计方案，可以用几句简单的话做概括：
压测流量落影子库，正常流量落正常库。
压测不能把系统压崩溃。
压测是模拟双十一流量最高峰时用户的购物行为，所以综合性的流量模型需要跟实际情况相符。