关于无服务器（Serverless）的讨论，我见过两种极端：要么觉得它能解决一切问题，要么认为这是个错误。但真实的情况比这两种极端都更有价值。
每个推销无服务器的人都会强调三点：不用管服务器、自动扩缩容、按用量付费。技术上都没错，但都不是全部真相。我上线过真正的生产级无服务器API——Go语言写的Lambda，挂在API Gateway后面，支撑真实的用户产品。我不是来劝退你的，对于合适的工作负载，它确实很棒。
但宣传与现实之间的差距是具体的，提前知道这些，能让你在早期做决策时省大钱。
冷启动真实存在，但和你想的不一样
Lambda冷启动发生在AWS需要为你的函数新建执行环境时：运行时启动，初始化代码运行，然后才是处理函数执行。Go语言在arm64架构上通常是50-150毫秒；Node.js或Python如果依赖很重，可能达到500毫秒到2秒。
没人重点说的是：冷启动是概率性的，不是必然发生。流量稳定时，大多数调用会命中热实例。P50甚至P95都很少看到，但在P99及更极端的尾部延迟里会冒出来——就在流量 spike 之后，或者周末安静后的第一个请求。
实用建议：在添加预置并发（Provisioned Concurrency）之前，先用真实流量在生产环境做分析。预置并发花钱还增加复杂度。对大多数API来说，更聪明的做法是优化初始化代码：懒加载依赖、保持二进制文件小巧、只初始化第一个请求真正需要的东西。先解决实际问题，再碰昂贵的方案。
账单数学会让你意外
Lambda定价纸上看起来简单：按请求次数和GB-秒的执行时间付费。低流量时几乎免费。但规模上来后，或者特定使用模式下，惊喜就来了。
最坑团队的场景：每次调用都做实质性工作的Lambda。解析大载荷、内存中转换、多次下游调用。这些函数运行时间长、内存用得多，单次调用成本比定价页面暗示的涨得快得多。
几个真实工作负载的数字：
• 轻量级REST Lambda（Go，128MB，平均20毫秒）：每百万请求约0.40美元
• 重处理型Lambda（Node，512MB，平均800毫秒）：每百万请求约8.00美元
每百万请求20倍的成本差距，在有真实流量时累积很快。相比跑服务器还是便宜，但"无服务器总是低成本"这个假设需要验证，不能想当然。
API Gateway的定价也常被忽略。HTTP API每百万请求3.50美元，高流量的公开端点可能让Gateway比它前面的Lambda还贵。得算清总账。
调试和可观测性是另一回事
本地开发时，你可以单步调试、打断点、快速迭代。无服务器环境里，这些都没了。日志分散在CloudWatch，跨多个函数追踪请求需要额外工具（X-Ray或第三方），本地模拟AWS服务永远不是1:1还原。
我见过团队在调试生产问题时，花在"搞清楚到底发生了什么"上的时间，比修bug本身还长。这不是不能克服，但要把这部分成本算进决策里。
什么时候该用，什么时候不该
无服务器在几种场景下是 genuinely excellent：流量波动大、事件驱动处理、快速原型验证、团队不想管基础设施。但在这些情况下要三思：持续高流量（成本曲线会翻转）、需要严格延迟保证（尾部延迟问题）、复杂有状态交互、团队缺乏相应的运维经验。
关键不是选边站，而是知道具体 trade-off 在哪里，然后在项目早期、改动还便宜的时候，做出知情选择。
热门跟贴