双十二的时候我们的一个重要业务崩盘了。

原因其实很简单，就一句话，流量太大导致某个中间件接入层的HA proxy满载，中间件不可用，整个业务基本瘫痪。

从测试的角度去总结一下，大概以后可以有如下的改进。

技术方案评审时就考虑高并发问题

我们这次的事故是因为比较乐观，可能技术方案评审的时候就开始盲目乐观了。

其实流量增长的速度有可能是我们难以去精确预估的，所以技术架构设计的时候我们就要提前准备。

对于测试同学来说，大家可以简单记住下面一些要点。

• 降级。在大流量的情况下，是否能通过一些机制让服务降级，从而保护整个系统的稳定性。举个例子，可能一般情况下，用户购买商品下一个订单就可以马上看到订单的详情，但是在秒杀场景中，用户可能在下单很长时间之后才能看到订单，这就是一种服务降级的表现。

• 削峰。把流量的高峰削平，不让突如其来的大流量对系统产生破坏性的影响。举个例子，12306抢票的时间点是分散的，大概每个小时抢一次，这就防止了一次性放出所有票导致所有用户同时抢票带来的流量高峰，这是一种业务上的削峰。

• 限流。这个很好理解。一些第三方api会限制每分钟调用的次数就是这个道理。

• 熔断。高并发时,如果一些api无法访问后，能不能自动不去访问这些有故障的api，从而保证主流程的顺畅和稳定。

• 故障摘除。一些容器如果被击垮，能不能动态去摘除这些节点，从而保证整个系统可用。

了解架构

事故之前，我们其实对整个架构能支撑的容量做了计算，结论是在当前架构下是可以撑住双12的峰值的。但是千算万算却没想到中间件在接入层之前有HA做负载均衡。这个ha实际上是单点，容量有限，如果提前了解该架构，并且进行扩容的话，事故大概也不会发生。

测试同学在看架构的时候可以先无脑关注单点问题。某个服务或中间件是不是单点？如果是，那么单点挂掉之后对整个系统可用性会不会造成影响？搞清楚这个问题的答案对系统高可用非常关键。

提前做好紧急预案

问题总会有可能发生的，因此提前准备好预案非常重要。

这次事故发生之前，我们并没有准备应急预案，因此，当临时发现了无法动态扩容的HA单点时，我们基本上只能眼睁睁的看着系统挂掉，什么事情都做不了。

不要迷信动态扩容

动态扩容属于亡羊补牢，在问题发生时候的那几秒，扩容往往是无法迅速完成的，因此提前计算好容量才是关键。

最后，下次的活动是在明年的双十一，嗯，这个锅要背一年了。

惭愧，惭愧。