微服务架构中的四种登录实现方式以及原理解析

单点登录：就是指在多个服务中，用户只需要登录，一次就可以访问所有相互信任的服务，用户只需要退出登录一次，就可以退出所有的服务

多端登录：当用户登录之后，如果再换一个设备进行登录的话，可以设计将原来的那个设备上的账号踢掉线，或者两个设备上的账号同时登录，一同操作同一个用户的数据、业务等信息

实现方案一：JWT

使用JWT的方式，将用户的信息存储到token中，用户只需要在登录服务器登录一次，就可以生成一个token，将用户的相关信息存储到token中，然后将token存储到cookie中，之后再去访问其它相互信任的服务时，就可以直接拿token去访问，那个服务就会解析token，拿到用户信息，进而进行其它操作。

JWT的结构：头部、载荷、签证

优点

• 去中心化
• 高并发

缺点

• 其它用户踢掉线无法实现

实现方案二：基于Redis

使用Redis作为第三方存储，用户登录生成token后，将用户信息存储到Redis中，而不是存储到token中了（这个token可以不基于JWT实现，只是普通的伪token即可，因为不存储信息），这样，下次浏览器再去访问其它服务器的时候，就可以使用token去Redis中获取用户信息，拿到用户信息后进行业务操作，然后返回响应数据

缺点

• 不是去中心化的，所有节点处理请求都依赖Redis，增加Redis负载

如何想要实现踢掉线的功能呢？只需将Redis中的用户信息删除即可，但是Redis中的用户信息存储的key是token，那么在其它浏览器中是拿不到这个token的，这样该如何才能去Redis中删除用户信息？

于是就有了第三种解决方案

实现方案三：JWT+Redis

使用Redis作为第三方存储，将userId存储到token中，用户登录生成token后，将用户信息存储到Redis中，key为userId，值为用户信息，下次访问其它服务器的时候，浏览器就会拿token去访问，然后服务器解析token，获取到userId，再根据userId去Redis中获取到用户信息，然后进行操作。

当想要进行踢其它用户掉线的时候，那么就需要在后台操作，后台可以直接获取到userId，然后拿userId去访问后台服务器，再拿userId去Redis中删除此用户信息，那么这个用户再访问的时候，就在Redis拿不到用户信息了，所以也就掉线了，需要重新登录。

踢掉线：假如你在打游戏，你发表了不良言论，我是管理员，我就要将你强制下线，这就是踢你掉线

缺点

• 不是去中心化的，所有节点处理请求都依赖Redis，增加Redis负载

实现方案四：CAS

CAS：集中式认证服务（Central Authentication Service）

使用Redis实现踢人掉线的功能，实际上就是使用了一个中心化的东西，而这个东西不止可以使Redis，还可以是一个服务。

浏览器去访问登录服务器，登录服务器返回一个token，登录成功。

如果浏览器没有携带token去访问业务服务器，那么请求到业务服务器之后，业务服务器再去请求登录服务器，登录服务器发现没有token，所以将此重定向到登录服务器，也就是让我们先去登录。

如果浏览器携带token去访问业务服务器，那么请求到业务服务器之后，业务服务器再去请求登录服务器，登录服务器发现token验证正确，返回给业务服务器一个此用户已登录，可以访问的消息，业务服务器收到消息之后，就可以继续执行接下来的业务了，最终执行完返回给浏览器一个响应数据，完成一次完整的请求。

优点

• 可以处理踢掉线。
• 现成的代码直接可以用

缺点

• 每次验证是否登录，都需要访问登录服务器，增大了网络开销
• 增加了登陆中心的负载问题
• 当用户无权限的时候，重定向还会有问题

此CAS原理图是使用通俗的语言进行分析，没有使用专业术语

• 例如：token在此就是ticket，TGT（Ticket Granting Tieckt）