我不了解事件来源

我是活动采购的新手，我心中有一些疑问。 Here example diagram.

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

感谢帮助。

我不了解事件来源

那不是你的错。文学真烂。

这里是示例图。

好的，因此，我可以为您提供有关该图的最重要的一课：它与事件源没有关系。它与消息，分布式系统和事件驱动有很大关系。但是事件源是另一种动物。

从高层次看，根本的担心是分布式系统不完善。因此，我们需要接受它作为设计中的约束，并加以处理。帕特·海兰（Pat Helland）的Memories,Guesses,and Apologies是一个很好的起点。

在正常操作中，我们永远不会有两个钱包服务执行相同的工作。它们可能是共享工作（与Book Services从负载平衡器共享工作的方式几乎相同）。

一种共享作品的方式是为每条消息分配一个唯一的编号；顶部的钱包处理奇数消息，而忽略偶数消息，底部的钱包处理偶数消息，而忽略奇数消息。

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

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