内容梳理
网站可用性(Availability)，描述网站可有效访问的特性。Usability，也可为译可用性，强调网站的有用性，体现对用户的使用价值。
5.1 网站可用性的度量与考核
5.1.1 网站可用性度量
通常用多少个9来衡量网站的可用性，
网站不可用时间（故障时间） = 故障修复时间点 - 故障发现（报告）时间点
网站年度可用性指标 = （1 - 网站不可用时间/年度总时间）*100%
2个9基本可用，3个9较高可用，4个9是具有自动回复能力的高可用。
5.1.2 网站可用性考核
可用性指标是网站架构设计的重要指标，对外是服务承诺，对内是考核指标，更多使用故障分考核。
故障分是指对网站故障进行分类加权计算故障责任的方法。
故障分 = 故障时间（分钟）* 故障权重
5.2 高可用的网站架构
硬件故障是常态，网站的高可用结构设计的主要目的就是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问，实现高可用架构的主要手段是数据和服务的冗余备份及失效转移。
大型网站的分层架构及物理服务器的分布式部署使得位于不同层次的服务器具有不同的可用性特点。关闭服务或服务器宕机时产生的影响也不同，高可用的解决方案也差异甚大。
5.3 高可用的应用
应用层主要处理网站应用的业务逻辑，因此也称为业务逻辑层，应用的一个显著特点是应用的无状态性。无状态的应用指应用服务器不保存业务的上下文信息，仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例（服务器）之间完全对等，请求提交到任意服务器，处理结果完全一样。
5.3.1 通过负载均衡进行无状态服务的失效转移
在业务量和数据量较高的情况下，当单台服务器不能承担所有负载压力时，通过负载均衡手段，将流量和数据分摊到一个集群组成多台服务器上，以提高整体的负载处理能力。
当集群中的服务器都可用时，负载均衡服务器会把用户发送的访问请求分发到任意一台服务器上处理。当有服务器宕机时，负载均衡服务器会通过心跳检测机制发现该服务器失去响应，就会把它从服务器列表中删除，而将请求发送到其他服务器上。
5.3.2 应用服务器集群的Session管理
应用服务器的高可用架构设计主要基于服务无状态这一特性，事实上，服务总是有状态的。
Web应用中将这些多次请求修改使用的上下文对象称作回话（Session）,单机情况下，Session可由部署在服务器上的Web容器管理。在负载均衡的集群环境中，请求有可能被发送到任意一台服务器上，保证每次请求获取正确的Session更加复杂。
集群环境下，Session管理的主要手段：
1. Session复制
在集群中的几台服务器之间同步Session对象，使得每台服务器上都保存所有用户的Session信息。服务器需要使用Session，只需在本机获取即可。
集群规模较大时，集群服务器之间需要大量的通信进行Session复制，占用服务器和网络大量资源。
2. Session绑定
利用负载均衡的源地址Hash算法实现，负载均衡服务器总是精来源于同一IP的请求分发到同一台服务器上。将Session绑定在某台特定的服务器上，保证Session总能在这台服务器上获取，称为会话粘滞。
一台服务器宕机，该机器上的Session也就不复存在。
3. 利用Cookie记录Session
将Session记录在客户端，每次请求服务器时，将Session放在请求中发送给服务器，服务器处理完请求后再将修改过的Session响应给客户端。网站没有客户端，可用浏览器支持的Cookie记录Session。
受Cookie大小限制，能记录的信息有限；每次请求响应带Cookie影响性能；关闭Cookie，访问不能正常进行。
4. Session服务器
利用独立部署的Session服务器（集群）统一管理Session，应用服务器每次读写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 代码控制
使用核心问题是如何进行代码管理，既能保证代码发布版本的稳定正确，又能保证不同团队的开发互不影响。
版本控制工具SVN有主干开发、分支发布和分支开发、主干发布两种方式。目前网站开发中主要使用分支开发、主干发布的方式。
Git也是很好的版本控制工具。
5.6.5 自动化发布
人的干预越少，自动化程度越高，引入故障的可能性就越小。
火车发布模型，基于规则驱动的流程。将每个应用看做一次火车旅行，火车定点运行，期间有若干站点，每一站都进行例行检查，不通过的项目下车，剩下的项目继续坐着火车旅行，直到火车到达终点（应用发布成功）。
5.6.6 灰度发布
将集群服务器分成若干部分，每天只发布一部分服务器，观察是否稳定运行没有故障，第二天继续发布一部分服务器，持续几天才把整个集群全部发布完，期间如果发现问题，只需回滚已发布的一部分服务器即可。
5.7 网站运行监控
“不允许没有监控的系统上线”
5.7.1 监控数据采集
涵盖所有非直接业务行为的数据采集和管理，包括供数据分析师和产品设计师使用的网站用户行为日志、业务运行数据，以及供运维工程师和开发工程师使用的系统性能数据等。
1. 用户行为日志收集
用户行为日志指用户在浏览器上所做的所有操作及其所在的操作环境，主要有服务器端日志收集和客户端浏览器日志收集两种。
2. 服务器性能监控
收集服务器性能指标，及时判断应用状况，防患于未然，在初始化系统时统一部署，应用程序开发不需要关心服务器性能监控。
3. 运行数据报告
监控与具体业务场景相关的技术和业务指标，运行数据要在具体程序中采集并报告。
5.7.2 监控管理
根据监控数据做系统性能评估和集群规模伸缩性预测，还可以进行风险预警、自动化负载调整，最大化利用集群所有机器的资源。
1. 系统报警
某些指标超过阈值，对相关人员报警，及时采取措施。
2. 失效转移
监控系统在发现故障时主动通知应用，进行失效转移。
3. 自动优雅降级
应对突然爆发的访问高峰，主动关闭部分功能，释放部分系统资源，保证网站核心更功能正常访问。
本章结构
