第2章：主流云厂商对比：AWS Lambda、Azure Functions、阿里云函数计算、腾讯云云函数的特性对比与选型建议
选Serverless平台，说白了就是选“靠山”。
我这些年接触过的项目，从初创公司到大型企业，几乎都绕不开这四个主流厂商：AWS Lambda、Azure Functions、阿里云函数计算、腾讯云云函数。每个平台都有自己的脾气，选错了，后面运维起来真的头疼。
今天我就把这四家的核心特性掰开揉碎了讲，最后再给点实在的选型建议。
2.1 四大平台核心特性速览
先看一张对比表，心里有个底。
| 特性维度 | AWS Lambda | Azure Functions | 阿里云函数计算 | 腾讯云云函数 |
|---|---|---|---|---|
| 运行时长上限 | 15分钟（同步调用） | 5分钟（默认），可调至10分钟 | 12小时（异步任务模式） | 24小时（最长） |
| 内存范围 | 128MB - 10GB | 128MB - 1.5GB（Premium计划可更高） | 128MB - 3GB | 64MB - 3GB |
| 并发限制 | 账户级别1000（可提额） | 按计划不同，无上限（实际受资源限制） | 按量付费模式无上限 | 默认500，可提额 |
| 支持的编程语言 | Node.js, Python, Java, Go, .NET, Ruby, 自定义Runtime | C#, Java, JavaScript, Python, PowerShell, TypeScript | Node.js, Python, Java, Go, PHP, .NET, 自定义Runtime | Node.js, Python, Java, Go, PHP, .NET |
| 冷启动优化 | Provisioned Concurrency（预留并发） | Premium计划 + 预热触发器 | 预留实例 | 预置并发 |
| 网络集成 | VPC、Direct Connect、PrivateLink | VNet集成、混合连接 | VPC、专有网络、NAT网关 | VPC、私有网络、NAT网关 |
| 计费粒度 | 1ms（毫秒级） | 1ms（Premium计划） | 1ms | 1ms |
2.2 AWS Lambda：生态之王，但有点贵
AWS Lambda是Serverless的鼻祖。我2017年第一次接触Serverless，用的就是它。
它的优势很明显：生态最成熟。你想集成S3、DynamoDB、API Gateway、SQS……几乎所有的AWS服务都能跟Lambda无缝对接。你想想看，一个电商订单处理流程，从API网关触发，到写入数据库，再到发送通知，全用Lambda串起来，代码量少得惊人。
但Lambda也有坑。最让我头疼的是冷启动。尤其是Java和.NET运行时，冷启动能到好几秒。我曾在一次实时数据处理项目中，因为冷启动导致请求超时，用户投诉不断。后来我用了Provisioned Concurrency（预留并发），才把延迟降下来。嗯，这里要注意：预留并发是要额外收费的，别开太多。
2.3 Azure Functions：企业级集成，但学习曲线陡
Azure Functions最大的卖点是跟微软生态的深度绑定。如果你的公司重度使用Office 365、Dynamics 365、或者Azure DevOps，那Azure Functions简直是天选之子。
我个人觉得，Azure Functions的触发器模型设计得很有意思。它把“绑定”这个概念玩到了极致。比如，你想把Blob存储里的新文件自动处理一下，只需要在函数定义里声明一个Blob触发器，连SDK都不用写。代码示例大概是这样：
// Azure Functions Blob触发器示例
[FunctionName("ProcessBlob")]
public static void Run(
[BlobTrigger("samples-workitems/{name}", Connection = "AzureWebJobsStorage")] Stream myBlob,
string name,
ILogger log)
{
log.LogInformation($"处理文件: {name}");
// 你的业务逻辑
}
但说实话，Azure Functions的定价模型有点复杂。消费计划、Premium计划、专用计划，每个计划的计费方式和性能都不一样。我刚开始用的时候，被“执行次数”、“执行时间”、“内存占用”这几个维度搞得晕头转向。建议你直接上Premium计划，虽然贵一点，但冷启动和网络性能都好很多。
2.4 阿里云函数计算：国内首选，但文档有点乱
阿里云函数计算（FC）在国内市场占有率很高。我服务过的几个国内客户，几乎都优先考虑它。
FC最大的亮点是异步任务模式。它支持最长12小时的运行时间，这对处理大数据、视频转码、ETL任务来说太友好了。你想想看，一个视频转码任务，动不动就十几分钟，如果用AWS Lambda，还得用Step Functions做状态机，而FC直接一个函数搞定。
不过，FC的文档质量确实有待提升。我遇到过好几次，官方文档里的示例代码跑不通，或者版本对不上。比如，FC的HTTP触发器，早期版本和现在版本的请求格式不一样，迁移起来很痛苦。我的建议是：多看社区博客，少依赖官方文档。
2.5 腾讯云云函数：后起之秀，性价比高
腾讯云云函数（SCF）起步比阿里云晚，但发展很快。我最近几个小项目都用了它，主要是便宜。
SCF的免费额度很慷慨。每月100万次调用、40万GB秒的计算时间，对小团队来说基本够用。而且它跟微信生态的集成做得很好，比如微信支付、公众号、小程序，都有现成的触发器。如果你做微信小程序后端，SCF几乎是首选。
但SCF的地域覆盖是个短板。海外节点少，如果你有全球部署的需求，可能不太合适。另外，SCF的自定义Runtime支持不如AWS Lambda灵活，有些冷门语言跑不了。
2.6 选型建议：到底选哪家？
说了这么多，到底怎么选？我总结了一个简单的决策树：
- 如果你在海外，且团队熟悉AWS生态： 闭眼选AWS Lambda。生态最全，社区最活跃，遇到问题随便一搜就有答案。
- 如果你是企业客户，重度使用微软产品： 选Azure Functions。跟Office 365、Azure DevOps的集成，其他家比不了。
- 如果你在国内，且业务以阿里云为主： 选阿里云函数计算。异步任务模式、12小时超时，适合长时间任务。
- 如果你做微信小程序，或者预算有限： 选腾讯云云函数。免费额度多，微信生态集成好。
- 如果你需要多活部署、多云容灾： 我建议你抽象一层函数调用接口，底层同时对接多家厂商。虽然开发成本高一点，但不会被一家绑定。
好了，这一章就到这里。下一章我会讲函数拆分与粒度控制，这是设计Serverless架构时最容易踩坑的地方。到时候见。