FaaS 的理想国
2019 年前后，Serverless 是技术圈最火的话题之一。「不用关心服务器」「按调用次数付费」「自动弹性伸缩」——这些叙事听起来像是运维领域的终极答案。我们也在那个时间点开始大规模推广函数计算，目标是让前端和业务开发同学可以零运维地部署服务端逻辑。
初期的反馈确实不错。简单的 API 聚合、定时任务、Webhook 处理这些场景，用函数计算写起来又快又轻。团队一度认为找到了银弹。
现实的冷水
问题在规模扩大后接踵而来。冷启动延迟是第一个被业务方频繁投诉的问题——一个 Node.js 函数首次调用可能需要 800ms 到 2s，对于用户侧 API 来说完全不可接受。虽然可以通过预留实例来缓解，但这就回到了「为闲置资源付费」的老路上。
更深层的问题是状态管理。真实的业务逻辑很少是纯粹无状态的，数据库连接池、缓存、会话状态，这些东西在函数计算的模型里都变得异常棘手。开发者为了绕过这些限制写出的代码，往往比传统方式更复杂、更难调试。
真正适合的场景
经过两年的实践，我们对函数计算的定位做了大幅修正。它真正发光的场景是：事件驱动的异步处理（如图片压缩、消息转发）、低频但需要弹性的批处理任务、以及作为 BFF 层处理简单的数据聚合。
关键认知是：FaaS 不是传统服务的替代品，而是架构工具箱中的一种补充。把它用在合适的地方，效率提升是显著的；把它当万能钥匙，就会陷入与范式对抗的困境。
反思：技术传播中的泡沫
函数计算的起落其实是技术传播周期的典型缩影。一项新技术出现时，社区倾向于放大它的优势、忽略它的约束。作为平台方，我们的教训是：推广一项技术之前，要先诚实地画出它的边界，而不是被 Hype Cycle 带着走。
相关文章