microservices - 事件存储可能成为单点故障？

Question

几天以来，我一直在试图弄清楚如何通知其他微服务在微服务 A 中创建了一个新实体，该微服务 A 将该实体存储在 MongoDB 中。

我想要:

微服务之间的低耦合

避免微服务之间的分布式事务，例如两阶段提交 (2PC)

起初，像 RabbitMQ 这样的消息代理似乎是完成这项工作的好工具，但后来我看到了 的问题。提交 MongoDB 中的新文档和 发布 代理中的消息不是原子的。

Why event sourcing?通过 eventuate.io:


解决此问题的一种方法是通过添加一个标记来说明文档是否已在代理中发布并具有计划的后台进程来搜索 MongoDB 中未发布的文档并将其发布到代理，从而使文档的架构更脏 confirmations ，当确认到达时，文档将被标记为已发布(使用至少一次和幂等语义)。此解决方案在 this 中提出和 this答案。

阅读 Introduction to Microservices作者:克里斯·理查森(Chris Richardson)我最终参加了 Developing functional domain models with event sourcing 的精彩演讲其中一张幻灯片问:

How to atomically update the database and publish events and publish events without 2PC? (dual write problem).

答案很简单(在下一张幻灯片上)

Update the database and publish events

这是与 this one 不同的方法。这是基于 CQRS a la Greg Young .

The domain repository is responsible for publishing the events, this would normally be inside a single transaction together with storing the events in the event store.

我认为将存储和发布事件的责任委托(delegate)给事件存储是一件好事，因为它避免了 2PC 或后台进程的需要。

然而，在某些方面它是真实的 that :

If you rely on the event store to publish the events you'd have a tight coupling to the storage mechanism.

但是，如果我们采用消息代理来实现微服务之间的通信，我们也可以这么说。

更让我担心的是，事件存储似乎变成了单点故障。

如果我们看这个 example来自 eventuate.io


我们可以看到，如果事件存储关闭，我们就无法创建账户或转账，失去了微服务的优势之一。 (尽管系统将继续响应查询)。

那么，确认最终示例中使用的事件存储是单点故障是否正确？

Answer 1

我们使用 NServiceBus 中的 Outbox 方法来处理这个问题:

http://docs.particular.net/nservicebus/outbox/

这种方法要求整个操作的初始触发器作为队列中的消息进入，但效果很好。