最近有一个想法，我是 JAVAWeb 出生，没有 SpringMVC 之前接触的项目都是 Servelet，我曾经接触到的是项目往往维护无数个不同功能的 Servelet,Servlet 中往往重写两个方法 onGet（），onPost（），然后在开发最近基于 WebSocket 的实时电子看板项目的时候我突然觉得在后端写 WebSocket 服务的时候和以前的 Servelet 是如此相似，也需要重写他的几个方法，我开发的项目是整个页面只请求一个 WS://地址，然后后端收到之后将整个客户端（网页）各个页面所需的数据进行组合（一个大的实体类包含所有页面数据模型），然后经由 WebSocket 发给前端页面，页面对这个大的 JSON 对象进行拆分并在不同的组件渲染（echart），能不能不这样而是我每个页面对应一个 WebSocket 服务（每个页面对应一个 WS：//地址），不同的服务只发送与之匹配的页面的数据呢？
所以两年前的时候推出了一个新的应用层协议：RSocket，它可以完成 http 和 socket 能完成的所有事。现在生态也越来越好了，Spring boot 对他也有了支持，而 Spring boot 2.3.x 版本中的 Spring Security 也对他有了“飞跃性”的支持。
你说在重点上了，保证消息有序性。我们有个项目正是这样设计的，一开始没细想觉得挺简单，不就是消息的分发和处理。真正开始写的时候发现浏览器和服务端通过消息指令交互会遇到个问题：如何将用户操作请求和处理结果响应对应起来。比如用户提交数据时走 ws.sendMsg(业务指令码, 参数)，服务端 ws.onMsg 根据业务指令码分发处理，然后通过 ws.sendMsg(操作指令码, 响应) 发消息给浏览器，此时浏览器就懵逼了：这个响应对应的是哪次业务提交数据的请求？
后来我们通过 UUID 来关联请求和响应，解决了“对应”问题，但又碰到另外一个问题，请求和响应的时序不对。有时候用户后触发的请求会先返回，传统的 HTTP 是同步的，即使用 AJAX 在某些场景也可以设置为同步，很简单就能解决，但是用 WebSocket 的话就只能自己实现同步。我们最后只是简单加了个时间戳来判断时序，丢弃较老的响应。
总之，如果要用 WebSocket 来实现浏览器和服务端的交互，建议楼主先处理好这两个问题，否则设计再优美也只是玩具。
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于