[笔记] 大型网站技术架构——核心原理与案例分析 [五]

5 万无一失：网站的高可用架构

5.1 网站可用性的度量与考核

5.1.1 网站可用性度量
5.1.2 网站可用性考核

5.2 高可用的网站架构

数据和服务的冗余备份及失效转移。

在复杂的大型网站架构中，模块划分的粒度会更小、更详细，结构更加复杂，服务器规模更加庞大。不同的业务产品会部署在不同的服务器集群上。

5.3 高可用的应用

5.3.1 通过负载均衡进行无状态服务的失效转移
5.3.2 应用服务器集群的Session管理

应用服务器的高可用架构设计主要基于服务无状态这一特性，但是事实上，业务总是有状态的。

1. Session复制：应用服务器开启Web容易的Session复制功能，在集群中的几台服务器之间同步Session对象，使得每台服务器上都保存所有用户的Session信息。但是费内存，可能会出现Session过多导致服务器内存不够的情况。
2. Session绑定：利用负载均衡的源地址Hash算法实现，负载均衡服务器总是将来源于同一IP的请求分发到同一个服务器上。
3. 利用Cookie记录Session：利用浏览器支持的Cookie记录Session
4. Session服务器：利用独立部署的Session服务器（集群）同一管理Session，应用服务器每次读写Session时，都访问Session服务器。

5.4 高可用的服务

可复用的服务模块为业务产品提供基础公共服务，大型网站中这些服务通常都独立分布式部署，被具体应用远程调用。可复用服务和应用一样，也是无状态的服务，因此可以使用类似负载均衡的失效转移策略实现高可用的服务。

除此之外，具体实践中，还有以下几点高可用的服务策略。

1. 分级管理：核心应用和服务优先使用更好的硬件
2. 超时设置：一旦超时，应用程序根据服务调度策略，可选择继续重试或将请求转移到提供相同服务的其他服务器上。
3. 异步调用：避免一个服务失败导致整个应用请求失败的情况。
4. 服务降级：为保证核心应用和功能的正常运行，需要对服务进行降级。降级有两种手段：拒绝服务和关闭服务
5. 幂等性设计：必须在服务器层保证服务重复调用和调用一次产生的结果相同。

5.5 高可用的数据

保证数据存储高可用的手段主要是数据备份和失效转移机制。

失效转移机制保证当一个数据副本不可访问时，可以快速切换访问数据的其他副本，保证系统可用。

5.5.1 CAP原理

• 数据持久性
• 数据可访问性
• 数据一致性

CAP原理认为，一个提供数据服务的存储系统无法同时满足数据一致性、数据可用性、分区耐受性这三个条件。

大型网站中，通常会选择强化分布式存储系统的可用性（A）和伸缩性（P），在某种程度上放弃一致性（C）。

数据一致性可分为如下几点：

数据强一致

数据用户一致

数据最终一致

5.5.2 数据备份

冷备份、热备份

热备份可分为两种：异步热备份方式和同步热备份方式

异步方式是指多份数据副本的写入操作异步完成，应用程序收到数据服务系统的写操作成功响应时，只写成功了一份，存储系统将会异步地写其他副本。

同步方式是指多份数据副本的写入操作同步完成，即应用程序收到数据服务系统的写成功响应时，多份数据都已经写操作成功。

5.5.3 失效转移

失效转移操作主要由三部分组成：

1. 失效确认：心跳检测和应用程序访问失败报告
2. 访问转移
3. 数据恢复

5.6 高可用网站的软件质量保证

软件系统本身的风险

5.6.1 网站发布
5.6.2 自动化测试
5.6.3 预发布验证
5.6.4 代码控制

• 主干开发、分支发布
• 分支开发、主干发布

5.6.5 自动化发布
5.6.6 灰度发布

5.7 网站运行监控

“不允许没有监控的系统上线”

5.7.1 监控数据采集

用户行为日志收集

1. 服务器端日志收集
2. 客户端浏览器日志收集（页面中嵌入JavaScript脚本）

服务器性能监控

运行数据报告

5.7.2 监控管理

• 系统报警
• 失效转移
• 自动优雅降级