我正在考虑在我的微服务上使用api网关。但是有一些架构问题我没有明确的答案，所以我希望得到社区的意见。如果你能分享你对好的和坏的做法的想法，那也很棒。因此，为了使这个问题易于阅读，我有两个主要部分＆＃34;问题＆＃34;和＆＃34;详细信息＆＃34;

问题

Api网关是否应承担授权和请求转换的责任？

问题主要在于什么是网关：它只是api用户和微服务之间的桥梁。或者它是微服务的主持人？请参阅＆＃34;网关实施策略＆＃34;了解更多信息。

如果使用Amazon API Gateway，使用额外的lambda函数层进行请求转换和授权是否是一种好习惯？

如果我选择使用亚马逊API网关，并回答上一个问题将是＆＃34;网关应该充当微服务的主持人＆＃34;。我需要通过亚马逊lambdas处理请求/响应转换和授权，这意味着我将在网关下面有另一层。所以问题是：拥有这种架构是一种好习惯吗？

详细

技术

Spring Boot 2.0
JWT
Spring云网关或亚马逊Api网关（取决于答案）

服务

我们的系统中有以下微服务

ServiceA

端点GET / api / resources / {dataId} / admin-endpoint

标头 - 授权：不记名令牌

只有具有ADMIN角色的用户才能访问此端点（如果没有该角色的用户请求，将返回403 http状态并返回响应）。

请注意，在处理请求之前，必须由AuthService验证令牌。处理完请求后（如果出现非错误的http状态），AuthService必须刷新令牌（响应必须包含刷新的令牌）

端点GET / api / resources / {dataId} / user-endpoint

标头 - 授权：不记名令牌

具有任何角色的用户可以访问此端点

AuthService

端点POST / api / auth / login

标头 - 授权：不记名令牌

body - {＆＃34;用户名＆＃34; ：字符串，＆＃34;密码＆＃34; ：String}

验证用户：如果成功签名，授权令牌将作为响应标头（承载JWT令牌）返回。如果验证失败，将返回401 http状态

端点POST / api / auth / logout

标头 - 授权：不记名令牌

使授权令牌无效（通过在适当的表中存储令牌），以便用户无法使用给定的令牌访问受保护的api

端点GET / api / auth / validate

标头 - 授权：不记名令牌

验证给定的令牌（必须在ServiceA中处理请求之前调用。有关验证检查，请参阅附录-A

回复正文 - {＆＃34;角色＆＃34; ：，＆＃34;用户名＆＃34; ：String}

网关实施策略

Gateway仅负责路由

使用此策略，ServiceA和AuthService在网关中注册为路由，在处理请求之前不会进行其他请求转换。

ServiceA直接与AuthServer进行协商以进行授权和令牌验证。

赞成

网关逻辑很简单
作为网关，有各种各样的框架和工具可供选择。

缺点

ServiceA和AuthService强烈耦合
如果我需要添加ServiceB，那么我需要做一些双重工作来建立ServiceB和ServiceA之间的通信
AuthService中的故障处理主要由ServiceA

Gateway负责授权和请求转换

使用此策略，在将请求传递给ServiceA之前，api-gateway将使用AuthServer处理令牌验证。当ServiceA提供非错误响应时，它还将处理令牌刷新

赞成

ServiceA与AuthService
添加另一个ServiceB会更容易
AuthService的失败将由网关

缺点

Gateway将承担更多责任，而不仅仅是成为微服务的桥梁
Amazon Api Gateway很可能不是一个好选择，因为使用Amazon lambda-s处理授权和转换可能会非常痛苦（也许我错了）

附录-A：JWT令牌验证检查

令牌具有有效的承载前缀：＆＃34; bearer＆＃34;
令牌未过期（令牌已创建属性，用于确定令牌是否超过10分钟）
用户存在：创建令牌后未删除用户（令牌具有subject属性，该属性保留用户的唯一标识符）
用户密码在令牌有效期内未被更改

Api网关责任：良好实践（授权，请求转换）

问题

Api网关是否应承担授权和请求转换的责任？

如果使用Amazon API Gateway，使用额外的lambda函数层进行请求转换和授权是否是一种好习惯？

详细

技术

服务

ServiceA

AuthService

网关实施策略

Gateway仅负责路由

Gateway负责授权和请求转换

附录-A：JWT令牌验证检查

2 个答案: