企业应用监控利器-ZABBIX（1）

缺陷
1）客户端不得不启用Cookie
Servlet规范规定一个用户只有一个Session，要求Web容器用一个唯一的键值来对该Session作对应，然而HTTP 请求却是没有状态的。客户端如何保持这个键值呢，一种方法是用Cookie来保存，要是Cookie在客户端被Disabled了，那就只能URL重写
 
2）必须得解决Cookie跨域的问题
  这就要求各个服务器统一域名方式
 
3）必须在客户端或者在某个DNS服务器上配置域名映射
   直接用IP访问是不行的，要是在客户端配置域名映射那将会非常麻烦
 
4）要是不用SSL传输等来加强安全，用户名和密码等存在Cookie中的信息将有可能给截取
 
[b]相对理想的另一设计
1）  用户登录通过认证后生成一个在所有应用都是唯一的ticket，这个ticket只能生效一次且有过期时间，有效时间与对应的Http Seesion的有效时间一样。同时生成一个SSOSeesion，这个用之前生成的唯一ticket对应。
2）  这个SSOSession用来保存相关的用户信息
3）  当用户首次成功登录后，所有应用都能获悉该ticket和SSOSession。
4）  当用户从当前应用访问其他应用时传输的是ticket而不是用户名和密码之类，更好点应该用Http Post方式提交请求
5）  当用户以SSO方式登录成功后，ticket应该被更新，旧ticket应该被立即失效，所有服务器上的旧ticket对应的SSOSession也应失效
6）  用户当前HTTP Session被invalidated时，所有服务器上同一SSOSession也应该同时被Invalidated；同样，登出时也一样
7）  为了更好的安全性，在认证阶段也需要HTTP SSL Transport
 
 
[b]接口

SSOSession                                 单点登录会话

SSOSessionContext                   单点登录会话上下文

ClusterContext                            集群上下文

ClusterEventSource                   集群消息源

ClusterNotification                   集群消息

SSOSessionContext需要跟踪所有会话。它继承ClusterContext，ClusterEventSource，这样它就有了集群的能力。

让我们考虑一下应用的场景：
存在应用A和B，用户X先是成功登录A，之后从A转跳到B。B发现自己没有A的登录会话，
于是发出一个集群消息请求会话支援。A收到消息后回应B。最后X成功登录B。

当然，这样的设计存在很多的难点，例如如何进行集群消息回应，更新SSOSession。怎样确定Peer也没有所请求的SSOSession等。
这些都是一些集群需要考虑的问题。

幸运的是，我们可以选择一些开源的集群实现JBoss Cache就是其中之一。要是有了这样的集群实现上面的三个Cluster开头的接口就可以省略了。