Azure Functions 基础运行架构
Azure Functions是微软提供的无服务器计算服务，开发者只需编写业务逻辑代码，无需管理底层服务器。其运行依赖于Functions主机，主机负责接收触发请求、调度函数执行、管理实例生命周期。默认情况下，当请求量上升时，平台会自动增加实例数量来应对负载，同时单个实例内可以并行处理多个请求，这两个特性分别对应实例扩展模型和并发处理机制。
并发节流机制详解
并发节流的作用是限制单个函数实例同时处理的最大请求数量，避免单个实例负载过高导致响应变慢甚至崩溃。C# Azure Functions的并发配置主要通过host.json文件实现，不同触发类型的函数并发控制逻辑略有差异。
配置参数说明
在host.json中，核心的并发配置项位于extensions节点下，针对不同触发类型有对应的配置字段：
- http触发函数：通过
extensions.http.maxConcurrentRequests设置单个实例最大并发HTTP请求数 - 非HTTP触发函数（如队列、定时器）：通过
extensions.queues.batchSize和extensions.queues.newBatchThreshold控制单实例并行处理的消息数量 - 全局并发限制：
functionTimeout可设置单函数执行超时时间，间接辅助并发控制
配置示例
以下是一个限制HTTP触发函数单实例最大并发50，队列触发函数单批次处理10条消息的host.json配置示例：
{
"version": "2.0",
"extensions": {
"http": {
"maxConcurrentRequests": 50
},
"queues": {
"batchSize": 10,
"newBatchThreshold": 5
}
},
"functionTimeout": "00:05:00"
}
并发节流生效逻辑
当单个实例的并发请求数达到配置的上限后，新的请求不会被丢弃，而是会被放入等待队列，直到有正在处理的请求完成释放资源。如果等待队列也超过限制，平台才会触发新的实例扩容，这也是并发节流和实例扩展模型联动的核心逻辑。
实例扩展模型解析
实例扩展模型决定了Azure Functions平台何时增加或减少运行函数的实例数量，其触发逻辑和函数触发类型、当前负载、配置的并发限制都有关联。
扩展触发条件
平台会定期检查当前的请求负载和实例资源使用情况，满足以下条件时会触发实例扩容：
- 当前所有实例的并发请求数都达到配置的并发上限，且等待队列中的请求持续增加
- 非HTTP触发函数（如队列存储触发）的消息积压数量超过单实例处理能力，且现有实例都在满负荷运行
- 实例的CPU、内存等系统资源使用率持续超过80%，且负载没有下降趋势
扩展限制规则
实例扩展不是无限制的，平台设置了多层限制：
| 限制类型 | 规则说明 |
|---|---|
| 单区域最大实例数 | 默认每个Function App在同一区域最多可扩展到200个实例，可通过工单申请提升上限 |
| 扩容速度限制 | 每分钟最多新增10个实例，避免短时间内大量创建实例导致资源波动 |
| 缩容等待时间 | 当负载下降后，实例不会立即销毁，会保留10-20分钟以应对可能的负载反弹 |
扩展和并发节流的联动
并发节流配置会直接影响实例扩展的触发频率：如果并发上限设置过低，会导致少量请求就触发实例扩容，造成资源浪费；如果并发上限设置过高，单个实例负载过高，可能出现响应超时，同时扩容触发滞后导致请求堆积。开发者需要根据函数的实际资源消耗情况调整并发参数，平衡实例数量和单实例负载。
C# 函数内辅助控制逻辑
除了通过host.json进行全局配置，还可以在C#函数代码内部添加自定义的并发控制逻辑，比如使用信号量限制同时执行的业务逻辑数量：
using System;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Azure.WebJobs;
using Microsoft.Extensions.Logging;
public static class ThrottleDemo
{
// 定义信号量，限制同时执行的业务处理逻辑最多为10个
private static readonly SemaphoreSlim _semaphore = new SemaphoreSlim(10, 10);
[FunctionName("QueueTriggerDemo")]
public static async Task Run(
[QueueTrigger("myqueue-items", Connection = "AzureWebJobsStorage")] string myQueueItem,
ILogger log)
{
// 等待获取信号量，超出限制则等待
await _semaphore.WaitAsync();
try
{
log.LogInformation($"处理队列消息: {myQueueItem}");
// 模拟业务逻辑处理
await Task.Delay(1000);
}
finally
{
// 释放信号量
_semaphore.Release();
}
}
}
上述代码通过SemaphoreSlim实现了函数内部业务逻辑的并发控制，即使host.json的并发配置较高，也能避免单个实例内业务逻辑过度并行导致的资源问题。
常见问题解答
并发节流配置后为什么还是出现实例无限扩容？
可能是配置的并发上限过高，或者函数的单个请求执行时间过长，导致单实例并发始终无法达到上限，平台误判需要扩容。可以适当降低并发上限，或者优化函数执行逻辑缩短执行时间。
实例扩展的最大数量可以自定义吗？
默认最大实例数无法在配置文件自定义，如需调整需要提交工单到Azure支持团队申请修改对应Function App的实例上限。
HTTP触发和非HTTP触发的并发控制可以分开配置吗？
可以，host.json中extensions.http和extensions.queues等节点是独立的，分别对应不同触发类型的配置，不会互相影响。
Azure_FunctionsC#并发控制实例扩展模型函数节流修改时间：2026-07-23 03:54:13