主流平台对比：AWS Lambda、Azure Functions、Google Cloud Functions、阿里云函数计算核心特性对比
说实话，每次有朋友问我「Serverless 选哪家」，我都得先反问一句：你的业务在哪个云上？
这不是敷衍。我这些年折腾过 AWS、阿里云、Google Cloud，也帮客户迁移过几次函数计算平台。说白了，各家都有自己的「脾气」。你选对了，开发效率翻倍；选错了，后面改起来真是头疼。
今天我就把四个主流平台的核心特性摊开来聊聊。嗯，咱们不搞那种「ABCD 优缺点罗列」的八股文，我直接说人话，讲干货。
一、运行时与语言支持
先看最基础的东西——你的代码能用什么语言写。
| 特性 | AWS Lambda | Azure Functions | Google Cloud Functions | 阿里云函数计算 |
|---|---|---|---|---|
| 原生支持语言 | Node.js、Python、Java、Go、.NET、Ruby、自定义运行时 | C#、Java、JavaScript、Python、PowerShell、TypeScript | Node.js、Python、Go、Java、.NET、Ruby、PHP | Node.js、Python、Java、Go、PHP、.NET、自定义运行时 |
| 自定义运行时 | ✅ 支持（通过 Runtime API） | ✅ 支持（通过自定义处理程序） | ⚠️ 有限支持 | ✅ 支持（通过 Custom Runtime） |
| 冷启动优化 | Provisioned Concurrency | Premium Plan 预分配实例 | 无内置方案 | 预留实例 + 单实例多并发 |
我个人习惯用 Python 和 Go 写函数。AWS Lambda 的自定义运行时最灵活，我曾在上面跑过 Rust 编译的二进制，效果不错。阿里云这边，单实例多并发这个特性很实用——说白了就是一个实例能同时处理多个请求，冷启动次数直接砍半。
二、触发器和集成生态
函数计算不能孤立存在。它得跟其他云服务「串」起来，才算真有用。
你想想看，一个函数如果只能通过 HTTP 调用，那跟普通 API 有什么区别？Serverless 的威力在于事件驱动——文件上传了、数据库变了、消息队列来了，自动触发函数执行。
| 触发器类型 | AWS Lambda | Azure Functions | Google Cloud Functions | 阿里云函数计算 |
|---|---|---|---|---|
| HTTP 触发器 | ✅ API Gateway | ✅ 内置 HTTP 触发器 | ✅ 内置 HTTP 触发器 | ✅ 内置 HTTP 触发器 |
| 对象存储 | S3 | Blob Storage | Cloud Storage | OSS |
| 消息队列 | SQS、SNS、Kinesis | Service Bus、Event Grid | Pub/Sub | RocketMQ、RabbitMQ、Kafka |
| 数据库变更 | DynamoDB Streams | Cosmos DB Change Feed | Firestore | 表格存储、RDS 变更捕获 |
| 定时任务 | CloudWatch Events | Timer Trigger | Cloud Scheduler | 定时触发器 |
我在项目中遇到过一个问题：客户想把 OSS 里的图片上传后自动生成缩略图。AWS 那边用 S3 + Lambda 很顺，但阿里云这边要注意——OSS 触发器有事件类型限制，你得确认是 PutObject 还是 PostObject 事件。嗯，这个坑我踩过。
三、计费模型与成本
说白了，选平台最后看的还是钱。但 Serverless 的计费模型比传统服务器复杂得多。
| 计费维度 | AWS Lambda | Azure Functions | Google Cloud Functions | 阿里云函数计算 |
|---|---|---|---|---|
| 免费额度 | 每月 100 万次请求 + 40 万 GB-秒 | 每月 100 万次请求 + 40 万 GB-秒 | 每月 200 万次请求 + 40 万 GB-秒 | 每月 100 万次请求 + 40 万 GB-秒 |
| 计费粒度 | 1 毫秒 | 1 毫秒（Premium Plan） | 100 毫秒 | 1 毫秒 |
| 并发限制 | 账户级别 1000 并发 | 按计划不同 | 区域级别 3000 并发 | 按量实例上限可调整 |
| 出站流量 | 按量计费（较贵） | 按量计费 | 按量计费 | 按量计费（国内便宜） |
我建议你重点关注两个数字：计费粒度和并发限制。AWS 和阿里云都是 1 毫秒计费，Google Cloud 是 100 毫秒。什么意思？如果你的函数平均执行 50 毫秒，在 Google Cloud 上会被算成 100 毫秒，成本直接翻倍。
另外，阿里云在国内的出站流量价格比 AWS 便宜不少。如果你的用户主要在国内，这个差价值得算一算。
四、性能与冷启动
冷启动是 Serverless 的老大难问题。我见过一个客户，他的函数平时跑 200ms，冷启动时直接飙到 5 秒。用户体验？嗯，用户直接投诉了。
为什么会这样？因为函数实例从零启动需要加载运行时、下载代码、初始化依赖。这个过程在 Java 和 .NET 上尤其慢。
| 优化手段 | AWS Lambda | Azure Functions | Google Cloud Functions | 阿里云函数计算 |
|---|---|---|---|---|
| 预留实例 | Provisioned Concurrency | Premium Plan 预分配 | 无 | 预留实例 |
| 单实例多并发 | 不支持 | 不支持 | 不支持 | ✅ 支持 |
| 代码包大小限制 | 250MB（含层） | 1GB（Premium Plan） | 500MB | 500MB |
| 临时磁盘空间 | 512MB - 10GB | 1GB - 10GB | 2GB | 10GB |
我个人觉得，阿里云的「单实例多并发」是个很聪明的设计。它让一个实例可以同时处理多个请求，相当于把冷启动的成本摊薄了。AWS 的 Provisioned Concurrency 也能解决冷启动，但要额外付费——说白了就是花钱买预热。
五、开发与调试体验
写函数容易，调试函数难。这是很多初学者的痛点。
| 开发工具 | AWS Lambda | Azure Functions | Google Cloud Functions | 阿里云函数计算 |
|---|---|---|---|---|
| 本地调试 | AWS SAM CLI | Azure Functions Core Tools | Functions Framework | Fun / Serverless Devs |
| IDE 集成 | VS Code、JetBrains | VS Code（最佳） | VS Code、Cloud Code | VS Code、IntelliJ |
| 日志与监控 | CloudWatch | Application Insights | Cloud Logging | 日志服务 SLS |
| 部署方式 | SAM、CDK、Terraform | ARM、Terraform、VS Code 发布 | gcloud CLI、Terraform | Serverless Devs、Terraform |
Azure Functions 在 VS Code 里的集成体验是最好的，没有之一。你装个插件，点几下就能创建、调试、发布一条龙。AWS 的 SAM CLI 也不错，但配置起来稍微复杂点。
阿里云的 Serverless Devs 工具链这两年进步很大。我记得 2021 年的时候还不太好用，现在支持多环境部署、灰度发布，已经能跟 AWS SAM 掰手腕了。
六、选型建议
好了，说了这么多，到底怎么选？我直接给结论：
- 海外业务、技术栈灵活：选 AWS Lambda。生态最成熟，社区资源最多，遇到问题基本都能搜到答案。
- 微软技术栈、企业级应用：选 Azure Functions。跟 .NET、Active Directory、Office 365 集成得天衣无缝。
- 数据密集型、AI/ML 场景：选 Google Cloud Functions。跟 BigQuery、Vertex AI 配合起来很舒服。
- 国内业务、成本敏感：选阿里云函数计算。国内节点多，出站流量便宜，单实例多并发能省不少钱。
最后说一句：别纠结「哪个最好」。没有最好的平台，只有最适合你业务的平台。你想想看，如果你的用户全在中国，非要去用 AWS 东京节点，延迟和成本都划不来。
嗯，这一章就到这儿。下一章咱们聊聊函数计算的架构设计模式，到时候我会拿一个真实项目来拆解。