我可以限制*特定* activity 函数的并发吗？
Can I limit concurrency on a *specific* activity function?
我有一个持久功能应用程序，运行正在 Azure 中使用高级弹性服务计划，其中我
- (a) 执行一次性任务，returns 可能产生大量结果
- (b) 运行 对 (a) 部分的每个结果进行一些独立处理
(a) 部分依赖于外部数据库，当我达到一定数量的并发请求时，它开始拒绝请求。
(b) 部分没有这种第三方依赖性，理论上应该能够无限扩展。
我知道可以设置限制：
- 我的服务计划将扩展到的最大实例数
- 每个实例的并发请求数
- 并发数activity函数
但是，使用这些选项中的任何一个来限制 (a) 也会限制 (b)，我希望它尽可能并发。
有没有办法限制 activity 函数 (a) 的并发调用次数，而不限制 (b) 的调用次数？
（如果其他所有方法都失败了，作为 运行ning activity (a) 的一部分，我可以自己在存储中跟踪当前执行的数量，但我更愿意配置它，或者如果可能的话，能够从持久函数框架中驱动它——因为它已经在跟踪每种类型的排队 activity 函数的数量。）
Is there a way I can limit the number of concurrent invocations of activity function (a), without placing restrictions on the number of invocations of (b)?
是的，Azure 中有大量工具可让您构建 (a) 和 (b) 的发布/订阅隔离。也许这里的错误是认为 (a) 的结果需要与接收/处理这些结果的消费者同步in-process/同步处理。
即如果（b）很有可能跟不上从（a）中检索到的消息，那么我会考虑通过队列将（a）中获取数据的任务与（b）中处理数据的任务分开或日志技术。
专注于 (b)：
- 如果 (b) 需要命令或事务语义（即保证恰好一次），则 Azure Service Bus 可用于对命令进行排队，直到它们可以被处理，并且消息的消费者可以独立于使用订阅生成 (a) 中的消息。想想 RabbitMQ。
- 如果 (b) 可以处理不太可靠的保证，例如at-least-once 语义，然后 Azure Event Hubs 将允许您在多个并发消费者之间划分消息。想想卡夫卡。
也存在其他替代方案，例如存储队列（低成本）和事件网格（大量订户协议）。
因此 TL;DR，如果您担心获取和处理数据的能力之间存在吞吐量差异，请缓冲处理过程中积累的数据。
有趣的是，如果传递给 (a) 的进程本身就是一个队列，那么您只需要关心 (b) 的性能。队列的黄金法则是如果您没有能力处理数据，请将数据留在队列中（因为您只需要再次缓冲它）。
我有一个持久功能应用程序，运行正在 Azure 中使用高级弹性服务计划，其中我
- (a) 执行一次性任务，returns 可能产生大量结果
- (b) 运行 对 (a) 部分的每个结果进行一些独立处理
(a) 部分依赖于外部数据库，当我达到一定数量的并发请求时，它开始拒绝请求。
(b) 部分没有这种第三方依赖性，理论上应该能够无限扩展。
我知道可以设置限制：
- 我的服务计划将扩展到的最大实例数
- 每个实例的并发请求数
- 并发数activity函数
但是，使用这些选项中的任何一个来限制 (a) 也会限制 (b)，我希望它尽可能并发。
有没有办法限制 activity 函数 (a) 的并发调用次数，而不限制 (b) 的调用次数？
（如果其他所有方法都失败了，作为 运行ning activity (a) 的一部分，我可以自己在存储中跟踪当前执行的数量，但我更愿意配置它，或者如果可能的话，能够从持久函数框架中驱动它——因为它已经在跟踪每种类型的排队 activity 函数的数量。）
Is there a way I can limit the number of concurrent invocations of activity function (a), without placing restrictions on the number of invocations of (b)?
是的，Azure 中有大量工具可让您构建 (a) 和 (b) 的发布/订阅隔离。也许这里的错误是认为 (a) 的结果需要与接收/处理这些结果的消费者同步in-process/同步处理。
即如果（b）很有可能跟不上从（a）中检索到的消息，那么我会考虑通过队列将（a）中获取数据的任务与（b）中处理数据的任务分开或日志技术。
专注于 (b)：
- 如果 (b) 需要命令或事务语义（即保证恰好一次），则 Azure Service Bus 可用于对命令进行排队，直到它们可以被处理，并且消息的消费者可以独立于使用订阅生成 (a) 中的消息。想想 RabbitMQ。
- 如果 (b) 可以处理不太可靠的保证，例如at-least-once 语义，然后 Azure Event Hubs 将允许您在多个并发消费者之间划分消息。想想卡夫卡。
也存在其他替代方案，例如存储队列（低成本）和事件网格（大量订户协议）。
因此 TL;DR，如果您担心获取和处理数据的能力之间存在吞吐量差异，请缓冲处理过程中积累的数据。
有趣的是，如果传递给 (a) 的进程本身就是一个队列，那么您只需要关心 (b) 的性能。队列的黄金法则是如果您没有能力处理数据，请将数据留在队列中（因为您只需要再次缓冲它）。