SSO单点登录在互联网电商应用中的解决方案(基于CAS的改造)

电商平台中无论是前端还是后端会存在大量的业务应用,在整个交易的过程中请求是在各个业务应用中流转的,对于用户来讲只需要登录一次就可以访问所有的业务,这就是单点登录SSO

单点登录开源有很多的解决方案,比如基于sessionSSO和基于cookieSSO

业界使用比较多的基于session的SSO的开源解决方案比如CAS,流程示意图如下:

这里不去详细说明流程,读者可以参考其他资料的说明

基于cookieSSO在原理上和上面的差不多,区别是把用户设置到cookie中作为token的一部分进行传递,而基于sessionSSOcookie是服务器给客户端生成的TGT

相对来说,基于cookie的安全性不高。

以上是单机环境下的方案,更多的满足传统企业级的方案;而在电商平台中,对SSO的性能、可用性、缓存数据量都是一个挑战,因此需要基于CAS做改造,满足互联网的要求。

简单对CAS的性能做了个压测:

软硬件环境:两个App,一个CAS Server。机器都是PC server16core 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 

 

TPS2000RT20-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进行请求,SSOServerticket采用hash算法定位到后端的cache进行存储。

7、  用户登出平台时,采用轮询RR算法选择一台SSO Server进行请求,清除Cache中的相关信息以及http方式回调各个应用的登出服务接口

8、平台初始化阶段需要把cache的各个sharding分配到某台SSO Server上做定时的Ticketexpire验证清理工作,也就是一台SSO Server负责一个或者多个sharding的Ticketexpire工作,进而http方式回调各个应用的登出服务接口。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值