关于双十二崩盘的一些思考

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

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

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

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

咱们此次的事故是由于比较乐观，可能技术方案评审的时候就开始盲目乐观了。

其实流量增加的速度有多是咱们难以去精确预估的，因此技术架构设计的时候咱们就要提早准备。

对于测试同窗来讲，你们能够简单记住下面一些要点。

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

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

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

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

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

了解架构

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

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

提早作好紧急预案

问题总会有可能发生的，所以提早准备好预案很是重要。

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

不要迷信动态扩容

动态扩容属于亡羊补牢，在问题发生时候的那几秒，扩容每每是没法迅速完成的，所以提早计算好容量才是关键。

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

惭愧，惭愧。