我们为何需要单点登录系统

Posted 2022-06-13 niceyoo

SSO，Single Sign On，也就是单点登录，保证一个账户在多个系统上实现单一用户的登录

现在随着网站的壮大，很多服务会进行拆分，会做SOA服务，会使用dubbo做微服务，或者简单的小型分布式，

这样在服务与服务之间，或者系统与系统之间都是通过HTTP或者restful来进行通信的，

在以往的单系统应用中，我们都是把user存入session中的，需要用到的时候随时取，如果取不到就跳转到登录注册页面，非常简单的原理

但是在现如今的分布式应用中，如何保证session同步呢？

比如订单服务是在 order.jd.com

购物车服务在 cart.jd.com

那么这2个二级域名下的用户信息如何实现同步呢？

解决方案：

1. tomcat有一个session同步方案，就是一个传播机制，打个比方有A B C 3台tomcat，这3台tomcat的user信息都在session中并且保持一致，如果其中一台的user信息变化了，那么就会传播至另外两台，则实现同步，这样做没问题，但是仅仅只是在做tomcat集群的时候tomcat很少的时候会用，一旦集群增大，有100台，那么就互相传播吧，传播是需要性能损耗的，那么整个网站的性能就会被拉低，你的网站在你的网络风暴中就会晕死

2. nginx 非粘性session，说穿了就是一个session绑定传播，起初user的session在tomcatA上，tomcatA宕机了，那么session会把所有的信息传播到tomcatB，以此实现session共享，但是这也有个问题，就是传播的时候需要等待，快的时候1分钟左右，慢的时候要5分钟，用户的耐性有限，所以也不能这么做

3. 自己研发一套session高性能共享系统，我见过有这么做的公司，但是需要时间人力成本，所以不建议，如果你是BAT，随意~

4. SSO解决方案，目前比较流行的方案，自行开发一套单点登录系统，比如就使用 sso.jd.com，可以在这个二级域名下进行登录和注册，登录和注册都是以restful形式，为了可以同时提供给cms以及手机端的支持,登陆后把用户的相关信息存入redis，redis设置好过期时间，key为一个token，使用uuid，uuid生成后需要存入cookie中，失效时间随意定，但是再登录后需要重置redis和cookie中的失效时间

京东的实现：

sso的登录系统：

sso的注册系统（京东是两套都分开了，这样布个集群怎么也得至少4台嘛）

首页：

商品(商品详情应该都是生成的静态页面)：

交易系统：

这些都实现了sso，在soa各个系统中user可以随意走

拦截器配置：

在需要user信息的时候肯定需要使用到拦截器，如果获取不到user信息，那么就跳转到登录页面，但是需要注意的是需要把原页面作为redirectUrl暂时保存，登陆成功后需要跳转

获取user的时候就是从cookie中读取token，调用sso服务从redis中查询用户信息，如果有则继续，没有则登录

淘宝的二级域名：

原文链接：https://www.cnblogs.com/leechenxiang/p/5475728.html