我目前正在评估使用服务总线和天蓝色功能来触发某些需要通过下游api调用完成的工作。除了我无法很好地处理下游系统过载和/或将报头返回到节流状态（即每分钟最大呼叫数/等）时，会发生什么情况。我们似乎没有对队列触发器强制调节的任何动态控制。Azure功能 - 限制服务总线触发
我知道我们可以手动设置max concurrency，但这并不一定能解决问题，因为我们无法控制下游系统，需要考虑随时可能处于脱机状态或缓慢状态。
此外，我们可以创建消息，使它们按照一定的速率流入，但下游系统仍然可以饱和或返回速率限制。
选项1：
假设消费计划，从解决方案的角度来看，这是一个方式，我能想到的：
- 队列1 - 全速或最高速度。如果我们开始获得速率限制，请设置缓存值。如果设置了缓存值，则不处理该消息，将其克隆并放入队列2
- Queue2 - 每个最大并发/预取计数下限。与上面相同的过程，但推入队列3。
- 队列3 - 最大每最大并发/预取计数。我们只是慢慢地处理它们。
基本上，当下游系统饱和时，队列1成为队列2和队列3的控制器。
选项2：
我们可以克隆的消息，并在未来进行重新排队，并继续这样做，直到他们的所有进程。保持一个队列，只需要等待，直到我们得到处理。
方案3：
假设我们有我们的是专用的，而不是消耗自己的应用程序的计划，我想我们可以Thread.Sleep，如果他们越来越接近成为速率限制或向下，并不断重试功能。这可能可能是最大并发性，实例和速率限制的计算。我不会在消费计划中考虑这一点，因为睡眠可能会大幅增加成本。
我不知道如果我失去了一些东西以最好的方式简单处理下游饱和或节流队列触发（可能是服务总线或存储队列）
编辑： 我想补充一点，我将100万条消息抽入服务总线队列，该队列在发送时计划。我观察Azure功能（消费计划）规模达到每秒1500次左右，以提供良好的指标。我不确定这些专用的程序如何执行。
它看起来可以即时修改主机文件，并且设置立即生效。虽然这是针对所有功能的，但在特定情况下可能会起作用（更新设置并根据速率限制每隔一分钟重新检查一次）。
This看起来它可能是一个正确的方向，当它被功能团队实现时迈出的一步，但即便如此，我们仍然需要一种方法来管理下游错误。
您想避免功能过载并保证服务总线队列消息的传递吗？ –
是的保证传递，消息需要处理。函数超载我打开最好的选择。 – lucuma