Infrastructure
Category
Advanced
Complexity
SaaS, 媒体
Industries
2+
Technologies
何时需要它
您的应用程序流量可变——夜间平静，工作时间高峰，以及市场活动或季节性事件带来的不可预测的突发流量。您正在为70%时间闲置的服务器付费。或者您正在构建一个新产品，在验证产品市场契合度之前，不想投入到基础设施配置、容量规划和24/7待命轮换中。Serverless 提供按请求计费、自动扩展和零基础设施管理——但这仅限于工作负载特性匹配的情况。
模式概述
Serverless 优先架构完全基于托管的、可扩展到零的计算服务（Lambda, Cloud Functions, Vercel Functions）构建应用程序，并通过托管事件服务（EventBridge, SQS, Step Functions）连接。无需修补服务器，无需调整集群大小，也无需规划容量。函数响应事件（HTTP 请求、队列消息、计划触发器、数据库更改）执行，并从零自动扩展到数千个并发实例。该模式还扩展到无服务器数据库（DynamoDB, Neon, PlanetScale）、无服务器队列（SQS）和无服务器编排（Step Functions, Temporal Cloud）。
Related Architecture Patterns
Explore more design patterns and system architectures
常见问题
Serverless优先架构不适合超过15分钟的长时间运行进程、需要持久 WebSocket 连接的工作负载、具有持续高吞吐量流量且预留容量更便宜的应用程序，以及需要底层 OS 或网络配置的系统。MicrocosmWorks 在架构设计期间会根据这些限制评估每个工作负载，并推荐混合方法，在这些方法中，Serverless 处理 API 端点和事件处理，而容器或 VM 运行需要持久计算的工作负载。这种务实的方法避免了在不适合的情况下强制将每个组件都纳入 Serverless 的常见错误。
MicrocosmWorks 通过为关键端点预置并发 (provisioned concurrency)、优化函数包以减少初始化时间，以及战略性地使用 Lambda SnapStart 处理 Java 工作负载来缓解 Lambda 冷启动问题，这将冷启动时间从秒级缩短到毫秒级。我们还会对应用程序进行架构设计，使延迟敏感的路径使用轻量级运行时，例如 Node.js 或 Python，并尽量减少依赖，即使没有预置并发，也能将冷启动时间保持在 200 毫秒以下。对于那些即使是这种延迟也无法接受的端点，我们会使用 Lambda@Edge 或 CloudFront Functions 来实现低于 10 毫秒的响应。
MicrocosmWorks 使用 SST (Serverless Stack)、LocalStack 或 Serverless Framework 的离线模式等工具设置本地开发环境，这些工具在开发者的机器上模拟云服务，具有接近生产环境的真实度。我们实施集成测试套件，这些套件针对按每个拉取请求（pull request）启动的临时云环境运行，这样开发人员就可以针对真实的 AWS 服务进行验证，而无需共享预演环境（staging environment）。这种双重方法为开发提供了快速的本地迭代循环，同时能在代码投入生产环境之前捕获云特有的问题。
MicrocosmWorks 发现，对于流量模式多变或峰值较高的应用程序，serverless 明显更便宜——通常比同等的常开 container 部署便宜 70-90%——但当每月持续吞吐量超过 1000-2000 万次调用时，成本优势会缩小。我们在架构设计阶段建立成本预测模型，比较 serverless 按次调用计费与针对您特定流量模式的预留 container 容量，包括 API Gateway 费用和数据传输费等隐藏成本。我们的优化服务（咨询费率为每小时 10-35 美元）定期审查 serverless 账单，以识别因内存过度配置、函数持续时间过长或不必要的 API Gateway 使用而造成的浪费。
MicrocosmWorks 使用连接池代理，例如 Amazon RDS Proxy 或 PgBouncer，它们被部署为 Lambda 函数和数据库之间的持久层，将数千个 Lambda 连接复用到一个可管理的实际数据库连接池中。我们还设计无服务器应用程序以优先选择 DynamoDB 或其他无连接数据库，用于高并发工作负载，在这些工作负载中，连接池仍然会造成瓶颈。对于必须使用关系型数据库的应用程序，我们实施连接感知的扩展限制，以限制并发 Lambda 调用，使其与数据库的连接容量相匹配。
