什么是 Microsoft Azure Functions 高级计划？

Azure Functions 高级计划（也称为弹性高级计划）是一种函数应用托管选项。还有其他托管计划可用。

我们的函数将通过高级计划托管以下列方式受益：

• 如果情况始终是热启动，则不会冷启动。
• 连接到虚拟网络。
• 执行时间无限制，至少保证 60 分钟。
• 提供多个核心实例。
• 与消耗计划相比，价格更具可预测性。
• 对于拥有多个函数应用的计划，应用分配密度更高。

计费

高级计划的计费完全取决于所利用的核心数量以及所有实例之间共享的内存。另一方面，消耗计划按操作和消耗的内存计费。高级计划没有执行费用。在所有计划或任何一个单独计划中，必须始终分配至少一个实例。

不再有冷启动

应用冷启动是指首次调用时遇到的额外延迟。

始终就绪实例和预热实例是高级计划中的两个功能，它们协同工作以有效避免我们的操作中的冷启动。

始终就绪实例

通过高级套餐，我们可以让我们的应用始终在一定数量的实例上做好准备。始终就绪实例的最大数量为 20 个。当事件开始触发应用时，它们首先发送到始终就绪实例。随着函数变得活跃，所有额外的实例都将作为缓冲区进行预热。

此缓冲区可防止新实例在扩展期间冷启动。缓冲的实例是预热的实例。我们的程序可以通过将始终就绪实例与预热缓冲区相结合来成功防止冷启动。

预热实例

预热的实例将继续缓冲，直到达到最大横向扩展限制。在大多数情况下，预热实例计数设置为 1，并且建议在大多数情况下保持不变。

如果我们的程序需要很长时间才能预热（例如，自定义容器镜像），我们可能需要增加此缓冲区。预热实例仅在所有活动实例都被充分利用后才变得活跃。

在此示例中，了解始终就绪实例和预热实例如何协同工作。高级函数应用默认配置为五个始终就绪实例和一个预热实例。

此时我们不会为预热实例付费，因为始终就绪实例未使用，并且未分配任何预热实例。

一旦收到第一个触发器，五个始终就绪实例就会变为活动状态，并分配一个预热实例。所以现在，应用正在运行六个已预配的实例：其中包括目前活动的五个始终就绪实例，以及一个预热的第六个缓冲区，它在其自然状态下处于非活动状态。

如果执行速率继续上升，这五个当前实例最终将被使用。当平台达到超过五个实例的容量时，它会切换到预热实例。然后，现在有六个活动实例，第七个实例已预配并从预热缓冲区中填充。

此扩展和预热过程将持续到达到应用的最大实例数。没有超过其最大容量的预热或活动实例。

最大函数应用实例

应用扩展限制可用于设置应用最大值。

私有网络连接

对于部署到高级计划的函数应用，提供 Web 应用的 VNet 集成。现在，我们的应用可以毫无问题地与 VNet 中的资源通信，或者在正确配置后通过服务终结点安全地通信。还可以使用应用中的 IP 限制来限制传入流量。

我们需要一个至少有 100 个可用地址的 IP 块。

更长的运行时间

消耗计划对 Azure 函数的单次执行限制为 10 分钟。为了防止失控执行，高级计划中的运行持续时间默认为 30 分钟。对于高级计划应用，我们可以更改 host.json 配置以使持续时间无限。当设置为无限制持续时间时，我们的函数应用可以运行至少 60 分钟。

高级计划中的计划和 SKU 设置。

创建计划时有两个计划大小设置：最小实例数（或计划大小）和最大突发限制。

如果我们的应用需要比始终就绪实例更多的实例，我们就可以继续横向扩展，直到达到最大突发限制，在某些情况下我们也会纵向扩展它们。

我们每秒只对大于计划大小的实例收费，前提是它们正在运行并分配给我们。平台尽力将我们的应用扩展到指定的最大限制。每个计划至少需要一个实例。

重要性

无论函数是否运行，用户都将按最小实例计数中分配的每个实例收费。

在大多数情况下，此自动伸缩功能非常有效，并且不需要任何用户修改。另一方面，超出最低限度的伸缩是最后的努力。如果新实例在某个时刻不可用，伸缩可能会延迟，但这并不常见。

可用实例 SKU

创建或扩展计划时，我们有三种实例大小可供选择。我们将根据分配给每个实例的总核心数和 RAM 按秒计费。根据需要，我们的软件可以自动横向扩展到多个实例。

内存使用情况

在内存更大的系统上运行我们的函数应用并不总是意味着它会使用所有内存。

例如，Node.js 中的默认内存限制限制了 JavaScript 函数应用的大小。添加应用设置 languageWorkers:node:arguments，其值为 -max-old-space-size=max memory in MB>，以增加此固定内存限制。

Azure Functions：专用托管计划

在传统托管中，这些计算资源类似于服务器场。一个或多个函数应用可以设置为与其他 App Service 应用（如 Web 应用）共享计算资源（App Service 计划）。

在以下情况下考虑使用 App Service 策略：

• 我们有未充分利用的虚拟机 (VM)，它们已经托管了其他 App Service 实例。
• 我们想为我们的函数提供自定义镜像以运行。

计费

无论计划中运行多少个函数应用或 Web 应用，我们只为计划付费。

始终开启

如果我们在 App Service 订阅上，我们应该开启“始终开启”选项，以确保我们的函数应用正常工作。

“始终开启”选项仅适用于 App Service 计划。平台会自动激活消耗计划上的函数应用。

缩放

我们可以通过添加新的 VM 实例手动使用 App Service 计划进行横向扩展。我们还可以启用自动缩放，尽管它会比高级计划的弹性缩放慢。

必须记住，当使用 App Service 计划运行 JavaScript (Node.js) 函数时，我们应该选择 vCPU 较少的计划。

App Service 环境

与 App Service 计划相比，在 App Service 环境 (ASE) 中运行使我们能够完全隔离我们的函数并利用更多的实例。

如果我们只想在虚拟网络中运行函数应用，则高级计划适合我们。

Azure Functions 通过添加更多 Functions 主机实例来扩展消耗计划和高级计划中的 CPU 和内存容量。

当我们删除函数应用的主要存储帐户时，函数代码文件也会丢失，无法恢复。

运行时缩放

缩放控制器是 Azure Functions 中的一个组件，它监视事件速率并确定是横向扩展还是纵向缩减。对于每种触发器类型，缩放控制器都使用启发式方法。

函数应用是 Azure Functions 的缩放单元。然而，当计算需求减少时，缩放控制器会移除函数主机实例。当函数应用内没有正在运行的函数时，实例数最终会“缩减”到零。

冷启动

当我们的函数应用空闲一定分钟数后，平台可能会将运行我们函数应用的实例数减少到零。从零扩展到一会增加下一个请求的延迟。这种延迟期称为冷启动。

我们的函数应用所需的依赖项数量会影响冷启动时间。对于必须提供响应的同步进程（例如 HTTP 触发器），冷启动更令人担忧。

了解缩放行为

缩放取决于各种因素，并且因触发器和使用的语言而异。缩放行为有一些细微之处，我们应该注意：

• 最大实例数：单个函数应用只能横向扩展到 200 个实例。如有必要，我们可以设置较低的最大节流缩放。
• 新实例速率：HTTP 触发器新实例最多每秒分配一次。非 HTTP 触发器新实例每 30 秒分配一次。使用高级计划时，缩放速度会快得多。
• 缩放效率：由于不能使用队列长度来驱动缩放决策，因此使用监听权限的缩放精度较低。我们可以使用管理权限来有效扩展服务总线或触发器。