Bendi新闻
>
微服务Token鉴权设计的几种方案

微服务Token鉴权设计的几种方案

5月前

👉 这是一个或许对你有用的社群

🐱 一对一交流/面试小册/简历优化/求职解惑,欢迎加入芋道快速开发平台知识星球。下面是星球提供的部分资料: 

👉这是一个或许对你有用的开源项目

国产 Star 破 10w+ 的开源项目,前端包括管理后台 + 微信小程序,后端支持单体和微服务架构。

功能涵盖 RBAC 权限、SaaS 多租户、数据权限、商城、支付、工作流、大屏报表、微信公众号、CRM 等等功能:

  • Boot 仓库:https://gitee.com/zhijiantianya/ruoyi-vue-pro
  • Cloud 仓库:https://gitee.com/zhijiantianya/yudao-cloud
  • 视频教程:https://doc.iocoder.cn
【国内首批】支持 JDK 21 + SpringBoot 3.2.2、JDK 8 + Spring Boot 2.7.18 双版本 

来源:juejin.cn/post/
7329352197837029385


Token透传(不推荐)

刚开始接触微服务时网上给的方案大都数是通过透传Token做鉴权,但我认为这种方式不是很妥当。接着往下看:

这种方式通过透传Token使得各微服务都能获取到当前登录人信息,在代码编写上确实可能会方便,但我认为这不是一种很好的设计方式。

原因一:内部API与外部API混合在一起不太好区分。

原因二:内部调用的微服务API因该具备无状态性质,这样才能保证方法的原子性以提高代码复用率。

换句话说:B服务提供API时不因该关心当前是否为登录状态,登录状态应该由路由中的第一个服务校验维护,在调用后续服务时应该显示的传入相关参数。比如以下场景:

场景一:用户签到添加积分

场景二:后台管理员给用户手动添加积分

场景三:分布式调度批量增加用户积分

根据需求积分服务提供了一个给用户添加积分的API,如果你的API是通过获取的当前登录用户ID增加的积分,那么面对场景二时你需要重新编写一个给用户添加积分的API,因为当前登录的是后台管理员而不是用户(代码复用率较低)

不透传数据,显示的提供入参

路由到达的第一个服务已经对Token进行了解析认证并将userId显示的传递给了后续服务,后续服务不需要再对token进行解析认证。根据1.1的三个场景只需要提供一个入参包含userId的API,保证了函数的原子性提供代码复用率。

注意: 提供的API不能暴露给外网,我们需要在路径上做区分,避免外网非法访问内部API。我们可以订好内部调用API路径规则,如: /api/inside/\** 。在网关层拒绝内部调用API请求的访问。

统一授权

统一授权是指:将API鉴权集中在应用网关上

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

  • 项目地址:https://github.com/YunaiV/ruoyi-vue-pro
  • 视频教程:https://doc.iocoder.cn/video/

Fegin内部调用方式

Spring Cloud Gateway + Fegin内部调用,集中在Gateway上做统一认证鉴权,鉴权后在请求头中添加鉴权后的信息转发给后续服务,如:userId等。。。

缺点:A服务调用B服务时,B服务需要写一个内部调用的Controller接口A服务才能通过Fegin调用到B服务,增加了代码量(这里的设计方案是内部调用与外部调用Controller是分开的)

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

  • 项目地址:https://github.com/YunaiV/yudao-cloud
  • 视频教程:https://doc.iocoder.cn/video/

Dubbo内部调用方式

Spring Cloud Gateway + Dubbo内部调用,集中在Gateway上做统一认证鉴权,鉴权后在请求头中添加鉴权后的信息转发给后续服务,如:userId等。。。

优点:与第一种相比不需要额外编写一个Controller接口,只有本地service与远程DubboService的区别,代码更简洁。

缺点:项目技术栈略微增加了复杂度。

Spring Boot Web + Dubbo内部调用方式

这里的设计方案直接去掉了Gateway,直接使用了一个Spring Boot Web项目来代替Gateway。但需要注意的是应该将Web项目的容器换成Undertow,因为Tomcat是阻塞式的容器,不换也不是不行,但吞吐量可能会少一下,Undertow是非阻塞式的容器,可以与Gateway到达相同的效果。(非阻塞式:当请求为线程进入阻塞状态时,当前线程会被挂起,当前的计算资源会去做别的事情,当被挂起的线程收到响应时才会被继续执行,压榨CPU用更少的资源做更多的事情,但并不会提升性能)

