共计 1504 个字符，预计需要花费 4 分钟才能阅读完成。
一、景象回顾
在明天 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 冷扩，如果有一天，你发现申请量暴涨负载过高，于是你扩容了机器，而后你接入了流量，哐当，被打崩了 …… 这个场景是不是太过惨淡了
作者：京东批发 吴毓群
内容起源：京东云开发者社区