37、AWS 解耦服务全解析：SQS、SNS、EventBridge 深度剖析

AWS 解耦服务全解析：SQS、SNS、EventBridge 深度剖析

在现代云计算架构中，组件解耦是提高系统灵活性和可扩展性的关键。AWS 提供了多种服务来实现微服务的解耦，下面将详细介绍其中四种常见的服务。

1. AWS 解耦服务概述

AWS 常用的四种解耦微服务的服务如下：
- Simple Queue Service (SQS) ：将任务添加到队列中进行处理。
- Simple Notification Service (SNS) ：以各种格式和通过各种渠道向一个或多个端点发送通知。
- EventBridge ：可以过滤事件，并根据事件内容将通知发送到特定的 AWS 服务，还能安排未来和重复发生的事件。
- Step Functions ：可以管理具有多个步骤、并行路径、用户审批等的复杂工作流。

2. Simple Queue Service (SQS)

SQS 是微服务解耦中最常用的服务之一，具有以下特点：
- 易于设置 ：是无服务器的（完全托管，按实际使用量计费），并与许多 AWS 服务（如 Lambda 和 S3）集成。
- 缓冲功能 ：除了解耦，SQS 队列还为需要扩展的云服务（如数据库或容器）提供了一个很好的缓冲方式。当服务扩展以满足增加的需求时，SQS 可以保留任务。

2.1 SQS 基本工作流程

在架构中创建一个 SQS 队列，生产者（如微服务）可以创建并向该队列发送任务（也称为消息），而消费者则检索并处理消息。SQS 是多对多的，一个队列可以有多个生产者和多个消费者。

消费者从队列中检索消息后，该消息会在一段时间内对其他消费者隐藏。如果处理成功，消费者可以永久删除该消息；如果出现错误，消息不会被删除，而是返回到活动状态，供另一个消费者拉取并尝试处理。

2.2 SQS 消息配置

• 消息延迟 ：生产者向队列发送消息时，可以配置长达 15 分钟的延迟，然后消息才可供消费者使用。
• 可见性超时 ：消息对其他消费者隐藏的时间可以配置长达 12 小时，通常与消息处理所需的时间相关。
• 消息保留时间 ：当没有消费者检索消息时，消息在队列中保留的时间可以配置长达 14 天。
• 重试次数 ：可以配置消费者在任务被视为永久失败之前允许的消息重试次数。之后，消息可以被删除或移动到一个称为死信队列（DLQ）的第二个队列进行故障处理。

2.3 SQS 队列类型

队列类型	特点
标准队列	消息无序，可能会出现消息重复或被消费者拉取两次的情况，需要在消费者代码中处理。
FIFO 队列	消息严格按顺序排列，不会出现重复，费用略高。

2.4 SQS 轮询方式

轮询方式	特点
短轮询	SQS 从一小部分 SQS 实例中检索消息，即使这些特定实例上没有消息，也能获得近乎即时的响应。
长轮询	更具成本效益，但会引入一定的延迟。可以配置长达 20 秒的时间等待新消息可见，并检查所有 SQS 实例。这种方法可以减少所需的请求数量，因为每个请求都是收费的。

下面是 SQS 工作流程的 mermaid 流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(生产者):::process -->|发送消息| B(SQS 队列):::process
    B -->|检索消息| C(消费者):::process
    C -->|处理成功| D(删除消息):::process
    C -->|处理失败| B(返回队列):::process

3. SQS 与 Lambda 集成

在无服务器架构中，SQS 最常见的设计模式是与 Lambda 微服务消费者集成。Lambda 及其大部分集成是完全托管的，设置起来更容易，但对集成的控制较少。

3.1 Lambda 轮询机制

• 集成最初创建时，或在长时间不活动后有消息到达时，Lambda 会使用五个并行的长轮询连接自动轮询 SQS 队列。轮询完全由 Lambda 服务处理，微服务中无需为此编写代码。
• Lambda 每月会产生约 650,000 个 SQS 请求，费用总计 26 美分。

3.2 Lambda 扩展机制

• Lambda 会监控 SQS 队列中的传入消息数量。当检测到消息数量增加时，它会调整轮询频率，增加 20 个额外请求和 60 个并发微服务实例。
• 只要消息数量持续增加，它将继续扩展轮询和并发微服务，直到达到 Lambda 的并发软限制（默认值为 1000）。当传入消息数量减少时，Lambda 会每次减少 10 个请求的轮询频率和 30 个并发实例。

3.3 并发管理问题及解决方案

