CQRS和WebSockets

时间:2015-02-11 15:16:20

标签: architecture websocket web-deployment cqrs event-driven

当我们必须将推送更新功能添加到基于CQRS的系统时,似乎有意义的是让#34;读取"模型负责管理那些推送消息。当使用长轮询和服务器事件(主要是单向)时,这很有意义

但WebSockets是双向持久性通道。它是一个已建立的连接,可用于获取推送更新和发送命令。问题在于WebSocket连接因其减少的延迟和状态而变得像自动完成搜索框这样的东西变得很方便。乍一看,从技术角度来看,当已经有一个有能力的通道准备就绪时,没有理由使用另一个端点(即:HTTP POST接收器)。

启用WebSocket端点的正确位置在哪里?

  • 读取模型:对于客户端的推送更新和回答自动完成搜索框等查询是有意义的,但如果它接受"写入",它将具有读取和更新模型同样的地方。

  • 更新模型:接受客户输入是有意义的。将推送更新发送到客户端有点意义,因为它们是由其他客户端输入触发的。但是对于搜索自动完成搜索等请求响应事项没有任何意义。

1 个答案:

答案 0 :(得分:3)

WebSockets是基础设施问题。正如您所指出的,它们在某些情况下比原始HTTP具有很大优势,但它们与您的域策略无关。

在我们的一个项目中,由于您提到的原因,我们通过WebSockets发送了所有命令和查询(包括可观察的查询),但这是从这些命令的作者和客户端抽象出来的。

在现代网络堆栈中放下他们(略微)较低的延迟[*]我相信有两个显而易见的地方可以发光

  • 订阅经典的发布/子事件流,例如在聊天系统中,或作为事件从某种用户模型中流式传输。
  • 订阅“可观察的阅读模型”或“流式投影”或“连续查询”或您想要调用的任何内容,从而将查询结果(例如,我有多少条未读消息)发送给用户每当更新。

[*]像IIS这样的容器会使HTTP调用变得如此昂贵,以至于你被迫进入WebSockets以实现可接受的延迟(即<1ms)。但这种情况正在改变。