5 万无一失:网站的高可用架构
5.1 网站可用性的度量与考核
5.1.1 网站可用性度量
5.1.2 网站可用性考核
5.2 高可用的网站架构
数据和服务的冗余备份及失效转移。
在复杂的大型网站架构中,模块划分的粒度会更小、更详细,结构更加复杂,服务器规模更加庞大。不同的业务产品会部署在不同的服务器集群上。
5.3 高可用的应用
5.3.1 通过负载均衡进行无状态服务的失效转移
5.3.2 应用服务器集群的Session管理
应用服务器的高可用架构设计主要基于服务无状态这一特性,但是事实上,业务总是有状态的。
- Session复制:应用服务器开启Web容易的Session复制功能,在集群中的几台服务器之间同步Session对象,使得每台服务器上都保存所有用户的Session信息。但是费内存,可能会出现Session过多导致服务器内存不够的情况。
- Session绑定:利用负载均衡的源地址Hash算法实现,负载均衡服务器总是将来源于同一IP的请求分发到同一个服务器上。
- 利用Cookie记录Session:利用浏览器支持的Cookie记录Session
- Session服务器:利用独立部署的Session服务器(集群)同一管理Session,应用服务器每次读写Session时,都访问Session服务器。
5.4 高可用的服务
可复用的服务模块为业务产品提供基础公共服务,大型网站中这些服务通常都独立分布式部署,被具体应用远程调用。可复用服务和应用一样,也是无状态的服务,因此可以使用类似负载均衡的失效转移策略实现高可用的服务。
除此之外,具体实践中,还有以下几点高可用的服务策略。
- 分级管理:核心应用和服务优先使用更好的硬件
- 超时设置:一旦超时,应用程序根据服务调度策略,可选择继续重试或将请求转移到提供相同服务的其他服务器上。
- 异步调用:避免一个服务失败导致整个应用请求失败的情况。
- 服务降级:为保证核心应用和功能的正常运行,需要对服务进行降级。降级有两种手段:拒绝服务和关闭服务
- 幂等性设计:必须在服务器层保证服务重复调用和调用一次产生的结果相同。
5.5 高可用的数据
保证数据存储高可用的手段主要是数据备份和失效转移机制。
失效转移机制保证当一个数据副本不可访问时,可以快速切换访问数据的其他副本,保证系统可用。
5.5.1 CAP原理
- 数据持久性
- 数据可访问性
- 数据一致性
CAP原理认为,一个提供数据服务的存储系统无法同时满足数据一致性、数据可用性、分区耐受性这三个条件。
大型网站中,通常会选择强化分布式存储系统的可用性(A)和伸缩性(P),在某种程度上放弃一致性(C)。
数据一致性可分为如下几点:
数据强一致
数据用户一致
数据最终一致
5.5.2 数据备份
冷备份、热备份
热备份可分为两种:异步热备份方式和同步热备份方式
异步方式是指多份数据副本的写入操作异步完成,应用程序收到数据服务系统的写操作成功响应时,只写成功了一份,存储系统将会异步地写其他副本。
同步方式是指多份数据副本的写入操作同步完成,即应用程序收到数据服务系统的写成功响应时,多份数据都已经写操作成功。
5.5.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 监控数据采集
用户行为日志收集
- 服务器端日志收集
- 客户端浏览器日志收集(页面中嵌入JavaScript脚本)
服务器性能监控
运行数据报告
5.7.2 监控管理
- 系统报警
- 失效转移
- 自动优雅降级