同步通信微服务

Question

我知道微服务是分离上下文并允许我们创建更小的模型的好方法。实现解耦的方法之一是微服务之间的异步发布/订阅通信。

假设微服务 A 负责处理请求，为此它需要存储在微服务 B 中的信息。 解决这个问题的方法之一是，让微服务 A 订阅来自微服务 B 的事件，将所需数据的一部分复制到它的数据存储中，然后将其用于将来的处理。

现在，如果用户向微服务 A 发送请求来处理某事，而微服务 A 没有处理来自微服务 的最新事件B，使用同步通信并直接请求那部分数据会更好吗？如果是，这是否被认为是对当前设计和耦合的“违反”？

是否也可以认为是错误的建模？例如 - 如果在 A 上下文中需要数据，那么它应该从一开始就是该上下文的一部分。

Answer 1

是否也可以认为是错误的建模？例如 - 如果 A 上下文中需要数据，那么从一开始它就应该是该上下文的一部分。

是的，可能是。

• The Known Unknowns of SOA
• Secret of Better UI Composition

总而言之，如果微服务 B 是您在此用例中所需数据的技术权威，那么微服务 B 应该提供该功能。

这是否被认为是对当前设计和耦合的“违反”？

在那个设计中，如果微服务 B 不可用，那么微服务 A 就无法提供价值。这听起来像是对我的耦合。

如果您陷入这种模式，我的猜测是与 B 同步通信，但在 B 不可用时使用本地数据缓存。

如果共享的数据是不可变的，一些问题就会消失。

这当然只有在业务允许使用缓存数据时才有效，否则 A 需要拥有数据或抛出异常

如果数据的写入者是B，那么A看到的任何数据都是缓存数据；服务 B 可能正在更改数据，而 A 正在查看它。如果 A 做出的决定需要 B 写入的数据的实时副本，那么您将遇到更大的问题 - 您的服务边界位于错误的位置。