主流云厂商 Serverless 计算服务对比
做 Serverless 离线数据处理，选对计算服务是第一步。我这些年接触过不少团队，上来就拍脑袋选 Lambda，结果跑批处理任务时被冷启动和超时限制搞得焦头烂额。
今天咱们把四大云厂商的 Serverless 计算服务拉出来遛遛。AWS Lambda、阿里云函数计算、Azure Functions、Google Cloud Functions，看看它们各自擅长什么，短板在哪。
核心能力速览
先看一张对比表，心里有个底：
| 特性 | AWS Lambda | 阿里云函数计算 | Azure Functions | Google Cloud Functions |
|---|---|---|---|---|
| 最大内存 | 10GB | 32GB | 14GB | 8GB |
| 超时时间 | 15分钟 | 24小时 | 10分钟（无服务器） | 9分钟 |
| 临时磁盘 | 512MB - 10GB | 10GB | 1GB | 2GB |
| 并发限制 | 1000（可提） | 100（可提） | 200（可提） | 3000 |
| 冷启动 | 中等 | 较快 | 中等 | 较快 |
| 自定义运行时 | 支持 | 支持 | 支持 | 有限 |
关键发现：阿里云函数计算在超时时间和内存上限上明显领先，适合长时间运行的离线任务。AWS Lambda 生态最成熟，但 15 分钟超时是个硬伤。
AWS Lambda：生态之王，但有限制
AWS Lambda 是 Serverless 的鼻祖。我最早接触 Serverless 就是用它，那时候连 VPC 支持都没有，现在功能已经非常完善了。
优势：
- 事件源极其丰富：S3、SQS、SNS、DynamoDB Streams、Kinesis……几乎 AWS 所有服务都能触发 Lambda
- 工具链成熟：SAM、Serverless Framework、CDK 都支持得很好
- 社区资源多：遇到问题基本都能搜到解决方案
痛点：
- 15 分钟超时：处理大文件或复杂 ETL 时很尴尬。我有个项目需要处理 500MB 的 CSV 文件，Lambda 跑不完，最后只能拆成多个小任务
- 冷启动：Java 和 .NET 运行时尤其明显，Python 和 Node.js 还好
- 临时磁盘只有 10GB：解压大文件或处理中间数据时捉襟见肘
我的经验：如果非要用 Lambda 做离线处理，建议配合 Step Functions 做状态编排，把一个大任务拆成多个小 Lambda 接力跑。或者直接用 Lambda 触发 ECS Fargate 任务，把重活交给容器。
阿里云函数计算：离线任务的隐藏高手
说实话，阿里云函数计算在离线场景下的表现让我挺意外的。它支持最长 24 小时的执行时间，这在国内厂商里是独一份。
亮点：
- 超长超时：24 小时，跑批处理任务完全够用
- 大内存：32GB，可以加载大模型或处理海量数据
- 性能实例：提供预留实例模式，冷启动几乎为零
- 与阿里云生态集成：OSS、SLS、DataWorks 都能直接触发
需要注意：
- 并发默认只有 100，需要提工单申请
- 国际版功能比国内版少一些
- 文档质量参差不齐，有些细节需要自己踩坑
避坑指南：我曾经在阿里云函数计算上跑一个数据清洗任务，用了 20GB 内存，结果账单吓我一跳。后来发现是没开「性能实例」的预留模式，每次冷启动都重新加载数据，浪费了大量资源。记住：长时间任务一定要用预留实例。
Azure Functions：企业级集成，但有点重
Azure Functions 在 .NET 生态里是王者，跟 Office 365、Dynamics 365 的集成非常丝滑。如果你公司用的是微软全家桶，选它准没错。
优势：
- 与 Azure 服务深度集成：Blob Storage、Event Grid、Service Bus 触发都很方便
- Durable Functions：内置状态管理，适合编排复杂工作流
- 多种计划模式：消费计划、高级计划、专用计划，灵活度很高
短板：
- 消费计划下超时只有 10 分钟，高级计划可以到 60 分钟，但成本会上升
- 冷启动比 AWS Lambda 还慢，尤其是 C# 运行时
- 临时磁盘只有 1GB，处理大文件很吃力
我的建议：如果你用 Azure，离线任务建议用 Durable Functions 做编排。它能把一个长时间任务拆成多个小步骤，每个步骤单独执行，还能自动重试和补偿。我帮一个金融客户做过数据对账系统，Durable Functions 处理了上百万条记录，稳得很。
Google Cloud Functions：轻量快速，但功能有限
Google Cloud Functions 给我的感觉是「小而美」。冷启动速度是四家里最快的，Python 和 Node.js 运行时基本感觉不到延迟。
优点：
- 冷启动极快：得益于 Google 的容器技术，启动时间通常在 100ms 以内
- 与 GCP 服务集成：Cloud Storage、Pub/Sub、Firestore 触发都很自然
- 并发上限高：默认 3000，适合高并发场景
缺点：
- 超时只有 9 分钟：比 AWS Lambda 还短，离线任务基本没法用
- 内存上限 8GB：处理大数据集时不够用
- 自定义运行时支持有限：只能用官方支持的几种语言
一句话总结：Google Cloud Functions 适合轻量级、实时性要求高的任务，比如图片处理、Webhook、数据校验。但做离线批处理？我劝你换个思路。
选型建议
说了这么多，到底怎么选？我个人的经验是这样的：
- 如果你在 AWS 生态里：Lambda + Step Functions 组合拳，或者直接用 Lambda 触发 ECS Fargate
- 如果你在阿里云生态里：函数计算直接上，24 小时超时和 32GB 内存足够应付大部分离线任务
- 如果你在 Azure 生态里：Durable Functions 是首选，或者用高级计划跑长时间任务
- 如果你在 GCP 生态里：Cloud Functions 只适合轻量任务，离线场景建议用 Cloud Run 或 Dataflow
最后提醒一句：别被「Serverless」这个词迷惑了。它只是不用你管服务器，不代表没有成本。我见过有人用 Lambda 跑 24 小时的任务，结果账单比买台服务器还贵。选型时一定要算清楚账，尤其是内存和运行时间这两个维度。
下一章咱们会深入讲如何用这些服务搭建一个完整的离线数据处理管道。到时候我会拿一个真实项目做例子，把踩过的坑都抖出来。