Serverless 的适用边界

发布时间:2026-04-14 17:38

不用管服务器，代码部署上去按调用计费——这是 Serverless（无服务器架构）最打动人的地方。它确实好用，但边界同样清晰，弄清适用场景比学会用法更重要。 一、它是什么形态 开发者只写函数，平台负责运行环境、伸缩与容错，计费按调用次数与运行时长算。请求来了起实例，没请求就不花钱。代价之一是冷启动：函数闲置一段时间后，首次调用要现起实例，多出几百毫秒到秒级延迟，对延迟敏感的业务要留意。 二、适合的场景 突发型负载最合适：图片压缩、消息回调（Webhook）、定时任务、活动落地页。这类场景请求量波动大、单次执行短，平时近乎零成本，高峰自动扩上去。一个每天只跑一次的报表任务、一个只在提交订单时触发的校验函数，用云服务器常驻反而是浪费。 三、不划算的场景 常驻型高负载要算账：7×24 满负荷调用折算下来，未必比包年云服务器便宜，性能还不受自己控制。长连接、有状态服务、运行时间超长的任务，也不适合函数模型。核心交易链路这种要求稳定可控的负载，常规云服务器更稳妥。试算方法很简单：把预估月调用量乘以平均执行时长，与包年云服务器的报价放在一起比，十分钟出结论。还有一个容易忽略的点：函数并发上限、依赖服务的配额都在平台侧，容量规划要按平台的限制反推架构。 四、厂商锁定要评估 函数运行时、事件触发格式、配套存储服务都与平台绑定，迁移要改代码。选型时优先用开放框架，把业务逻辑与平台接口隔离开，给将来留一条迁移的路——这和买任何托管服务是一个道理。 选型前先问一句：这个功能的负载曲线是脉冲还是平稳。脉冲型交给函数，平稳型交给云服务器，各归其位，成本与稳定性都不吃亏。