1.2 Serverless 的优势与劣势

1.2 Serverless 的优势与劣势

本节摘要：任何技术都有两面。Serverless 的甜头是自动伸缩、按需付费、不用运维、迭代快；苦头是冷启动、厂商锁定、调试难、状态管理麻烦、执行时长受限。本节把两边的账都算清楚，给你一个判断"该不该用"的框架，而不是一边倒的吹捧。

学完这节你能做到

阅读完本节，你应当能够：

1. 列出 Serverless 的主要优势和主要劣势
2. 解释冷启动、厂商锁定、执行时长限制各自的成因和影响
3. 对一个具体场景，判断 Serverless 的利弊孰大
4. 知道哪些坑可以通过架构手段缓解

一、为什么这件事不能只看一面

新技术的宣传总是把优点喊得震天响，把缺点藏在小字里。Serverless 在"自动伸缩 + 按需付费"的叙事下看起来像银弹，但真用起来你会发现：冷启动让你的接口偶尔卡半秒、换了家云厂商函数几乎要重写、出了 bug 想本地复现都难。所以这一节的目标不是劝你用或不用，而是给你一张平衡的账单——收益和代价同时摆在台面上，你按自己的场景去称。

二、优势这一栏

把这些翻译成一句大白话：Serverless 把"省钱、省事、快"这三件很多团队最想要的东西打包给到了你，前提是你的场景吃得下它的代价。

三、劣势这一栏（重点）

优势大多一听就懂，劣势才是决定成败的地方，得多花点笔墨。

1. 冷启动（Cold Start）

函数长时间没被调用后，实例被回收归零；下次请求来时，平台要重新拉起运行时、加载代码和依赖，这段时间叫冷启动。它可能引入几十毫秒到几秒不等的额外延迟。

冷启动的严重程度取决于运行时（Java 通常比 Node/Python 慢）、代码体积（依赖越多越慢）和调用频率（越频繁越不容易冷）。对后台任务无所谓，但对要求 P99 在 100ms 以内的在线接口，冷启动就是真痛点。

缓解手段有不少：定时 ping 保活、减小打包体积、选冷启动更轻的运行时、用平台提供的预热能力。但要彻底消除很难——这是"缩放至零"这个特性的孪生兄弟，你享受了零成本待机，就得接受偶尔的冷启动。

2. 厂商锁定（Vendor Lock-in）

各家云厂商的函数签名、触发器配置、事件格式、SDK 都不一样。你在 A 云写好的函数，搬到 B 云往往要重写事件处理逻辑、换 SDK、改部署方式。这不是 Serverless 独有的，但 Serverless 把你和平台的耦合做得特别紧。

缓解办法：用 Serverless Framework 这类抽象层、把业务逻辑和平台 SDK 解耦（核心逻辑写成纯函数，入口层才接平台的事件对象）、关键路径避免深度依赖某家专有 BaaS。

3. 调试和监控难

函数是临时的、分布式的、事件驱动的，传统那种"登录机器 tail 日志、打断点"的调试方式基本失效。一次请求可能串起好几个函数和好几个 BaaS，链路一长，出问题难定位。

应对：从一开始就上分布式追踪和结构化日志，善用平台提供的链路追踪；本地用工具模拟事件来开发。

4. 状态管理麻烦

函数是无状态的，每次执行互相独立。这带来好处（好扩缩），但也意味着任何要跨请求保留的状态都得放到外部 BaaS（数据库、缓存）里。传统架构里一个内存变量能搞定的事，这里要绕一圈外部存储，复杂度和延迟都上去了。

5. 执行时长限制

FaaS 函数通常有最大执行时长（常见 15 分钟左右）。长时间运行的任务——批量数据处理、大文件转码、复杂计算——单次函数跑不完，得拆成多次或者用别的方案（如任务队列 + 多次触发，或专门的批处理服务）。

6. 性能调优空间小

你对底层基础设施的控制很少，CPU 型号、网络细节都摸不到，某些极致性能优化的场景 Serverless 给不了你足够的旋钮。

四、怎么判断该不该用

把上面两栏对照你的场景问自己几个问题：

• 流量是平稳的还是突发的？平稳大流量常驻服务，传统方案可能更划算；突发或低频，Serverless 更香。
• 对延迟敏感吗？要求极低且稳定的延迟，冷启动会咬你。
• 团队有没有运维？没有的话 Serverless 省心；有的话边际收益小一些。
• 任务跑得久吗？超过十几分钟就要拆分或换方案。
• 会不会要换云厂商？会的话，现在就得做解耦。

💡 一个实用判断：如果你的应用是"事件驱动、流量不平稳、单次处理较快"，Serverless 几乎是量身定做；如果是"常驻、长连接、超大计算密集"，谨慎。

五、优劣势的历史由来

