协调服务与状态管理

在 AWS 上开发应用

Ricardo Sueiras

Principal Technologist

服务协作

 

• 多个服务需协同完成一个工作流。
• 需要一套协调策略。
• 两种方式：orchestration 与 choreography。

Orchestration（编排）

 

• 由中央编排器协调工作流。
• 编排器控制顺序并决定下一个运行的服务。
• 适用于重试、条件逻辑和错误处理。
• 在 AWS 上：用 Step Functions 统筹 Lambda、ECS、DynamoDB。

Orchestration（编排）

 

• 工作流逻辑集中，便于调试与监控。
• 权衡：引入了中心化依赖。

Choreography（舞蹈式）

• 无中央控制器。
• 服务独立响应事件。
• 各服务监听相关事件并各自处理。
• 无需任何服务了解完整工作流。
• 提升松耦合与可扩展性。

 

Choreography（舞蹈式）

• 在 AWS 上：EventBridge、SNS、SQS。
• 高度可扩展。
• 权衡：工作流增长后更难理解与调试。

 

事件驱动架构

• 服务通过生产与消费事件通信。
• 促进服务间的松耦合。
• 提升可扩展性。
• 支持事件的并行处理。
• 新服务可订阅而不改动现有服务。

 

事件驱动架构

 

• 实施 EDA 的权衡：
• 设计为最终一致性。
• 实现幂等性。
• 故障处理更复杂。

幂等性

 

• 同一操作多次执行，结果保持不变。
• 异步与事件驱动系统中的关键设计原则。
• 分布式系统可能产生重复事件（重试、网络故障、重处理）。
• 保障系统正确性与可靠性。

死信队列

 

• 管理异步通信中的失败。
• 隔离有问题的"毒"消息。
• 多次重试仍失败后，消息移入 DLQ。
• 主处理流保持运行。

死信队列

• 适用于消息顺序不关键的场景。
• 对非关键系统，可接受偶发数据丢失时可跳过。
• 当必须保持消息顺序时避免使用。

 

状态管理

• 状态管理是云原生应用的基础。
• 状态是交互之间保留的任何数据。
• 在服务器本地存储状态会限制扩展性与韧性。

 

状态管理

• 状态管理需按业务做权衡。
• 外部化状态可提升扩展性与韧性。
• 成本：增加延迟与复杂度。
• 需考虑：一致性、缓存与数据访问模式。

 

有状态（Stateful）

 

• 会话数据保留在服务器上。
• 请求需路由到同一实例（粘性会话）。
• 限制伸缩灵活性。
• 若实例故障，会话即丢失。

无状态（Stateless）

 

• 每个请求独立处理。
• 服务器不存储状态。
• 状态存于外部系统。
• 云原生应用的首选方式。
• 任意实例可处理任意请求，水平扩展更简单。

让我们一起练习吧！

在 AWS 上开发应用