备案站点的 Serverless 函数计算运维

免运维不等于没有运维工作，只是运维对象换了

Serverless 函数计算承诺的核心卖点是"不用管服务器、不用管扩缩容，写好函数逻辑直接部署就行"。这个承诺在很大程度上是真的——确实不再需要自己配置和维护服务器实例。但它并没有消灭运维工作，只是把运维的对象从"服务器和进程"换成了"函数的调用行为本身"，而这些新对象带来的问题，很多都是传统常驻服务架构里完全不存在的新约束，照搬以前的运维经验往往会直接踩坑。

关键要点

• 冷启动延迟不是一个可以被完全消除的问题，只能通过架构和配置手段缓解，运维要接受它的存在并设计相应的应对策略。
• 按请求和执行时长计费的模型下，成本曲线和常驻服务完全不同，一些看似合理的优化思路反而可能推高账单。
• 并发实例数通常有上限，一旦触顶，表现为新请求被拒绝或排队，这和传统架构下"资源不够就扩容"的直觉完全不同。
• 函数天然无状态，这个约束彻底颠覆了常驻服务里习以为常的本地缓存和连接池复用思路，需要重新设计这部分逻辑。

冷启动：函数计算特有的延迟来源

函数长时间没有被调用后，承载它运行的环境会被回收。下一次请求到来时，需要重新初始化一个新的执行环境，这个初始化过程（代码加载、运行时启动、依赖初始化）本身需要耗费时间，这段时间直接体现在这次请求的响应延迟里，这就是冷启动延迟。它和常驻服务下的实例预热问题性质上有相似之处（都是"刚启动的执行单元表现不如稳态"），但函数计算下冷启动发生得更频繁、影响面也更直接，具体的预热耗时来源分层可以参考 实例启动预热与慢启动治理 中关于连接池、运行时优化等多层延迟来源的讨论，只是在函数计算场景下这些延迟被压缩进了单次请求的响应时间里，对用户的感知更直接。

缓解冷启动的常见手段：

• 预留一定数量的常驻执行环境：代价是失去了"完全按需付费、空闲时零成本"这个核心优势的一部分，本质上是用成本换延迟稳定性。
• 定期发送低频的保活请求：防止执行环境被系统判定为空闲并回收，但这个手段的效果依赖平台的具体回收策略，且本身会产生额外的调用成本。
• 精简函数的依赖和初始化逻辑：减少冷启动时真正需要初始化的内容，这是少数没有额外成本代价、纯粹靠优化就能见效的方向。

选择哪种手段取决于业务对延迟的敏感度：面向用户的实时交互场景，冷启动延迟往往不可接受，需要投入成本去缓解；后台异步处理场景，偶尔的冷启动延迟通常可以接受，不值得为此付出额外成本。

成本模型的反直觉陷阱

常驻服务的成本思维是"实例规格和数量决定成本，使用率越高越划算"。函数计算的计费通常按调用次数和实际执行时长计算，这套模型下有几个容易被忽视的反直觉之处：

直觉	函数计算下的实际情况
"函数执行得越快，成本肯定越低"	通常是对的，但如果执行时间短到被平台的最小计费单位兜底，再怎么优化速度也无法进一步降低单次成本
"调用量越大，整体成本应该线性增长"	大体如此，但如果函数内部有重复的冷启动开销，调用模式零散（而不是集中批量）会让总成本明显偏高
"免运维所以整体成本肯定比自己维护服务器低"	对于调用量大、负载稳定持续的场景，常驻服务的整体成本反而可能更低，函数计算的成本优势主要体现在负载波动大、有大量空闲时段的场景

一个常见的成本陷阱是把原本适合常驻处理的高频稳定负载硬搬到函数计算上，结果是账单远超预期，还要承受冷启动带来的延迟问题，两头都不占优。评估是否适合用函数计算，关键看业务负载的形态——波峰波谷明显、大量时间段接近空闲的场景，函数计算的成本优势才能真正体现出来；持续高负载的场景，这个判断需要结合实际账单仔细核算，而不是想当然地认为"免运维就一定便宜"。

并发实例数上限：触顶之后的连锁反应

函数计算平台通常对同一个函数的并发执行实例数设有上限（防止失控的调用量无限消耗资源）。这个上限触顶之后的表现，和传统架构下"资源不够就临时扩容顶一下"的直觉完全不同——新到达的请求可能直接被限流拒绝或者排队等待，而不是像常驻服务那样至少还能靠现有实例硬扛一段时间。

这个限制对流量设计的影响是：

• 突发流量场景需要提前评估并发上限是否足够，而不是假设平台会无限弹性应对，这和传统架构下容量规划的思路是一致的，见 容量规划与弹性伸缩 中关于提前压测拿到容量基线的讨论，只是函数计算下"基线"换成了并发实例数上限而不是单机承载能力。
• 一个函数的并发触顶，不会影响其他独立的函数，这是函数计算天然的隔离优势，但如果多个业务逻辑共用同一个函数，就会互相影响彼此的并发配额，这类设计上的耦合需要在拆分函数边界时提前考虑。
• 上游调用方要有应对限流的能力，被拒绝或排队的请求如何重试、如何降级，这部分逻辑不能假设平台会自动兜底，重试与退避的通用做法见 超时设置与重试策略。

