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