SSO - 我们为何需求单点登录系统

  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台嘛)

  

  首页