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

Tech 导读 机器扩容后瞬间被高流量击穿，背后发生了什么？本文从实际案例入手，探讨在冷启动的场景下如何保护系统不被瞬间流量压垮。

01

现象回顾

在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了！

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

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

图1.监控示意

02

问题重现

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。

如上只是理论分析，重新进行现象回放，模拟问题重现，目前订单单机400QPS下，CPU大概是达到30-40%，模拟一下在没有提前预热（重启Java服务）的情况下，使用压测脚本对服务进行请求回放，如下是一次重现的结果 （非必定，会有一定的概率重现），同样的高CPU、频繁FullGC，对内存无法被回收，JVM直接进入崩溃状态。

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

图2.一次重现结果示意

03

解决方案

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。

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

图3.设置一条CPU不超过80%的系统保护规则

3.1 冷启动状态下，没有设置系统保护规则的场景

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

图4.CPU监控视图示意

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

图5.监控示意

3.2 热启动状态下，没有设置系统保护规则

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

图6.监控示意

3.3 冷启动状态下，设置系统保护规则

再压测一下冷启动状态下设置系统保护规则的情况（压测前重新启动一下Java进程，让应用处于“冷启动”的状态），看如下监控图，只要系统不进入“准崩溃状态”，那么系统会很快就恢复到正常状态，从下面图上看冷启动下对系统的影响只有前一分钟。

如下是压测端视图：

图7.压测端视图

如下是CPU的情况：

图8.CPU情况示意

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

图9.Sentinel熔断情况示意

3.4 冷启动性能差之谜

冷启动过程性能比较慢，主要是有几方面因素导致：

1）HotSpot JVM优化：热点监测JVM会在程序运行期间不断对代码进行不同级别的优化，高频执行代码会被JIT Compiler优化到最佳的状态，而在冷启动开始运行的时候，代码还处于原始状态，性能相对会差

2）资源就绪情况：譬如一些线程池在开始运行之后才会被创建，Sentinel只有初次被访问之后才会开始初始化，或者程序中有一些连接是在启动之后才会开始建立

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

04

题外话

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。

这个问题不仅仅出现在Serverless冷扩，如果有一天，你发现请求量暴涨负载过高，于是你扩容了机器，然后你接入了流量，哐当，被打崩了......这个场景是不是太过惨淡了🤣。

打造SAAS化服务的会员徽章体系，可以作为标准的产品化方案统一对外输出。结合现有平台的通用能力，实现会员行为全路径覆盖，并能结合企业自身业务特点，规划相应的会员精准营销活动，提升会员忠诚度和业务的持续增长。

▪

底层能力：维护用户基础数据、行为数据建模、用户画像分析、精准营销策略的制定

▪功能支撑：会员成长体系、等级计算策略、权益体系、营销底层能力支持

▪用户活跃：会员关怀、用户触达、活跃活动、业务线交叉获客、拉新促活