我目前正在评估使用服务总线和azure函数来触发一些需要通过下游api调用完成的工作。这一切都非常标准，除了我没有很好地处理下游系统过载和/或返回标头节流（即每分钟最大呼叫次数/等）时发生的事情。我们似乎没有动态控制强制限制队列触发器。
我知道我们可以手动设置max concurrency，但这并不一定能解决问题，因为我们无法控制下游系统，需要考虑它可能处于离线或缓慢的状态时间。
此外，我们可以创建消息，使它们按照一定的速率流入，但下游系统仍然可以饱和或返回速率限制。
选项1：
假设消费计划，从解决方案的角度来看，这是我能想到的一种方式：
当下游系统饱和时，队列1基本上成为queue2和queue3的控制器。
选项2：
我们可以克隆消息并在将来重新排队，并继续这样做，直到它们都是进程。保留一个队列，然后重新排队，直到我们处理完毕。
选项3：
假设我们有自己的应用计划专用而非消费，我想我们可以Thread.Sleep功能，如果他们接近速率限制或下降并继续重试。这可能是最大并发，实例和速率限制的计算。我不会在消费计划中考虑这一点，因为睡眠可能会大大增加成本。
我想知道我是否错过了处理下游饱和的最佳方法或限制队列触发器（可能是服务总线或存储队列）
编辑： 我想补充一点，我将100万条消息泵入一个在发送时间安排的服务总线队列。我看着Azure功能（消费计划）规模达到1500 /秒左右，以提供一个好的指标。我不确定专用的表现如何。
看起来主机文件可以动态修改，设置立即生效。虽然这适用于所有功能，但它可以在我的特定情况下工作（更新设置并根据速率限制每分钟再检查一次）。
This看起来可能是功能团队实施时朝着正确方向迈出的一步，但即便如此，我们仍然需要一种方法来管理下游错误。
答案 0 :(得分：1)
不幸的是，像您需要的背压功能目前无法通过Service Bus触发器（以及更常见的Azure功能）提供，因此您需要自己处理。
您所描述的方法可行，您只需在不同的功能应用中处理，因为服务总线设置适用于整个应用而不仅仅是功能。
在您的方案中可能不是一个巨大的帮助，但对于处理队列2或3的应用程序，您还可以尝试使用预览标记来限制应用程序的扩展实例数量：WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT。请注意，这是预览版，目前还没有任何保证。
我建议您在记录您的方案的functions repo上打开一个问题。这些问题绝对是我们想要解决的问题，我们的反馈越多越好。
答案 1 :(得分：0)
就是这样，除了正常的api端点之外，您能否请求您的下游人员提供队列端点？ 然后你可以充斥他们的队列，他们可以在闲暇时处理它。