SignalR 的微服务设计

如何解决SignalR 的微服务设计

我们已经构建了一个微服务架构，但遇到了一个问题，即发送到总线的消息太大。 （在迁移到 Azure 服务总线后发现，因为与 RabbitMQ 4MB 相比，这仅允许 256KB）

我们的设计如下图所示。我们正在努力处理返回的数据。

一个例子是执行搜索并返回多个结果。

要逐步完成我们当前的流程：

1. Web 客户端向 Web Api 发送 http 请求。
2. Web api 然后将适当的消息放到总线上。 （Web api 以 Accepted 响应响应客户端）
3. 微服务接收此消息。
4. 微服务在其数据库中查询符合搜索条件的记录。
5. 从数据库返回的结果。
6. 一条 SearchResult 消息被添加到总线上。 （这包含结果）
7. 我们的响应微服务正在侦听此 SearchResult 消息。
8. 响应微服务然后发布到我们的 SignalR api。
9. SignalR Api 将结果发送回网络客户端。

我的问题是，以这种方式设计时，我们如何处理大型结果集？如果不可能，应该如何更改设计以处理大型结果集？

我知道我们可以对结果进行分页，但即便如此，一个结果也可能超过 256KB 的限额，例如文档或特别大的对象。

解决方法

有两种方式：-

1. 使用支持大尺寸消息的类似 Kafka 的系统。
2. 如果您不能采用第一种方法（出现在您的问题中），那么微服务可以为响应服务放置 2 种类型的消息 (1.) 如果尺寸较小，则放置完整的消息并 (2.) 如果大小超过支持，则放置包含指向 Azure 存储 Blob 的链接的消息，这些链接具有结果 响应服务可以根据消息得到正确的结果并将结果返回给客户端。