如何从事件驱动架构中错过的集成或通知事件中恢复？

如何解决如何从事件驱动架构中错过的集成或通知事件中恢复？

情况如下。共有三种服务，一种服务是事件源，并使用事件总线（如 Azure 服务总线或 ActiveMQ）向其他两种服务（订阅者）发布集成或通知事件（发件箱模式）。

此设计灵感来自.NET microservices - Architecture e-book - Subscribing to events。

我想知道如果这些事件之一由于错误而无法传递或者事件处理只是没有正确实现会发生什么。

• 如果出现应用程序错误，我应该信任我的消息总线吗？
  • 这是死信队列的用例吗？
• 在重新发布事件时，是否应该将所有消息重新发布到所有主题，还是只能重新发布一个子集？
  • 服务重新发布事件是否应该能够访问发布者和订阅者数据库以了解消息偏移量？
  • 或者订阅微服务是否应该能够读取发件箱？

解决方法

只是为了补充@xander 的出色回答，我相信您可能对您的事件总线使用了不合适的技术。您应该会发现 Azure Event Hubs 或 Apache Kafka 更适合事件发布/订阅架构。与旧的服务总线方法相比，专用事件总线技术的优势包括：

• 每条事件消息只有一个副本（而 Azure 服务总线或 RabbitMQ 为每个订阅者制作每条消息的深层副本）
• 任何订阅者消费后都不会删除消息。相反，消息会在指定的时间段内保留在主题上（在 Kafka 的情况下可以是不确定的）。
• 每个订阅者（消费者组）将能够跟踪其提交的偏移量。这允许订阅者在丢失消息时重新连接和回滚，独立于发布者和其他订阅者（即隔离）。
• 新消费者可以在消息发布后订阅，并且仍然可以接收所有可用消息（即倒回可用事件的开始）

考虑到这一点：

如果出现应用程序错误，我应该信任我的消息总线吗？

是的，因为 xander 提供的原因。一旦发布者确认事件总线已接受该事件，发布者的工作就完成了，不应再次发送相同的事件。

Nitpicky，但由于您处于发布订阅架构（即 0..N 个订阅者）中，无论使用何种技术，您都应该将总线称为事件总线（而不是消息总线）。

这是死信队列的用例吗？

死信队列通常是点对点队列或服务总线交付架构的产物，即其中有一条命令消息（事务性地）用于单个或可能有限数量的接收者。在发布-订阅事件总线拓扑中，期望发布者监控所有订阅者的交付对发布者来说是不公平的。

相反，订阅者应承担弹性交付的责任。在 Azure 事件中心和 Apache Kafka 等技术中，每个消费者组的事件都是唯一编号的，因此订阅者可以通过监控消息偏移量来收到丢失消息的警报。

在重新发布事件时，是否应该将所有消息重新发布到所有主题，还是可以只重新发布一个子集？

不，事件发布者不应重新发布事件，因为这会破坏所有观察者订阅者的事件链。请记住，每个发布的事件可能有 N 个订阅者，其中一些可能在您的组织之外/在您的控制之外。事件应被视为在某个时间点发生的“事实”。事件发布者不应该关心事件的订阅者是 0 还是 100。由每个订阅者决定如何解释事件消息。

例如不同类型的订阅者可以对事件执行以下任何操作：

• 只需记录事件以进行分析
• 将事件转换为命令（或 Actor 模型消息）并作为特定于订阅者的事务处理
• 将事件传递到规则引擎以推理更广泛的事件流，例如如果特定客户执行异常大量的交易，则触发反欺诈措施
• 等

因此您可以看到，为了一个 flakey 订阅者的利益重新发布事件会破坏其他订阅者的数据流。

服务重新发布事件是否应该能够访问发布者和订阅者数据库以了解消息偏移量？

正如 xander 所说，系统和微服务不应该共享数据库。但是，系统可以公开 API（RESTful、gRPC 等）

事件总线本身应该跟踪哪个订阅者读取了哪个偏移量（即每个消费者组、每个主题和每个分区）。每个订户将能够监视和更改其偏移量，例如以防事件丢失并需要重新处理。 （同样，一旦确认事件已被总线接收到，生产者不应重新发布事件）

或者订阅微服务是否应该能够读取发件箱？

事件驱动的企业架构至少有两种常用方法：

• “最少信息”事件，例如Customer Y has purchased Product Z。在这种情况下，许多订阅者会发现事件中包含的信息不足以完成下游工作流，并且需要丰富事件数据，通常是通过调用靠近发布者的 API 来检索其余数据他们需要。这种方法具有安全优势（因为 API 可以验证对更多数据的请求），但会导致 API 的 I/O 负载较高。
• “深度图”事件，其中每条事件消息都包含任何订阅者希望需要的所有信息（这在未来证明非常困难！）。尽管事件消息的大小会变大，但它确实节省了大量触发 I/O，因为订阅者不需要从生产者那里执行进一步的充实。