CQRS和WebSockets

Question

当我们必须将推送更新功能添加到基于CQRS的系统时，似乎有意义让“读取”模型负责管理这些推送消息。当使用长轮询和服务器事件时（大多数是单向的），这很有意义

但WebSockets是双向持久通道。这是一个已经建立的连接，可用于获取推送更新和发送命令。问题是WebSocket连接由于减少了延迟和状态而变得非常方便，因为很多事情都像自动完成搜索框一样。乍一看，从技术角度来看，当已经有一个可用的通道就绪并准备就绪时，使用另一个端点（即：HTTP POST接收器）是没有道理的。

哪里可以找到启用WebSocket端点的正确位置？

• 阅读模式：是有道理的推送更新客户端和像自动完成搜索框解答问题，但如果它接受“写”，那就已经阅读并在同一个地方更新模型试。

• 更新模型：接受客户端输入是有意义的。将推送更新发送到客户端是有道理的，因为它们是由其他客户端输入触发的。但是对于搜索自动完成搜索等请求响应的东西是没有意义的。

Answer 1

WebSockets是一个基础设施问题。正如您指出的那样，它们在某些情况下比原始HTTP具有实质优势，但它们与您的域策略无关。

在我们的项目之一，我们发送的所有命令和查询（包括观察到的查询）以上的WebSockets为你提到的原因，但是这是抽象这些命令的作者和客户端了。

撇开他们（略）更低的延迟在现代的网络堆栈[*]我相信有两个很明显的地方，他们可以照

• 订阅经典的酒吧/事件的子流，例如在聊天系统，或者来自某种用户模型的事件流。
• 订阅“可观察读取模型”或“流式投影”或“连续查询”或任何您想要调用它们的查询结果（例如，我有多少条未读消息）发送到用户每当更新。

[*]有些像IIS这样的容器使得HTTP调用非常昂贵，您被迫进入WebSocket以实现可接受的延迟（即< 1ms）。但是，这在变化。