架构

1.高可用性度量
网站不可用时间 = 故障修复时间 - 故障报告时间
网站年可用性指标 = （1- 网站不可用时间/年度总时间）*100%

2解决方案
数据和服务的备份冗余以及失效转移

3.应用层
    a.利用负载均衡实现无状态服务的失效转移（应用服务本身是不涉及状态的）
    b.利用集群session 实现有状态的失效转移（记录相关访问上下文的信息）
        i.session 复制（缺点：集群规模庞大的时候，session 复制会暂用大量的内存，和网络带宽）
        ii.session 绑定（缺点：万一一台服务器坏掉，那么绑定在该服务器的上seession 将无法访问）
        iii.cookie 记录session 信息（每次请求需要传递相关的session 信息，占用宽带，用户可以禁止使用cookie）
        iv.session 服务器（推荐使用）

4.服务层
    与应用层方式一样，只是除了这些方式意外，还有一些特殊的手段来解决服务层的高可用性

5.数据库存储
        备份，和失效转移

架构

1.高可用性度量
网站不可用时间 = 故障修复时间 - 故障报告时间
网站年可用性指标 = （1- 网站不可用时间/年度总时间）*100%

2解决方案
数据和服务的备份冗余以及失效转移

3.应用层
    a.利用负载均衡实现无状态服务的失效转移（应用服务本身是不涉及状态的）
    b.利用集群session 实现有状态的失效转移（记录相关访问上下文的信息）
        i.session 复制（缺点：集群规模庞大的时候，session 复制会暂用大量的内存，和网络带宽）
        ii.session 绑定（缺点：万一一台服务器坏掉，那么绑定在该服务器的上seession 将无法访问）
        iii.cookie 记录session 信息（每次请求需要传递相关的session 信息，占用宽带，用户可以禁止使用cookie）
        iv.session 服务器（推荐使用）

4.服务层
    与应用层方式一样，只是除了这些方式意外，还有一些特殊的手段来解决服务层的高可用性

5.数据库存储
        备份，和失效转移