从AWS Lambda转Azure Functions的新手技术疑问汇总

问题组1：函数应用始终显示运行状态的原因及计费规则 #

• 运行状态的原因：Azure Functions门户中显示的“运行状态”，指的是托管函数的实例/容器状态，而非函数执行状态：
  • 若使用消费计划：实例会处于待命状态（不会完全关闭），随时准备响应触发请求，因此门户显示“运行中”；
  • 若使用Premium/专用计划：实例会持续运行（除非手动停止应用），所以状态始终为“运行中”。
• 计费规则：
  • 消费计划：仅在函数被触发执行时计费，按执行时长、内存消耗及调用次数收费，闲置待命时无费用；
  • Premium/专用计划：按实例运行时间计费，只要实例处于运行状态（不管有没有函数执行）就会产生费用，只有停止实例或调整预配实例数为0时才会停止计费。
    对比AWS Lambda：Lambda是纯无服务器模式，仅在函数执行期间计费，而Azure Functions的计费逻辑因托管计划不同有明显差异。

问题组2：Premium计划EP1实例是否必须7×24运行，能否夜间关闭节省成本 #

• 并非必须7×24运行，你可以通过以下方式调整实例状态节省非高峰时段成本：
  1. 调整预配实例数：Premium计划的“预配实例”是为消除冷启动持续运行的实例，你可以手动或通过自动缩放规则（基于时间调度）在夜间将预配实例数调整为0；
  2. 自动化工具：使用Azure自动化账户或Logic Apps创建定时任务，在非高峰时段停止函数应用，高峰时段重新启动。
• 注意：如果将预配实例数设为0，下次触发函数时会出现冷启动；若只是停止函数应用，重启后同样会有冷启动，需根据业务对冷启动的容忍度选择方案。

问题组3：EP1实例支持的并行函数执行数及50个并发请求的处理能力 #

• 并行执行数上限：EP1实例（1 vCPU、3.5GB内存）的并行函数执行数没有固定值，取决于函数的资源消耗（CPU、内存占用），默认配置下通常支持10-15个并发执行。你可以通过调整FUNCTIONS_WORKER_PROCESS_COUNT（进程数）和每个进程的并发数优化，但受限于1vCPU的硬件上限，提升空间有限。
• 50个并发HTTP触发的处理：单个EP1实例无法处理50个耗时5分钟的并发任务——1vCPU的处理能力不足以支撑这么多同时运行的任务，会导致请求延迟甚至超时。此时Azure Functions会自动启动额外的EP1实例分担负载，直到达到你设置的缩放上限。

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