Luouy~羽林
学问如逆水行舟,不进则退; 有知识的人不实践,等于一只蜜蜂不酿蜜; 我们可以由读书而收集知识,但必须利用思考把糠和谷子分开

电商平台中无论是前端还是后端会存在大量的业务应用,在整个交易的过程中请求是在各个业务应用中流转的,对于用户来讲只需要登录一次就可以访问所有的业务,这就是单点登录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方式回调各个应用的登出服务接口。

 
 
posted on 2015-01-15 10:23  羽林.Luouy  阅读(1030)  评论(0编辑  收藏  举报