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 的所有内容保存在单独的存储库中。

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