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

我正在考虑在我的微服务之上使用api网关。但有一些架构问题我没有明确的答案，所以我想从社区得到一个意见。如果你能分享你对好的和坏的做法的想法，那也太好了。因此，为了使这篇提问文章易于阅读，我有两个主要部分“问题”和“细节”

问题 Api网关是否应负责授权和请求转换？ 问题主要是什么是网关：它只是api用户和微服务之间的桥梁吗。还是微服务的版主？有关更多信息，请参阅“网关实施策略”一节

在使用AmazonAPI网关的情况下，使用附加的lambda函数层对请求进行转换和授权是否是一种良好的做法？ 如果我选择使用AmazonAPI网关，对前面问题的回答将是“网关应该充当微服务的调节者”。然后我需要通过Amazon lambdas处理请求/响应转换和授权，这意味着我将在网关下面有另一层。所以问题是：拥有这种架构是一种好的实践吗

细节 技术

• 弹簧靴2.0
• JWT
• Spring云网关或亚马逊Api网关（取决于答案）

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

服务A 端点GET/api/resources/{dataId}/admin端点

标题-授权：承载令牌

只有具有管理员角色的用户才可以访问此端点（如果来自没有该角色的用户的请求403 http状态将随响应一起返回）

请注意，在处理请求之前，必须由AuthService验证令牌。并且在处理请求后（在http状态为非错误的情况下），AuthService必须刷新令牌（响应必须包含刷新的令牌）

端点GET/api/resources/{dataId}/user Endpoint

标题-授权：承载令牌

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

授权服务 端点POST/api/auth/login

标题-授权：承载令牌

正文-{“用户名”：字符串，“密码”：字符串}

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

端点POST/api/auth/logout

标题-授权：承载令牌

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

端点获取/api/auth/validate

标题-授权：承载令牌

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

响应正文-{“角色”：，“用户名”：字符串}

网关实现策略 网关只负责路由 使用此策略，ServiceA和AuthService在网关中注册为路由，在处理请求之前不会进行额外的请求转换

ServiceA直接与AuthServer对话以进行授权和令牌验证

专业人士

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

缺点

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

网关负责授权和请求转换 使用此策略，api网关将在将请求传递给ServiceA之前使用AuthServer处理令牌验证。当ServiceA给出无错误响应时，它还将处理令牌刷新

专业人士

• ServiceA与AuthService完全解耦
• 添加另一个ServiceB会容易得多
• AuthService的故障将由网关处理

缺点

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

附录A：JWT令牌验证检查

• 令牌具有有效的承载前缀：“承载”
• 令牌未过期（令牌具有createdAt属性，用于确定令牌是否早于10分钟）
• 用户存在：创建令牌后未删除用户（令牌具有subject属性，该属性保留用户的唯一标识符）
• 用户密码在令牌生存期内未更改

---

在我的微服务经验中，我了解到应该有只拥有业务逻辑的核心微服务，而应用程序逻辑应该在其他地方实现。API网关，作为连接外部世界和内部微服务生态系统的中心服务，是一个放置大部分微服务的好地方……如果您需要更改，请您的应用程序逻辑（例如，您希望在一组受限的API上为某种类型的客户端启用基本身份验证），您始终可以向您的体系结构添加另一个API网关

一般来说，api网关不是负载均衡器或路由器……是可以做任何事情的微服务。重要的是，架构师让它们做正确的事情