電商平臺中無論是前端還是后端會存在大量的業務應用，在整個交易的過程中請求是在各個業務應用中流轉的，對于用戶來講只需要登錄一次就可以訪問所有的業務，這就是單點登錄SSO。

單點登錄開源有很多的解決方案，比如基于session的SSO和基于cookie的SSO。

業界使用比較多的基于session的SSO的開源解決方案比如CAS，流程示意圖如下：

這里不去詳細說明流程，讀者可以參考其他資料的說明

基于cookie的SSO在原理上和上面的差不多，區別是把用戶設置到cookie中作為token的一部分進行傳遞，而基于session的SSO中cookie是服務器給客戶端生成的TGT。

相對來說，基于cookie的安全性不高。

以上是單機環境下的方案，更多的滿足傳統企業級的方案；而在電商平臺中，對SSO的性能、可用性、緩存數據量都是一個挑戰，因此需要基于CAS做改造，滿足互聯網的要求。

簡單對CAS的性能做了個壓測：

軟硬件環境：兩個App，一個CAS Server。機器都是PC server，16core 32G

場景：用戶在一個迭代中做登陸、操作業務、登出操作

測試結果：

CAS Server的機器情況
top - 17:05:18 up 1 day, ?8:39, ?2 users,?load average: 4.25, 2.62, 1.22

Tasks: 783 total, ? 1 running, 782sleeping, ? 0 stopped, ? 0 zombie

Cpu(s): 69.4%us, ?5.9%sy,?0.0%ni, 22.7%id, ?0.0%wa, ?0.0%hi, ?2.0%si, ?0.0%st

Mem: ?65964644k total, 16462164k used,49502480k free, ? 251036k buffers

Swap: 30719992k total, ? ? ??0k used, 30719992k free, ?1240744k cached?

?

TPS：2000，RT：20-30ms

?

改造后的SSO的架構示意圖如下：

1、??改造CAS Server為無狀態的節點，以前緩存的ticket、用戶等信息放到后端的cache中

2、??后端Cache采用redis,去掉持久化的功能，只做cache用

3、??考慮數據量的關系，Cache采用分布式的方案，進行數據切分，每個sharding只存儲一定范圍的數據

4、??每個sharding采用主備方式，leader作為主節點，replica只作為備份，在主節點宕機時可以升級為主節點

5、??整個集群的采用zookeeper進行分布式集群管理服務。

6、??App watch sso節點的變化，采用輪詢RR算法選擇一臺SSO Server進行請求，SSOServer對ticket采用hash算法定位到后端的cache進行存儲。

7、??用戶登出平臺時，采用輪詢RR算法選擇一臺SSO Server進行請求，清除Cache中的相關信息以及http方式回調各個應用的登出服務接口

8、平臺初始化階段需要把cache的各個sharding分配到某臺SSO Server上做定時的Ticketexpire驗證清理工作，也就是一臺SSO Server負責一個或者多個sharding的Ticketexpire工作，進而http方式回調各個應用的登出服務接口。

轉載于:https://www.cnblogs.com/Luouy/p/4225604.html

總結

以上是生活随笔為你收集整理的转)SSO单点登录在互联网电商应用中的解决方案(基于CAS的改造)的全部內容，希望文章能夠幫你解決所遇到的問題。

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