Serverless冷扩机器在压测中被击穿问题

在今天ForceBot全链路压测中，有位同事负责的服务做Serverless扩容（负载达到50%之后自动扩容并上线接入流量）中，发现新扩容的机器被击穿，监控如下（关注2:40-3:15时间段的数据），我们可以看到，超高CPU，频繁FullGC，并且每次FullGC之后对内存并不回收（见FullGC时间段对应的堆内存的曲线，是一条横线）。

分析结论：内存已经被处理线程全部占完，FullGC之后基本收不回多少内存，那么意味着很快又会继续FullGC，频繁FullGC占用大量CPU时间片段和暂停会导致系统处理能力剧烈下降，最终导致整个JVM进入崩溃状态。

分析结论：我们需要避免瞬间流量让服务进入超高负载，进而被击穿。

针对如上情况，我们尝试使用Sentinel的系统规则，在系统负载过高的时候自动进行熔断，避免系统过载导致被击穿，我们设置一条CPU不超过80%的系统保护规则，如下，通过后面几个过程，我们对比一下这条规则对我们系统的影响。

在没有配置如上规则的情况下，即便没有被击穿，我们看到，在冷启动的状态下，系统大概需要5-7分钟的时间来让系统从“准崩溃状态”中恢复回来，如下是CPU监控视图（大概6分钟左右处于高负载的CPU状态下，一旦恢复回来，CPU仅在30-40%左右）。

压测端在高CPU阶段QPS上不去，仅在50-100之间波动，CPU恢复之后，QPS迅速上涨到400，整个过程Sentinel无熔断发生。

在热启动状态下，我们在上面压测完一轮之后再压测一轮，我们可以看到这个时候系统就没有一个“预热过程”的“准崩溃状态”了。

如下是压测端视图

如下是CPU的情况

如下是Sentinel熔断情况，有1分钟左右有熔断发生。

3）崩溃循环：当系统响应突然变慢之后-->意味着同样的吞吐量需要有更多的活跃线程-->意味着更多的活跃对象也同时意味着GC（不管是YGC还是FGC）发生的时候，一次回收的内存变少-->也意味着更多的CPU时间片被分配给了GC进一步导致CPU升高（叠加更多线程导致的线程切换）-->也意味系统响应进一步变慢，于是系统进入一个越来越糟的状态；同时另一方面，随着系统的运行，未初始化的资源初始化完毕，JVM代码逐步被JIT Compiler优化，这是让系统越来越好的积极因素；两股力量达到一个平衡点，系统进入一种准崩溃的状态，直到其中一股力量将局势逆转——系统崩溃或系统恢复。