Azure Consumption计划扩缩容机制及静态变量共享问题咨询

核心结论 #

Azure Consumption计划的函数扩缩容确实具备VM亲和性——多个函数实例（工作进程）会被调度到同一台底层VM上，而非每个实例独占一台VM。

扩缩容的具体机制 #

• 当负载上升时，Azure会优先在已有的VM主机上启动新的函数工作进程（实例），直到该VM的CPU、内存等资源达到阈值，才会部署新的VM。
• 函数应用的最大实例数限制（默认100，可通过支持工单提升）是指整个应用的总工作进程数，而非VM数量。单台VM通常能承载多个工作进程，这也是总实例数限制存在的原因之一。

对共享静态变量（如数据库连接池）的影响 #

• 同一工作进程内的多次函数调用会共享静态成员变量，比如静态初始化的数据库连接池，能有效复用连接，减少资源消耗。
• 同一VM上的不同工作进程（实例）属于独立的进程空间，不会共享静态变量，每个进程会维护自己的连接池实例。
• 这种机制下，总数据库连接数是「工作进程数 × 单进程连接池大小」，而非「VM数 × 单VM连接池大小」。但因为单VM能承载多个进程，实际VM数量远小于工作进程数，不会出现每个实例独占VM导致的连接数爆炸问题。

内容的提问来源于stack exchange，提问作者Rob Reagan