经过近十年的普及,无服务器架构已经从一种实验趋势发展成为应用程序开发的主流方法。到 2025 年,有两个平台将在这种情况下脱颖而出:AWS Lambda(继续主导市场的先驱)和 [Cloudflare Workers13],后者因其基于 Web 标准的创新方法而获得了巨大的关注。
本文探讨了如何使用这两个平台开发现代无服务器应用程序,分析它们的架构差异、理想用例,以及组织如何将它们结合起来创建强大的解决方案。
2025 年无服务器的现状
超越最初限制的进化
当无服务器计算出现时,由于冷启动、执行限制和调试复杂性等限制,它面临着质疑。到 2025 年,其中许多障碍已被拆除:
- 冷启动:在两个平台上从秒缩短到毫秒
- 状态持久性:用于在运行之间维护状态的新抽象
- 可观察性:用于监控和诊断的集成工具
- 集成:强大的生态系统支持混合架构
市场增长和采用
根据云原生计算基金会的数据,到 2025 年,78% 的组织将在生产中使用某种形式的无服务器计算,比 2021 年的 35% 显着增加。推动这种采用的因素包括:
- 适当工作负载的运营成本降低 40%
- 新功能的平均启动时间缩短 65%
- 能够立即扩展以满足需求高峰
AWS Lambda 与 Cloudflare Workers:架构比较
运行时和性能模型
2025 年 AWS Lambda
自推出以来,AWS 对 Lambda 进行了重大改进:
- SnapStart 架构:现在可用于所有运行时,将冷启动减少高达 90%
- Lambda ƛ2:完整的第二代平台,提供改进的 CPU 和网络性能
- Lambda Graviton4:性价比最佳的定制ARM处理器
- 统一运行时:允许语言切换而无需重新部署的新模型
热调用的平均延迟降至 10-50 毫秒,冷启动范围在 100-300 毫秒之间,具体取决于配置。
2025 年的 Cloudflare 工作人员
Cloudflare 继续押注于其基于 V8 隔离的架构:
- Isolates 2.0:优化版本,具有更好的隔离性和更低的开销
- 通用边缘计算:在全球 500 多个地点运行
- [WebAssembly17 作为一等公民:多语言支持和近乎原生的性能
- 高级持久对象:具有一致性保证的分布式状态的鲁棒解决方案
现在,工作人员在全球范围内的延迟始终为 5-15 毫秒,冷启动几乎为零。
定价和经济模型
成本结构已演变成更细粒度和可预测的模型:
AWS Lambda
- 按每毫秒执行收费(以前按 100 毫秒收费)
- 基于 vCPU 和内存的定价,具有线性扩展
- 自动批量折扣,无需提前承诺
- 免费套餐扩展至每月 200 万次运行
Cloudflare 工作人员
- 双重定价模型:按请求或按 CPU 持续时间
- Cloudflare 生态系统内无网络费用
- KV存储和耐用对象的价格自2023年以来降低了40%
- 为开发者和初创公司提供慷慨的免费计划
限制和限制
这两个平台都扩大了其限制以适应更复杂的工作负载:
AWS Lambda
- 最长跑步时间:30 分钟(之前为 15 分钟)
- 可配置内存:高达 32GB(之前为 10GB)
- 部署包大小:最大10GB
- 按地区竞争:默认3000个,可按需扩展
Cloudflare 工作人员
- 最大 CPU 持续时间:60 秒(之前为 30 秒)
- 内存限制:每个worker 2GB
- 支持流式请求和响应
- 通过持久对象和 D1 数据库的请求之间的持久性
用例和新兴架构模式
Web 应用程序和 API
模式:API 网关 + Lambda (AWS)
连接到 Lambda 函数的传统 API 网关模式已经发展并具有新功能:
0
默认:Workers 站点 (Cloudflare)
Cloudflare 为 Web 应用程序开发了完整的生态系统:
1
数据处理和 ETL
默认:事件驱动的 ETL (AWS)
AWS 制定了强大的数据处理标准 [无服务器18:
2
默认:边缘处理 (Cloudflare)
Cloudflare 创建了用于分布式数据处理的新原语:
3
多云集成和架构
随着更加成熟,公司现在将在 2025 年实施结合了两个平台优势的架构:
标准:边缘到核心(Cloudflare + AWS)
一种流行的模式在边缘使用 [Cloudflare Workers19 进行路由、缓存和初始处理,将较重的工作负载委托给 AWS Lambda:
4
模式:Lambda@Edge 逐步迁移
对 AWS Lambda 进行了大量投资的组织正在使用 Lambda@Edge 和 [Cloudflare Workers20 来实施逐步迁移策略:
5
2025 年最佳实践和优化
冷启动优化
最大限度地减少冷启动影响的策略已经发生了重大变化:
AWS Lambda
- 对关键负载使用预置并发
- 适用于所有语言(不仅仅是 Java)的 Lambda SnapStart
- 函数之间代码重用的分层依赖关系
- 根据流量模式智能调度预热
Cloudflare 工作人员
- 用于隔离维护的流量预测算法
- 全球资源的地理请求分布
- 选择性捆绑以最小化代码大小
- 与后端的持久连接
弹性和稳定性设计
[无服务器21] 中的弹性最佳实践已经成熟:
断路器和重试
6
幂等设计
7
可观察性和监控
到 2025 年,[可观测性22不再是事后的想法,而是从一开始就集成到系统中:
集成 OpenTelemetry
8
实时性能分析
9
2025 年之后无服务器的未来
新兴趋势
除了当前的功能之外,一些趋势正在塑造[无服务器23]的未来:
1. 函数的组合和编排
下一代编排工具正在使函数组合更加直观和声明性:
10
2.辅助AI进行功能优化
人工智能工具正在分析使用模式并自动优化资源设置:
11
3. 计算边缘的无服务器
下一个前沿领域是更接近终端设备的计算:
12
挑战和未来的考虑
随着[无服务器24小时架构的不断发展,新的挑战出现了:
能源消耗和环境影响
不同方法的能源效率争论 [无服务器25 已经引起了人们的关注:
- [AWS Lambda26 引入了函数的碳指标
- Cloudflare 扩展了由 100% 可再生能源供电的基础设施
- 效率基准测试工具正在成为 CI/CD 管道的一部分
数据主权和法规
随着全球隐私法规的激增:
- 针对 [无服务器27] 工作负载的精细数据驻留控制
- 自动化合规认证
- 可配置代码执行的区域限制
迁移和可移植性策略
对锁定的担忧导致了以下方面的发展:
- 多云抽象框架(Serverless Framework 4.0)
- 容器作为功能的可移植机制
- 适用于不同提供商的适配器[无服务器28
结论:选择正确的方法
没有适合所有情况的单一解决方案。到 2025 年,AWS Lambda 和 [Cloudflare Workers29](或两者的组合)之间的选择取决于几个因素:
- 全球关键延迟:[Cloudflare Workers30 由于全球边缘网络而具有优势
- 与 AWS 服务深度集成:Lambda 提供与 AWS 生态系统的卓越集成
- 可预测工作负载的成本:Cloudflare 通常具有更可预测的定价
- 计算密集型要求:Lambda 支持更高的内存和 CPU 分配
- 持久性和状态:Lambda 与更多持久性服务集成,但 Durable Objects 提供了更加集成的体验
真正的技能是知道何时以及如何使用每种工具,并可能将它们组合成一个能够充分利用每个世界优点的架构。
您如何在项目中使用[无服务器31]架构?哪个平台最能满足您的需求?在下面的评论中分享您的经验。
另请阅读
- [应用程序的无服务器:它是什么以及为什么它很重要32
- [应用程序的无服务器:具有真实示例的架构33
- [应用程序的无服务器:实践中的架构34
- [Cloudflare Workers:无服务器边缘计算实用指南35
- [生产中的 Cloudflare Workers:hello world 之后发生了什么变化36
- [应用程序中的缓存:良好实践快速指南(及其隐藏的错误)37
