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

<一>Token透传

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

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

原因二：内部换句话说：B服务提供API时不因该关心当前是否为登录状态，登录状态应该由路由中的第一个服务校验维护，在调用后续服务时应该显示的传入相关参数。

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

 路由到达的第一个服务已经对Token进行了解析认证并将userId显示的传递给了后续服务，后续服务不需要再对token进行解析认证。

 

<二>Fegin内部调用方式

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

 缺点：A服务调用B服务时，B服务需要写一个内部调用的Controller接口A服务才能通过Fegin调用到B服务，增加了代码量（这里的设计方案是内部调用与外部调用Controllway上做统一认证鉴权，鉴权后在请求头中添加鉴权后的信息转发给后续服务，如：userId等。。。优点：与第一种相比不需要额外编写一个Controller接口，只有本地service与远程DubboService的区别，代码更简洁。

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

 <三>Spring Boot Web + Dubbo内部调用方式

<四>常规模式

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

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

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