微服务跨服务依赖

Question

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

1. 验证
2. 位置
3. 广告

身份验证服务对用户进行身份验证并发送回JWT访问令牌，并将其用于其他服务。它的无国籍，一切运作良好。

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

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

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

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

1. 获取位置API以发出另一个访问令牌，其中包含他们有权访问的位置的其他声明。
2. 或发出另一个完全独立的某种令牌，并通过标题将其传递给库存微服务，以进行类似于JWT验证方式的验证。

修改

如下所述，在提供聚合根（或者我假设其意味着与API网关相同）时，它将提供另一个服务的第三个选项，以便与两者进行通信以提供信息。

然而，它留下了第3个服务依赖于其他2个，所以我只是增加了我的服务依赖性。

Answer 1

你的微服务设计很差。您正在建模（location和items）1 class = 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！在阅读之后，在你的脑海里。

Answer 2

虽然@jlvaquero提供了上述想法，但我只是想列出我的实际解决方案是什么以及为什么。

然后归结为此设置

现在验证是在网关级别完成的。我在这里遇到一定程度的不确定性的唯一事实是，我现在正在验证服务之外的实体，该实体意味着负责该域。

库存服务只是接受允许用户附加到该位置。但考虑到位置和用户验证在服务域之外，它适合于它不应该关注该验证。

Answer 3

网关应该只进行身份验证而不是授权。授权在服务内部处理，因为服务仅维护谁可以访问它。我会获得Inventory服务以获取用户有权访问的位置列表。

整个业务流程将在UI级别进行，以便库存服务不会对位置服务构建硬依赖。

这是一种方法 - 不确定这是否适合您。