Netty HTTPS服务端高并发宕机案例

读李林峰《netty进阶指南》于第18章有感。特此记录一下问题的现象，以及他是如何排障的，以此加深理解

事件梳理

某系统内部两个模块之间采用 HTTPS 通信。

某天：

1. 客户端某时间吞吐量为0，发送给服务端的消息失败
2. 服务端OOM

排查

1. 查看流量，并没有明显的流量变化，排除突发流量高峰导致系统过载。
2. 客户端存在大量超时以及关闭连接的日志。
3. 服务端日志发现，后台某个逻辑超时，超过了客户端的超时时间，所以这是客户端超时的原因。
4. 此时dump内存，发现服务端的NioSocketChannel占用排名第一。这是服务端OOM的原因
5. 停止压测，发现一切逐渐正常：客户端没有超时连接、服务端内存也正常。

事后分析

客户端与服务端通信架构图。客户端采用 HTTP 连接池的方式与服务端进行 RPC 调用，单个客户端连接池上限为200，客户端部署了30个实例，而服务端只部署了3个实例。

此问题出现原因是使用了HTTP1通信，高并发时，服务端瞬间涌入大量的HTTPS连接，
同时进行SSL握手，服务端处于高负载所以导致部分连接失败超时。客户端发起的重连、服务端GC受限无法及时关闭超时连接，又进一步加重服务器压力。

如何解决

功能层面：

1. 服务端可以做流控（比如窗口限流等）、动态扩容、换为Open SSL