Azure功能如何扩展？

下面是Azure函数如何决定何时添加更多应用程序实例的详细信息

比如说，我有一个由Github webhook触发的函数。10000人同时提交Github repo（没有合并冲突；），Github在很短的时间内调用我的函数10000次

我能期望发生什么？具体来说,

Azure函数会限制webhook调用吗？i、 例如，如果我的函数应用程序处于高负载状态，Azure函数会拒绝某些函数调用吗

Azure函数是否以某种方式将请求排队？如果是，在哪里/如何

Azure函数在此场景中将创建多少my function应用程序实例？每个请求一个（即10000个），每个请求将并行运行

如果我的应用程序功能被缩减到零实例，因为它没有负载，那么在执行第一个功能之前，我是否可以期望看到一些“预热时间”？大概多长时间

Azure函数不会拒绝webhook调用，但在突然的极端负载情况下，某些请求可能会超时。对于web API，作为最佳实践，请包括在客户端上重试

他们不会在任何地方排队。它们由IIS管理（实现细节）

（实现细节）实例的数量不是一个硬性规定。我们有一些未公开的保护措施，但我们的设计规模相当大。您的请求将由多个实例处理

对。现在，它非常强大（秒），但我们将努力改进它。对于性能敏感的情况，建议使用金丝雀或定时器触发器使其保持清醒

我来自Azure功能团队。我标记为实现细节的东西并不是承诺，而且随着我们服务的发展也可能会改变；只是一种透明度的尝试

今天测试。这花费了超过秒的时间：(

---

你能详细介绍一下计时器触发解决方案吗？我能在函数应用程序上使用另一个计时器触发函数，并依靠它来保持HTTP触发函数的“温暖”吗？如果你在同一个函数应用程序上使用另一个类似计时器触发的函数，它将为另一次执行保留一个温暖的实例，今天，是的。谢谢这有点令人担忧，但我欣赏诚实。这是故意的。我们不保证将来不会改变这种行为，但我们目前没有改变它的计划，也没有压力（如能力不足）改变它。如果我们想提高资源的利用率，我们会改变它，但在我们让冷启动对人们来说不再是问题之前。经过一些实验后，我认为这不是真的，或者对于预编译的azure函数不再是真的。我添加了一个计时器函数，它每分钟运行一次，很容易确认它确实做到了这一点它确实是写一个跟踪，但是在大约10分钟的不活动之后，我支付了大约5-10秒的热身费。

ACTUAL PERFORMANCE
--------------
ClientConnected:  13:58:41.589

ClientBeginRequest:   13:58:41.592

GotRequestHeaders:    13:58:41.592

ClientDoneRequest:    13:58:41.592

Determine Gateway:    0ms

DNS Lookup:       65ms

TCP/IP Connect:   40ms

HTTPS Handshake:  114ms

ServerConnected:  13:58:41.703

FiddlerBeginRequest:  13:58:41.816

ServerGotRequest: 13:58:41.817

ServerBeginResponse:  14:00:36.790

GotResponseHeaders:   14:00:36.790

ServerDoneResponse:   14:00:36.790

ClientBeginResponse:  14:00:36.790

ClientDoneResponse:   14:00:36.790


Overall Elapsed:  **0:01:55.198**