微服务：集中授权与每个服务中的授权
Microservices: Centralized Authorization vs Authorization in each service
假设我有一个使用 API 网关构建的微服务系统。
通过网关后的每个请求都必须由身份验证服务（防火墙模式）进行预身份验证
但是授权呢？例如，我在 Hotel Management 系统中有 3 个模型和 3 个服务：
用户
- 每个用户可以拥有多个酒店
酒店
- 酒店由单个用户（所有者）拥有
- 每个酒店可以有很多员工（也是一个用户）
- 一个酒店可以有很多房间
- 为了简单起见，我们假设员工与酒店所有者拥有相同的权利
房间
- 一个房间只能属于一个酒店
- 所有者和员工只能编辑他们 owned/employed 在
酒店的房间
编辑房间 Y 的示例请求，在通过身份验证后，它将有一个经过验证的声明，声明类似于 'I am user X'.
要知道 X 是否有权编辑 Y 我必须向酒店服务提出请求 "Does Y's Hotel associated with (owned by/employing) X?" .
问题是：我在哪里提出这些请求？
让网关在将客户端请求转发到 客房服务 之前询问 酒店服务，或者让 客房服务请自行询问酒店服务。什么时候选择一个而不是另一个？有什么好处？
另外，我觉得这个模型有点不对。所有这些围绕微服务的关系只会让我的系统变得非常复杂。随着它的增长，我越来越难以想象服务之间的工作流程。这个问题有解决办法吗？一个集中式的关系服务，也许可以利用像 Neo4j 这样的图形数据库？
TL；博士；您的问题是您基本上是在将数据模型转换为服务。那是错误的，这不是您为微服务架构建模的方式。 这与数据模型无关，与功能有关。 （我基于你提出问题的方式，你不谈论功能和责任，你谈论关系）。
我将快速回答您问题的第一部分，因为我认为您的问题实际上出在您的建模上。
关于认证授权
The question is: Where do I make these requests? Have the Gateway ask
the Hotel Service before forwarding client request to Room Service, or
let the Room Service ask the Hotel Service by itself. When to choose
one over another ? What's the benefit ?
首先，在您的模型上，客房服务具有足够的 上下文 来实际授权请求。网关没有（也不应该有）足够的信息来判断（网关不应该了解任何关于房间或酒店或任何东西，它的工作是转发请求，而不是解释它们）。
其次，虽然可以让客房服务向酒店申请授权，但最好还是客房服务自己来做，或者打电话给其他负责提供授权的服务（即授权服务）。
但最重要的是，这种微服务架构没有多大意义（正如您所描述的），这就是整个模型使用起来很奇怪的原因。
为什么模型错了
之所以这个模型看起来是错误的，是因为它确实是。
术语 "micro" 服务的问题在于，人们倾向于关注 "micro" 部分而忘记 "service" 部分。关于什么是微服务有不同的看法，但服务是可以自行调用并提供在该服务的多个客户端之间共享的值。
你的客房服务毫无意义。 您基本上是在将数据模型转化为服务。酒店有房间，因此您可以定义酒店服务和客房服务。那不是微服务的意义...
在不知道您的特定用户需求的情况下很难判断，但我的直觉是您可能不需要这里的微服务架构。仅仅因为这是最新趋势，您就不需要用它来解决每一个问题。
如果您的操作类似于 "Register a new room, add photos to a room, remove photos from a room, book a room, etc"，您最好只拥有一个带有简单 API 的后端服务，它允许您执行所有这些简单的操作。老实说，酒店管理系统似乎不是使用微服务架构构建的正确应用程序。老实说，这感觉更像是传统的 MVC 模型。
如果我必须想出一个房间微服务的用例，我会说你可能想要一个了解所有酒店所有房间的客房服务。房间可以由酒店注册、编辑和更改。任何人都可以获得所有可用房间的列表，按可用日期筛选，按床位筛选等。
请注意，我们现在有两三个可能的客户：
- 您管理酒店的前端。
- 您搜索房间的前端。
- 其他人为您的客房服务搜索房间的前端？？。
另请注意，我们已将系统从酒店管理系统更改为可用于查询不同酒店的免费房间的系统...很有用，但完全不同的用户需求。
所以现在您的服务真正有意义了...然后各个部分将开始出现故障。
因为现在你有匿名用户（或系统外的用户），再去酒店服务就没有意义了（毕竟用户不再需要管理酒店了）所以为什么酒店服务会知道吗？
现在，您将如何处理系统的用户？每个微服务会有不同的用户吗？或者是否会有一个在所有微服务之间共享的用户？可能是后者，因此这暗示了另一个用于身份验证的服务（或者如果它适合您的模型，您可以使用 oauth2，这正是对人进行身份验证的服务）。
你打算如何管理你的权限（你的授权），你想要授权的中央配置还是每个微服务都有自己的配置？如果是前者，那么你可能想要另一个为每个微服务提供授权的服务。
假设我有一个使用 API 网关构建的微服务系统。
通过网关后的每个请求都必须由身份验证服务（防火墙模式）进行预身份验证
但是授权呢？例如，我在 Hotel Management 系统中有 3 个模型和 3 个服务：
用户
- 每个用户可以拥有多个酒店
酒店
- 酒店由单个用户（所有者）拥有
- 每个酒店可以有很多员工（也是一个用户）
- 一个酒店可以有很多房间
- 为了简单起见，我们假设员工与酒店所有者拥有相同的权利
房间
- 一个房间只能属于一个酒店
- 所有者和员工只能编辑他们 owned/employed 在 酒店的房间
编辑房间 Y 的示例请求，在通过身份验证后，它将有一个经过验证的声明，声明类似于 'I am user X'.
要知道 X 是否有权编辑 Y 我必须向酒店服务提出请求 "Does Y's Hotel associated with (owned by/employing) X?" .
问题是：我在哪里提出这些请求？
让网关在将客户端请求转发到 客房服务 之前询问 酒店服务，或者让 客房服务请自行询问酒店服务。什么时候选择一个而不是另一个？有什么好处？
另外，我觉得这个模型有点不对。所有这些围绕微服务的关系只会让我的系统变得非常复杂。随着它的增长，我越来越难以想象服务之间的工作流程。这个问题有解决办法吗？一个集中式的关系服务，也许可以利用像 Neo4j 这样的图形数据库？
TL；博士；您的问题是您基本上是在将数据模型转换为服务。那是错误的，这不是您为微服务架构建模的方式。 这与数据模型无关，与功能有关。 （我基于你提出问题的方式，你不谈论功能和责任，你谈论关系）。
我将快速回答您问题的第一部分，因为我认为您的问题实际上出在您的建模上。
关于认证授权
The question is: Where do I make these requests? Have the Gateway ask the Hotel Service before forwarding client request to Room Service, or let the Room Service ask the Hotel Service by itself. When to choose one over another ? What's the benefit ?
首先，在您的模型上，客房服务具有足够的 上下文 来实际授权请求。网关没有（也不应该有）足够的信息来判断（网关不应该了解任何关于房间或酒店或任何东西，它的工作是转发请求，而不是解释它们）。
其次，虽然可以让客房服务向酒店申请授权，但最好还是客房服务自己来做，或者打电话给其他负责提供授权的服务（即授权服务）。
但最重要的是，这种微服务架构没有多大意义（正如您所描述的），这就是整个模型使用起来很奇怪的原因。
为什么模型错了
之所以这个模型看起来是错误的，是因为它确实是。
术语 "micro" 服务的问题在于，人们倾向于关注 "micro" 部分而忘记 "service" 部分。关于什么是微服务有不同的看法，但服务是可以自行调用并提供在该服务的多个客户端之间共享的值。
你的客房服务毫无意义。 您基本上是在将数据模型转化为服务。酒店有房间，因此您可以定义酒店服务和客房服务。那不是微服务的意义...
在不知道您的特定用户需求的情况下很难判断，但我的直觉是您可能不需要这里的微服务架构。仅仅因为这是最新趋势，您就不需要用它来解决每一个问题。
如果您的操作类似于 "Register a new room, add photos to a room, remove photos from a room, book a room, etc"，您最好只拥有一个带有简单 API 的后端服务，它允许您执行所有这些简单的操作。老实说，酒店管理系统似乎不是使用微服务架构构建的正确应用程序。老实说，这感觉更像是传统的 MVC 模型。
如果我必须想出一个房间微服务的用例，我会说你可能想要一个了解所有酒店所有房间的客房服务。房间可以由酒店注册、编辑和更改。任何人都可以获得所有可用房间的列表，按可用日期筛选，按床位筛选等。
请注意，我们现在有两三个可能的客户： - 您管理酒店的前端。 - 您搜索房间的前端。 - 其他人为您的客房服务搜索房间的前端？？。
另请注意，我们已将系统从酒店管理系统更改为可用于查询不同酒店的免费房间的系统...很有用，但完全不同的用户需求。
所以现在您的服务真正有意义了...然后各个部分将开始出现故障。
因为现在你有匿名用户（或系统外的用户），再去酒店服务就没有意义了（毕竟用户不再需要管理酒店了）所以为什么酒店服务会知道吗？
现在，您将如何处理系统的用户？每个微服务会有不同的用户吗？或者是否会有一个在所有微服务之间共享的用户？可能是后者，因此这暗示了另一个用于身份验证的服务（或者如果它适合您的模型，您可以使用 oauth2，这正是对人进行身份验证的服务）。
你打算如何管理你的权限（你的授权），你想要授权的中央配置还是每个微服务都有自己的配置？如果是前者，那么你可能想要另一个为每个微服务提供授权的服务。