原文发布于:https://mp.weixin.qq.com/s/LJMi_2svfiTHyuKRZ9YH9g

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

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

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

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

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

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

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

了解架构

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

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

提前做好紧急预案

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

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

不要迷信动态扩容

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

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

惭愧,惭愧。


↙↙↙阅读原文可查看相关链接,并与作者交流