【问题标题】:Event Sourcing, Conflict between two services in processing same event事件溯源,两个服务在处理同一事件时发生冲突
【发布时间】:2019-08-31 19:39:59
【问题描述】:

我开始学习事件溯源和 CQRS,但我没有做对。

如果我有两个服务都以不同的方式处理相同的事件(例如在预订示例中,一个服务检查时间段,另一个检查用户信用),并且其中一个接受事件但另一个不接受,系统应该怎么做?

服务应如何知道其他服务是否已接受或拒绝该事件?

【问题讨论】:

    标签: microservices cqrs event-sourcing


    【解决方案1】:

    在高层次上:当您拥有分布式系统时,系统中的不同组件通过传递消息来共享信息。当您的日程安排服务想让您知道您请求的时间段已为您保留时,它会向您发送一条消息。

    当您想知道其他地方发生了什么时,您可以查看收到的消息。

    服务应如何知道其他服务是否已接受或拒绝该事件?

    要理解的重要一点是,服务永远不应该是declining 事件。 ApprovalRequested 是描述发生的事情,订阅服务不能让它不发生。

    通常会发生的情况是订阅者将收到ApprovalRequested,更新自己的本地数据,然后根据需要发出ApprovalGrantedApprovalDeclined

    在您的情况下,您有一个订阅者将发出对时间段的批准或拒绝,而另一个订阅者将发出对信用检查的批准或拒绝。

    在其他地方,我们有一个状态机,它正在记录所有这些事件以了解预订是否成功。

    Rinat Abdullin 关于process managers 的文章可能会有所帮助。

    【讨论】:

      【解决方案2】:

      据我所知,这些处理器中的每一个都会根据其他结果进行计算。

      例如,您可以在上游拥有另一个服务,该服务将收集这些服务的结果并将它们聚合,当它拥有事件的所有处理结果时,它可以做任何您想做的事情。它知道哪些进程被接受,哪些进程没有被接受,并根据您系统的逻辑决定要做什么。

      例子:

      BookingService 发出事件:

      {
          "bookingId": 123,
          "creditCardDetails": ...,
          "timeslot": ...
      }
      

      CreditCardService 接收和发射:

      {
          "service": "CreditCardService",
          "bookingId": 123,
          "accepted": false,
      }
      

      TimeslotService 接收和发射:

      {
          "service": "TimeslotService",
          "bookingId": 123,
          "accepted": true,
      }
      

      BookingProcessingAggregatorService 中,您会收到所有回复并做出相应反应。

      我创建了一个示例,使用 Typescript 和 RxJS 来模拟带有事件的消息传递系统, 希望这足够清楚(无论如何写它都很好,所以它也可能对您有所帮助?):

      https://rxjs-nexjv8.stackblitz.io

      【讨论】:

      • 感谢您的回答。对我来说,这种方法的问题在于接受事件的服务改变了它的物化视图。因此,如果其他服务未以某种方式批准该事件,则聚合器服务应撤消它。我认为这可能会导致非常复杂的情况,因为所有服务都应该支持撤消事件。
      • 如果在撤消发生之前到达服务的另一个事件会变得更加复杂。
      • 因此您必须将操作与验证分开。绝望的验证和行动,聚合器,然后变成一个主要的验证服务,将验证传递给服务的事实,只有这样他们才会做他们能做的。
      • 如果你不能这么简单地做到这一点,你必须想办法进行回滚或防止副作用离开系统。
      • 这是阅读这类东西的好资源:docs.microsoft.com/en-us/azure/architecture/patterns
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2019-02-20
      • 1970-01-01
      • 2016-04-25
      • 2013-03-09
      • 2023-03-24
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多