Events 如何处理服务之间的事件处理时间

假设我们有两个服务A和B。B与A有关系，所以它需要了解A的现有实体

每次创建或更新实体时，服务都会发布事件。服务B订阅A发布的事件，因此知道服务A中存在的实体

问题：客户端（UI或其他微服务）创建了一个新的实体“a”，并立即创建了一个引用“a”的新实体“b”。这是在没有太多延迟的情况下完成的，因此，如果服务B在获得引用为“B”的创建请求之前没有接收/处理来自B的事件，会发生什么情况

这应该如何处理

服务B必须失败，客户端应处理此问题，并可能重试

服务B接受实体，并随着时间的推移，期望在接收到预期事件时满足关系。服务B为实体提供了一种状态，以确保在关系被验证之前它不受信任

客户端可以/必须在同一事务中执行这两个调用，这是一个糟糕的设计。设计应该有所不同。怎么做

其他方式

---

我知道像Kafka这样的事件平台可以确保非常快的事件传递，但总是会有延迟，因为这是一个异步过程，所以会有一种竞争条件。

我认为您希望利用代理的灵活性和同步调用的确认。这两个目标都可以通过这种方式实现

---

您所问的问题属于弥合最终一致性与良好用户体验之间差距的一般范畴，这是分布式体系结构中一个有据可查的挑战。您必须在可用性和一致性之间进行选择；通常情况下，您不能同时拥有这两者

您的示例提出了服务边界是否合适的问题。在实体周围定义微服务边界是一个常见的错误，但这是一个反模式。微服务边界应与与业务用例相关的域边界一致，而不是如何在这些边界内对实体建模。讨论分解，但TL；博士是:

微服务应该是动词，而不是名词

例如，您可以有一个

CreateNewBusinessThing

microservice来处理这个特定案例。但是，现在，我们假设您有充分和有效的理由将服务按原样进行划分

在您的情况下，“正确”的解决方案取决于消费服务/应用程序的需求。如果消费者是某种应用程序或用户界面，则需要响应能力，这将成为您的首要需求。如果消费者是另一个微服务，那么它很可能更关心获得好的“最终”数据，而不是响应

在这两种情况下，一个好的选择是facade（又称网关）服务，它位于客户机和高度依赖的服务之间。此服务可以接收并持久化请求，然后根据您的意愿进行响应。它可以为消费者提供一个

200-OK

响应，该响应带有一个端点，用于回调以检查请求的状态，响应速度非常快。或者，当从两个后端服务完成响应时，它可以接收一个URL用作webhook，因此它可以直接通知客户端。或者它也可以发布自己的事件（很可能应该发布）。本质上，您可以定制facade服务，以便以每个消费者想要的方式向需要的尽可能多的消费者提供服务

还有其他选择。你可以调查，调查，甚至只是