基于请求与基于事件的架构

bet*_*bet 4 architecture messaging message-queue event-driven-design request-response

第一季度

我知道基于事件与基于请求/驱动架构之间的根本区别。问题是基于请求的总是同步完成而基于事件的总是异步完成的吗?

Q2

此外,在 API 世界(请求-响应)中,如果请求消息无效,您通常会返回 400 http 代码。幸运的是,在 API 世界中,我们可以执行契约测试,使集成更加健壮。

除了将消息放入错误队列之外,在消息队列中处理此类似问题的最佳方法是什么?发布者服务或消费者服务是否有责任首先获得问题通知?

Imr*_*had 6

第一季度

这就是根本的区别。事件发布者不关心谁消费它。在请求/响应中,服务被捆绑在一起。

Q2

在事件驱动系统中,发布者有责任包含其他服务可以使用的所有内容。如果事件不包含它需要的所有内容,那么您首先无法发布事件,因此您需要确保是这种情况。这是事件驱动的重点,因为消费者希望选择带有它需要的所有数据的消息。

如果您仍然能够发布格式不正确的事件,那么您将拒绝该事件并绝对记录它。如果被拒绝的事件是事务的一部分并链接到另一个事件的发布,那么您将引发失败的处理事件(Saga 模式)。

最佳实践是使用所有必要的有效负载引发事件。如果事件格式不正确,那么这是一个糟糕的设计,最终会变得难以大规模处理。

  • “你的建议没什么特别的。当然我已经实施了”。我在你的问题中找不到那个实现部分?您的问题很笼统,答案也很笼统。如果你不喜欢它,你总是可以恭敬地不同意。 (3认同)
  • 微服务是一种不断发展的方法,我们可以不断改进。您的退款示例是其他服务 B 无法更改合同,这完全违反了开闭原则,最终必须修复。但事情可能而且确实会变得更糟。由于被拒绝的消息被推送到死信队列,因此您需要监视死信队列并调查原因。您可以根据拒绝的邮件阈值触发警报。一般来说,监控是关键,特别是在这种情况下。 (2认同)