无状态约束：彻底颠覆本地缓存和连接池的思路

函数计算的执行环境是临时的、随时可能被回收，这意味着函数内部不能依赖任何需要长期保持的本地状态。这对习惯了常驻服务架构的运维和开发来说是一个需要彻底调整思路的约束：

• 本地内存缓存不再可靠：缓存可能在下一次调用时就已经不存在（换了一个全新的执行环境），常驻服务里行之有效的本地缓存策略在这里基本失效，需要转向外部共享缓存，具体做法见 缓存与 Redis 运维。
• 数据库连接池难以常规方式复用：每次冷启动都需要重新建立连接，如果调用量大且冷启动频繁，可能对数据库造成大量短连接的冲击，这和连接池设计里强调的"长连接复用"原则正好相反，缓解手段通常需要专门的连接代理层来吸收这部分压力，连接池设计的一般原则见 数据库连接池与连接数治理，只是函数计算下需要额外一层代理来弥补无法常规复用连接的问题。
• 任何需要跨调用保持的状态都必须外置：这其实和分布式系统里"服务无状态、状态外置到专门的存储"的原则是一致的，函数计算只是把这个原则执行得更彻底、给的选择余地更少。

可观测性的特殊难度

函数计算下的可观测性比常驻服务更有挑战，原因在于执行环境是短暂且大量的：传统的"登录到某台机器查日志"的排查方式完全不适用，每次调用可能运行在完全不同的执行环境里。有效的做法是：

• 每次调用都要有明确的请求标识贯穿日志，因为无法再靠"这台机器"来定位问题，只能靠标识把同一次调用的全部记录串联起来，这和分布式系统里请求标识透传的思路是一致的，见 日志规范与集中检索 中关于贯穿请求标识的讨论。
• 冷启动和执行耗时要分开统计，混在一起的平均耗时无法反映真实的性能分布，也无法判断延迟问题是出在冷启动还是函数逻辑本身。
• 错误和超时的归因要更谨慎：函数计算的网络和运行环境受平台托管，出现问题时需要先分辨是业务逻辑的问题还是平台层面的问题，不能完全照搬自建服务器环境下的排查经验。

常见坑

• 把高频稳定负载硬搬到函数计算上：账单远超预期，还要额外承受冷启动延迟，没有发挥出函数计算真正的成本优势。
• 假设平台会无限弹性应对突发流量：并发实例数触顶后请求被直接拒绝，上游没有相应的降级和重试逻辑。
• 继续沿用常驻服务的本地缓存和连接池思路：缓存频繁失效、数据库被大量短连接冲击，却没意识到根因是架构约束本身。
• 只统计整体响应耗时，不区分冷启动和实际执行时间：无法判断延迟问题的真实来源，优化方向容易找错。
• 为了彻底消除冷启动而大量预留常驻执行环境：变相把函数计算用成了常驻服务，却没有获得常驻服务应有的运维便利性，两头的优势都没拿到。

常见问题

什么样的业务场景最适合用函数计算？

负载波动明显、存在大量空闲时段的场景最能体现函数计算的成本优势，比如事件触发型的异步处理、调用频率不稳定的后台任务。持续高负载、对延迟极度敏感且不能接受冷启动的核心链路，需要更谨慎评估，有时常驻服务反而更合适。

冷启动问题能不能完全消除？

无法完全消除，只能缓解。即使通过预留常驻执行环境大幅降低冷启动发生的概率，极端情况下（比如并发量突然超过预留的常驻数量）仍然可能触发冷启动。运维上应该接受冷启动是这套架构的固有特性，设计相应的应对策略，而不是追求彻底杜绝。

函数计算下怎么处理数据库连接的问题？

常见做法是引入一层连接代理，由代理维护到数据库的实际连接池，函数通过轻量的方式连接到代理而不是直接对数据库建立大量短连接。这本质上是把连接池复用的职责从函数本身转移到了一个常驻的中间层。

从常驻服务迁移到函数计算，最容易踩的坑是什么？

最常见的是直接照搬常驻服务的代码逻辑，继续假设本地状态（缓存、连接）可以长期保持，上线后才发现大量缓存频繁失效、数据库连接压力异常。迁移前应该先梳理清楚代码里有哪些隐含的状态假设，逐一改造为无状态或外置状态的方式。

资料来源

主流云厂商函数计算产品关于冷启动、并发限制与计费模型的公开文档，以及无服务器架构领域关于可观测性与状态管理的通用工程实践。本文为通用运维说明，仅供参考，具体限制与计费细节以各平台最新官方文档为准。