微服务之间的依赖关系问题

Question

系统上大约有10个微服务，但是其中一个与其他服务的耦合太多。每个微服务都有自己的数据库。可以说

LocationService 

ServiceA

ServiceB

ServiceC

...

ServiceA，ServiceB和ServiceC具有一些与LocationService相关的实体。这意味着这些服务具有某个实体，该实体具有一个名为LocationId的字段，该字段使用LocationService引用LocationDB。

LocationService-> LocationDB

-- Location --

Id

Name

ServiceA-> ServiceADB

-- EntityA --

Id

LocationId

Name

ServiceB-> ServiceBDB

-- EntityB --

Id

LocationId

Name

Description

IpAddress

因为ServiceA或ServiceB无法验证请求传递的LocationId，所以需要使用LocationAPI验证EntityA或EntityB上的任何CRUD操作。因此，当客户端希望通过使用ServiceB创建EntityB时，应该从其他地方验证LocationId。

一种方法是编写一个api编写器，然后在对EntityB或EntityA进行任何操作（实际上仅在创建和更新时）之前，应将LocationId参数（如果已通过验证）发送到LocationAPI，然后将其发送到相关的API 。但是它变得太复杂了，由于耦合，微服务很容易在以后的更改中被破坏。

此问题是否还有其他有效的解决方案，或者这是边界指定错误的设计问题

Answer 1

在某些情况下会发生这种情况，您需要打电话给谁来确保LocationId的正确性。 如果直接从服务中调用此api，则您无法控制，可以通过在创建和更新时验证位置ID来强制使用ID。但是，如果您可以控制服务（在您的范围之内），则可以将位置ID公开为字符串，只是一个ID的占位符，由谁来编写数据以选择正确的值是责任人。

归结为您如何公开合同，谁是相关数据的所有者以及您对呼叫者的信任程度