WebSocket 能否完全承担后端 Controller 的角色呢?

最近有一个想法,我是 JAVAWeb 出生,没有 SpringMVC 之前接触的项目都是 Servelet,我曾经接触到的是项目往往维护无数个不同功能的 Servelet,Servlet 中往往重写两个方法 onGet(),onPost(),然后在开发最近基于 WebSocket 的实时电子看板项目的时候我突然觉得在后端写 WebSocket 服务的时候和以前的 Servelet 是如此相似,也需要重写他的几个方法,我开发的项目是整个页面只请求一个 WS://地址,然后后端收到之后将整个客户端(网页)各个页面所需的数据进行组合(一个大的实体类包含所有页面数据模型),然后经由 WebSocket 发给前端页面,页面对这个大的 JSON 对象进行拆分并在不同的组件渲染(echart),能不能不这样而是我每个页面对应一个 WebSocket 服务(每个页面对应一个 WS://地址),不同的服务只发送与之匹配的页面的数据呢?

  • WebSocket

    WebSocket 是 HTML5 中定义的一种新协议,它实现了浏览器与服务器之间的全双工通信(full-duplex)。

    41 引用 • 156 回帖 • 630 关注
  • 架构

    我们平时所说的“架构”主要是指软件架构,这是有关软件整体结构与组件的抽象描述,用于指导软件系统各个方面的设计。另外还有“业务架构”、“网络架构”、“硬件架构”等细分领域。

    118 引用 • 414 回帖
  • Q&A

    提问之前请先看《提问的智慧》,好的问题比好的答案更有价值。

    1733 引用 • 11434 回帖 • 584 关注

赞助商 我要投放

21 回帖
请输入回帖内容 ...
  • ferried

    后端直接触发 reducer 会让用户感觉非常诡异,我 tm 什么都没动,页面怎么变了

  • 其他回帖
  • 88250

    理论上没问题,设计方面可以用命令模式,方便扩展不同业务。

    2 回复
  • yoss

    你说在重点上了,保证消息有序性。我们有个项目正是这样设计的,一开始没细想觉得挺简单,不就是消息的分发和处理。真正开始写的时候发现浏览器和服务端通过消息指令交互会遇到个问题:如何将用户操作请求和处理结果响应对应起来。比如用户提交数据时走 ws.sendMsg(业务指令码, 参数),服务端 ws.onMsg 根据业务指令码分发处理,然后通过 ws.sendMsg(操作指令码, 响应) 发消息给浏览器,此时浏览器就懵逼了:这个响应对应的是哪次业务提交数据的请求?

    后来我们通过 UUID 来关联请求和响应,解决了“对应”问题,但又碰到另外一个问题,请求和响应的时序不对。有时候用户后触发的请求会先返回,传统的 HTTP 是同步的,即使用 AJAX 在某些场景也可以设置为同步,很简单就能解决,但是用 WebSocket 的话就只能自己实现同步。我们最后只是简单加了个时间戳来判断时序,丢弃较老的响应。

    总之,如果要用 WebSocket 来实现浏览器和服务端的交互,建议楼主先处理好这两个问题,否则设计再优美也只是玩具。

    1 回复
  • zhaozhizheng

    现在很多简单的通信都是这么做的,比如我们的一些嵌入的小客服程序等。D 大说的命令比如收到已读销毁指令。不过这样使用主要注意保证消息的有序性与连续性吧。

    1 回复
  • 查看更多回帖