如何在微服务世界中发布事件？

Question

有许多书籍和博客详细介绍了微服务之间基于事件的通信如何比服务直接相互调用更容易维护。

但是，这将如何在 AWS 世界中实施？我正在考虑主题，但它远非理想。

这种模式通常如何实现以保证延迟、持久性、保证交付、幂等性等。

Answer 1

这里肯定有几个选项：

AWS 原生方式

不确定为什么您认为主题远非理想？

SNS 主题专为事件而设计：

1. 为每种事件类型创建一个 SNS 主题
2. 为每个消费者创建一个 SQS 队列
3. 为 SQS 队列订阅消费者有兴趣订阅的 SNS 主题（事件）

就是这样。

优点：

• 订阅在发布者或消费者之外进行管理 - 耦合非常松散
• 缺点 - 您可以连接其他订阅者（例如电子邮件或 api 调用或 lambda 函数）以触发特定事件的特定操作 - 非常可扩展

缺点：

• 没有回放事件历史的本地方式 - 例如让新消费者获取有关其订阅之前发生的事件的信息

发布者提供事件历史供消费者投票

这不是 AWS 特定的，但另一种方法是让每个发布者公开一个 API，允许消费者轮询新事件。通常，事件存储数据库存储事件，API 允许缓存和“检索自 X 以来的新事件”语义。

Atom 协议经常用于以这种方式发布事件。

优点：

• 完整的事件历史记录可用于重播事件和“追赶”新消费者
• 与基础设施无关

缺点：

• 必须运行/维护事件存储和事件发布机制

服务总线方法

我不太熟悉其他语言，但在 .NET 世界中，有两个提供服务总线语义的大型项目 - NServiceBus 和 Mass Transit

两者都为活动通信提供了一系列“运输”。 NServiceBus 有一个开源 AWS SQS 插件来使用 SQS 队列作为传输，但在撰写本文时，订阅由 NServiceBus 在每个发布者的本地持久性中维护（然后，当每个事件发布到本地持久化列表中的每个订阅者时，它们会转发每个事件订阅数）。

担心吗？

如果您能澄清您对 SNS 主题的担忧，我很乐意扩大答案。