架构风格与通信模式

在 AWS 上开发应用

Ricardo Sueiras

Principal Technologist

您的讲师

什么是架构模式？

 

 

 

• 针对常见问题的可复用解法。
• 模式帮助您组合 AWS 服务。
• 架构决定高负载下的表现。
• 需要掌握的多种架构模式。

单体架构

 

 

 

 

• 单一、强耦合单元。
• 单一代码库，单次部署。
• 起步开发简单。
• 扩展痛苦：必须整体扩展。

微服务

 

 

• 小而独立的服务：各自负责一项业务能力。
• 各服务可独立部署、扩展与更新。
• 取舍：运维更复杂，需管理服务间通信。

无服务器架构

• 无需管理基础设施，仅关注代码与配置。
• 通过组合托管的 AWS 服务构建。
• 由 AWS 负责供给、扩缩与维护。
• 取舍：执行时限、冷启动、厂商锁定。
• 运维开销近乎为零，自动扩展。

 

事件驱动架构（EDA）

• 组件通过产生/消费事件通信，而非直接调用。
• 事件记录已发生的事（下单、收款、发货）。
• 生产者发出事件。
• 消费者订阅其关注的事件。

 

紧耦合与松耦合系统

• 现代云应用由多个服务组成。
• 服务需通信与协作完成工作。
• 同步通信为紧耦合。
• 异步通信为松耦合。

同步通信

 

• 一个服务发送请求并等待响应。
• 调用方在响应或超时前被阻塞。
• 实现与理解都较直接。
• 紧耦合：下游变慢或失败会级联。
• 通过超时、重试、断路器缓解。

模式：请求/响应

• 多数应用接口的骨干。
• 行为可预测。
• 向用户即时反馈。

异步通信

 

• 发送方不等待响应。
• 发送消息或事件后继续处理。
• 接收方独立处理消息。
• 松耦合：更易扩展且容错性更好。
• 能优雅应对流量峰值与部分故障。
• 挑战：重复消息、顺序、最终一致性。

模式：基于队列的解耦

• 生产者将消息发送到队列。
• 消费者独立拉取并处理消息。
• 防止故障级联。
• 生产者与消费者可独立扩展。

 

模式：工作队列

• 多个工作进程从同一队列拉取消息。
• 并行处理消息。
• 支持横向扩展与更高吞吐。
• 不保证消息顺序。

模式：发布/订阅

• 发布者向 SNS 主题发送消息。
• 多个订阅者接收同一消息。
• 实时向多消费者广播。

 

模式：扇出

• 一条消息同时投递给多个消费者。
• 在事件驱动架构中广泛使用。
• 适用于多个服务需响应同一事件。

消息有序性

• 某些负载需按正确顺序处理消息。
• Amazon SQS FIFO 与 Kinesis 支持有序处理。
• 严格有序会降低吞吐。
• 在正确性与可扩展性间权衡。

让我们一起练习吧！

在 AWS 上开发应用