问题描述
我们已经构建了一个微服务架构,但遇到了一个问题,即发送到总线的消息太大。 (在迁移到 Azure 服务总线后发现,因为与 RabbitMQ 4MB 相比,这仅允许 256KB)
我们的设计如下图所示。我们正在努力处理返回的数据。
要逐步完成我们当前的流程:
- Web 客户端向 Web Api 发送 http 请求。
- Web api 然后将适当的消息放到总线上。 (Web api 以 Accepted 响应响应客户端)
- 微服务接收此消息。
- 微服务在其数据库中查询符合搜索条件的记录。
- 从数据库返回的结果。
- 一条 SearchResult 消息被添加到总线上。 (这包含结果)
- 我们的响应微服务正在侦听此 SearchResult 消息。
- 响应微服务然后发布到我们的 SignalR api。
- SignalR Api 将结果发送回网络客户端。
我的问题是,以这种方式设计时,我们如何处理大型结果集?如果不可能,应该如何更改设计以处理大型结果集?
我知道我们可以对结果进行分页,但即便如此,一个结果也可能超过 256KB 的限额,例如文档或特别大的对象。
解决方法
有两种方式:-
- 使用支持大尺寸消息的类似 Kafka 的系统。
- 如果您不能采用第一种方法(出现在您的问题中),那么微服务可以为响应服务放置 2 种类型的消息 (1.) 如果尺寸较小,则放置完整的消息并 (2.) 如果大小超过支持,则放置包含指向 Azure 存储 Blob 的链接的消息,这些链接具有结果 响应服务可以根据消息得到正确的结果并将结果返回给客户端。