WebSocket/REST：客户端连接？

Question

我了解两者背后的主要原则。但是我有一个无法回答的想法。

基准测试表明 WebSockets 可以提供更多消息，如本网站所示：http://blog.arungupta.me/rest-vs-websocket-comparison-benchmarks/

这是有道理的，因为它声明连接不必关闭和重新打开，还有 http 标头等。

我的问题是，如果连接总是来自不同的 客户端（也许一些来自同一个客户端）怎么办。基准表明，根据我的理解，连接的客户端是相同的，这将是有意义的保持恒定连接。

如果用户每分钟左右只发出一次请求，那么通过 REST 而不是 WebSockets 运行通信会不会有好处，因为服务器会释放套接字并可以处理 更大的人群说话？

要解决 REST 的问题，您会采用垂直缩放，而 WebSockets 将是水平的？

这是有道理的还是我没用了？

Answer 1

这是我迄今为止的经验，我很高兴讨论我在使用 CQRS 处理的大型应用程序中使用 WebSockets 的结论：

实时应用

您是否正在创建金融应用程序、游戏、聊天或任何需要低延迟、频繁、双向通信的应用程序？使用 WebSockets：

• 得到很好的支持。
• 标准。
• 您可以使用发布者/订阅者模型或请求/响应模型（通过为每个请求创建一个correlationId 并订阅一次）。

小型应用程序

您的客户端是否需要推送通信和/或发布/订阅，并且您的应用程序不是太大？使用 WebSockets。可能没有必要让事情进一步复杂化。

预计会有一定程度的高负载的常规应用

如果您不需要非常快速地发送命令，并且您希望读取远多于写入，您应该公开一个 REST API 来执行 CRUD（创建、读取、更新、删除），特别是 C_UD。

• 并非所有设备都喜欢 WebSocket。例如，移动设备可能更喜欢使用 REST，因为维护 WebSocket 连接可能会阻止设备节省电池电量。
• 您期待一个结果，即使它是一个超时。即使您可以使用correlationId 在WebSockets 中进行请求/响应，仍然不能保证响应。当你向系统发送命令时，你需要知道系统是否接受了它。是的，您可以实现自己的逻辑并达到相同的效果，但我的意思是，HTTP 请求具有发送命令所需的语义。
• 您的应用程序是否经常发送命令？您应该努力进行深入交流而不是闲聊，因此您可能应该批量处理这些更改请求。

然后您应该公开一个 WebSocket 端点以订阅特定主题，并执行低延迟查询响应，例如填充自动完成框、检查唯一项目（例如：用户名）或在您的阅读模型中进行任何类型的搜索。还可以在实际处理和完成更改请求（写入）时获得通知。

我在一个宠物项目中所做的是将 WebSocket 端点放在读取模型中，然后在连接时服务器通过 WebSocket 向客户端提供一个连接 ID。当客户端通过 REST 执行操作时，包含一个可选参数，指示“完成后，通过此 connectionID 通知我”。 REST 服务器返回说明命令是否正确发送到服务总线。队列消费者处理命令，当完成（好或坏）时，如果命令有通知请求，另一条消息被放置在“Web 通知队列”中，指示命令的结果和要通知的连接 ID。读取模型订阅此队列，获取消息并将它们转发到适当的 WebSocket 连接。

但是，如果您的 REST API 将被非浏览器客户端使用，您可能希望提供一种使用异步 REST 方法检查命令是否完成的方法：https://www.adayinthelifeof.nl/2011/06/02/asynchronous-operations-in-rest/

我知道，拥有一个可用于发送命令的低延迟 UP 通道非常有吸引力，但如果你这样做了，你的整体架构就会变得一团糟。例如，如果您使用的是 CQRS 架构，那么您的 WebSocket 端点在哪里？在读模型中还是在写模型中？

1234563将命令发送到写入模型并通知它是否无法这样做。

• 如果将其放置在写入模型上，则可以轻松放置命令，但如果您想通过 WebSocket 回答搜索查询，则需要访问读取模型和读取数据库。

通过将 WebSockets 视为您的读取模型的一部分并将命令处理留给 REST 接口，您可以保持读取模型和写入模型之间的松散耦合。