我是微服务的新手，已经读了很多文章，但是我没有找到任何实际有用的教程。
因此，我将在Laravel 9中构建微服务，并在Docker上使用passport，它将使用每个服务的数据库和API网关。所有请求都将流经API网关，在那里将进行身份验证，然后将其转发到特定的微服务。
请注意，只有我的API网关将公开访问，其他微服务将不会公开，他们将在内部使用。
此外，这将托管在AWS上，并将使用无服务器架构，可能是Lambda，Api Gateway或Fargate尚未真正决定。
我有以下问题：
What grant type is suitable in API gateway architecture ?Do I need to write all routes from all microservices in API gateway ? if yes than means that routes will be written twice i.e. in API gateway and individual microservice as well, so how to write the API gateway exactly ?If I want to combine data from different mciroservices into one than should I do that in api gateway ?How to authenticate request between microservices as I want it to be secure internally too, should I use the public and private key feature that is provided in passport ? if yes how to verify the keys when request arrives in each microservice ?
1条答案
按热度按时间6kkfgxo01#
我想你的系统看起来像这样：
System Architecture
授权类型并不完全取决于API网关架构，而是更多地取决于将使用API的客户端类型。您能否对此进行更详细的说明？
正如您所说的那样，API网关将负责身份验证和路由。选择实现微服务架构的主要原因之一是将系统分解为更小的独立服务。API网关和服务之间存在依赖关系。但是你可以通过使用通配符将这种依赖性保持在一个可管理的级别。例如，所有匹配
/pets/*的请求都转到"Pets"服务。不应在API网关中聚合来自多个微服务的数据以组合单个响应，因为这通常是某种业务逻辑的实现。API网关不应实现业务逻辑，它应验证和路由请求。
实现此类功能的正确方法是BFF (Backend for frontend)，它基本上是一个附加的微服务，用于实现所需的行为。
它看起来像这样：System with BFF
这也很难推广。但是如果你愿意，你可以使用用户的授权令牌。验证这个令牌的一种方法是只检查令牌在微服务中是否还没有过期。如果API网关注意令牌通常是有效的，这就可以工作。
如果您需要在没有用户上下文的情况下在微服务之间进行通信，那么您需要找到一种替代方法。