一、景象回顾
在明天ForceBot全链路压测中，有位共事负责的服务做Serverless扩容（负载达到50%之后主动扩容并上线接入流量）中，发现新扩容的机器被击穿，监控如下（关注2:40-3:15时间段的数据），咱们能够看到，超高CPU，频繁FullGC，并且每次FullGC之后对内存并不回收（见FullGC时间段对应的堆内存的曲线，是一条横线）
剖析论断： 内存曾经被解决线程全副占完，FullGC之后根本收不回多少内存，那么意味着很快又会持续FullGC，频繁FullGC占用大量CPU工夫片段和暂停会导致系统解决能力激烈降落，最终导致整个JVM进入解体状态
二、问题重现
如上只是咱们的实践剖析，咱们从新进行景象回放，模仿问题重现，目前订单单机400QPS下，CPU大略是达到30-40%，咱们模仿一下在没有提前预热（重启Java服务）的状况下，应用压测脚本对服务进行申请回放，如下是咱们一次重现的后果 （非必然，会有肯定的概率重现），同样的高CPU、频繁FullGC，对内存无奈被回收，JVM间接进入解体状态
剖析论断： 咱们须要防止霎时流量让服务进入超高负载，进而被击穿
三、解决方案
针对如上状况，咱们尝试应用Sentinel的零碎规定，在零碎负载过高的时候主动进行熔断，防止零碎过载导致被击穿，咱们设置一条CPU不超过80%的零碎爱护规定，如下，通过前面几个过程，咱们比照一下这条规定对咱们零碎的影响
1.冷启动状态下，没有设置零碎爱护规定的场景
在没有配置如上规定的状况下，即使没有被击穿，咱们看到，在冷启动的状态下，零碎大略须要5-7分钟的工夫来让零碎从“准解体状态”中复原回来，如下是CPU监控视图（大略6分钟左右处于高负载的CPU状态下，一旦复原回来，CPU仅在30-40%左右）
压测端在高CPU阶段QPS上不去，仅在50-100之间稳定，CPU复原之后，QPS迅速上涨到400，整个过程Sentinel无熔断产生
2.热启动状态下，没有设置零碎爱护规定：
在热启动状态下，咱们在下面压测完一轮之后再压测一轮，咱们能够看到这个时候零碎就没有一个“预热过程”的“准解体状态”了
3.冷启动状态下，设置零碎爱护规定
咱们再压测一下冷启动状态下设置零碎爱护规定的状况（压测前重新启动一下Java过程，让利用处于“冷启动”的状态），看如下监控图，只有零碎不进入“准解体状态”，那么零碎会很快就复原到失常状态，从上面图上看冷启动下对系统的影响只有前一分钟
如下是压测端视图
如下是CPU的状况
如下是Sentinel熔断状况，有1分钟左右有熔断产生
4.冷启动性能差之谜
冷启动过程性能比较慢，次要是有几方面因素导致：
1）HotSpot JVM优化：热点监测JVM会在程序运行期间一直对代码进行不同级别的优化，高频执行代码会被JIT Compiler优化到最佳的状态，而在冷启动开始运行的时候，代码还处于原始状态，性能绝对会差
2）资源就绪状况：譬如一些线程池在开始运行之后才会被创立，或者程序中有一些连贯是在启动之后才会开始建设
3）解体循环：当CPU升高之后，线程切换等操作自身可能会导致CPU更高，从而让零碎螺旋式进入一种越来越蹩脚的状态，直到达到一个平衡点，而下面的1）和2）随着运行的优化会在达到平衡点之后突破平衡点，螺旋式降落让零碎复原到比拟好的状态，但最蹩脚的状况是达不到平衡点零碎间接解体无奈复原
四、题外话
这个问题不仅仅呈现在Serverless冷扩，如果有一天，你发现申请量暴涨负载过高，于是你扩容了机器，而后你接入了流量，哐当，被打崩了......这个场景是不是太过惨淡了
作者：京东批发 吴毓群
内容起源：京东云开发者社区