Token透传不推荐刚开始接触微服务时网上给的方案大都数是通过透传Token做鉴权但我认为这种方式不是很妥当。接着往下看这种方式通过透传Token使得各微服务都能获取到当前登录人信息在代码编写上确实可能会方便但我认为这不是一种很好的设计方式。原因一内部API与外部API混合在一起不太好区分。原因二内部换句话说B服务提供API时不因该关心当前是否为登录状态登录状态应该由路由中的第一个服务校验维护在调用后续服务时应该显示的传入相关参数。比如以下场景场景一用户签到添加积分场景二后台管理员给用户手动添加积分场景三分布式调度批量增加用户积分根据需求积分服务提供了一个给用户添加积分的API如果你的API是通过获取的当前登录用户ID增加的积分那么面对场景二时你需要重新编写一个给用户添加积分的API因为当前登录的是后台管理员而不是用户代码复用率较低不透传数据显示的提供入参路由到达的第一个服务已经对Token进行了解析认证并将userId显示的传递给了后续服务后续服务不需要再对token进行解析认证。根据1.1的三个场景只需要提供一个入参包含userId的API保证了函数的原子性提供代码复用率。注意: 提供的API不能暴露给外网我们需要在路径上做区分避免外网非法访问内部API。我统一授权统一授权是指将API鉴权集中在应用网关上Fegin内部调用方式Spring Cloud Gateway Fegin内部调用集中在Gateway上做统一认证鉴权鉴权后在请求头中添加鉴权后的信息转发给后续服务如userId等。。。缺点A服务调用B服务时B服务需要写一个内部调用的Controller接口A服务才能通过Fegin调用到B服务增加了代码量这里的设计方案是内部调用与外部调用Controllway上做统一认证鉴权鉴权后在请求头中添加鉴权后的信息转发给后续服务如userId等。。。优点与第一种相比不需要额外编写一个Controller接口只有本地service与远程DubboService的区别代码更简洁。缺点项目技术栈略微增加了复杂度。Spring Boot Web Dubbo内部调用方式这里的设计方案直接去掉了Gateway直接使用了一个Spring Boot Web项目来代替Gateway。但需要注意的是应该将Web项目的容器换成Undertow因为Tomcat是阻塞式的容器不换也不是不行但吞吐量可能会少一下Undertow是非阻塞式的容器可以与Gateway到达相同的效果。非阻塞式当请求为线程进入阻塞状态时当前线程会被挂起当前的计算资源会去做别的事情当被挂起的线程收到响应时才会被况业务服务只需要考虑Dubbo线程池的使用情况。缺点没办法通过配置中心动态调整路由。比如说增加了一个服务Gateway可以不重启通过配置中心增加路由配置即可。非统一授权非统一授权不在应用网关上集成鉴权网关只有单一的路由转发业务。各位服务都有自己的鉴权方式当然也可以通过jar包的方式统一各服务的鉴权方式。常规模式通过编写通用的鉴权模块各服务集成该模块。该模块具备以下功能JWT Token解析权限校验拦截缓存本地缓存\Redis缓存这种模式更适合大型项目团队可能各微服务都由一个项目组负责。各服务维护自己的权限规则这里指的是权限规则数据规则是统一的该模式下由于应用网关比较轻量级不再涉及复杂的鉴权流程使得项目部署可以更灵活当我们使用K8S部署项ngress网关通过应用网关Service的负载均衡调用应用网关应用网关需要通过注册中心获取服务注册列表通过服务注册列表负载均衡到后续服务。与K8S集成我们再来看看将应用网关替换成K8S中的Ingress网关的完整链路这里不仅只是去掉了应用网关同时我们通过K8S Service 负载均衡的能力去掉了注册中心。减少了我们部署微服务时还要额外搭建一套注册中心。同时减少了一层没必要的转发。至于K8S中的Service大家可以理解成一个本地的host假域名比如我们在K8S给商品创建一个Service名称为goods-svc。那么我们可以通过goods-svc直连。如http://goods-bo://goods-svc:20880方案没有对错选择适合自己的就是最好的。