无服务器优先架构

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 调用，使其与数据库的连接容量相匹配。