Lambda 扩展直到达到并发限制存在相当大的风险，因为这可能会占用该账户和区域中所有可用的并发资源，从而可能阻止其他微服务执行。因此，需要仔细管理由 SQS 触发的微服务的并发。可以采取以下措施：
- 增加区域并发限制 ：但这可能只是推迟问题的发生。
- 配置预留并发 ：在处理 SQS 队列的微服务上配置预留并发。但如果轮询器数量超过微服务实例数量，Lambda 可能无法处理某些 SQS 消息，未处理的消息将被发送回队列。
- 控制生产者速度 ：如果可以控制生产者，也可以限制消息添加到队列的速度，但这可能会在未来扩展或移除限制时导致问题。

3.4 批量处理优化

批量处理是优化队列处理和潜在管理并发问题的一种方法。当将 SQS 与 Lambda 集成时，可以指定批量大小（每次请求发送到 Lambda 的消息数量）和批量窗口（轮询器等待填充批量的时间）。
- 批量大小 ：对于标准队列，批量大小最大可达 10,000。
- 批量窗口 ：最大可达 300 秒。

批量处理有助于并发管理，例如在默认的 1000 并发限制下，批量大小为 2 时，一次可以有效管理 2000 条消息；批量大小为 10,000 时，在达到并发限制之前可能管理 1000 万条消息。但考虑到处理 10,000 条消息的 Lambda 事件可能的开销和潜在处理时间，最优化的批量大小可能在两者之间，需要针对每个案例进行测试以找到最佳平衡。

4. Dead Letter Queue (DLQ)

消息经过几次重试后可被视为永久失败，在 SQS 中，可以配置将消息删除或移动到死信队列（DLQ）。DLQ 类似于普通的 SQS 队列，其目的是收集失败的消息以进行进一步处理。

4.1 消息进入 DLQ 的条件

在 SQS 中，消息在经过可配置的重试次数后（即达到前面提到的可见性超时且消息未从队列中显式删除）会被发送到 DLQ。每次消息被添加回队列时， ReceiveCount 会递增。当它超过配置的 MaxReceiveCount 时，消息将被移动到 DLQ。

4.2 DLQ 的作用

• 临时故障 ：如网络或硬件故障，相同的消息发送到不同的微服务实例时可能会成功处理。
• 永久故障 ：如无效的输入数据或代码中的错误。使用 DLQ 可以分析这些失败的消息，并在修复错误后将其丢弃或重新发布回源队列。

下面是一个使用 SQS 进行图像上传和处理的示例：
当用户提交新请求时，Lambda 微服务 upload-image 在 SQS 队列中创建一条消息。另一个微服务 apply-filter 从 SQS 中检索消息进行处理。如果 apply-filter 失败，常见原因是上传文件的格式不支持，消息不会被删除，在可见性超时后会被添加回队列， ReceiveCount 加 1。直到 ReceiveCount 超过 MaxReceiveCount ，消息将被发送到 DLQ。如果是应用程序代码的问题，开发人员可以在修复错误后将这些失败的消息重新发布回源队列以重新处理。

5. SQS 缓冲示例

在一个架构中，使用 S3 托管前端，使用 Fargate 容器进行对象识别服务。在需求突然激增的情况下，完全托管的 S3、Lambda 和 SQS 会扩展以处理任何额外的负载。SQS 创建的缓冲区意味着消息可以在那里等待，而 Fargate 有时间进行扩展并添加更多容器。随着 Fargate 的扩展，它将从 SQS 接收更多消息，从而避免突然高峰带来的过载。如果出现故障，消息要么被添加回 SQS 队列，要么进入 DLQ 供应用程序团队进一步调查。

6. Simple Notification Service (SNS)

SNS 是一个通知服务，不要与 Simple Email Service (SES) 混淆，SES 是用于向用户发送格式良好的电子邮件的服务。SNS 支持多种格式，包括电子邮件、短信、移动推送和 HTTP 端点。

6.1 SNS 工作模式

在 SNS 中创建一个主题，然后可以向该主题发布消息。SNS 使用“扇出”模式将消息广播给主题的一个或多个订阅者，所有订阅者将大致同时收到消息。

6.2 SNS 特点

• 低延迟和高吞吐量 ：设计为具有低延迟和高吞吐量。如果订阅者不可用，SNS 将尝试重新传递消息，并遵循每个端点类型的重试策略。
• DLQ 处理 ：与 SQS 一样，经过几次尝试后，无法传递的消息可以移动到 DLQ 进行审查。但与 SQS 不同的是，如果订阅者无法处理消息，该消息不能添加回主题，SNS 认为一旦订阅者收到消息，其工作就完成了，之后的错误需要由订阅者自己管理。

