[TOC]
5. 网站的高可用架构
网站的可用性（Availablilty）描述网站可有效访问的特性。
网站的有用性（Usability），通常也被译作可用性，但是后者强调的是网站的有用性，即对最终用户的使用价值。
5.1 网站可用性度量
网站不可用时间（故障时间）= 故障修复时间点 - 故障发现（报告）时间点。
网站年度可用性指标 = （1 - 网站不可用时间/年度总时间）* 100%。
5.2 网站可用性考核
故障分是指对网站故障进行分类加权计算故障责任的方法。
故障分的计算公式：
故障分 = 故障时间（分钟）* 故障权重
| 网站故障分类 | 描述 | 权重 |
|---|---|---|
| 事故级故障 | 严重故障，网站整体不可用 | 100 |
| A类故障 | 网站访问不顺畅或核心功能不可用 | 20 |
| B类故障 | 非核心功能不可用，或核心功能少数用户不可用 | 5 |
| C类故障 | 以上故障以外的其他故障 | 1 |
5.3 高可用的网站架构
- 硬件故障是常态。
- 网站可用性架构设计不但要考虑实际的硬件故障引起的宕机，还要考虑网站升级发布引起的宕机。
- 网站高可用架构设计的主要目的：保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问。
- 实现高可用架构的主要手段：数据和服务的冗余备份及失效转移。
在复杂的大型网站架构中，划分的粒度会更小、更详细，结构更复杂，服务器规模更庞大，但通常还是能够把这些服务器划分到以上三层中。
应用层服务器：负载均衡、心跳检测。
服务层服务器：集群部署、分布式服务调用框架、软件负载均衡、心跳检测。
数据层服务器：数据同步复制、数据冗余备份。
5.4 高可用的应用
应用层（业务逻辑层）主要处理网站应用的业务逻辑。
应用层的特点：应用的无状态性。
无状态应用：
应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务器实例之间完全对等，请求提交到任意服务器，处理结果完全一样。
通过负载均衡进行无状态服务的失效转移
负载均衡顾名思义，主要使用在业务量和数据量较高的情况下，当单台服务器不足以承担所有的负载压力时，通过负载均衡手段，将流量和数据分摊到一个集群组成的多台服务器上，以提高整体的负载处理能力。
目前，不管是开源免费的负载均衡软件还是昂贵的负载均衡硬件，都提供失效转移功能。在网站应用中，当集群中的服务是无状态对等时，负载均衡可以起到事实上高可用的作用。
负载均衡开源解决方案
1. LVS
LVS，工作在 4 层，Linux 实现的高性能高并发、可伸缩性、可靠的的负载均衡器，支持多种转发方式 (NAT、DR、IP Tunneling)，其中 DR 模式支持通过广域网进行负载均衡。支持双机热备 (Keepalived 或者 Heartbeat)。对网络环境的依赖性比较高。
2. Nginx
Nginx 工作在 7 层，事件驱动的、异步非阻塞的架构、支持多进程的高并发的负载均衡器 / 反向代理软件。可以针对域名、目录结构、正则规则针对 http 做一些分流。通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持 url 来检测。对于 session sticky，可以基于 ip hash 的算法来实现，通过基于 cookie 的扩展 nginx-sticky-module 支持 session sticky。
3. HAProxy
HAProxy 支持 4 层和 7 层做负载均衡，支持 session 的会话保持，cookie 的引导；支持后端 url 方式的检测；负载均衡的算法比较丰富，有 RR、权重等。
应用服务器集群的 Session 管理
会话（Session）：Web 应用中多次请求修改使用的上下文对象。
单机环境下的 Session 管理：由部署在 Web 容器（如 JBoss）管理。
集群环境下的 Session 管理：
- Session 复制。
- Session 绑定：利用负载均衡的源地址 Hash 算法实现。
- 利用 Cookie 记录 Session。
- Session 服务器：利用独立部署的 Session 服务器（集群）统一管理 Session。
Session 服务器将应用服务器的状态分离：
- 无状态的应用服务器。
- 有状态的 Session 服务器：分布式缓存、数据库。
5.5 高可用的服务
可复用的服务模块为业务产品提供基础公共服务。
高可用服务策略：
- 分级管理。（将服务器进行分级管理：核心服务器、非核心服务器）
- 超时设置。（在应用服务中设置服务调用的超时时间）
- 异步调用。（消息队列）
- 服务降级。（拒绝服务、关闭功能）
- 幂等性设计：必须在服务层保证服务重复调用和调用一次产生的结果相同。
5.6 高可用的数据
保证数据存储高可用的手段：
- 数据备份；
- 失效转移；
数据备份是保证数据有多个副本，任意副本的失效都不会导致数据的永久丢失，从而实现数据完全的持久化。
失效转移保证当一个数据副本不可访问时，可以快速切换访问数据的其他副本，保证系统可用。
CAP 原理
为了保证数据的高可用，网站通常会牺牲另一个很重要的指标：数据一致性。
高可用数据的含义：数据持久性、数据可访问性、数据一致性。
CAP 原理认为，一个提供数据服务的存储系统无法同时满足数据一致性（ Consistency）、数据可用性（Availibility）、分区耐受性（Partition Tolerance，系统具有跨网络分区的伸缩性）这三个条件。
在大型网站中，通常会选择强化分布式存储系统的可用性和伸缩性，而在某种程度上放弃一致性。
数据一致性：
- 数据强一致。
- 数据用户一致。
- 数据最终一致。
数据备份
异步方式：多份数据副本的写入操作异步完成，应用程序收到数据服务系统的写操作成功响应时，只写成功一份，存储系统将会异步地写其他副本。
同步方式：多份数据副本的的写入操作同步完成。即应用程序收到数据服务系统的写成功响应时，多份数据都已经写操作成功。
失效转移
若数据服务器集群中任何一台服务器宕机，那么应用程序针对这台服务器的所有读写操作都需要重新路由到其他服务器，保证数据访问不会失败，这个过程叫作失效转移。
失效转移操作由三部分组成：失效确认、访问转移、数据恢复。
系统确认一台服务器是否宕机的手段：
- 心跳检测；
- 应用程序访问失败报告；
5.7 高可用网站的软件质量保证
网站发布
使用发布脚本完成发布
自动化测试
Web 自动化测试技术工具：Selenium
预发布验证
网站发布时，先发布到预发布服务器上。
快速失败：如果系统在启动时发现问题就立刻抛出异常，停止启动让工程师介入排查错误，而不是启动后执行错误的操作。
代码版本控制
版本控制工具：
- Git；
- SVN；
自动化发布
灰度发布
灰度发布：将集群服务器分成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部分服务器，持续几天才把整个集群全部发布完毕，期间如果发现问题，只需要回滚已发布的一部分服务器即可。
5.8 网站运行监控
不允许没有监控的系统上线。
监控数据采集
- 用户行为日志收集。
- 服务器端日志收集；
- 客户端浏览器端日志收集；
- 服务器性能监控。
- 开源性能监控工具：Ganglia。
- 运行数据报告。
监控管理
- 系统报警；
- 失效转移；
- 自动优雅降级；