Azure 服务总线，使用过滤器将大消息组装成较小的消息

Question

我正在尝试寻找在 Azure 服务总线上接收大消息的解决方案。我想到的基本模式是分部分发布一条大消息——以及相关 ID、页面和“of”。

因此，如果我有一条由四部分组成的消息，它们都将具有相同的相关 ID，每个消息的“of”为 4，页面将为 0 - 3。该集合将作为批处理发布。

监听器只能监听page为0的消息，然后根据事务id拉取剩余的消息。

发布这些消息非常容易。 ServiceBusMessage 有一个 CorrelationId 字段和一个名为 ApplicationProperties 的字典字段，我可以将自定义“page”和“of”字段添加到其中。我可以在发布之前将它们组装成 ServiceBusMessageBatch。

我不确定如何接收消息。我正在使用 Function Apps，因此设置监听器很容易。

[FunctionName("GeneralLogger")]
public static void Run([ServiceBusTrigger("queueName", Connection = "AzureWebJobsServiceBus")] string myQueueItem, ApplicationProperties ap, ILogger log)
{ /// process message }

但我不知道如何在这里过滤。另外，我可以通过向消息处理器添加处理程序来拉取消息，如下所述: https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dotnet-get-started-with-queues但同样我不知道如何过滤。

我看到的唯一 Azure 服务总线过滤是在主题和订阅之间进行的。那里有很多功能，但在运行时我无法动态设置任何内容。

我觉得我要么试图误用某些东西，要么重新发明轮子。还有其他人使用 Azure 服务总线做类似的事情吗？

Answer 1

I'm trying to find a solution for receiving large messages on Azure Service Bus.

解决方案已经存在。这是 Azure 服务总线 premium tier 。能够发送最大 100MB 的消息。它是有代价的。假设您想要吐出该文件，要么是因为需要支付大量费用，要么是因为消息可能大于 100MB，那么声明检查模式就是最佳选择。当在高级层上使用声明检查模式时，只有一个问题 - 当消息是一个事件并且有多个接收者时，您无法进行确定性清理。您需要制定一些策略来清理这些 Blob，因为这些 Blob 很大，并且随着时间的推移会快速增加存储消耗，具体取决于流经系统的消息数量。对于高级层，不存在清理问题。您也不必提供存储帐户。因此，如果您的大消息不超过 100MB，那么它可能是更适合您的生产环境的解决方案。