architecture - 微服务跨服务依赖

Question

为了简化我的情况，我目前有 3 个微服务。

认证

地点

库存

身份验证服务对用户进行身份验证并发回 JWT 访问 token ，我在其他服务中使用它。它是无状态的，一切正常。

我在位置服务中设置了其他一些位置，并且效果很好并且符合预期。

但现在我在库存服务，我需要添加一些库存，但它链接到一个位置。我可以轻松地在 API 调用中传递 locationId，但我无法授权当前用户向该位置添加内容，除非我随后调用位置服务来验证这一点。

然后这会在彼此之间创建服务依赖关系，这是我不惜一切代价试图避免的事情，否则你只会失去微服务的大部分好处。

验证当前用户是否具有该位置的权限的推荐方法是什么？到目前为止我唯一想到的是

让位置 API 发出另一个访问 token ，并附加声明他们有权访问的位置。

或者发出另一个完全独立的某种 token ，并通过 header 将其传递给库存微服务，以进行类似于 JWT 身份验证方式的验证。

编辑

正如下面提到的提供聚合根(或者我假设这意味着与 API 网关相同)，它将提供另一个服务的第三个选项，以便与两者进行通信以提供信息。

然而，它使第三个服务依赖于另外两个，所以我只是增加了我的服务依赖。

Answer 1

你的微服务设计很差。您正在建模( location 和 items )1 个类 = 1 个微服务，这不是一个好主意。

你应该像 Aggregate Roots 这样的微服务建模在 DDD ;即使有自己的有界上下文。因此，在您的情况下，您应该为 Aggregate Root 建模与 location , items和 user允许在 item addition user action 检查域规则.这可能是，即在您的 Stock Context 中.

当然，这并不意味着您不应该拥有 Wharehouse Context您可以在其中添加、修改和/或删除 locations和(如果不需要依赖项来检查域规则)Aggregate Root只是 Location class .但这是另一个上下文中的其他微服务。

此 post应该可以帮助你。它会给你带来一个很大的A-HA!读完之后在你的脑海里。