Events AWS SNS—；主题应具有多大的通用性，何时应重用/创建主题？

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

我的问题是，这些主题应该有多普遍？我们什么时候应该创建新主题

比如说，我们有一个用户域，它需要发布创建和删除的两个事件。我们正在考虑的两个方案是：

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

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

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

• 根据事件的类型，使用者将承担过滤事件或采取不同操作的额外责任（他们还可以配置队列订阅以过滤某些事件类型）

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

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

---

请注意，您将在哪里为每个资源包括云配置？（队列资源创建是应该与使用者一起部署，还是应该独立于任何发布者/使用者？

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

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

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

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

• 存储库

  用户服务

  包含服务/lambda代码、服务及其主题订阅的cloudformation/terraform模板
• 存储库

  sns

  包含所有与sns主题相关的云信息/地形模板
• 存储库

  sqs

  包含所有与sqs主题相关的云信息/地形模板

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

---

一般来说，把你的话题看作一个“数据库”是有帮助的，这条思路应该为你的所有问题指明正确的方向。

谢谢你的详细回答！如果我正确理解了您关于分离infra配置的建议，您的意思是说有一个，比如说，

serverless.yml

，其中包含SNS主题的配置，它是订阅，SQS队列（+存储等）和消费者lambda将分别部署？这是否意味着您将所有与事件相关的infra放在一个repo中，而不管域是什么，还是将一个infra repo放在domain=topic中？