【发布时间】：2018-08-03 04:09:48
【问题描述】：
据我了解，当数据库事务跨越微服务时，我们可以通过发布事件使用消息代理（kafka、RabbitMQ 等）来解决此问题，以便订阅者微服务可以通过侦听这些事件来更新其数据库。
如果出现异常，我们可以发送失败事件，以便订阅者服务可以更新它们的状态。
这还不够吗？这种方法有什么问题？
为什么以及何时需要事件溯源？
我们真的需要事件溯源吗？
【问题讨论】：
标签： microservices cqrs event-sourcing
【发布时间】：2018-08-03 04:09:48
【问题描述】：
一点也不。无需 CQRS 和事件溯源，您就可以拥有定义良好的微服务风格架构。 CQRS 和事件溯源是微服务内部设计的解决方案。您可以选择使用 CQRS 和事件溯源来实现所有或部分微服务。
让我们看看事件溯源如何帮助您。事件溯源是使用事件而不是像实体框架或 Hibernate 和 SQL 数据库这样的 ORM 来恢复实体的当前状态的替代方法。假设您有一个微服务来存储有关图书的数据。如果您使用 SQL，您将拥有控制器和端点来创建、更新和删除一本书并将这些书存储在 SQL 表中。如果您想更新那本书，那么为了获得当前状态，您将返回 SQL 表并查询该书（通过其 id），然后您的 ORM 将该表表示形式转换为书对象（对象关系阻抗不匹配问题），然后您将应用更改并将更改的书籍对象保存回 SQL 表中。作为替代方案，您可以将书籍对象的事件存储在 NoSQL 数据库（如 MongoDB）或事件存储中。现在为了更新这本书，首先你会想要恢复当前状态，你可以通过取回与这本书相关的所有事件并重播这些事件来恢复当前状态来做到这一点。您的事件成为事实的来源，您完全避免了 ORM 映射和 SQL 连接的瓶颈。事件存储为 JSON 文档，通常速度非常快。
现在，来到 CQRS - CQRS 纯粹是一种用于分离关注点的模式。您将使用 CQRS 将读取端与写入端分开。与写入端相关的端点（如创建、更新和删除）存在于一个服务中，而读取端的端点存在于另一个服务中。您在这里获得的优势是独立扩展、部署、维护等等。如果您的应用程序是读取密集型的，则为读取端服务部署多个实例。
如果你想了解更多，欢迎私信我。祝你好运！
【讨论】：
您将补偿模式描述为分布式事务的替代。在面向微服务的架构中，这是一种通过利用最终一致性来关注可用性的好方法：每个服务将在没有事务上下文的情况下执行其子任务，而不是在服务之间拥有一个集中协调的分布式事务。如果出现问题，每个服务都会被告知失败并执行某种（语义）对先前操作的补偿。因此，事务操作最终被撤消。
正如您已经说过的，可以通过消息总线系统进行通信，并且不需要事件溯源或 CQRS，补偿模式不依赖于这些原则。
【讨论】：
我认为您对微服务的东西感到困惑 :) 它们是设计可扩展应用程序的解决方案，与数据库事务无关。更重要的是，数据库事务（理想情况下）不应该跨越进程，更不用说微服务了。
发布-订阅方法是不同微服务（也适用于进程内模型）的通信方式。与数据库事务无关。事件溯源就是将域状态视为相关更改的集合。与微服务相比，目标截然不同。
我们使用 ES 是因为我们喜欢将领域事件存储为“单一事实来源”，无论是否为微服务。这都是关于域模型设计的。
了解有关 ES、DDD、CQRS 的更多信息，并将微服务留到未来。它们现在太流行了，很少有应用需要它们，很少有开发者能真正正确地使用它们。
【讨论】：