记录一次websocket长连接导致的业务生产故障

websocket背景

因为服务器是单机的，所以从开始做开始我建议是采用长轮询来减少长连接对业务服务器的连接数，避免影响网络资源的占用和业务接口的影响，但是因为某些原因还是采用了实时性较高的Websocket。
并且支持多端，不同的端采用随机数 + 用户id作为一个新的socket的key，同时一个终端一个tab就是一个新的连接，意味着一个网页可以打开N个socket保持连接。

问题故障现场

业务反应，pc和用户app都无法使用，但是我们小组进行生产环境测试时发现能够正常使用。
等等，突然发现大量接口无法请求，单个请求没问题，但是当大批量请求同时触发时会有部分接口无法请求，接口状态码是502和504。

故障排查

起初因为之前遇到过502，原因是因为服务是容器化部署，内部的net网络是容器内的虚拟网卡分配的ip，所以如果不是自定义net网组并且同一时刻多个容器同时重新部署会导致ip产生变化。

但是现在的情况是部分接口可以，部分接口不行，显然不是因为ip变化导致的问题。

于是想到在功能实现时担心到的网络连接数的问题，服务器显然能够支撑的住，开始怀疑项目的tomcat问题。
但是tomcat项目之间的部署都是独立的，如果A项目产生问题显然不应该对B项目造成连接的影响，于是也放弃这个想法，开始想两个项目共享资源的模块有哪些。

真相只有一个：Nginx 网络连接数，默认1024个，大量的tab打开导致占用了60%的网络连接数，剩下的日活用户再进行http请求无疑就会产生争夺不到资源导致无法访问的情况，此时心中已经有了答案，开始查证。直接定位nginx日志信息。

临阵处理

让前端同学关闭ws的连接代码之后进行发布，重启容器让PC后端一些网络连接立刻中断减少对APP用户的使用影响。随后完成之后，连接数和项目逐步自动清空连接恢复正常使用。

解决方案

确定问题之后开始着手想解决思路。

产生原因的问题：网络连接数nginx不够、消息通知对业务产生了影响下手，有以下几个解决方案：

1. 直接增加Nginx 的网络连接数 1024 到服务器与业务兼并的数量。但是该方案无法彻底解决问题，只能止渴。
2. 增加一台服务器脱离实际业务资源，独立部署消息通知等处理，业务消息下推到该服务器，由该服务器负责维护所有的连接进行消息推送等，这样资源足够同时不影响业务服务。但是该方案需要增加服务器，以目前的日活实在无法解决再考虑。
3. 由长连接改造为长轮询，可以解决连接问题。但是该方案无法做到近实时的收到消息同时因为起初设计的流程和通知相关的架构上下文是采用的主动推送的形式，而不支持主动拉取，所以需要改造架构影响有些大。
4. 前端尝试独立一个线程登陆之后监听一个Websocket，让Tab之间socket共享，当得到消息所有Tab都可以进行触发推送消息。

websocket和nginx之间的问题

还有一个额外的问题，如果websocket经过Nginx来建立长连接，那么在默认情况下会产生60s没有通讯产生，进行自动断连。
如果前端做了断连自动重试，那么会产生很多连接请求。
有两种解决方案

1. Nginx 配置超时为业务需要的时长。
2. 前端同学设置小于 Nginx 超时时长进行一次心跳消息包。