把这张账单放回演化史里看，会发现每一条都不是偶然。免运维是四层抽象一脉相承的方向——每一代都在把更多底层细节收进平台，Serverless 只是走到了"运行环境"这一步。按需付费则是云计算计费粒度持续细化的一站：物理机按台、虚拟机按小时、容器按秒级资源、函数按毫秒按请求，计量越细，"为闲置买单"的部分越小。冷启动这个最大的劣势，同样有清晰的来源：它是"缩放至零"的直接代价，而缩放至零又是为了兑现"闲置零成本"的承诺——换句话说，冷启动不是工程缺陷，是设计权衡。理解到这一层，你对它的预期就会从"等厂商修好"变成"用架构手段管理它"。

厂商锁定也值得多说两句历史。早期云厂商刻意让各家函数签名、事件格式互不兼容，这是商业策略——用得越深越难走。社区的反应是造出抽象层框架（统一描述、多后端部署），而厂商近年也在事件格式标准化上达成了一些共识。趋势是锁定的"深度"在变浅，但专有 BaaS（尤其是深度绑定某家的数据库与认证）仍是锁定最重的部分。务实的策略不是追求"零锁定"（那是幻觉），而是把锁定的成本控制在"换云时重写入口层就能走"的程度。

劣势的另一面是它们逼出了更好的架构。 这个说法听起来像自我安慰，但确有实例：因为函数无状态，开发者被迫把状态外置到专门的存储，反而获得了水平扩展的自由；因为执行时长受限，长任务被拆成事件链，反而获得了失败重试的粒度；因为调试难，团队从第一天就上结构化日志和链路追踪——这些实践在传统架构里同样是最佳实践，只是 Serverless 把它们从"可选"变成了"必须"。不少团队回顾转型经历时的共识是：被强制执行的纪律，长期看是收益。

六、算一笔具体的成本账

空谈"低频省钱、高频可能更贵"不够直观，用一个假想但参数真实的小实验把账算出来。设一个接口，单次执行 200 毫秒、配置 512MB 内存，某云厂商函数计费约每百万次请求几十元、计算部分按毫秒内存积计费。若每天一万次调用，一个月约三十万次，费用大约在个位数到十几元人民币的量级；而承载它的最低配常驻服务器每月至少几十元。反过来，若每天一千万次调用，函数费用按比例放大到数百元，而三台常驻机器可能就扛住了——成本交叉点大致就落在这个量级附近。结论不在于具体数字（各家定价不同），而在于方法：拿你的真实调用量、单次时长代入计费公式画一条曲线，再画一条常驻方案的水平线，交点就是你的决策边界。 每次流量结构变化后重画一次。

本节要点回顾

• 优势：免运维、自动伸缩、按需付费、迭代快、平台兜底高可用。
• 劣势：冷启动、厂商锁定、调试难、状态管理麻烦、执行时长受限、调优空间小。
• 冷启动是"缩放至零"的孪生产物，能缓解但难根除。
• 厂商锁定靠"框架抽象 + 业务逻辑与平台 SDK 解耦"来缓解。
• 判断框架：看流量形态、延迟要求、运维人力、任务时长、迁移可能。

下一节把这些判断落到具体场景上，给你一张"适合 / 不适合"的场景地图。

五、优劣之外的第三维度：组织匹配度

优劣势对比之外，实践里更决定成败的是第三个维度——组织与 Serverless 的匹配度。三个匹配问题：其一，团队技能结构——Serverless 把工作重心推向事件编排、权限配置、可观测性，传统"装机上架"型运维团队需要转型期，没有转型配套的切换会留下能力真空。其二，调试与排障文化——Serverless 的黑盒性要求团队习惯"靠日志与追踪而非登机排查"的工作方式，习惯于"登上服务器看一眼"的组织会经历漫长的戒断反应。其三，供应商深度的接受度——深度使用平台特有能力（触发器、权限体系、托管服务）带来的效率，与迁移成本的增加同步发生——对"必须多云规避锁定"的组织，Serverless 的很多红利会被抽象层吃掉。三个匹配问题都不该由技术团队单独回答——它们本质是组织决策。把这一节加进选型材料，是对"Serverless 好不好"这类问题的最诚实回答：技术没有好坏，匹配才有。

再补一组量化锚点帮住"弹性"的想象：函数平台从零到千级并发的扩容通常在秒级完成（对比传统自建集群的分钟到小时级），从千级回收同样快——这种"呼吸式"的弹性是它对流量毛刺免疫的根源；但弹性的方向不对称要记住：扩容快、回收也快，冷启动的代价恰恰藏在"回收快"里——每一次回收都是下一次唤醒的冷启动。弹性与冷启动是同一枚硬币，优化其一常动另一，这对矛盾贯穿全书后面的性能话题。

最后补一条给决策者的沟通技巧：呈现 Serverless 提案时，永远同时给出"反向清单"——列出这项技术做不到的事（首字延迟的硬下限、平台故障的连带风险、深度定制的天花板）——反向清单不是示弱，是可信度的抵押品；只讲优势的提案在评审桌上折价，优劣并陈的方案才被当成专业意见对待。