SSO單點登入在互連網電商應用中的解決方案(基於CAS的改造)

標籤：

電商平台中無論是前端還是後端會存在大量的業務應用，在整個交易的過程中請求是在各個業務應用中流轉的，對於使用者來講只需要登入一次就可以訪問所有的業務，這就是單點登入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方式回調各個應用的登出服務介面。

 
 

SSO單點登入在互連網電商應用中的解決方案(基於CAS的改造)