6.3 SNS 错误处理

在一个架构中，消息被添加到 SNS 主题（例如一个新订单），然后同时发送给所有订阅者：
- 仓库 ：通知仓库准备订单。
- 客户积分 ：更新客户积分。
- 网站管理员 ：向网站管理员发送订单确认。
- 移动应用 ：向客户手机上的移动应用发送推送通知。

对于无法传递给任何订阅者的消息，经过几次重试后会移动到 DLQ。对于不同类型的订阅者，错误处理方式如下：
| 订阅者类型 | 错误处理方式 |
| ---- | ---- |
| SQS 订阅者 | 可以使用自己的重试和 DLQ 方法处理无法处理的消息。 |
| Lambda 订阅者 | 需要将错误记录到 CloudWatch，通过主动的日志记录策略触发通知或其他操作。也可以选择使用 DLQ 选项。 |
| SNS 电子邮件订阅者 | 难以调试，发件人始终是 Amazon 的无回复地址，退信会直接消失。添加电子邮件地址时需要验证，SNS 电子邮件适用于系统和内部收件人，对消息内容和格式的控制有限，因此 SES 通常更适合向外部用户发送电子邮件通知。 |
| 移动或 Web 应用订阅者 | 需要在应用程序及其调试策略的范围内处理问题。 |

下面是 SNS 工作流程的 mermaid 流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(发布者):::process -->|发布消息| B(SNS 主题):::process
    B -->|广播消息| C(订阅者 1):::process
    B -->|广播消息| D(订阅者 2):::process
    B -->|广播消息| E(订阅者 3):::process
    C -->|处理成功| F(完成):::process
    C -->|处理失败| G(自行处理):::process
    D -->|处理成功| F(完成):::process
    D -->|处理失败| G(自行处理):::process
    E -->|处理成功| F(完成):::process
    E -->|处理失败| G(自行处理):::process
    B -->|无法传递| H(DLQ):::process

7. EventBridge

EventBridge 是 CloudWatch Events 的继任者，它分离出来并添加了新功能。如果需要为 AWS 服务目标提供通知解决方案，EventBridge 通常是比 SNS 更好的选择。

7.1 EventBridge 功能

• 事件过滤和目标指定 ：是一个无服务器事件总线，用于构建事件驱动的应用程序。可以设置规则来过滤事件，并指定将事件发送的目标。事件源可以是云服务、计划事件、自定义事件，甚至是一些第三方 SaaS 应用程序。
• 数据转换 ：可以在事件源和事件目标之间转换数据，这对于以接收者可能需要的方式格式化消息很有用。
• 重试和 DLQ 处理 ：如果消息传递失败，EventBridge 将在 24 小时内最多重试 185 次。与其他服务一样，无法传递的消息会移动到 DLQ。
• 事件保留和重放 ：可以存档旧事件并在事件总线中重放，这对于测试和调试特别有帮助。

7.2 SNS 与 EventBridge 的比较

比较项	SNS	EventBridge
事件类型	针对外部目标（比最终用户更具技术性）	通常用于云应用程序内的事件和通知
集成服务数量	3 个（Firehose、Lambda、SQS）	超过 35 个目标 AWS 服务
目标数量	支持数百万个订阅者	最多 1,500 个
消息路由	订阅者通过必需的确认步骤订阅可用主题	由提供服务的人配置接收者
输入转换	无	可以在源和目标之间转换消息数据
消息过滤	可以过滤消息	可以过滤消息，还可以根据 IP 地址过滤事件
定价	每百万请求 50 美分，每月有 100 万个免费层请求	每百万请求 1 美元
其他功能	无	具有 Schema Registry 和事件序列重放等功能

通过以上对 AWS 解耦服务的详细介绍，我们可以根据不同的需求和场景选择合适的服务来实现微服务的解耦，提高系统的灵活性和可扩展性。

AWS 解耦服务全解析：SQS、SNS、EventBridge 深度剖析

8. 选择合适的解耦服务

在实际应用中，需要根据具体的业务需求和场景来选择合适的 AWS 解耦服务，以下是一些选择建议：
| 业务需求 | 适用服务 | 原因 |
| ---- | ---- | ---- |
| 任务异步处理 | SQS | 可以将任务添加到队列中，实现生产者和消费者的解耦，支持消息重试和 DLQ 处理 |
| 消息广播通知 | SNS | 采用“扇出”模式，能将消息快速广播给多个订阅者，支持多种消息格式和端点 |
| 事件驱动架构 | EventBridge | 可过滤事件、指定目标，支持数据转换、事件保留和重放，适合构建事件驱动的应用程序 |
| 复杂工作流管理 | Step Functions | 能够管理具有多个步骤、并行路径和用户审批的复杂工作流 |

