《大型网站技术架构――核心原理与案例分析》读书笔记(5)

第五章 网站的高可用架构

一、可用性度量与考核

　　1. 网站可用性的度量

　　网站不可用时间=故障修复时间点-故障发现时间点

　　网站年度可用性指标=（1-网站不可用时间/年度总时间）*100%

　　2. 网站可用性的考核

　　故障分是对网站故障进行分类加权计算故障责任的方法。其计算公式为：故障分=故障时间（分钟）*故障权重。每个分类的故障有一个权重，例如事故级故障权重为100，A类为20等。一个故障可能多个部门和个人承担，故障分也会相应的分摊到不同的团队和个人。

二、高可用的架构

　　网站高可用架构设计的主要目的是：保证服务器硬件故障时服务依然可用，数据依然保存并能够被访问 。

　　实现网站高可用架构的主要手段是：数据和服务的冗余备份以及失效转移。一旦某些服务器宕机，就将服务切换到其他可用的服务器上；如果磁盘损坏，就从备份的磁盘读取数据。

　　典型的网站分三层：应用层、服务层、数据层，下面的三节分别介绍这三层采用的高可用设计。

三、高可用的应用

　　无状态服务：通过负载均衡进行失效转移。所谓无状态的应用是指应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例（服务器）之间完全对等，请求提交到任意服务器，处理结果都是一样的。

　　有状态服务：Web应用中将上下文对象称为会话（Session），单机情况下由部署在服务器上得Web容器（如IIS、Tomcat、JBoss等）管理。在使用了负载均衡的集群环境中，Session管理的几种常见手段：

　　1. session复制：集群中的几台服务器之间同步Session对象，任何一台服务器宕机都不会导致Session对象的丢失，服务器也只需要从本机获取即可。但是， 该方案只适合集群规模较小的情况下。当规模较大时，大量的Session复制操作会占用服务器和网络的大量资源。

　　2. session绑定：利用负载均衡的源地址Hash算法，将源于同一IP地址的请求总是分发到同一台服务器上。这样，在整个会话期间，用户所有的请求都在同一台服务器上进行处理，即Session绑定在某台特定服务器上，保证Session总能在这台服务器上获取。这种方案又叫做会话粘滞。这种方案 不符合高可用的需求 。因为一旦某台服务器宕机，那么该机器上得Session也就不复存在了，用户请求切换到其他机器后因为没有Session而无法完成业务处理。因此，很少有网站采用此方案进行Session管理。

　　3. cookie记录session：利用浏览器支持的Cookie记录Session简单易行，可用性高，并且支持服务器的线性伸缩，因此，许多网站都或多或少地使用了Cookie来记录Session。但是Cookie记录Session有缺点：比如受Cookie大小限制、每次请求响应都要传输Cookie影响性能、用户关闭了Cookie会造成访问不正常等。

　　4. session服务器：利用独立部署的Session服务器（集群）统一管理Session，应用服务器每次读写Session时，都访问Session服务器。这种方案实际上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session服务器。有状态的Session服务器，一种较简单的方法是利用分布式缓存（如Memcached、Redis等）、数据库等，在这些产品的基础上进行封装，使其符合Session的存储和访问要求。如果业务场景对Session管理有比较高的要求，比如利用Session服务集成单点登录SSO等功能，则需要开发专门的Session服务管理平台

四、高可用的服务

　　高可用的服务模块为业务产品提供基础公共服务，在大型站点中这些服务通常都独立分布式部署，被具体应用远程调用。在具体实践中，有以下几点高可用的服务策略可以参考：

　　1. 分级管理：核心应用和服务具有更高的优先级，使用更好的硬件和更快的故障响应，同时在部署上使用必要的隔离，避免故障连锁反应。低优先级服务采用启用不同的线程隔离，高优先级服务采用不同的物理机。

　　2. 超时设置：设置服务调用的超时时间，一旦超时后，通信框架抛出异常，应用程序则根据服务调度策略选择重试or请求转移到其他服务器上；

　　3. 异步调用：通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。但不是所有服务都可以异步调用，对于获取用户信息这类调用，采用异步方式会延长响应时间，得不偿失。对于那些必须确认服务调用成功后才能继续进行下一步的操作的应用也不适合异步调用。

　　4. 服务降级：网站访问高峰期间，为了保证核心应用的正常运行，需要对低优先级服务降级。降级有两种手段：一是拒绝服务，拒绝较低优先级的应用的调用，或者随机拒绝部分请求，减少服务调用并发数，确保核心应用的正常运行；二是关闭功能，关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约系统开销，为核心应用服务让出资源；

