AWS SNS — 主题应该如何通用以及我们应该何时重用/创建主题？

Question

我们正在引入 SNS + SQS 来处理我们的微服务架构中的事件生产和传播，到目前为止，我们的微服务架构依赖于 HTTPS 调用来相互通信。我们正在考虑将多个 SQS 队列连接到一个 SNS 主题上。然后队列中的事件将由 lambda 或在 EC2 中运行的服务使用。

我的问题是，主题应该如何通用？我们什么时候应该创建新主题？

假设我们有一个用户域，它需要发布两个事件——创建和删除。我们正在考虑的两个选项是：

选项 A：有两个主题，“用户创建”和“用户删除”。每个主题保证一个单一的事件类型。

• 消费者不必担心丢弃他们不感兴趣的事件，因为他们已经知道来自“用户创建”主题的消息仅与用户创建相关。
• 将代码的多个不同部分发布到同一主题

选项 B：有一个主题“用户”，它接受多种事件类型

• 消费者将有额外的责任过滤事件或根据事件的类型采取不同的行动（他们还可以配置他们的队列订阅来过滤某些事件类型）

• 可以确保每个主题有一个发布者

有没有人对这两种选择有强烈的偏好，为什么会这样？

在相关说明中，您将在哪里包含每个资源的云配置？（队列资源创建应该与消费者一起部署，还是应该独立于任何发布者/消费者？）

Answer 1

我认为你应该选择选项 B，并将与给定“域”（例如“用户”）有关的所有事件保留在一个主题中：

• 让您的基础设施保持简单
• 您可能会引入对多种事件类型感兴趣的服务（例如“创建”和“删除”）。从两个主题中获得正确的顺序是很困难的；想象一下“用户删除”事件在“用户创建”事件之前到达
• 吞吐量可能是一个问题，这实际上取决于您的域（创建和删除用户听起来不像是一个大容量问题）
• 考虑主题中数据结构的变化，同时在两个或多个主题中引入变化可能会很快变得复杂

关于您的其他问题：将您的主题/基础设施配置与您的服务分开。它是一个单独的基础设施（如数据库），应该保持独立；特别是如果您向系统引入更多消费者和生产者。

编辑：这可能是一个示例“设置”：

• 存储库user-service包含服务/lambda 代码、服务及其主题订阅的 cloudformation/terraform 模板
• 存储库sns包含有关 SNS 主题的所有 cloudformation/terraform 模板
• 存储库sqs包含有关 SQS 主题的所有 cloudformation/terraform 模板

您可以考虑将 SNS 和 SQS 基础设施代码保存在单个存储库中（最后两个），但我强烈建议将特定于某个服务/lambda 的所有内容保存在单独的存储库中。

一般来说，将您的主题视为一个“数据库”会有所帮助，这种思路应该为您所有的问题指明正确的方向。