微服务架构——如何从API网关获取用户信息到微服务

Question

我计划使用 API 网关设置一组微服务，我是微服务架构的新手，但我计划添加更多服务并保持此应用程序的高度可扩展性。 API 网关应管理用户及其权限，并将传入请求委托给底层微服务。 但我的问题是，如何在网关处的用户与微服务中的实体之间建立关系。

就像上图一样，我需要弄清楚在底层服务中处理用户关系的最佳实践是什么。 我想用 laravel 实现所有服务，网关应该使用 laravel\passport。

我的想法是 API 网关负责对用户进行身份验证并将请求转发到网关后面的服务。 如果用户通过了身份验证，他就可以通过网关访问服务。 但是我如何向服务提供有关用户的信息，例如，如果用户在服务 A 中编辑了一个项目，我如何存储哪个用户编辑了该项目。 建立这种关系的方法是什么？

Answer 1

选择方法时需要考虑很多方面，因此基本上回答您的问题主要是为您提供可以深入研究的指导。

以下是您应该查看的一些方法，它们在很大程度上取决于您的服务：

• 整个平台的身份验证/授权方法
• 每个单独的服务如何相互通信（同步 REST 呼叫、消息、GraphQL、GRPC，...）
• 个人服务是如何安全的（每个服务都是公共的并且进行身份验证，每个服务都在一个安全的网络后面，只有网关是公共的，服务网格负责身份验证，......）

基于 REST 的微服务中最常见的身份验证方法是OAuth ，具有 JWT 个令牌。 我建议你深入研究一下。

（现在离题一点，以证明这取决于用例和架构的变化有多大）

采取 OAuth 并查看您的问题，您将根据用例使用 OAuth 中的不同流程。 例如，为用户生成令牌将不同于为服务生成令牌。

然后您仍然需要决定在每个服务中使用哪个令牌：网关后面的服务是接受用户令牌，还是只接受服务到服务令牌？ 这对您需要评估的架构有影响。 使用用户令牌时，您可以在令牌中对用户 ID 进行编码，然后从那里提取它。 但是，如果您在任何地方都使用用户令牌，那么它会假定服务仅作为用户流的一部分相互通信，并且您将通过使用用户令牌来强制执行此操作。 如果您 go 使用服务到服务令牌（我认为是一种更常见的方法），则需要以其他方式传递用户 ID（同样，这取决于您选择的体系结构）。 想到REST，可以使用Headers，Request Params，Request Path，Request Body。 您需要根据每个服务的业务领域评估每个服务的权衡，这会影响 API 设计。

如果您根本不使用令牌，因为您的所有服务都在一个安全网络中，那么您仍然必须使用协议的某些方面来传递用户 ID（标头、参数等...）