我有一个带有ServiceBusTrigger的Azure函数，它将消息内容发布到Azure API管理器后面的Web服务中。在某些情况下，（第三方）网络服务器后端的负载太高，它会崩溃并返回错误500。
我正在这里寻找实现断路器的适当方法。
我考虑了以下内容：
- 禁用azure功能，但是由于内存中有多个消息（serviceBus.prefetchCount），它可能会导致数据丢失
- 使用速率限制策略实施API管理器，但这似乎适得其反，因为它在大多数情况下运行良好
- 重新架构第三方Web服务超出范围：）
- 将队列设置为ReceiveDisabled，这是首选的解决方案，但是它导致我的InputBinding抛出大量MessagingEntityDisabledExceptions，而我（到目前为止）无法捕获并处理自己。我已经检查了文档中的host.json，ServiceBusTrigger和Run参数，但无法在其中找到有用的设置。
- 保留某种响应代码结果集并增加重试时间，这在具有多个并行功能的无服务器场景中并不理想。
- 让API管理器将500个错误映射到429个错误，并在以后重新安排它们的时间，可能会起作用，但是由于我们发送了大量消息，因此它将在一段时间内影响该服务。此外，很难区分暂时的500错误还是连续的错误。
请注意，此问题不是要决定是否触发断路器，而仅仅是要事后处理适当的动作。
其他信息
- Azure功能V2，dotnet core 3.1在消费计划中运行
- API Manager运行基本SKU
- 服务总线在高级级别运行
消息数：300.000