无服务器架构指南

Serverless 被宣传成"不再需要服务器"，但这个说法掩盖了真正的交易。你并没有消灭服务器，只是把基础设施管理换成了一组新的约束：冷启动、执行时间上限、以及按请求计费的成本模型。做对了，Serverless 能砍掉闲置成本、缩放到零、并移除运维里最硬的部分。做砸了，它就是一个装满超时、失控账单和供应商锁定的火葬场。这篇指南是一棵"成本与约束决策树"：告诉你什么时候 Serverless 真能省钱、怎么选平台、以及复杂度反噬收益之前该停在哪儿。

想先理解 Serverless 通常架在其上的基础设施，我们的Docker 入门指南和云与 DevOps 英文版会把容器与部署的底子打好。一个闲置的 Serverless 函数不花你一分钱——整句话就概括了它的承诺。陷阱在于架构师读到这句话，把所有东西都搬成函数，然后发现第二个真实的流量高峰，交出的云账单让 CFO 直冒冷汗。Serverless 不是免费计算，它是"精细化计算"——你不再为闲置时间付费，改为为每次调用付溢价。真正的技能是判断哪些负载能优雅平移，哪些会悄悄把你的成本结构倒过来。

为什么云账单的形状会随 Serverless 改变

传统服务器逼你为"希望用到的容量"付费：你开一台 4GB 实例，全天候付费，祈祷利用率能到两位数。Serverless 把模型倒过来：按请求数、按 GB·秒的执行时间付费（由厂商的计费单位近似得出）。缓慢、可预测、常驻的流量在 Serverless 上通常更贵，因为有每次调用的开销。而尖峰、不可预测、或低频的流量通常便宜得多——因为那 90% 什么都没发生的空档，你不需要租机器。动手架构前，先用真实的请求模式对着两套计费都建模一遍。这张 Excel 省下的钱胜过任何框架选择，而这种"让成本匹配真实负载"的纪律，正是更广阔的云与 DevOps策略的核心。

冷启动问题真实存在，但没有吹得那么凶

冷启动让 Serverless 因为错误的原因出了名。冷启动是指函数在回第一个请求前，为启动一个全新运行时所花的那几百毫秒。厂商已经大幅改善：Lambda 的免费档和现代运行时比早年快得多，provisioned concurrency 也消除了关键路径上的惩罚。务实的建议是：低流量函数接受冷启动（用户几乎察觉不到），只给那几个真正需要亚百毫秒响应的端点保留热池。其余都能忍。错误在于把函数一视同仁——既把无聊的函数过度供应了，又给热点路径留余量不足。

最佳适配：API、Webhook 和事件处理

有几类负载几乎天生适合 Serverless。流量波动的 HTTP API 端点很合适，因为函数在突发之间会缩到零。第三方不规则触发的 Webhook 完美契合，因为它们低量且间歇。事件处理——响应文件上传、队列消息、数据库变更或物联网遥测——是 Serverless 的舞台，因为事件以不均匀的波浪到达，计算确实零星。一次性任务如缩略图生成、报表聚合也能干净地平移，每次短暂运行随即消失。这些模式能用最少意外换到规模化与成本的好处，所以团队往往会从这些场景入手，再往技术栈深处推广这个模型。

最差适配：长运行或常驻负载

在 Serverless 上吃亏的负载有两个共同特征：要么跑得长，要么一直跑。一个典型的反面代表是必须保持打开数分钟甚至数小时的 WebSocket 长连接，它和请求-响应模型天生打架。永不停歇的遥测流、实时聊天服务器、持续的重型计算，都会把你推向按秒计费，最终比一台便宜的常驻实例还贵。运行超过几分钟的后台任务会撞上执行时间上限，逼你编排一串链式函数，徒增延迟和复杂度。如果你的架构几乎每秒钟都是"热"的，固定实例（包括云厂商的容器）通常更便宜也更简单。选哪个模型取决于你真实的负载，而不是偏好——这正是软件架构基础里成本与适配思维要处理的。

