微业务跨服务依赖关系

Question

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

1. 身份验证
2. 位置
3. 库存

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

我在位置服务中设置了一些其他的位置，这很好，而且和预期的一样。

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

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

建议采用什么方法来验证当前用户是否拥有该位置的权限？到目前为止我唯一想到的就是

1. 让locations发出另一个访问令牌，并附加声明它们可以访问哪些位置。
2. 或者发出另一个完全独立的令牌，并将其通过报头传递给库存微服务，以进行类似于JWT身份验证的验证。

编辑

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

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

Answer 1

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

您应该在DDD中建模像DDD这样的微服务；即使使用它自己的有限上下文也是如此。因此，在您的示例中，您应该使用允许在Aggregate Root上检查域规则的location、items和user来建模一个user。这可能是，即，在您的Stock Context中。

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

这个post应该能帮你。它会给你带来一个大A-哈哈！在你读完它后在你脑海里。

Answer 2

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

然后，它归结到这个设置

​

​

现在，验证是在网关级别完成的。在这里，我唯一有某种程度的不确定性是，我现在正在对服务之外的一个实体进行验证，该实体本来是负责该领域的。

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

Answer 3

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

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

这是一种方法--不确定这是否对你有用。