Serverless设计原则有效架构选择实践_LucaMezzalira

核心观点与关键数据

• 分布式系统目标：组织可扩展性、更快的反馈循环、业务敏捷性、减少爆炸半径、减少外部依赖。
• Serverless 的定位：Serverless 是一种策略，是赋能团队（Enablement teams）的延伸，强调去中心化和赋权。
• Serverless 的适用场景：适用于需要高可用性（99.99%关键路径，99.9%其余系统）、事件驱动、快速响应时间（<1秒）、高并发（3000 TPS）的工作负载。
• 关键数据：示例工作负载需达到 3000 TPS 并有 50% 头量（headroom）。

文档结构及内容

1. 分布式系统与 Serverless 的关系：

   • 引用 Conway 定律，指出组织结构会影响系统设计（中心化 vs 去中心化）。
   • Serverless 作为一种联邦服务（Federated Service），是赋能团队的延伸，强调去中心化与赋权。

2. 发展 Serverless 文化的建议：

   • 文化：培养 Serverless 首先的文化。
   • 快速胜利：成立中心化能力中心（CCOE），获得领导层支持并交付战略性的“灯塔”现代化工作负载。
   • 最佳实践：去中心化 CCOE 并在组织内联邦化，构建可重用的模式、参考架构和共享服务。
   • 社区建设与赋能：建立社区并持续赋能。

3. 系统架构设计：

   • 演进式架构：从定义架构特征开始，识别合适的模式。
   • AWS 服务映射：根据需求选择合适的 AWS 服务（如 Lambda, API Gateway, Step Functions, DynamoDB, DynamoDB Streams, EventBridge）。
   • 设计原则：强调模块化，包括代码层面的强封装、设计模式使用、业务逻辑与环境解耦，以及基础设施层面的配置优于代码、内置行为和可控性。
   • 支持的架构模式：Serverless 支持微服务和数据架构。

4. 设计 Serverless 工作负载的示例：

   • 业务需求：电商礼品码服务，需支持系统或第三方生成，每次使用需通知客服、更新用户历史、通知第三方（如适用）。
   • 工作负载特征：高可用性、事件驱动、快速响应、高并发。
   • 高级架构：展示如何使用 Serverless 服务实现同步 API、事件驱动通知、第三方系统集成和流量削峰。
   • Serverless 实现方式：
     • 使用 API Gateway 和 Step Functions 生成/更新礼品码。
     • 使用 DynamoDB Streams 和 EventBridge 实现异步通知和事件传递。
     • 使用队列处理第三方系统 API 限制。
     • 使用 Lambda 和队列集成 CRM 和用户账户系统。

5. 结论：

   • 将架构特征和业务需求转化为基础设施，关注业务目标而非立即构建软件。
   • 引用 Frederick Brooks，强调先关注业务目标。