Azure Functions - 并行/并发函数执行和横向扩展

问题描述

限时删除！！

我最近开始使用 Azure Functions，并且(在阅读了 SO 和 Microsoft 文档后)一直无法理解横向扩展和并行执行.

I've recently started working with Azure Functions and (after reading SO and Microsoft docs) have been having trouble understanding scale out and parallel execution.

我的情况是一个带有 CRUD Azure Functions 的函数应用程序——它们需要像 REST API 一样快速并发地做出反应.但是，当在我自己的浏览器上测试并运行 10 个不同的选项卡时，这些选项卡似乎连续/顺序完成(一个接一个，最后一个选项卡等待很长时间).

My situation is a function app with CRUD Azure Functions - they need to react quickly and concurrently like a REST API.However, when testing on my own browser and running 10 different tabs, it seems the tabs finish consecutively/sequentially (one after the other, the last tab waiting a LONG time).

我想知道我是否遗漏了什么，或者是否有办法允许使用其他 Azure 产品进行并行执行?

I was wondering if I am missing something, or if there is a way to allow for parallel execution using some other Azure product?

(我已经阅读了一些应用程序设置，可能使用 APIM 或托管函数，但这些似乎不是答案.)

(I've read into a few application settings and possibly using APIM or hosting the functions, but these didn't seem to be the answer.)

谢谢！

推荐答案

我认为 冷启动问题已经提到了.

除了支付更多费用(应用服务计划或高级计划)之外，另一种选择是编写更多代码以节省一大笔钱.

Other than paying more (App Service plan or Premium plan), one other option is to write a little more code to save a bunch of money.

• 将新的查询参数 ?keepWarm=1 添加到您要保温的 REST API 端点.如果是 keepWarm 调用，此函数的实现将返回 200.
• 添加一个计划函数(定时器触发器)，每 X 秒唤醒一次，调用 /endpoint?keepWarm=1

• Add a new query param ?keepWarm=1 to your REST API endpoint you want to keep warm. Implementation of this function would be to return 200 if it's a keepWarm call.
• Add a scheduled function (timer-trigger) that wakes up every X seconds, makes a call to /endpoint?keepWarm=1

在消费计划中主持这整个事情.

Host this whole thing in consumption plan.

即使对于 X = 1 秒，您最终也可能比其他昂贵的计划(我认为是 100 美元以上)少付很多钱(5-20​​ 美元).

Even for X = 1 second, you'll probably end up paying a LOT less ($5-20) than other expensive plans ($100+ I think).

恕我直言，高级和专用计划适用于您需要更多火力的时候，而不是您想要保暖的时候.事实上，消费计划可以让您扩展到 200 个实例 而其他昂贵计划的限制是 10 到 100.

IMHO Premium and Dedicated plans are when you need more fire-power, not when you want to keep things warm. In fact Consumption plan would let you scale to 200 instances whereas the limit for other pricey plans is 10 to 100.

通过昂贵的计划，您确实获得了更多的火力，因此您可以完成更大的任务并花费您喜欢的时间:

With pricey plans you do get more fire-power so you can do bigger tasks and take as long as you like:

• 210-840 ACU
• 1.75-14GB 内存
• 无限执行时间限制 (#)

($) 无限执行时间限制:如果您的触发器是 HTTP 触发器(REST API)，那么由于 负载均衡器限制

($) unbounded execution time limit: If your trigger is HTTP Trigger (REST API) then this is useless due to load balancer limitation

如果使用 HTTP 触发器的函数未在 230 秒内完成，Azure 负载均衡器将超时并返回 HTTP 502 错误.该函数将继续运行，但无法返回 HTTP 响应.

---

关于缩放单位:

这很不清楚.

如此处所述.

在消费和高级计划中，Azure Functions 通过添加额外的 Functions 主机实例来扩展 CPU 和内存资源.实例的数量取决于触发函数的事件数量.

消耗计划中的每个 Functions 主机实例限制为 1.5 GB 内存和一个 CPU.宿主实例是整个函数应用，这意味着函数应用中的所有函数在一个实例内共享资源并同时扩展.

• 清楚的是
  • 当 AFR(Azure 函数运行时)发现需要扩展(基于流量)时，它将生成新的函数主机，每个主机都包含整个函数应用程序及其所有函数.
  • 作为开发人员，您创建函数时必须将资源使用限制在一个函数主机提供的范围内.
  • 每个 Host 是否只有每个 Function 的一个实例，还是多个.
  • 同一个App内的多个不同Function是否并行执行.如果是，那么每个 Function 实现都需要与该 App 中共存的其他 Function 共享 Host 资源.

  还可以通过 .

  Also it is possible to set FUNCTIONS_WORKER_PROCESS_COUNT to control number of language worker processes via Application Settings.

  我猜在这种情况下，每个语言工作者进程都将在同一主机内运行并共享资源.

  I guess in this case each language worker process would run within same host and would share resources.

  这篇关于Azure Functions - 并行/并发函数执行和横向扩展的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！

  1403页，肝出来的..