我不懂事件溯源答案

【问题标题】：I don't understand event sourcing我不懂事件溯源
【发布时间】：2021-02-04 21:06:11
【问题描述】：

我是事件溯源的新手，我有一些疑问。 Here example diagram.

假设我们有 2 个服务 BookShop 实例和 2 个服务 Wallet 实例。用户要求 BookService_1 给他买一本书。该图书服务创建事件 BuyBookRequestCreated 并将其推送到事件总线。事件总线将此事件发送到服务钱包的两个实例。现在有两个实例尝试从用户钱包中预留足够的钱，它们都发出事件 BookMoneyReserved?现在在另一方面，BookShop 服务的两个实例接收 2 个事件，它们都尝试发出事件 BookBought？或者，也许 eventbus 只会将 BuyBookRequestCreated 发送给一个订阅者？但是当这个选定的服务失败时会发生什么？
从 API 消费者的角度来看，如何处理这种模式？如果我调用某个 API 给我买一本书，我希望它在买书时“返回 200”。在事件溯源模式中，无需等待其他服务的响应，因此如果其他服务必须发出事件以完成图书购买，则无法告诉客户他的购买是否真的失败。
我有点迷失在整个微服务世界中。一方面我们有 Grpc、protobufs 和服务网格，但另一方面我们有事件溯源和事件驱动架构。什么时候用哪个？从我所看到的和可以理解的情况来看，我可以同时使用事件溯源和 grpc 吗？我可以只使用 grpc 来传达 beetwen 服务并将事件保存为一种状态持久性的形式，或者我可能完全没有得到它，应该再次阅读文章？

感谢您的帮助。

【问题讨论】：

【解决方案1】：

我不懂事件溯源

这不是你的错。文学很烂。

这里是示例图。

好的，关于该图，我能给你的最重要的一课是：它与事件溯源无关。它与消息传递、分布式系统和事件驱动有很大关系。但事件溯源是另一回事。

在高层次上，一个基本的问题是分布式系统是不完美的。所以我们需要接受它作为我们设计中的约束，并使用它。 Pat Helland 的Memories, Guesses, and Apologies 是一个很好的起点。

在正常操作中，我们永远不会让两个钱包服务做同样的工作。他们可能正在共享工作（与 Book Services 共享来自负载平衡器的工作的方式非常相似）。

您可以共享工作的一种方法是为每条消息分配一个唯一编号；顶层钱包处理奇数消息并忽略偶数消息，底层钱包处理偶数消息并忽略奇数消息。

当然，正常运行是你想要的，但不一定是你得到的——毕竟distributed systems are imperfect。对于某些类型的问题，有舒适的模式 - 锁定或幂等消息处理 - 并且您的系统可以继续提供业务价值。

对于其他类型的问题，答案是有人打电话，告诉别人有错误，我们可以解决吗？

【讨论】：

我想我开始明白了。我混淆了事件溯源和域事件。事件通信 beetwen services != 事件溯源，但因为在互联网上的大多数讲座中，这两者都显示在我的脑海中作为一个单一的概念。
@Arczewski 绝对是。事件溯源实际上只是一种数据持久化机制。它是关于保持关于您的域的“事实”流（例如“CustomerSignedUp”、“CustomerCreditLimitIncreased”、“CustomerMovedAddress”），并且可以“重放”以构建域聚合的当前状态（例如客户、销售订单、产品等）。事件溯源并没有强制要求消息通过网络发送，但实际上，大多数事件溯源系统也是分布式系统，因此也与消息异步通信。
@VoiceOfUnreason 不确定为什么文学如此糟糕。我乐观地假设我的书有足够的关于事件溯源的内容。在 Event Store 博客中，我们发表了几篇解释什么是 Event Sourcing 的文章。我同意那里的许多博客文章不会通过讲述有关事件溯源的奇怪事情来帮助人们，但这对于其他事情也是有效的。