站点的可用性（Avaliability）描写叙述站点可有效訪问的特性。
1、站点可用性的度量与考核
站点不可用时间（故障时间）=故障修复时间点-故障发现（报告）时间点
站点年度不可用时间=（1-站点不可用时间/年度时间）× 100%
可用性指标时站点架构设计的重要指标，对外是服务承诺，对内是考核指标，详细到每一个project师。很多其它的是使用故障分。
所谓故障分是指对站点故障进行分类加权计算故障责任的方法。例如以下是个案例：
| 分类 |
描写叙述 |
权重 |
| 事故级故障 |
严重故障，站点总体不可用 |
100 |
| A类故障 |
站点訪问不顺畅或核心功能不可用 |
20 |
| B类故障 |
非核心功能不可用。或核心功能少数用户不能訪问 |
5 |
| C类故障 |
其它故障 |
1 |
故障分的计算公式为：
故障分=故障时间（分钟）* 故障权重
2、站点的高可用架构
一个典型的站点设计通常遵循例如以下图所看到的的基本分层模型。
在负载的大型站点架构中，划分的粒度会更小，更详细，但通常还是能够把这些server划分到这三层中。
对于应用层的server通常为了应对高并发的訪问请求，会通过负载均衡设备将一组server组成一个集群共同 对外提供服务，当负载均衡设备通过心跳检測到某台server不可用时，就将其从集群列表中提出，并将请求分发到集群中其它 可用的server上，是整个集群保存可用，从而实现应用高可用。
位于服务层的server情况和应用层相似，也是通过集群方式实现高可用，仅仅是这些server被应用层通过分布式服务调用框架訪问。 分布式服务调度框架会在应用层client中实现负载均衡功能。
位于数据层的server情况比較特殊。数据server上存储着数据，为了保证数据不丢失，数据訪问服务不中断，须要在数据写入时进行数据同步复制，将数据写入多台server上，实现数据冗余备份。
站点升级的频率一般都非常高，每次站点公布都须要关闭服务，又一次启动系统，相当于server宕机。因此站点的可用性架构还须要考虑到站点升级 公布引起的宕机。
3、高可用的应用
应用层主要处理站点应用的业务逻辑。也称为业务逻辑层。应用的一个显著特点就是应用的无状态行，因此实现负载均衡相对简单一点。
Web应用中将这些多次请求的上下文称为回话（Session）。在单机情况下，session可部署在server上的Web容器上管理。在使用负载均衡 的集群环境中，因为负载均衡server可能会将请求分发到集群不论什么一台应用server上，所以保证每次请求依旧能够获得正确的session比单机 时要复杂的多。在集群环境下，session管理主要有 下面手段。
1、Session复制
Session复制是早期企业应用系统使用较多的一种server集群Session管理机制。应用server开启Web容器的Session复制功能，在集群中几台server之间同步Session对象。是每台server上都保存全部用户的Session信息。
这样的方案尽管简单，从本机读取Session信息也非常快，但当集群规模比較大的时候会占用server和站点的大量资源，在大量用户訪问的情况下，甚至会出现内存不够Session使用的情况。
2、Session绑定
Session绑定能够利用负载均衡的源地址Hash算法实现，负载均衡server总是将来源于同一IP的请求分发到同一台server上。这样在整个回话期间。用户全部的请求都在同一天server上处理，即Session绑定到某台特定的server上。保证Session总能在这台server上获取。这样的方法有成为回话粘滞。
3、利用Cookie记录Session
一种管理Session的方式是将Session记录在client，每次请求server的时候。将Session放在请求中发送给server，server处理完请求后再将改动后的Session响应给client。
4、Sessionserver
Sessionserver。即把session的管理独立部署在某一台机器上，Webserver不保存用户Session信息，每次都去Sessionserver取数据。
这样的解决方式其实是将应用server的状态分离，分为无状态的应用server和有状态的Sessionserver。
对于有状态的Sessionserver，一种比較简单的方式是利用分布式缓存、数据库等。
4、高可用的服务
5、高可用的数据
6、高可用的站点质量保证
7、站点执行监控
1、用户行为日志收集（server端和浏览器端）