SignalR 的微服务设计

Question

我们已经构建了一个微服务架构，但遇到了一个问题，即发送到总线的消息太大。 （在迁移到 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 的限额，例如文档或特别大的对象。

Answer 1

有两种方式：-

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