我不明白事件溯源
I don't understand event sourcing
我是事件溯源的新手，有一些疑问。 Here example diagram.
假设我们有 2 个 BookShop 服务实例和 2 个 Wallet 服务实例。
用户要求 BookService_1 给他买一本书。此图书服务创建事件 BuyBookRequestCreated 并将其推送到事件总线。事件总线将此事件发送到服务钱包的两个实例。现在有两个实例尝试从用户钱包中预留足够的钱，它们都发出事件 BookMoneyReserved?现在在另一边，BookShop 服务的两个实例接收到 2 个事件，它们都尝试发出事件 BookBought？或者 eventbus 可能只会将 BuyBookRequestCreated 发送给一个订阅者？但是当这个选定的服务失败时会发生什么？
如何从 API 消费者的角度处理这种模式？如果我打电话给一些 API 给我买一本书，我希望它在买书时是“return 200”。在事件采购模式中，没有等待其他服务的响应，因此如果其他服务必须发出事件来完成图书购买，则无法告诉客户他的购买是否真的失败了。
我对整个微服务世界有点迷茫。一方面，我们有 Grpc、protobufs 和服务网格，但另一方面，我们有事件溯源和事件驱动架构。什么时候使用哪个？从我所看到和理解的情况来看，我可以将事件溯源和 grpc 一起使用吗？我可以只使用 grpc 来通信 beetwen 服务并将事件保存为状态持久性的一种形式，或者我可能完全没有理解它并且应该再次阅读文章？
感谢您的帮助。
I don't understand event sourcing
那不是你的错。文学烂透了。
Here example diagram.
好的，所以我可以给你关于该图的最重要的一课：它与 事件源 无关。它与消息传递、分布式系统和事件驱动有很大关系。但事件溯源是另一种动物。
在高层，一个根本的问题是分布式系统是不完美的。所以我们需要接受它作为我们设计中的约束，并使用它。 Pat Helland 的 Memories, Guesses, and Apologies 是一个很好的起点。
在正常操作中，我们永远不会让两个钱包服务做同样的工作。他们可能 共享 工作（与图书服务从负载平衡器共享工作的方式大致相同）。
您可以共享工作的一种方式是为每条消息分配一个唯一的编号；顶部钱包处理奇数消息并忽略偶数消息，底部钱包处理偶数消息并忽略奇数消息。
当然，正常运行是你想要的，但不一定是你得到的——毕竟distributed systems are imperfect。对于某些类型的问题，有舒适的模式 - 锁定或幂等消息处理 - 您的系统可以继续提供业务价值。
对于其他类型的问题，答案是有人上了 phone，然后告诉其他人出现了错误，我们可以解决吗？
我是事件溯源的新手，有一些疑问。 Here example diagram.
假设我们有 2 个 BookShop 服务实例和 2 个 Wallet 服务实例。 用户要求 BookService_1 给他买一本书。此图书服务创建事件 BuyBookRequestCreated 并将其推送到事件总线。事件总线将此事件发送到服务钱包的两个实例。现在有两个实例尝试从用户钱包中预留足够的钱，它们都发出事件 BookMoneyReserved?现在在另一边，BookShop 服务的两个实例接收到 2 个事件，它们都尝试发出事件 BookBought？或者 eventbus 可能只会将 BuyBookRequestCreated 发送给一个订阅者？但是当这个选定的服务失败时会发生什么？
如何从 API 消费者的角度处理这种模式？如果我打电话给一些 API 给我买一本书，我希望它在买书时是“return 200”。在事件采购模式中，没有等待其他服务的响应，因此如果其他服务必须发出事件来完成图书购买，则无法告诉客户他的购买是否真的失败了。
我对整个微服务世界有点迷茫。一方面，我们有 Grpc、protobufs 和服务网格，但另一方面，我们有事件溯源和事件驱动架构。什么时候使用哪个？从我所看到和理解的情况来看，我可以将事件溯源和 grpc 一起使用吗？我可以只使用 grpc 来通信 beetwen 服务并将事件保存为状态持久性的一种形式，或者我可能完全没有理解它并且应该再次阅读文章？
感谢您的帮助。
I don't understand event sourcing
那不是你的错。文学烂透了。
Here example diagram.
好的，所以我可以给你关于该图的最重要的一课：它与 事件源 无关。它与消息传递、分布式系统和事件驱动有很大关系。但事件溯源是另一种动物。
在高层，一个根本的问题是分布式系统是不完美的。所以我们需要接受它作为我们设计中的约束，并使用它。 Pat Helland 的 Memories, Guesses, and Apologies 是一个很好的起点。
在正常操作中，我们永远不会让两个钱包服务做同样的工作。他们可能 共享 工作（与图书服务从负载平衡器共享工作的方式大致相同）。
您可以共享工作的一种方式是为每条消息分配一个唯一的编号；顶部钱包处理奇数消息并忽略偶数消息，底部钱包处理偶数消息并忽略奇数消息。
当然，正常运行是你想要的，但不一定是你得到的——毕竟distributed systems are imperfect。对于某些类型的问题，有舒适的模式 - 锁定或幂等消息处理 - 您的系统可以继续提供业务价值。
对于其他类型的问题，答案是有人上了 phone，然后告诉其他人出现了错误，我们可以解决吗？