让函数围绕无状态和异步来设计

你 build 的每个 Serverless 应用都必须假定运行时随时可能消失。这意味着：没有内存里的聊天状态、不指望本地文件持久化、绝不假设同一个实例会连续回答两个请求。把所有有意义的东西持久化到外部存储——数据库、对象存储或队列——并让每个函数幂等，这样一次重试产生相同结果。优雅的套路是 step functions 或工作流编排：一个函数触发下一个，异步工作流经队列流动，状态存在你掌控的存储里。当函数无状态且可重试时，厂商的伸缩就变成纯收益，而不是竞态条件的来源，无论流量如何波动，运维故事都能保持简单。

突发风扇展开，以及热情的成本

让 Serverless 有吸引力的那种伸缩，也照样能在风扇展开（fan-out）模式里烧你。想象一个 webhook 扇出成三千个下游函数去通知用户。在精细化计费下，这三千倍的爆发正是成本翻倍的地方，一个配错的 retry 还能把账单再放大。控制你的风扇：给每个函数设并发上限、能批量的就批量、设置带退避的合理重试策略、给误触发的集成加熔断器。这类成本与稳定性的权衡，和数据工程基础里处理批量与背压的思路一脉相承。从第一天就设预算告警，让异常变成一条通知，而不是下个月账单的惊喜。把 Serverless 成本当作主动监控的课题、而不是被动后果的运维者，项目才活得下去。

主流 Serverless 平台对比

计费因内存和地区而异，一定要用真实的请求量和时长去估算。免费档对原型和业余项目很慷慨，但绝不是持续生产流量的可靠模型。对多数 Serverless-first 的 Web 应用，Cloudflare Workers 和 Vercel Functions 开发者体验最友好，而 AWS Lambda 提供最深的企业级工具。

把 Serverless 嵌进更大的架构

Serverless 很少需要做成"全有或全无"的决定。务实的架构会保留一个稳定核心——数据库，可能再加一个固定容器服务来承载热点端点——然后把易变的边缘包成函数。稳定层扛住常驻的基础负载，函数吸收尖峰和批量工作。这种混合方案避开了两者的最坏情况：你既不为永远温热的工作负载付溢价每秒费率，也不为突发流量过度花钱租固定实例。从云计算英文版打下的基础出发，你按工作负载选计算单元，而不是强行让一个模型套所有东西——免费的粒度选择才是真正省钱的地方。

常见问题

Serverless 比固定虚拟机更便宜吗？

几乎完全取决于请求量和时长。尖峰或低流量负载在 Serverless 上更便宜，因为闲置时你一分不花。常驻或长运行负载通常固定实例更便宜。决定前先用真实的请求模式对两套计费建模。

什么是冷启动，2026 年我还要担心它吗？

冷启动是突发中函数为回第一个请求而启动全新运行时的那段延迟。现代运行时和 Cloudflare Workers 之类的平台已大幅削减它。只有当它对延迟关键的端点有影响时才要担心，那里可以用 provisioned concurrency 让路径保持温热。

能把数据库跑在 Serverless 上吗？

能，但要把数据存储（而不是逻辑）作为持久层。Aurora Serverless 这类托管数据库服务会随需求伸缩，而你的函数保持无状态。函数只读写数据库而不持有状态——这才是让 Serverless 保持可靠的模式。

怎么防止 Serverless 成本意外飙升？

从第一天就设预算告警、每个函数设并发上限、能批量就批量、控制重试策略，别让一个失败的集成放大调用数。把云账单当作主动监控的对象，而不是月末才核对一下。

什么时候绝对不能选 Serverless？

对持续、常驻的进程——如长连接的 WebSocket、永不停歇的遥测流、或一直跑的 CPU 密集型工作。按请求计费会惩罚时刻温热的工作负载，执行时间上限则惩罚任何必须长时间不间断运行的东西。更多容器与 Serverless 如何配合，可参考我们的Docker 入门指南。