小编Edw*_*win的帖子

我有一个带有 ServiceBusTrigger 的 Azure 函数，它将消息内容发布到 Azure API 管理器后面的 Web 服务。在某些情况下，（第 3 方）网络服务器后端的负载过高，并且会崩溃并返回错误 500。

我正在寻找一种在这里实现断路器的正确方法。

我考虑过以下几点：

禁用azure功能，但可能会因内存中存在多条消息而导致数据丢失（serviceBus.prefetchCount）
使用速率限制策略实施 API Manager，但这似乎适得其反，因为它在大多数情况下运行良好
重新构建第 3 方 Web 服务超出了范围:)
将队列设置为 ReceiveDisabled，这是首选解决方案，但它会导致我的 InputBinding 抛出大量 MessagingEntityDisabledExceptions，我（到目前为止）无法自己捕获和处理。我已经检查了 host.json、ServiceBusTrigger 和 Run 参数的文档，但无法在那里找到有用的设置。
保留某种响应代码结果集并增加重试时间，这在具有多个并行功能的无服务器场景中并不理想。
让 API 管理器将 500 错误映射到 429 错误，并在以后重新安排这些错误，这可能会起作用，但由于我们发送了大量消息，它会在一段时间内影响服务。此外，很难区分临时 500 错误还是连续错误。

请注意，这个问题不是关于决定是否触发断路器，只是为了在之后处理适当的操作。

附加信息