我正在基于 AWS 的托管业务中使用 AWS SNS 上的事件驱动架构实施一个流程。对我来说，这在很大程度上是一种学习经验，具有新的架构，编程和托管范式。
我考虑过 AWS Step 函数，但决定使用 AWS SNS 主题实施消息总线，因为我想了解底层事件驱动编程模型。
几乎所有操作都由 lambda 函数执行，步骤通过 SNS 和/或 SQS 耦合。
我不确定是否使用一个或多个 SNS 主题实现该过程，以及是否应该将核心逻辑订阅到具有一个或多个 lambda 函数的消息总线。
一条或多条消息总线
我的核心流程目前由 9 个事件组成，其中 2 组 2 个可以并行，其余 4 个是顺序的。将这些消息全部订阅到同一消息总线更容易设置，但需要每个 lambda 函数检查消息是否与其相关，这似乎是浪费资源。
另一方面，我可以有 6 个消息总线，并确保通知的资源与消息有关。
一个或多个 lambda 函数
如果所有 lambda 函数都订阅到同一消息总线，则将它们与调度程序函数一起打包到单个 lambda 函数中可能更容易。它还将减少上传到 lambda 的代码量，尽管我不必为此付费。
另一方面，我会失去控制 lambda 函数超时的能力，并且对事件顺序的任何更改现在都取决于调度程序代码。
我仍然能够缩放每个流程部分，因为包含重复元素的任何部分都由 SQS 队列分隔。
应始终将每种类型的消息发送到其自己的主题，因为这允许其他服务使用这些事件，而无需紧密耦合这两个服务。
同样，每个想要使用消息的工作线程都应该有自己的队列，并订阅自己的主题。
通过执行以下操作，您可以为给定事件添加新的消息使用者，而无需修改上游服务。此外，对每个组件的责任是明确的 - 向主题生成消息的服务拥有该主题(和消息格式)，而消费者拥有其队列和事件处理语义。
您的使用者可以在订阅主题时指定消息过滤器，因此它只能接收它关心的消息(文档)。
例如，在客户收到订单后发送客户调查的流程会将其队列订阅Order Status Changed事件，并将筛选器设置为仅接收new_status字段等于shipment-received的事件)。
上面反映了面向服务的体系结构的原则 - 并且有很多很好的材料来阐述上述观点。