咱們爲什麼須要單點登陸系統

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