服务端网关请求性能波动

平台基于Netty构建了高性能的API网关，支持HTTP、Restful、TCP等的接入和消息路由。当性能压测到4000 QPS一段时间后，发现性能急剧下降，最低时到0，停止压测一段时间，系统恢复，再压测一段时间，用户并发量大了之后，性能又急剧下降，形成周期性波动，吞吐量非常不稳定。

【服务端代码】

压测一段时间之后，发现内存和CPU占用飙升，同时QPS下降，客户端停止压测一段时间，CPU占用降低，内存占用恢复正常，

在压测过程中，当吞吐量下降、CPU占用飙升时，采集线程堆栈，发现GC线程占用大量 CPU资源，堆栈如图6-3所示（需要采集线程CPU占用相关数据，此处省略)。

通过监控数据分析，发现性能波动与内存占用情况强相关，当内存占用比较高时，GC线程忙于内存回收，抢占大量CPU资源，而且在GC过程中也会导致应用线程暂停（不同的GC收集器，暂停策略不同)，最终造成吞吐量急剧下降。但是当停止压测或者并发请求量降低之后，服务端还可以恢复，说明并不存在真正的内存忘记释放导致的泄漏问题。

问题分析：

结合代码分析发现，API网关每次收到请求消息，无论请求消息大还是小，哪怕只有100字节，都会构造一个默认为64KB的char数组，用于处理和转发请求消息。如果后端转发消息较慢，就会导致任务队列积压，由于每个任务（Runnable，此处为Lambda表达式)持有一个64KB的char数组，所以积压多了就会转移到老年代，一旦触发老年代GC，耗时太长系统吞吐量就变为0了。

优化后的代码：

【网关类产品的优化建议】

网关类产品的主要功能就是消息的预处理和转发，请求和响应对象都是“朝生夕灭”类型的，在高并发场景下，一定要防止不合理的内存申请，具体措施如下。

(1） 内存按需分配。不要一次性申请较大的内存来保存较小的消息，造成内存空间浪费，引发频繁GC问题。

(2） 不要频繁地创建和释放对象。这会增加GC的负担，降低系统的吞吐量，可以采用内存池等机制优化内存的申请和释放。

(3) 减少对象拷贝。对于透传类的消息,尽量把涉及业务逻辑处理的字段放入Header，不要对Body做解码，直接透传到后端服务即可。这样可以大幅减少内存的申请和对象拷贝，降低内存占用，提升性能。

(4） 流控机制必不可少。除了客户端并发连接数流控、QPS流控，还需要针对内存占用等指标做流控，防止业务高峰期的OOM。