Azure功能-阻止服务总线触发

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

我知道我们可以手动设置，但这不一定解决这个问题，因为我们不能控制下流系统，并且需要考虑它在任何时候都可能是离线或慢的。 此外，我们还可以创建消息，使它们按一定的速率计划流入，但下游系统仍然可以饱和或返回速率限制

选项1:

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

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

基本上，当下游系统饱和时，队列1成为队列2和队列3的控制器

选项2:

我们可以克隆消息并在将来重新查询它，并继续这样做，直到它们都是进程。保持一个队列并重新排队，直到我们处理它

选项3:

假设我们有自己的专用应用程序计划而不是消费，我想我们可以

Thread.Sleep

在功能接近速率限制或下降时继续重试。这可能是对最大并发性、实例和速率限制的计算。我不会在消费计划上考虑这一点，因为睡眠会极大地增加成本。 我想知道我是否缺少处理下游饱和或限制队列触发器（可能是服务总线或存储队列）的最佳方法中的一些简单内容

编辑： 我想补充一点，我在发送时向一个服务总线队列发送了100万条消息。我看到Azure功能（消费计划）的规模达到1500/秒左右，以提供一个良好的指标。我还不确定那些专注的人会如何表现

看起来可以动态修改主机文件，并且设置会立即生效。虽然这适用于所有功能，但在我的特定情况下可能会起作用（根据速率限制，每分钟左右更新设置并再次检查）

---

看起来，当功能团队实现它时，这可能是朝着正确方向迈出的一步，但即便如此，我们仍然需要一种方法来管理下游错误。

不幸的是，像您需要的功能这样的backpresssure功能目前在服务总线触发器（以及更一般的Azure功能）中不可用，所以你需要自己处理

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

在您的场景中可能不会有很大帮助，但对于处理队列2或3的应用程序，您也可以尝试使用预览标志来限制应用程序的扩展实例数：

WEBSITE\u MAX\u DYNAMIC\u APPLICATION\u SCALE\u out

。请注意，这是在预览，并没有保证尚未

---

我鼓励您在记录您的场景时打开一个问题。这些类型的问题肯定是我们想要解决的，我们得到的反馈越多越好。

那么，除了正常的api端点之外，您能要求下游人员提供一个队列端点吗？

---

然后您可以让他们的队列满溢，他们可以在空闲时处理它。

您想避免功能过载并保证服务总线队列消息的传递吗？是的，在保证传递时，需要处理消息。功能过载我愿意接受最好的选择。你希望你的下游每分钟能处理多少个请求？1/分钟：定时器触发。每秒数百次：可能是异步并行和某种批处理？你是否需要最大化下游系统，或者你能负担得起某种低速率，就像一个函数可以做到的那样？假设我们有一个来自Jira、Bitbucket、appveyor的webhook，比如asana，它正在接收大量发布到slack的数据。这些Webhook可能会使内部队列饱和，Azure功能可以轻松扩展，但Slack有速率限制。多亏了，我们可能会有自己的专用应用程序计划，并将在各种队列上管理它。我将提出一个问题。我注意到我可以更新主机文件，但我知道它适用于所有队列。我在文档中没有看到的是服务总线处理的“最大”吞吐量，假设消息的大小很小，并且正是根据队列大小计算扩展的参数。如果下游人员为您工作，这是可行的，但如果是限制请求的第三方服务，则不可行。