微服务客户循环依赖

Question

在微服务架构中，使用客户端包在服务之间进行通信时，我们遇到了一个问题，即两个客户端包相互依赖，从而产生了循环依赖。

我们正在努力寻找最佳解决方案，我想知道是否有人能够帮助或指出我们正确的方向。

这是场景：

• 汽车和保险这两项服务
• 两个客户端软件包，CarClient和InsuranceClient。

每当任何服务需要与Car服务进行通信时，都应使用CarClient软件包进行通信。每当任何服务需要与保险服务进行通信时，都应使用InsuranceClient程序包。

CarClient程序包具有一个数据传输对象（DTO）Car，其属性之一是insurance。此属性的类型是InsuranceClient软件包CarInsurance中可用的DTO。

问题是CarInsurance DTO需要访问CarClient软件包CarTypeEnum中可用的枚举时。现在我们有了两个相互依赖的软件包。

我能想到的可能解决方案：

1. 这是由于设计不良所致。重新设计服务和软件包以防止这种循环依赖。
2. 将枚举移动到单独的程序包中，因此，两个客户端都可以依赖这些程序包，但客户端彼此之间不会相互依赖。

感谢您的帮助。

Answer 1

您不应该在服务之间共享任何代码，因为这破坏了它们100％独立的全部目的。

在MS体系结构中，CarDTO仅具有与汽车相关的属性。如果您想获取有关保险的信息，可以单独致电保险服务以获得仅具有保险属性的InsuranceDTO。

在调用任何一项服务时，您都将使用一些键将其绑定在一起。即您将使用从客户服务获得的customerId调用汽车服务，而CarDTO将拥有carId，然后可以使用customerId / carId调用保险服务以获取InsuranceDTO。

Answer 2

我阅读了先前回答的注释中漫长的对话，并且我想补充一点，以支持“在每个回购中仅复制它们”的想法。

如果您基于DDD（域驱动设计）的思想来设计服务，您可能会意识到，相同的概念/实体可能意味着不同域中的事物。

这意味着CarService内的“保险”可能具有-取决于域/要求-与InsuranceService中的属性完全不同的属性。这就是为什么CarService中的保险概念应具有自己的dto，而该dto应该完全脱离InsuranceService的保险定义。

Answer 3

您不能在保险服务中使用CarTypeEnum。只需使用一个CarId。当您需要了解类型时，只需向汽车服务部门索取该信息即可。