Azure Functions 的缩放算法是什么（永远无法运行超过 7 个并行实例）

Question

我正在尝试了解如何使用 azure 函数进行缩放。我们一直在测试一个在存储队列中生成 88 条消息的应用程序，这会触发我们的函数。该函数是用c#编写的。该函数下载一个文件，对其执行一些处理（它最终会将其发回，但出于测试目的我们还没有这样做）。该功能需要大约 30 秒才能完成每个请求（总共约 2500 秒的处理时间）。出于测试目的，我们将其循环 10 次。

我们的理想情况是，经过一些升温后，Azure 会自动扩展功能，以最方便的方式处理消息。使用某种考虑到启动时间等的算法。或者只是扩大到积压中的消息数量，并设置某种上限。

这是它应该如何工作的吗？我们从未能够获得超过 7 个“消费单位”。并且通常需要大约 45 分钟来处理消息队列。

关于可扩展性的其他几个问题......我们的函数是一个内存密集型操作，内存如何在函数的扩展实例之间“共享”？我问是因为我们看到了一些我们通常看不到的内存不足错误。我们已经为函数配置了最大内存（1536MB）。看到大约 2.5% 的操作因内存不足错误而失败

在此先感谢您，我们真的很想完成这项工作，因为它可以让我们将大量工作从 EC2 上的专用 Windows VM 转移到 Azure 功能上。

Answer 1

目的是让平台为您自动扩展，最终目标是您不必考虑或关心“消费单位”的数量（有时称为实例) 分配给您的函数应用。也就是说，总会有改进的余地，以确保我们为大多数用户提供正确的服务。 :)

但要回答您关于内部细节的问题（就队列处理而言），我们现在拥有的是一个检查队列长度和数量的系统每条消息在被您的应用处理之前位于队列中的时间。如果我们认为您的函数应用在处理这些消息方面“落后”了，那么将添加更多消耗单元，直到我们认为您的应用能够跟上传入的负载。

值得一提的非常重要的一点是，除了消费单位的数量之外，规模还有另一个方面。 每个消费单元都有能力并行处理许多消息。 我们经常看到人们遇到的问题不是分配的消费单元的数量，而是他们工作负载的默认并发配置。查看可以在 host.json 文件中调整的 batchSize 和 newBatchThreshold 设置。根据您的工作负载，您可能会发现更改这些值后吞吐量会显着提高（在某些情况下，减少并发已被证明可以显着提高吞吐量）。例如，如果每个函数执行需要大量内存，或者如果您的函数依赖于只能处理有限并发访问的外部资源（如数据库），您可能会观察到这一点。更多关于这些并发控制的文档可以在这里找到：https://github.com/Azure/azure-webjobs-sdk-script/wiki/host.json。

正如我在上面所暗示的，使用按消耗单元并发可能有助于解决您遇到的内存压力问题。每个消耗单元都有自己的内存池（例如自己的 1.5 GB）。但是，如果您在单个消耗单元中处理太多消息，那么这可能是您看到的内存不足错误的根源。

综上所述，我们一直在努力识别和优化我们认为最常见的某些负载场景，无论是从队列中排出一堆消息，还是消耗存储容器中的 Blob“流” ，处理大量的 HTTP 请求等。期待随着我们学习、成熟和从像你这样的人那里获得更多反馈，事情会发生变化。向产品组提供此类反馈的最佳位置是our GitHub repo's issue list，该地址会定期审核。

感谢您的提问。我希望这些信息对您有所帮助，并且您能够获得您正在寻找的号码。