写在前面

大家从事技术开发时日都不会太短。在公司肯定都会遇到之前的系统，由于人员更替，最终维护责任落在你的头上。这样的系统明知道问题重重，却不敢擅自改动(可能会引发更严重的问题)。经常令人头疼不止！

问题现象

当时公司的出口网关带宽告警。于是，紧急联系相关人员处理，发现业务虽然在高峰时期，但并没有达到能把出口网关带宽打满的地步。于是，紧急升级出口带宽成原来 2 倍。虽然当时情况缓和，但过了一会带宽仍然被打满。此问题持续到高峰期结束仍未解决。只能夜里反复测试，仔细查找分析原因。

问题原因

最终确定是系统的架构问题：四层 SLB 转发问题造成的。因为四层 SLB 只负责 IP 和端口的转发，客户端与服务端建立连接后，这个连接的所有流量都同样转发到同一台服务器处理。客户端和服务端建立连接表，后续服务端根据连接表状态响应客户端信息。但连接超时的情况时有发生，在超时重连的过程中，由于服务端所在的虚拟机的系统连接表超时时间比宿主机连接表的超时时间长，导致服务端发给客户端的响应数据在宿主机找不到对应的连接表信息。那么，这段数据包在宿主机就变成主动发送给客户端的数据包，而经过出口网关，导致带宽被占用明显。

解决办法

发现了问题，分析出原因。那么，就要把问题解决。问题就是出在四层 SLB 上，那如果换成七层 SLB 是否可行。四层 SLB 和七层 SLB 的区别：

• SLB，即负载均衡服务，四层 SLB 类似于 LVS；七层 SLB 类似于 Nginx。

• 四层负载是根据 IP+Port；七层负载是基于 URL

• 四层负载只能分析 IP 层的属性；七层负载会记录 URL、浏览器类别、语言等客户端属性更加详尽。

基于以上分析，七层负载较四层负载更适合。可以更换成七层 SLB，但是并不知道当时为什么选择四层 SLB，导致今天事故的发生。

总结

在公司，各种可能的情况都会发生。如果前人能多分析分析，采用七层 SLB，就不会有今天的事故。但是没有这么多如果，只能愿自己能为后面的接盘人少埋一些坑。