单点登录 （上）

前言

本文主要讲述的是单点登录三种主要实现形式的理论知识

1. 单一服务模式

在还没出现微服务架构的时候，我们一般都使用单一服务器的模式实现登录。这种方式操作简单，实现也很方便。

实现方式：使用session对象进行实现。
当用户输入用户名和密码与数据库匹配成功时，程序通过session把用户数据进行存储；这样我们在该服务的任何界面上都能得到用户的登录信息，也可以对它进行相应的判定操作。
缺点：随着互联网项目的不断壮大，单一服务器已经远远不能满足需求，我们需要把功能分配到不同的模块上，把不同的模块部署到不同的服务器上，这就是所谓的微服务。那么这种单一服务器的模式显然不能满足需求，它也存在着单点性能压力大，无法扩展等问题。

2. 单点登录 (SSO 模式)

这种单点登录在我们生活十分常见，就好比我们每天浏览的百度。当我们在浏览器上登录百度的账号后，我们可以在贴吧，百度文库，百度音乐上都能找到我们的登录信息，而无需再重复登录（这就是所谓的不同服务部署在不同的地方上，但是我们只需登录一次就能在其他服务上获取到相关的登录信息）。

单点登录实现的三种主要形式：

第一种（现在已逐渐被淘汰）：session 的广播机制实现
假设我们的在线教育项目有多个不同的模块，service-edu (教育课程模块)，service-oss （文件上传模块)， service-cms(轮播图模块), 他们分别部署在不同的服务器上，当我们在教育课程模块进行登录后，session会对用户信息进行存储，然后把它复制到不同的模块上进行使用。（缺点：若模块十分多，复制的过程十分繁琐，也十分消耗资源）
第二种：使用cookie + redis实现：
1.在项目中任何一个模块进行登录后，会把数据存储到两个地方
(1) redis： （以key-value的形式存在）
key: 生成唯一的随机值 （策略有很多种：如用户的ip , 用户的id , UUID等等）
value: 存放用户的登录信息
(2) cookie: 把redis里面生成的key值放到cookie这里
2. 由于cookie是客户端上的行为，当访问项目的其他模块时，带着cookie一起发送请求。其他模块获取到cookie值，通过获取里面存放的redis的key对它进行查询，若查询得到数据就证明是已登录。
第三种：使用token实现

token是什么？
按照一定规则生成的字符串，该字符串中可以包含用户的登录信息。

1.在项目某个模块进行登录，登录之后，按照规则生成包含有用户信息的字符串。并进行返回。
token信息的携带方式：
(1) 可以把字符串通过cookie返回
(2) 可以把字符串通过地址了返回
(3) 可以包含在请求体中。
2.再去访问其他模块时，通过获取Token中的用户信息。判断用户是否登录，然后做相关的响应处理。