微服务认证授权概览

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>>

从单体架构向微服务架构转型的过程中，认证方式也发生了改变。

而转变最大的方面便是有状态向无状态的转变。

在单体架构时代，我们一般使用的是会话管理(Session)，架构图如下所示

即多实例采用一个同一个Session Store(一般采用Redis来存储)来进行Session的管理，即共享Session,在第二代网关GateWay搭建流程的SaveSession小节中有介绍共享Session的配置。对以上这种设置，我们称之为有状态。

而与之相对的就是无状态，指的是服务器端不去记录用户的登录状态，不再去维护用户的Session。在微服务时代，如果依然采用共享Session的策略，则把各个独立的微服务又捆绑在了Session Store中，如果Session Store挂了，则所有的微服务都无法运行，等于把鸡蛋放到了一个篮子中。而更主要的是如果Session Store需要做迁移，则所有的微服务地址都要调整，牵一发而动全身。再就是如果Session Store达到了瓶颈(容量瓶颈，性能瓶颈)，都得对其进行扩容。

微服务的无状态架构图如下所示

服务器端不会存储用户的登录状态，而是在用户登录的时候颁发一个token,之后用户的请求都需要带上token(可能放在head中，可能放在url参数中),服务器端拿到token后进行解密，校验token是否合法，有无过期，如果合法并没有过期，就认为用户为登录状态，否则为未登录状态。我们还可以在Token里面存储一些不太敏感的用户信息(比如用户名),这样服务器在解密完token以后就可以直接使用。但有时候token里不一定带有用户信息;而是利用token在某个地方查询，才能获得用户信息。比如在Spring OAuth2中可以做如下设置，其中8002为鉴权中心的端口。

security:
  oauth2:
    resource:
      user-info-uri: http://local.register.com:8002/user-me
      prefer-token-info: false

然后通过OAuth2.0通过token获取受保护资源的解析来拿取用户的详细信息。

有状态和无状态的优缺点

优缺点	有状态	无状态
优点	服务器端控制力强	去中心化，无存储，简单，任意扩容，缩容
缺点	存在中心点，鸡蛋在一个篮子里，迁移麻烦，服务器端存储数据，加大了服务器端压力	服务器端控制力弱

无状态登录的实现和变种