Cloud Frontier

简介

Serverless 计算已成为云架构中的热门话题。但与任何工具一样，它既有优势也有短板。在构建和维护多个 serverless 应用后，我总结出了它适合的场景与易产生问题的场景。本文分享这些经验教训。

Serverless 有益的场景

1. 事件驱动的工作负载

Serverless 在代码响应事件（文件上传、数据库变更、HTTP 请求）时表现优异。其按执行计费的模式意味着你无需为闲置时间付费。

// AWS Lambda handler for image resizing
exports.handler = async (event) => {
  const bucket = event.Records[0].s3.bucket.name;
  const key = event.Records[0].s3.object.key;
  // resize and save
  return { statusCode: 200 };
};

Enter fullscreen mode Exit fullscreen mode

2. 流量多变或不可预测

如果你的应用会出现偶发流量高峰（如营销活动），serverless 可即时自动扩展，无需预置峰值容量。

3. 快速原型与 MVP

你可以在几分钟内部署一个功能完整的 API，而无需管理服务器，从而加速反馈循环。

4. 微服务与胶水代码

Serverless 函数非常适合连接其他服务的小型、单一用途服务（例如处理 webhook、数据转换）。

Serverless 有害的场景

1. 长时间运行的进程

大多数云提供商都有最大执行超时限制（例如 AWS Lambda 为 15 分钟）。批处理或视频转码可能会触及此限制。

# This will timeout if processing takes > 15 minutes
def handler(event, context):
    process_large_file(event['file'])
    return {'done': True}

Enter fullscreen mode Exit fullscreen mode

2. 冷启动

在一段时间无活动后，首次请求可能会出现数秒的延迟，这对延迟敏感的应用（如同步 API）非常不利。

3. 有状态应用

Serverless 设计为无状态。如果需要持久连接（如 WebSocket）或本地状态，你必须借助 Redis 或 DynamoDB 等附加服务，增加复杂性。

4. 高而稳定的负载

如果你的服务 24/7 全天候运行且流量恒定，预置服务器通常更省钱。Serverless 的按调用计费成本可能会超过固定月租的服务器费用。

5. 复杂的调试与测试

本地模拟（例如 SAM、serverless-offline）有帮助，但永远无法完全复制生产环境。跨函数的分布式追踪调试会非常痛苦。

实践建议

适合使用 Serverless 的场景：

  • 工作负载为事件驱动或间歇性
  • 你希望尽量减少运维开销
  • 你需要从零开始的快速扩展

不适合使用 Serverless 的场景：

  • 存在长时间运行或有状态的进程
  • 需要一致的低延迟（冷启动会造成影响）
  • 流量恒定且量大

结论

Serverless 是一种强大的范式，但并非万能解药。在采用之前，请评估工作负载的特性。使用得当，它能降低复杂度和成本；使用不当，则会带来新问题。请明智选择。