转)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方式回调各个应用的登出服务接口。