SSO，Single Sign On，也就是單點登錄，保證一個賬戶在多個系統上實現單一用戶的登錄

現在隨著網站的壯大，很多服務會進行拆分，會做SOA服務，會使用dubbo做微服務，或者簡單的小型分布式，

這樣在服務與服務之間，或者系統與系統之間都是通過HTTP或者restful來進行通信的，

在以往的單系統應用中，我們都是把user存入session中的，需要用到的時候隨時取，如果取不到就跳轉到登錄注冊頁面，非常簡單的原理

但是在現如今的分布式應用中，如何保證session同步呢？

比如訂單服務是在 order.jd.com

購物車服務在 cart.jd.com

那么這2個二級域名下的用戶信息如何實現同步呢？

解決方案：

tomcat有一個session同步方案，就是一個傳播機制，打個比方有A B C 3臺tomcat，這3臺tomcat的user信息都在session中并且保持一致，如果其中一臺的user信息變化了，那么就會傳播至另外兩臺，則實現同步，這樣做沒問題，但是僅僅只是在做tomcat集群的時候tomcat很少的時候會用，一旦集群增大，有100臺，那么就互相傳播吧，傳播是需要性能損耗的，那么整個網站的性能就會被拉低，你的網站在你的網絡風暴中就會暈死

nginx 非粘性session，說穿了就是一個session綁定傳播，起初user的session在tomcatA上，tomcatA宕機了，那么session會把所有的信息傳播到tomcatB，以此實現session共享，但是這也有個問題，就是傳播的時候需要等待，快的時候1分鐘左右，慢的時候要5分鐘，用戶的耐性有限，所以也不能這么做

自己研發一套session高性能共享系統，我見過有這么做的公司，但是需要時間人力成本，所以不建議，如果你是BAT，隨意~

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

總結

以上是生活随笔為你收集整理的我们为何需要单点登录系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。