问题：mq推送正常，监听正常，但页面不显示推送信息。浏览器报错如下
原因：stomjs请求websocket获取信息时，websocket协议404访问不通，便使用其他协议，且报了500，解决方法二选一，1解决ws协议404问题，2解决其他协议500问题.ws协议404访问不通，定位到，因为tomcat用的是7，项目中用的websocket相关jar包冲突，导致访问ws协议不通。经过权衡，升级了tomcat到8，问题解决。
资料：
解决过程：
公司部分服务接入用户中心项目后，修改了配置，出现各种问题，其中未接入的服务也受影响了，比如web项目mq推送的信息页面显示不出来，但其他服务推送和web监听都是正常的。
可以推出是websocket页面到后端出问题了，且打开浏览器的控制台，确实在报错，404和500，但测试环境正常，又因这块最近未上过代码，所以怀疑是配置的问题，但其他人坚信web项目未接入新项目，不应该会受接入新项目的影响。
只能自己逐个百度，websocket报错404，查到原因可能有2个，1ngix不允许websocket协议；2tomat自带websocket jar包与项目中websocket 相关jar包冲突。
测试环境和线上都是一样的代码，不一样的最可能的是ngix配置不一样，虽然原先是可以的，但是不能排除运维偷偷改东西了，让运维查看了配置，大致看了一下，允许websocket协议这块是对的，虽然发现了各台服务的ngix配置未统一这么一个小问题。
对ngix配置也不大懂，就没有深究，想先从jar包冲突下手，在排查过程中，意外发现线上项目中用的websocket相关jar包是tomcat8的，而线上的tomcat是7，且这些jar是接入新项目后产生的，而且是依赖进来的。测试环境正常，本地正常，而我们用的都是tomcat8，真相似乎就要出来了，为了验证猜想，把本地tomcat版本降到线上一致，确实复现了websocket404的问题，但不报500，也不影响显示，这就奇怪了，但通过查资料，知道了前端websocket插件的请求原理，跟请求协议有关，如果websocket协议不通或者超时，那就使用其他协议，发现确实是websocket协议404，其他的协议500.由于直接删jar冲突jar包影响不明，jar包降版本不符合发展趋势且新接入的项目都是比较新的版本，而冲突jar是新项目带进来的，比较保守的是tomcat升级但动作比较大，所以尝试，延长websocket请求超时时间，并常规解决其他协议500中报的错，暂时让websocket可用，以后再升tomcat版本。测试环境复现了500问题并解决了，于是上线，未起作用。
经过商讨，决定把计划提前，让线上tomcat升8，线上、测试保持一致，也符合发展趋势。
升级完成，推送显示正常，由于运维给力，升级神速，且平稳过渡。
回顾解决问题的过程，总结如下：
1 当时悬案"延长websocket请求超时时间，并常规解决其他协议500中报的错，测试环境解决问题，上线却无用，tomcat升8正常”,由于当时情况紧急控制变量没做好，一下改了2个，测试环境解决问题的是"延迟websocket请求超时时间”这个改动，用的还是ws协议，其他协议500问题其实没有验证过，泪。而线上不起作用，是因为jar冲突ws协议访问不通，延迟超时时间也没有。以后排查问题，要注意控制变量。
2 线上和测试环境配置、线上各服务间的配置尽量保持一致，减少差错。
3 部分推送也是我做的，虽然架构和技术选型不是我，但接触新的东西的时候，即使再忙，做完东西后，也要挤出时间更深入了解一下，尽量知其然而知其所以然，这样可以在出现问题时减少排查问题的时间，如果先去就知道stomjs请求使用协议的规则，看到ws协议404，其他协议500的问题，不用百度就知道线上是因为ws协议404访问不通，才使用其他协议，且报了500。解决问题方向就缩小了，要不然解决ws协议404问题，要不然解决其他协议500问题。
4 运维升级神速且过渡平缓的原因：先用tomcat8部署项目，让测试修改host，指定访问服务器进行测试，测试通过后，再把流量全部切过去。