　　5. 幂等性设计：保证服务重复调用和调用一次产生的结果相同；

五、高可用的数据

　　对于大多数网站而言，数据是其最宝贵的物质资产。

　　1. 高可用的数据有如下几层含义：

　　数据持久性：保证数据在任何情况下都不丢失。

　　数据可访问性：部分数据故障后，切换到备份数据的快慢。

　　数据一致性：数据在多个副本中是否一致。数据一致性有分为如下几点：

　　　　数据强一致：各个副本的数据在物理存储中总是一致的

　　　　数据用户一致：各个副本可能不一致，但返回给用户的通过纠错机制等，返回给用户一个正确的数据。

　　　　数据最终一致：经过一段时间以后，数据最终会达到一致

　　2. CAP原理

　　一个提供数据服务的存储系统无法同时满足数据一致性(Consistency)、数据可用性(Availibility)、分区耐受性(Partition Tolerance，系统具有跨网络分区的伸缩性)这三个条件。大型网站中，通常会选择强化分布式存储系统的可用性(A)和伸缩性(P)，而在某种程度上放弃一致性。一般来说，数据不一致发生在高并发写和集群状态不稳定的情况下，应用系统应该对数据不一致有所了解，并进行某些意义上的补偿和纠错。

　　3. 保证数据高可用的主要手段有两种：一是数据备份，二是失效转移。

　　数据备份：数据备份是保证数据有多个副本，又分为冷备份和热备份，冷备份简单廉价，通常采用定期复制，但不能保证数据的最终一致性和系统可用性。热备份又分为异步热备和同步热备，异步热备是指多份数据副本的写入操作异步完成，而同步方式则是指多份数据副本的写入操作同时完成。关系数据库的热备机制就是通常所说的主从同步机制，实践中通常使用读写分离的方法来访问Master和Slave数据库，也就是说写操作只访问Master库，读操作均访问Slave库。

　　失效转移：若数据服务器集群中任何一台服务器宕机，那么应用程序针对这台服务器的所有读写操作都要重新路由到其他服务器，保证数据访问不会失败。失效转移操作由三部分组成：失效确认、访问转移、数据恢复三种。

　　4. 缓存服务的高可用性：

　　整个网站共享一个分布式缓存集群，单独的应用和产品不再部署自己的缓存服务器，只需要向共享缓存集群申请资源即可。

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

　　网站发布：柔性发布，每次关闭的服务都是集群中的一小部分，并在发布完成后立即可以访问；

　　自动化测试：使用自动测试工具或脚本完成测试；

　　预发布验证：引入预发布服务器，与正式服务器几乎一致，只是没有配置在负载均衡服务器上，外部用户无法访问；采用快速失败，启动时发现错误立即停止，而不是启动后再处理。

　　代码控制：目前大多数网站采用SVN，分支开发，主干发布模式；另外，目前开源社区广泛采用Git作为版本控制工具，正逐步取代SVN的地位；

　　自动化发布：自动化程度越高，引入故障的可能性越小

　　灰度发布：将集群服务器分为若干部分，每次只发布一部分服务器。

七、网站运行监控

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

　　1. 监控数据采集

　　（1）用户行为日志收集：服务器端的日志收集和客户端的日志收集；目前许多网站逐步开发基于实时计算框架Storm的日志统计与分析工具；

　　（2）服务器性能监控：收集服务器性能指标，如系统Load、内存占用、磁盘IO等，及时判断，防患于未然；

　　（3）运行数据报告：监控与具体业务相关的指标，如待处理任务数、缓存命中率等，采集汇总后统一显示，应用程序需要在代码中处理运行数据采集的逻辑；

　　2. 监控管理

采集到的监控数据，除了用于性能评估、集群伸缩性预测等，还可以根据实时运行情况进行风险提示。

　　（1）系统报警：配置报警阀值和值守人员联系方式，系统发生报警时，即使工程师在千里之外，也可以被及时通知；

　　（2）失效转移：监控系统在发现故障时，主动通知应用进行失效转移；

　　（3）自动优雅降级：为了应付网站访问高峰，主动关闭部分功能，释放部分系统资源，保证核心应用服务的正常运行； 网站在监控管理的基础上自动实现优雅降级，是柔性架构的理想状态。

八、思维导图

来自：http://www.cnblogs.com/edisonchou/p/3836862.html