《大型网站技术架构》读书笔记五：万无一失之网站的高可用架构
本篇文章是《大型网站技术架构》的笔记，感兴趣可以阅读该书。
一、网站的高可用架构
网站的可用性（Avaliability）描述网站可有效访问的特性。相比于网站的其他非功能特性，网站的可用性更牵动人们的神经。
1.1 网站可用性的度量与考核
网站的页面完整呈现在最终用户前面，需要经过多个环节，任何一个环节出现问题，都可能导致网站页面不可访问。
网站可用性度量:
- 网站不可用时间（故障时间）=故障修复时间点-故障发现（报告）时间点
- 网站年度不可用时间=（1-网站不可用时间/年度时间）× 100%
可用性指标时网站架构设计的重要指标:
对外是服务承诺，对内是考核指标，具体到每个工程师，更多的是使用故障分。
所谓故障分是指对网站故障进行分类加权计算故障责任的方法。
故障分=故障时间（分钟）* 故障权重
1.2 网站的高可用架构
一个典型的网站设计通常遵循如下图所示的基本分层模型。
在负载的大型网站架构中，划分的粒度会更小，更详细，但通常还是能够把这些服务器划分到这三层中。
应用层：
对于应用层的服务器通常为了应对高并发的访问请求，会通过负载均衡设备将一组服务器组成一个集群共同 对外提供服务，当负载均衡设备通过心跳检测到某台服务器不可用时，就将其从集群列表中提出，并将请求分发到集群中其他 可用的服务器上，是整个集群保存可用，从而实现应用高可用。
服务层：
位于服务层的服务器情况和应用层类似，也是通过集群方式实现高可用，只是这些服务器被应用层通过分布式服务调用框架访问， 分布式服务调度框架会在应用层客户端中实现负载均衡功能。
数据层：
位于数据层的服务器情况比较特殊，数据服务器上存储着数据，为了保证数据不丢失，数据访问服务不中断，需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份。
网站升级：
网站升级的频率一般都非常高，每次网站发布都需要关闭服务，重新启动系统，相当于服务器宕机。因此网站的可用性架构还需要考虑到网站升级 发布引起的宕机。
1.3 高可用的应用
应用层主要处理网站应用的业务逻辑，也称为业务逻辑层，应用的一个显著特点就是应用的无状态行。无状态的应用指应用服务器不保存业务的上下文信息。
1.3.1 通过负载均衡进行无状态服务的失效转移
1.3.2 应用服务器集群的Session管理
事实上，业务总是有状态的。如交易类。
Web应用中将这些多次请求的上下文称为会话（Session），在单机情况下，session可部署在服务器上的Web容器上管理。在使用负载均衡 的集群环境中，由于负载均衡服务器可能会将请求分发到集群任何一台应用服务器上，所以保证每次请求依然能够获得正确的session比单机 时要复杂的多。在集群环境下，session管理主要有 以下手段。
（一）Session复制：
Session复制是早期企业应用系统使用较多的一种服务器集群Session管理机制。应用服务器开启Web容器的Session复制功能，在集群中几台服务器之间同步Session对象，是每台服务器上都保存所有用户的Session信息。
这种方案虽然简单，从本机读取Session信息也很快，但当集群规模比较大的时候会占用服务器和网站的大量资源，在大量用户访问的情况下，甚至会出现内存不够Session使用的情况。
（二）、Session绑定
Session绑定可以利用负载均衡的源地址Hash算法实现，负载均衡服务器总是将来源于同一IP的请求分发到同一台服务器上。这样在整个回话期间，用户所有的请求都在同一天服务器上处理，即Session绑定到某台特定的服务器上，保证Session总能在这台服务器上获取，这种方法有成为回话粘滞。
但是，这种方案不符合高可用的需求。因为一旦某台服务器宕机，那么该机器上得Session也就不复存在了，用户请求切换到其他机器后因为没有Session而无法完成业务处理。因此，很少有网站采用此方案进行Session管理
（三）、利用Cookie记录Session
Cookie记录Session：利用浏览器支持的Cookie记录Session简单易行，可用性高，并且支持服务器的线性伸缩，因此，许多网站都或多或少地使用了Cookie来记录Session。但是Cookie记录Session有缺点：比如受Cookie大小限制、每次请求响应都要传输Cookie影响性能、用户关闭了Cookie会造成访问不正常等
（四）、Session服务器
利用独立部署的Session服务器（集群）统一管理Session，应用服务器每次读写Session时，都访问Session服务器
这种解决方案事实上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session服务器。对于有状态的Session服务器，一种比较简单的方式是利用分布式缓存、数据库等。
1.3.3 高可用的服务
可复用的服务模块为业务产品提供基础公共服务，大型网站中这些服务通常都独立分布式部署，被具体应用远程调用。可复用的服务和应用一样，是无状态的，因此可以使用类似
负载均衡的失效转移策略实效高可用的服务。
除此之外，在实践中，还有几点高可用的服务策略。
- 分级管理：核心应用和服务有限使用更好的硬件。同时在服务部署也进行必要隔离，避免故障连锁反应。
- 超时设置：设置服务调用的超时时间，一旦超时后，通信框架抛出异常，应用程序则根据服务调度策略选择重试or请求转移到其他服务器上；
- 异步调用：通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。
- 服务降级：网站访问高峰期间，为了保证核心应用的正常运行，需要对服务降级。
降级有两种手段：
一是拒绝服务，拒绝较低优先级的应用的调用，减少服务调用并发数，确保核心应用的正常运行；
二是关闭功能，关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约系统开销，为核心应用服务让出资源；
- 幂等性设计：保证服务重复调用和调用一次产生的结果相同；
1.3.4 高可用的数据
对许多网站而言，数据是其最宝贵的物质资产
保证数据存储高可用的手段主要是数据备份和失效转移机制。
（一）、CAP原理：
即数据持久性、数据可访问性、数据一致性
CAP原理认为，一个提供数据服务的存储系统无法同时满足这三者
（二）、数据备份
数据备份是一种古老而有效的数据保护手段，早期的数据备份手段主要是数据冷备，即定期将数据复制到某种存储介质上并物理存档保管。
冷备的优点是简单和廉价，成本和技术难度都较低。缺点是不能保证数据最终一致，由于数据时定期复制，因此备份设备中的数据比系统中的数据陈旧，如果系统数据丢失，那么从上个备份点开始后更新的数据就会永久丢失，不能从备份中恢复。
所以单单使用数据冷备是不行的。还需要使用数据热备。数据热备有两种方案：异步热备方式和同步热备方式。
-
异步方式： 异步方式是指多份数据副本的写入操作异步完成，应用程序收到数据服务系统的写操作成功响应时，只写成功了一份，存储系统将会异步地写其他副本。
在异步写入方式下，存储服务器分为主存储服务器（Master） 和 从存储服务器（Slave）。应用程序正常情况下只连接主存储服务器，数据写入时，由主存储服务器的写操作代理模块将数据写入本机存储系统后立即返回写操作成功响应，然后通过异步线程将写操作数据同步到从存储服务器。
-
同步方式： 指多份数据副本的写入操作同时完成。但是当应用程序收到数据写操作失败的响应时，可能有部分副本或者全部副本都已经写成了。
（二）、失效转移
若数据服务器集群中任何一台服务器宕机，那么应用程序针对这太服务器的所有读写操作都需要重新路由到其他服务器，保证数据访问不会失败，这个过程叫做失效转移。
失效转移操作有三部分组成：失效确认、访问转移、数据恢复。
-
失效确认：（检测方式：心跳检测和应用程序访问失败报告）
-
访问转移：确认某台数据存储服务器宕机后，需要将数据读写访问重新路由到其他服务器上。
-
数据恢复
1.3.5 高可用网站的软件质量保证
（一）、网站发布
发布过程中，每次关闭的服务器都是集群中的一小部分，并在发布完成后立即可以访问，因此整个发布过程不影响用户使用
（二）、自动化测试
目前大部分网站都采用Web自动化测试技术，使用自动测试工具或脚本完成测试。
（三）、预发布验证
在网站发布时，并不是把测试通过的代码包直接发布到线上服务器，而是先发布到预发布机器上，在该预发布机器上进行预发布验证，执行一些典型的业务流程，确认系统没有问题后才正式发布。
（四）、代码控制
网站代码控制的核心问题是如何进行代码管理，既能保证代码发布版本的稳定正确，同时又能保证不同团队的开发互不影响。
（五）、自动化发布
（六）、灰度发布
1.3.6 网站运行监控
（一）、监控数据采集
-
用户行为日志收集：服务器端的日志收集和客户端的日志收集；目前许多网站逐步开发基于实时计算框架Storm的日志统计与分析工具；
-
服务器性能监控：收集服务器性能指标，如系统Load、内存占用、磁盘IO等，及时判断，防患于未然；
-
运行数据报告：采集并报告，汇总后统一显示，应用程序需要在代码中处理运行数据采集的逻辑；
（二）、监控管理
-
系统报警：配置报警阀值和值守人员联系方式，系统发生报警时，即使工程师在千里之外，也可以被及时通知；
-
失效转移：监控系统在发现故障时，主动通知应用进行失效转移；
-
自动优雅降级：为了应付网站访问高峰，主动关闭部分功能，释放部分系统资源，保证核心应用服务的正常运行；
参考
- 本文是《大型网站技术架构》的读书笔记
- 可以参考这篇文章 http://www.cnblogs.com/edisonchou/p/3836862.html