因为去掉了Gateway我们需要将所有服务的Controller集成到Web应用,然后在这个Web应用上做统一认证授权。如果将所有代码写到Web应用中,这样可能不合适,我们可以选择每个服务创建一个Controller模块,Web网关服务只有一个启动类,通过依赖的方式集成所有服务的Controller。

优点:简化了项目结构,所有服务只有service代码。性能压测时不用考虑Gateway的线程池使用情况,业务服务只需要考虑Dubbo线程池的使用情况。

缺点:没办法通过配置中心动态调整路由。比如说增加了一个服务Gateway可以不重启通过配置中心增加路由配置即可。

非统一授权

非统一授权:不在应用网关上集成鉴权,网关只有单一的路由转发业务。各位服务都有自己的鉴权方式,当然也可以通过jar包的方式统一各服务的鉴权方式。

常规模式

通过编写通用的鉴权模块,各服务集成该模块。该模块具备以下功能:

  1. JWT Token解析
  2. 权限校验拦截
  3. 缓存(本地缓存\Redis缓存)

这种模式更适合大型项目团队,可能各微服务都由一个项目组负责。各服务维护自己的权限规则(这里指的是权限规则数据,规则是统一的)

该模式下由于应用网关比较轻量级,不再涉及复杂的鉴权流程,使得项目部署可以更灵活,当我们使用K8S部署项目时,我们可以将应用网关替换成K8S中的Ingress网关。

我们先看常规模式部署在K8S中完整的链路:

当用户访问时会先到达K8S Ingress网关通过应用网关Service的负载均衡调用应用网关,应用网关需要通过注册中心获取服务注册列表,通过服务注册列表负载均衡到后续服务。

与K8S集成

我们再来看看将应用网关替换成K8S中的Ingress网关的完整链路:

这里不仅只是去掉了应用网关,同时我们通过K8S Service 负载均衡的能力去掉了注册中心。减少了我们部署微服务时还要额外搭建一套注册中心。同时减少了一层没必要的转发。至于K8S中的Service,大家可以理解成一个本地的host假域名,比如我们在K8S给商品创建一个Service,名称为:goods-svc。那么我们可以通过goods-svc直连。如:

  1. http://goods-svc:8080/api/goods/info/10001
  2. dubbo://goods-svc:20880

方案没有对错,选择适合自己的就是最好的。


欢迎加入我的知识星球,全面提升技术能力。

👉 加入方式,长按”或“扫描”下方二维码噢

星球的内容包括:项目实战、面试招聘、源码解析、学习路线。

文章有帮助的话,在看,转发吧。

谢谢支持哟 (*^__^*)

微信扫码关注该文公众号作者

来源:芋道源码

相关新闻

聊聊 微服务之间的几种调用方式微服务架构中10个常用的设计模式常见的几种治疗术后恶心呕吐的不合理使用方案微服务过微怎么办?字节跳动提供了一种合并编译的方案|QCon为什么图纸好看的方案,设计费一般都不低?Construct 公司从 0 到 1 基于 Kitex+Istio 的微服务系统建设公司来了个大神,三方接口调用方案设计的真优雅~~Spring Cloud Gateway:打造可扩展的微服务网关遇到面试官问微服务架构设计到底该如何回答?这才是真正的城市设计方案!现在的城市设计方案,到底怎么了?基于微服务和DDD的架构模板微服务之间调用的异常应该如何处理?今天开始,高考出分!心里没底?高考后另一种进入名校的机会,这三种留学方案助力直通英本名校!Ceph 提供 NFS 服务:高效存储解决方案的终极指南高考后另一种进入名校的机会,这三种留学方案助力直通英本名校!从青光眼微支架到射频能量平台,朗目医疗打造医工融合创新下的眼科微创治疗完整解决方案微信聊天最惹人反感的4种行为,希望你一个也没有微信聊天最让人反感的4种行为,希望你一个都没有李强主持召开国务院常务会议 研究统筹融资信用服务平台建设提升中小微企业融资便利水平的举措等多人同时导出 Excel 干崩服务器!新来的大佬给出的解决方案太优雅了!微岩医学:病原宏基因组实验室全自动化解决方案【动脉严选新品鉴第63期】快!是谁还没加上豹乡田小姐姐的微信?恒大债务重组停滞近一年,公告尚未觅得合适的方案
logo
联系我们隐私协议©2024 bendi.news
Bendi新闻
Bendi.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Bendi.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。