后端java spring boot 及cloud全家桶，整合stomp协议的websocket。具体如何整合不是此文章的重点，先不详细描述。此组合在web端使用sockjs的websocket测试过程中没有问题，当整合uniapp时，uniapp不支持sockjs，使用的是uniapp封装的websocket对应的js，会出现断开后无法重新连接，只有uniapp,stomp,gateway三者同时存在的时候测试过程中一定会出现无法重新连接的情况，后来经过阅读uniapp的源码发现，只是因为gateway的响应速度问题导致问题暴露，逻辑上本身就有问题。接下来是bug寻找之旅。

一、发现bug

测试手机时无法接收到websocket返回信息，开始只是添加了重新连接逻辑。改过之后有时能够重连成功，有时不能。初步判断重新连接需要一定时间。然后增加了重新连接时间。由前端在重新连接前暂停1秒，重新连接失败后进入回调再暂停2秒，每次连续失败逐步增加间隔时间。

二、定位到真正的bug出现情况

经过上面的调整成功率提升了，但是又发现了两点情况，

1.就是在公司网络使用的人多的时候失败概率显著提升，网络好的时候失败概率下降

2.在重新连接失败一次之后，就一定会永远重新连接不上了，只能杀掉进程重新初始化所有实例后才能正常连接

再发现了第一点之后，利用手动测试发现，连续点击主动断开再连接。或者连续快速点击连接和断开一定会出现连接失败，然后再继续出现第二点。

开始以为是心跳发送的问题，也更改的心跳发送间隔，后端也设置了心跳发送的间隔，结果还是没有任何影响

最后通过测试和观察发现，如下图，一个正常的websocket连接请求，一定会一个上行的connect请求，后续才会正常发送心跳。但是所有的连接失败的连接请求并没有发送connect 消息下图会是一片空白，而后端debug上

在spring message的消息解析的在失败连接请求上没有进入任何消息 直接上源码

抽象类 AbstractBrokerMessageHandler  为入口类，启动装配的时候取决于配置的 本地 simple还是 外部服务例如

如上图第一个 子类为本地方式，(其实如果使用了 外部的消息服务例如 rabbitMQ等应该是可以直接连MQ来解决集群问题，我没有试过)这里使用的方式是本地模式用gate way  + ribbon的方式搭建集群 ，具体集群的逻辑下一篇文章再说

如上图后端接收消息处的源码，每次连接时会有一个预连接，会进入这里，但是不会携带任何消息体，只会记录session的信息，到这时一切都正常。后续应该会再发一个connect消息这里才会真正的建立连接 如下图前端发送情况

而在 网络不好，或者测试们疯狂测试的时候，不去发送这个connect消息的 概率大大提升。撸了很多很多 后端源码，发现就是没有connect消息进来。所以第一次预连接的session也会失效。而前端疯狂的 重试，也么有用，后来发现，前端所有失败的连接都是没有发送connect消息。

只能撸撸前端源码了。。。

经过之前的经验发现，在连续点击连接 -> 断开， 速度很快立刻就能复现前端的错误，然后待错误时进入 debug找 哪里出了问题，，，

经过很久的debug 定位到这里，到这里拿到了 要请求的url，但是没有立马去请求后端，uni做了啥呢，他将当前拿到的url封装成了一个对象，放入一个数组里，就是这里的f 封装的 d对象作为一个 异步执行的task包含了当前websocket请求的状态，地址，等等。其实所有的请求都是放在这里，前端要触发断开，连接，等等事件需要从f  数组里拿到task后请求后端。

到这里一切正常，进入 后续的回调函数里。。。

bug 就出现在这里，这里的逻辑是 进入回调的 c 对象，即websocket的 task对象，用来和上边 push到数组的对象进行比较，是否是同一个再决定是否进行下一步请求。 也就是 u函数 。。。。

那么每次都是取数组的第一个，这也就解释了为什么 网络好的时候，或者我们自己模拟时每个操作间隔长的时候，都不会进行发送connect消息，之前也试了 去掉  gateway 直连，基本也能成功，也试了去掉 stomp协议 加上gateway (stomp协议要求必须发送第二次的connect消息才能建立连接)也没有复现失败的情况，因为stomp的二段连接，加上gateway 使用了 spring reactor 基于netty的异步网关，导致这个数组在快速出现多次操作时一定会出现多个对象，那么我第一次请求断开，gateway还没有给我返回消息或者uni没来得及处理的时候，这里发送连接请求，到上图的代码处，却是拿到上一次断开连接的task，永远不会进入u函数 发送connect消息！！！ 啊

着手改一下吧。。。

加了两段逻辑，大概就是 取最新的task来比较决定是否进入 u 函数，并且每次发现有多个task时 将以前的task作为过期的task删掉，经过debug发现，uni都是取下标0操作，所以就算前端删掉了，后端有 过期逻辑，是设置的心跳时间的3倍时间没有交互心跳则会清理掉session

上图为清理session逻辑，所以前端维护最新的一个 task即可。

试了试Ok了，但是 这个源码是uni的 h5端的，安卓和iost的理不清源码逻辑了。。。又不能debug，只能前端在外部控制了，同一时间点只能有一个 和后端交互的websocket请求解决此问题。。