我知道微服务是分离上下文并允许我们创建较小模型的好方法。实现解耦的方法之一是微服务之间的异步发布/订阅通信。
假设微服务 A 负责处理请求，并且需要存储在微服务 B 中的信息。 解决此问题的方法之一是，使微服务 A 订阅来自微服务 B 的事件，将所需数据的一部分复制到其中＆＃39;数据存储并将其用于将来的处理。
现在，如果用户向微服务 A 发送请求以处理某些内容，并且微服务 A 未处理来自微服务的最新事件B ，它是一种更好的方式来使用同步通信，并直接请求该部分数据吗？如果是的话，这被视为＆＃34;违反＆＃34;当前的设计和耦合？
它是否也被视为错误的建模？例如 - 如果 A 上下文中需要数据，则它应该从开始就成为该上下文的一部分。
答案 0 :(得分：3)
它是否也被视为错误的建模？例如 - 如果在A上下文中需要数据，则它应该从开始就成为该上下文的一部分。
是的，可能是。
总之，如果微服务B是此用例中所需数据的技术权威，那么微服务B应该提供该功能。
是否被认为是对当前设计和耦合的“违反”？
在该设计中，如果微服务B不可用，那么微服务A就无法提供价值。这听起来像是与我联系。
我的猜测，如果你被困在这种模式中，那就是与B同步进行通信，但是当B不可用时，可以使用本地数据缓存。
如果共享的数据是不可变的，则有些问题会消失。
这当然只有在业务允许使用缓存数据时才有效，否则A需要拥有数据或抛出异常
如果数据的编写者是B，那么A 看到的任何数据都是缓存的数据;服务B可能在A正在查看时更改数据。如果A做出的决定需要B写的数据的实时副本，那么您就会遇到更大的问题 - 您的服务边界位置错误。