Azure函数-节流服务总线触发

Question

我目前正在评估使用一个服务总线和azure函数来触发一些需要通过下游api调用来完成的工作。这都是相当标准的，只是我没有很好地处理当下游系统过载和/或返回header到trottle时会发生什么（即每分钟最大调用数/等）。对于队列触发器的强制节流，我们似乎没有任何动态控制。

我知道我们可以手动设置最大并发，但这并不一定解决问题，因为我们无法控制下游系统，需要考虑它随时可能脱机或变慢。

假设消费计划，从解决方案的角度来看，这是我能想到的一种方法：

• 队列1-全速或最大速度。如果我们开始获得速率限制，则设置一个缓存值。如果设置了缓存值，则不要处理该消息，克隆它并将其放入队列2
• 队列2-每最大并发/预取计数较低。与上述进程相同，但推入队列3。
• 队列3-每最大并发/预取计数最低。我们只是慢慢地处理它们。

基本上，当下游系统饱和时，Queue1成为queue2和queue3的控制器。

我想知道我是否遗漏了一些简单的处理下游饱和或限制队列触发器（可能是服务总线或存储队列）的最佳方法

编辑：我想补充的是，我将100万条消息注入到一个在发送时间调度的服务总线队列中。我看到Azure函数（消费计划）规模达到1500/秒左右，以提供一个很好的度量。我还不确定那些敬业的会有怎样的表现。

看起来主机文件可以在飞行中修改，设置立即生效。虽然这是所有的功能，它可能在我的特定情况下工作（更新设置和检查每分钟左右，取决于速率限制）。

Answer 1

不幸的是，像您所需要的backpresssure特性目前还不能与服务总线触发器一起使用（更普遍地说，Azure函数也是如此），所以您需要自己处理。

您所描述的方法是可行的，您只需要在不同的功能应用程序中处理它，因为服务总线设置适用于整个应用程序，而不仅仅是一个功能。

在您的场景中可能不会有很大帮助，但对于处理队列2或3的应用程序，您还可以尝试使用一个预览标志来限制应用程序的扩展实例数:website_max_dynamic_application_scale_out。请注意，这是在预览，还没有任何保证。

我会鼓励您打开一个关于功能回购文档您的场景的问题。这些问题肯定是我们想要解决的，我们得到的反馈越多越好。