8.1 示例场景分析

假设我们正在开发一个电商系统，可能会遇到以下几种场景，需要不同的解耦服务来支持：
- 订单处理 ：当用户下单后，需要将订单信息发送给多个服务进行处理，如库存管理、支付处理、物流安排等。此时可以使用 SNS 广播订单消息，让各个服务并行处理。
- 数据同步 ：在数据库更新后，需要将更新的数据同步到其他系统。可以使用 SQS 队列来缓冲更新任务，确保数据同步的可靠性和顺序性。
- 系统监控 ：监控系统需要实时捕获各种事件，并根据事件内容触发相应的操作。EventBridge 可以过滤和处理这些事件，将其发送到指定的目标服务。

9. 最佳实践与注意事项

在使用 AWS 解耦服务时，遵循一些最佳实践和注意事项可以提高系统的性能和可靠性。

9.1 SQS 最佳实践

• 合理配置队列参数 ：根据业务需求，合理设置消息延迟、可见性超时、消息保留时间和重试次数等参数，避免消息丢失或处理不及时。
• 选择合适的队列类型 ：如果消息顺序和唯一性要求较高，选择 FIFO 队列；如果对顺序和重复不敏感，标准队列更具成本效益。
• 使用长轮询 ：长轮询可以减少请求次数，降低成本，同时保证消息的及时处理。

9.2 SNS 最佳实践

• 正确处理错误 ：不同类型的订阅者需要采用不同的错误处理策略，确保消息能够被正确处理。
• 验证订阅者 ：对于电子邮件等订阅者，确保进行验证，提高消息传递的成功率。

9.3 EventBridge 最佳实践

• 优化规则设置 ：合理设置事件过滤规则，减少不必要的消息传递，提高系统效率。
• 利用数据转换功能 ：根据目标服务的需求，对事件数据进行转换，避免在微服务中进行额外的处理。

9.4 通用注意事项

• 监控和日志记录 ：使用 AWS 提供的监控和日志服务，如 CloudWatch，实时监控服务的运行状态，及时发现和解决问题。
• 安全配置 ：确保服务的安全配置，如访问控制、加密等，保护数据的安全性和隐私性。

10. 未来发展趋势

随着云计算技术的不断发展，AWS 解耦服务也将不断演进和完善。以下是一些可能的未来发展趋势：
- 更强大的集成能力 ：与更多的 AWS 服务和第三方服务进行深度集成，提供更丰富的功能和解决方案。
- 智能化的事件处理 ：引入人工智能和机器学习技术，实现智能化的事件过滤、预测和处理。
- 更好的用户体验 ：简化服务的配置和管理，提供更直观的用户界面和工具，降低使用门槛。

11. 总结

AWS 提供的 SQS、SNS、EventBridge 等解耦服务为构建灵活、可扩展的微服务架构提供了强大的支持。通过合理选择和使用这些服务，可以实现组件之间的解耦，提高系统的性能、可靠性和可维护性。

在实际应用中，需要根据具体的业务需求和场景，结合最佳实践和注意事项，灵活运用这些服务。同时，关注未来的发展趋势，及时调整和优化系统架构，以适应不断变化的业务需求。

下面是一个综合的 mermaid 流程图，展示了在一个电商系统中如何使用不同的解耦服务：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(用户下单):::process -->|订单消息| B(SNS 主题):::process
    B -->|广播消息| C(库存管理服务):::process
    B -->|广播消息| D(支付处理服务):::process
    B -->|广播消息| E(物流安排服务):::process
    C -->|更新库存| F(SQS 队列):::process
    D -->|处理支付| F
    E -->|安排物流| F
    F -->|任务处理| G(微服务实例):::process
    G -->|处理结果| H(EventBridge):::process
    H -->|通知相关服务| I(监控系统):::process
    H -->|触发操作| J(数据分析系统):::process
    C -->|失败| K(DLQ):::process
    D -->|失败| K
    E -->|失败| K

通过这个流程图，我们可以更直观地看到不同解耦服务在电商系统中的协同工作方式，以及如何处理可能出现的错误情况。希望本文能帮助你更好地理解和应用 AWS 解耦服务，为你的系统架构带来更多的优势。