一、可用性度量
我们通常使用多少个9来衡量网站的可用性，比如4个9代表一个服务99.99%可用，即该需要保证在单位时间内只有0.01%的时间可以发生故障服务不可用。2个9与3个9的意思也同样如此。但对于网站整体而言，想要达到4个9甚至5个9的可用性，除了过硬的技术、大量的设备资金投入还需要有个好运气。
一般为了将网站的可用性指标转换成对应的责任度量下放到个人或者组织，我们一般使用“故障分”来对网站的单位时间故障进行加权计算，进而将责任分担下放到个人，加入其年度的绩效考核中。比如可以对不同级别的故障类型划分不同的权重分，再通过对应类型故障的发生时间进而得到该故障的故障分。
二、高可用的整体架构
我们一般将网站架构分为三层：应用层、服务层、数据层，应用层负责业务逻辑处理，服务层提供可复用的服务，数据层负责数据的封装与存储，各层之间相对独立。由于网站的架构资源中，硬件故障是最常见的问题。那么高可用架构的主要目的就是保证服务器在硬件故障时依然可用。主要手段是数据和服务的冗余备份以及失效转移。
位于应用层的服务器通常为了应对高并发的请求，会通过负载均衡（Load Balancer）组成集群对外透明的提供服务。负载均衡会通过心跳检测来监控服务器状态，当发现不可用机器时将其从集群中剔除，并将该机器的路由设置为不可用，同时所有请求将转发到集群内的其他机器。服务层的机器与应用层类似。位于数据层的服务器比较特殊，为了保证数据不丢失，我们需要在数据写入时同时对集群内的其他服务器同步复制数据，以保证数据的一致性和可用性。
三、高可用的应用
由于应用层主要负责对业务的处理，为了使用集群来提高应用服务的高可用性，我们将应用层设计成无状态的服务，即不在应用服务器本地保存用户的状态信息（比如 Session 信息）。这样的做的目的是为了让集群内的所有服务器对等，在负载均衡调度请求时可以无差别对待。而用户的状态信息我们会用专门的方式来进行管理。
由于业务总是有状态的，在单机情况下，我们将会话信息交由服务器上的 Web 容器来管理，但对于集群环境来说，我们通常用以下几种方式来处理：Session 复制（所有应用服务器在本地共享同一套会话信息，每一次新增的会话都会在整个应用集群内进行复制，只用于小型集群）、Session 绑定（负载均衡服务器将同一 IP 来源的请求绑定在固定的应用服务器上，又被称为“会话粘滞”，但不符合高可用的特性）、利用 Cookie（将用户的会话信息存储在客户端的浏览器中，安全性低、影响传输性能、受到浏览器限制）、Session 服务器（专门的 Session 集群，由负载均衡调度，可以利用分布式缓存/数据库来进行包装）。
四、高可用的服务
高可用的服务一定是独立的、可复用的。服务的设计同样需要遵循几个原则：分级管理（核心应用和服务优先使用更好的硬件，核心服务和数据需要部署在不同地域的数据中心，低优先级的服务甚至可以只使用多线程来隔离）、超时设置（设置服务的远程调用超时时间，某一台机器超过规定的响应时间即由集群 Leader 或负载均衡重新分配资源）、异步调用（将一次完整的业务流程拆分，比如发送成功邮件等任务，可以延后执行的步骤均放在消息队列中异步进行，即使用传统的消费者模式）、服务降级（在并发数较高的情况下，可以通过适当关闭不必要的低优先级服务来节约系统性能，或者通过随机拒绝服务的方式，将压力分散）、幂等设计（我们无法确定一次失败的服务请求是否真的失败了，为了避免服务的二次调用产生“非预期”的结构，我们需要将服务调用幂等化，即一次调用和多次调用产生的效果是一致的）。
五、高可用的数据
保证高可用数据的手段主要是数据备份和失效转移。一般为了保证数据高可用，我们肯能会牺牲另一个指标，即：”数据一致性“。高可用数据一般包括“数据持久性”，“数据可用性”和“数据一致性”三个指标。根据 CAP 原理，一个数据服务的存储系统是无法同时满足数据一致性（Consistency）、数据可用性（Availibility）和分区耐受性（Partition Tolerance）的。数据一致性即所有应用都能访问到相同的数据，可用性即任何时候，任何应用都可以进行数据读写，分区耐受性指系统可以跨网络分区线性的伸缩。由于 A 和 P 两个指标较 C 更为重要，我们既然放弃了数据的强一致性，退而求其次在不影响用户体验时，可以选择保障数据用户一致。
常用的数据备份方式分为热备份和冷备份，冷备份是一种古老而有效的数据保护手段，主要通过定期将数据复制到存储介质上并物理存档保存来保护数据。缺点是不能保证数据的最终一致（最弱的一致性，系统经过一段时间的自我恢复和修正最终达到一直），而且在数据备份时需要宕机。热备份是一种实时备份的数据保护方式，分为异步热备和同步热备。同时对于关系型数据库来说，热备机制的 Master-Slave同步机制还可以通过读写分离的方式来改善数据库性能。
失效转移一般通过心跳检测或者应用程序的访问失败报告来进行通知，控制中心在收到失败报告时会再次通过心跳检测来进行确认，如果确认失败则将该机器路由转移到其他可用机器上。
六、高可用的软件质量保证
比如我们在发布软件的新版本时一定要注意不能影响原有的线上正在运行中的服务。因此我们一般通过发布脚本每次只关闭一部分集群的机器，进行软件更新，然后启用。再关闭另一部分机器，重复上述过程。再软件发布之前还需要进行“预发布”，即先发布到线上集群中一台只有内网能够访问到的机器，但使用的是线上的数据，在通过内部测试无误后再发布到线上。
同时对于大型网站的软件发布，我们可以采用“灰度发布”的方式，即一段时间内只发布线上集群中的一部分机器，待观察一段时间没有问题后，再逐渐发布集群内的其他机器。会进行“灰度发布”的同时，我们甚至可以进行“AB测试”，新发布的机器作为对照组，查看新旧软件的用户反馈情况。
另一方面，也需要对网站进行全天候的实时的监控。比如监控服务端日志、客户端日志、运行数据报告（缓存命中率、平均响应延迟等）。设置要做到自动检测系统报警并向 Leader 机器反馈，可以即时做到系统失效转移，以及优雅降级（高并发高压力时自动关闭某些低优先级的服务）等操作。
相关阅读：
大型网站技术架构，初入探秘（一）
大型网站技术架构，网站的高性能架构（二）
