azure - 我可以限制并发功能吗？

我有一个耐久的功能应用程序，运行于Azure中的高级弹性服务计划上，其中我

（a）部分依赖于外部数据库，当我遇到一定数量的并发请求时，该数据库开始拒绝请求。

（b）部分没有这种第三方依赖性，并且理论上应该可以无限扩展。

我知道可以设置以下限制：

但是，使用这些选项中的任何一个来限制（a）也会限制（b），我想尽可能地保持并发。

有没有办法限制活动函数（a）的并发调用次数，而又不限制（b）的调用数？

（如果所有其他方法均失败，我可以在运行活动（a）中自己跟踪存储中当前执行的次数，但是我更愿意配置它，或者能够从持久功能框架中进行驱动，如果可能的话-因为它已经在跟踪每种类型的排队活动功能的数量。）

有没有办法限制活动函数（a）的并发调用次数，而又不限制（b）的调用数？

是的，Azure中有很多工具可让您建立（a）和（b）的发布/订阅隔离。也许这里的错误是认为（a）的结果需要与接收/处理这些结果的使用者在过程中/同步处理。

即如果（b）很有可能无法跟上（a）检索到的消息，那么我将考虑通过队列将（b）中获取数据的任务与（a）中获取数据的任务分开或日志技术。

专注于（b）：

如果（b）需要命令或事务语义（即，仅一次，保证），则可以使用Azure Service Bus对命令进行排队，直到可以对其进行处理为止，并且可以独立于消息的产生来扩展消息的使用者（a）中使用订阅的邮件。想想RabbitMQ。
如果（b）不能处理较不可靠的担保，例如至少一次语义，然后Azure Event Hubs将允许您在多个并发使用者之间划分消息。想想卡夫卡。

也存在其他替代方法，例如存储队列（低成本）和事件网格（大量订户协议）。

因此，如果您担心在获取和处理数据的能力之间存在吞吐量差异，请 TL; DR 缓冲处理过程中的数据积累。

足够有趣的是，如果传递给（a）的过程本身就是一个队列，那么您只需要关心（b）的性能即可。队列的黄金法则是，如果您没有处理数据的能力，则将数据留在队列中（因为您只需要再次对其进行缓冲）。