【问题标题】：Request based vs Event based architecture基于请求与基于事件的架构
【发布时间】：2019-07-19 09:21:41
【问题描述】：

第一季度

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

第二季度

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

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

【问题讨论】：

【解决方案1】：

第一季度

这是根本的区别。事件发布者不关心谁使用它。在请求/响应中，服务被捆绑。

第二季度

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

如果您仍然能够发布格式不正确的事件，那么您将拒绝该事件并明确记录它。如果该被拒绝事件是事务的一部分并与另一个事件的发布相关联，那么您将引发失败的处理事件（Saga 模式）。

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

【讨论】：

理论上说“糟糕的设计”很容易，但你不能总是涵盖所有场景。例如，ServiceA 发布了 ServiceB 消费的交易事件，期望 Amount 属性大于 0。但有一天，该事件包括“Refund”类型的交易，其 Amount 将为负数。在这种情况下，ServiceB 将抛出异常并将其放入错误队列。除了“糟糕的团队沟通”，您有什么建议可以减轻/防止这种情况？
微服务是一种不断发展的方法，我们在其中不断改进。您的退款示例，其他服务 B 无法更改合同，这完全违反了开闭原则，最终必须修复。但事情可能而且确实会变坏。由于被拒绝的消息被推送到死信队列，因此您需要监控死信队列并调查原因。您可以根据拒绝邮件阈值触发警报。总体而言，尤其是在这种情况下，监控是关键。
你的建议没什么特别的。当然，我已经对死信 q 实施了警报，但现在的争论是谁会在半夜被吵醒？是写 ServiceA 还是 ServiceB 的团队？
“你的建议没什么特别的。当然我已经实现了”。我在你的问题中找不到那个实施部分？你的问题很笼统，答案也很笼统。如果你不喜欢它，你总是可以尊重地不同意。