微服务跨服务依赖答案

【问题标题】：Micro Service cross service dependencies微服务跨服务依赖
【发布时间】：2015-09-03 15:56:19
【问题描述】：

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

身份验证
地点
库存

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

我在定位服务中设置了位置以及其他一些东西，这运行良好且符合预期。

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

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

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

让位置 API 发出另一个访问令牌，并附加声明他们有权访问哪些位置。
或者发出另一个完全独立的某种令牌，并通过标头将其传递给库存微服务，以执行类似于 JWT 身份验证方式的验证。

编辑

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

但是它使第 3 个服务依赖于其他 2 个服务，所以我只是增加了我的服务依赖项。

【问题讨论】：

在谷歌中寻找aggregate 和aggregate root。它是一个非常适合微服务的事务元素。

标签： architecture microservices

【解决方案1】：

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

您应该在DDD 中为Aggregate Roots 之类的微服务建模；即使有自己的有界上下文。因此，在您的情况下，您应该使用location、items 和user 对Aggregate Root 建模，以允许在item addition user action 检查域规则。这可能是，即，在您的 Stock Context 中。

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

这个post 应该可以帮助你。它会给你带来一个大大的 A-HA！读完后记在心里。

【讨论】：

我还没有建模 1 class= 1 个微服务。每个服务都处理自己的域，有许多表，但它在逻辑上分组为处理特定的功能。位置和库存有几个与之关联的模型。但是那里有依赖关系。位置服务还将为应用程序中与库存无关的其他部分处理基于位置的服务。
只是添加示例真的很愚蠢，所以我可以强调跨服务依赖的方面。当我看到一个跨服务依赖时，我首先想到的是，我应该将它组合在一起，但它不能在所有情况下都完成，因为我会将库存、位置和其他服务全部组合成一个，然后它只是最终形成一个庞大的单体 API，将所有内容组合在一起。
" 我将把库存、位置和其他服务合二为一" 我的意思不是组合服务，我的意思是从持久性中获取聚合根，并仅提供一个带有用户案例的微服务，这意味着这一点聚合根。
当然，这会带来很多关于如何处理持久性的问题；所有微服务都使用相同的持久性系统？分成读/写模型？每个服务都有独立的写入模型，只有一个读取模型？等等。这当然取决于您的系统和要求。微服务的旅程很长，需要花费大量时间和工作，直到一切都匹配。

【解决方案2】：

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

然后归结为这个设置

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

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

【讨论】：

如果我可以问，我也开始使用微服务模式。我可以麻烦你一些建议吗？我在这里发了一个Q：stackoverflow.com/questions/34794630/micro-service-security

【解决方案3】：

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

整个编排将在 UI 级别进行，因此库存服务不会建立对位置服务的硬依赖。

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

【讨论】：