sso 单点登录1-“前世缘由”

一.单点登录的起源

1.1 单体架构图时代

1.单体web架构时代：

所有的应用功能都放到一个war包中，然后部署到tomcat的web容器中，称之为单体应用，在单体应用使用场景下，用户的登录和权限十分简单：使用过滤器对非法请求进行验证拦截，用户登录成功后将信息存储到session会话中，HTTP维护这个会话,再每次用户请求服务器的时候来验证这个会话即可。

缺点：十分不好 扩展和拆分

验证登录的这个会话就是session,维护了用户状态,也就是所谓的HTTP有状态协议,我们经常可以在浏览 器中看到JSESSIONID,这个就是用来维持这个关系的key。

client 发送请求访问server，如下图：

1.2 分布式集群时代 

1.2.1 综述

随着业务的发展，网站的访问量越来越大，单体应用已经是巨大瓶颈，决定采用分布式集群部署。例如：将同一个war包的单体应用部署到3个tomcat下面，然后使用nginx实现负载均衡和反向代理。
但是会出现一个问题：session无法在这3台tomcat上实现共享，用户信息会丢失，即多服务之间的session无法实现共享。

1.2.2 session无法共享，情况1：

但是现在server采用了集群，现在client，到底是访问server1，还是server2呢？，访问server1，成功登录后，session保存在server1中，如果再次访问，此时访问了server2，server2并没有session，还得再次登录，这就存在问题，不是吗？

1.2.3 session无法共享，情况2：

针对上述的问题，我们的解决办法是采用服务端的负载均衡器ngix，可以采用轮询，或者其他策略的方法实现server1，server2的访问。但是第一次访问的是server1，第二次沦陷后，访问server2，server2中还是没有session，还需要重新登录。

1.2.4 session无法共享，情况3：

使用ip hash，同一个ip经过计算后，会一直访问某一台器，还是会造成热点问题，单台机器过载的问题。

1.2.5 使用session复制，解决session共享问题：

针对上述阐述的问题，决定使用session复制解决session共享解决，在登录server1成功之后，将session的信息同步到server2上不就行了，看似完美，但是，如果机器是50-100台，没有同步完，用户又访问了server100，server100还是没有session信息的问题，所以还是又问题的，session延迟复制问题。

1.3 分布式集群解决session时代  

最后针对以上阐述问题： 给出完美的解决方案：将session放到一台的单独的缓存服务器中，第一次登录成功后，将session信息写入到第三方缓存服务器中，同时将相应信息放回给client端，cookie存储key信息，第二次登录server2时，去第三方服务器通过key获取session信息，存在的话不用登录，直接进行后续操作。如果不存在的话，需要重新登录。这就是sso的原理。

预知单点登录相关内容，请看下集分解！！！！