程序员架构修炼：架构设计，高可用设计

高可用设计

高可用性（High Availability）通常用来描述一个系统经过专门的设计，减少了停工时间，并保证了其服务的高度可用性，简而言之，就是不间断地对外提供服务。

高可用性的度量与考核

对高可用性度量的公式为：

◎ 网站不可用时间（故障时间）=故障修复时间点-故障发现（报告）时间点；

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

业界通常用多个9来衡量网站的可用性，如下所述。

◎ 2个9：表示基本可用，不可用时间少于88小时。

◎ 3个9：表示较高可用，不可用时间少于9小时。

◎ 4个9：表示具有自动恢复能力的高可用，不可用时间少于53分钟。

◎ 5个9：表示极度高可用，不可用时间少于5分钟。

可用性指标是网站架构设计的重要指标，对外是服务承诺，对内是考核指标。从管理层面来看，可用性指标是网站或系统架构的整体考核指标，具体到每个工程师的考核，更多地使用故障分。故障分是指对网站故障进行分类加权计算故障责任的方法，如表5.1所示。

表5.1

故障分的计算公式：故障分=故障时间（分钟）×故障权重。

高可用的架构

典型的网站设计遵循基本分层架构模型：应用层（处理具体的业务逻辑）、服务层（提供可复用的服务）、数据层（数据的存储和访问）。

1.高可用的应用层

应用层主要处理业务逻辑，一个显著特点是应用的无状态性。

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

高可用的应用层的第1个特点是通过负载均衡实现失效转移。

在业务量和数据量都较高的情况下，通过负载均衡，可以将流量和数据都分摊到一个集群所组成的多台服务器上，以提高整体的处理能力。目前的负载均衡软、硬件都提供了失效转移功能。所以，如果集群的服务是无状态的对等服务，则负载均衡技术可以保证系统的高可用性。

当 We b 服务器集群中的服务器都可用时，负载均衡服务器会将访问请求分发给任意一台服务器进行处理。负载均衡服务器会通过心跳检测机制，在发现某台服务器（如图5.8所示的Web服务器-001）失去响应时，将该服务器从服务器列表中剔除。为了保证高可用性，即使某个应用的访问量非常少，也必须部署至少两台服务器，通过负载均衡构建一个小型集群。

可以看出，高可用的应用层的第2个特点是服务器集群中的Session管理。

业务总是有状态的，比如交易类网站需要有购物车记录用户购买的商品。在 We b 应用中，这些状态就被称为Session。在单机情况下，Session可以由部署在服务器上的Web容器（如Tomcat）进行统一管理。但在使用负载均衡的集群环境中，要保证每次请求都能够获得正确的Session就是个很复杂的话题。在集群环境中，有如下手段可以进行Session管理。

图5.8

（1）复制Session。应用服务器开启Web容器的Session复制功能，然后在集群中的几台服务器之间同步Session对象，使得每台服务器都保存所有用户的Session信息。

（2）绑定Session。利用负载均衡的源地址Hash算法，将源于同一IP的请求分发到同一台服务器上。这样，在整个会话期间，用户的所有请求就都在同一台服务器上进行处理，即把 Session 绑定到某台特定的服务器上，这种方法又被称为“会话粘滞”。绑定 Session的方案不符合系统高可用性的需求，因为一旦某台服务器宕机，该服务器上的 Session 就不存在了。即使将用户的请求切换到其他服务器，也会因为没有 Session 而导致业务无法正常处理。所以很少有网站使用绑定Session的方案。

（3）利用 Cookie 记录 Session。这种方式是将 Session 记录在客户端，在每次请求服务器时，都将Session放在请求中发送给服务器，在服务器处理后，再将修改过的Session发送回客户端。利用Cookie记录Session也有一些缺点，如下所述。

◎ Cookie有大小限制，记录的信息有限。◎ 每次请求响应都要传输Cookie，影响性能。

◎ 如果用户关闭了Cookie，访问就会变得不正常。

但 Cookie 简单易用，能够支持应用服务器的线性伸缩；而且大部分应用需要记录的Session信息又比较小。所以许多网站都或多或少地使用Cookie记录Session。

（4）Session服务器。利用独立部署的Session服务器或集群来统一管理Session。应用服务器在每次读写Session时，都需要访问Session服务器。这样的方案是把应用服务器分为无状态的应用服务器和有状态的Session服务器。对于有状态的Session服务器，可以这样简单实现：在分布式缓存、数据库等组件的基础上进行封装，使其符合 Session 的存储与访问要求。

2.高可用的服务层

可复用的服务模块为业务产品提供基础公共服务，通常都独立分布式部署，被具体应用远程调用。可复用的服务和应用一样，也是无状态的服务，因此可以使用类似负载均衡的失效转移策略实现高可用的服务。

除此之外，具体实践中，还有如下几种高可用的服务策略。

（1）分级管理。在运维层面对服务器进行分级管理，核心应用与服务优先使用更好的硬件。在服务部署上进行必要的隔离，避免故障的连锁反应。低优先级的服务通过启动不同的线程或部署在不同的虚拟机上进行隔离。高优先级的服务需要部署在不同的物理机上，核心服务和数据最好部署在不同地域的数据中心上。

（2）超时设置。在应用中设置调用服务的超时时间，一旦超时，通信框架就会抛出异常。应用根据服务调度策略，可以选择继续重试或者将请求转移到提供相同服务的其他服务器上。

（3）异步调用。应用对服务的调用，通过消息队列的异步方式实现。应用程序会将用户注册信息发送给消息队列服务器，之后立即返回用户注册成功的响应。而多个消费者任务（记录用户信息到数据库、发送注册成功邮件、开通权限）会从消息队列中获取用户注册的信息，之后异步执行。注意：不是所有的服务调用都可以使用异步调用模式，比如获取用户信息的服务或必须确认服务调用成功才能继续下一步操作的服务等，都不适合使用异步调用模式。

（4）服务降级。在网站访问的高峰期，服务可能因为大量的并发调用导致性能下降，严重时甚至会导致服务宕机。所以为了保证核心应用与服务的正常运行，我们必须对某些服务进行降级。降级有如下两种手段。

◎ 拒绝服务：拒绝低优先级应用的调用，减少并发数，以确保核心应用；或随机拒绝部分请求，以节约资源。

◎ 关闭功能：关闭部分不重要的服务，或关闭服务内不重要的功能，以节约资源。

（5）幂等性设计。应用在调用服务失败后，会将请求发送给其他服务器，但这个失败可能不是真的！比如服务实际上已处理成功，但因为网络故障，应用没有收到响应，那么这时应用所重新提交的请求，就是在重复调用服务！如果这是一个转账服务，那么后果会很严重。重复调用服务是不可避免的，所以服务层必须保证重复调用服务与调用一次服务的结果是相同的，即服务具有幂等性。比如转账交易的操作就需要通过交易编号对调用的服务进行有效性校验，保证调用是有效的才能继续执行。

3.高可用的数据层

对于系统而言，最珍贵的资产是多年运营积累下来的数据（用户数据、交易数据和商品数据等），所以保护了数据就是保护了企业的命脉。而保证数据高可用的手段是数据备份和失效转移，如下所述。

（1）数据备份：保证数据有多个副本，任意副本的失效都不会导致数据的永久丢失。

（2）失效转移：当有一个数据副本不可访问时，可以快速切换到其他副本。

注意：缓存服务不是数据存储服务，缓存服务器宕机引起的缓存数据丢失及服务器负载过高的问题，应该通过其他手段进行解决。可以让整个网站共享一个分布式缓存集群，应用只需要向共享缓存集群申请缓存资源即可，这样任何一台缓存服务器宕机所引起的缓存失效，都只会影响到缓存数据的一小部分，而不会对应用的性能和数据库负载造成太大的影响。

下面讲讲 CAP 的原理。为了保证数据的高可用，系统通常会牺牲数据的一致性。高可用的数据有如下几层含义。

◎ 数据持久性：保证数据可持久存储，即在将数据写入可持久性存储的硬件的同时，将数据备份成一个或多个副本。

◎ 数据可访问性：将多个数据副本存储在不同的存储设备上，如果一个存储设备损坏，就需要将对数据的访问切换到另一个数据存储设备上。这个过程要尽量快，让客户不可感知。

◎ 数据一致性：在数据有多个副本的情况下，如果网络、服务器或软件出现故障，则会导致部分副本写入成功，部分写入失败，这样就会造成各个副本之间存在数据不一致的情况。

下面讲讲备份数据。早期的数据备份主要是冷备份，即定期地将数据复制到存储介质中（磁带、光盘等）并进行物理存储，冷备份的优点是简单、廉价，缺点是不能保证数据最终一致。因为数据是定期复制的，所以备份设备中的数据比系统中的数据老，如果系统数据发生丢失，那么从上一个备份点开始，更新的数据就会永久丢失、不能恢复。冷备份作为一个传统的数据保护手段，依然在网站日常运维中使用，但还需要进行数据热备份，以提供更好的数据可用性。数据热备份有两种：异步热备和同步热备。

下面讲讲失效转移。失效转移指的是在服务器集群中如果有任意一台服务器宕机，那么应用针对这台服务器的所有读写操作，都需要被重新路由到其他服务器，保证服务依然是可用的。保证数据高可用性的手段是失效确认、失效转移和数据恢复。

（1）失效确认。系统通过心跳检测和应用访问失败的报告来确认某台服务器是否宕机。对于应用程序的访问失败报告，控制中心还需要再发送一次心跳检测对服务器进行确认，以免应用程序判断错误。因为一旦进行失效转移，就会出现存储的多份数据副本不一致，后续就要对这种情况进行一系列复杂的纠错操作。

（2）访问转移。在确认服务器宕机后，就要将数据的读写访问重新路由到其他服务器上。这又分为如下两种情况。

◎ 存储完全对等：直接切换到对等服务器上。

◎ 存储不对等：重新计算路由，选择健康的服务器。

（3）数据恢复。在某台服务器宕机后，数据存储的副本就会减少，这时系统会从健康的服务器上复制数据，将副本的数量恢复到系统设定的值。

高可用质量保证

下面会介绍一些保证线上系统的高可用质量的手段。

（1）发布系统。系统的发布实际上与服务器的宕机效果差不多，因为需要关闭服务器上的原有应用，然后重新部署、启动新的应用。但系统的发布毕竟是一次提前预知的“服务器宕机”，其过程可以更

柔和，对用户的影响可以更小。因为每次关闭的服务器只是集群中的一小部分，而且在发布完成后可以立即访问，所以整个发布过程并不影响用户的使用。

（2）自动化测试。代码在发布到服务器之前需要进行严格的测试。即使发布的新功能都在原有系统的功能上进行小幅增加，也需要对整个网站的功能进行全面的回归测试。此外，还要针对各种浏览器进行兼容性测试。大部分系统都采用了We b自动化测试技术。

（3）预发布过程。即使经过了严格测试，在部署到现网后还是有可能出现问题的。因为测试环境与现网环境不同，特别是应用可能会依赖其他服务，例如数据库、缓存及第三方服务（短信网关、支付接口等），所以在发布时可以先将包发布到“预发布服务器”上，这样开发人员与测试人员就可以在预发布服务器上进行验证了。一般会测试一些典型的业务流程，在确认系统没有问题后才会正式发布。

（4）代码控制。代码控制的核心问题是如何进行代码管理，既能保证代码发布的版本稳定、正确，又能保证不同团队的开发互不影响。

（5）很多公司都要求周期性发布系统，例如要求每周四都是发布日，在月底、节日前不允许发布。这样做是为了避免周末、节假日出现问题时无人解决问题，也避免周末、节假日加班。使用“火车发布模型“可以有效控制发布故障，减少发布日的加班问题。

（6）灰度发布模型。灰度发布又叫作AB测试，常被用于观察用户体验或测试新功能，即在线上环境中同时存在新老版本的系统，通过将部分用户导流到新版本中并监控用户的操作，来得到用户体验报告，这样就可以比较出用户对新老系统的满意度，为运营人员提供最真实的可信度数据。

系统运行监控

我们常常说：“不允许没有监控的系统上线”。系统运行监控对于系统运维和架构设计优化至关重要，没有监控的系统，是不完整的系统。

（1）采集监控数据。用户行为日志指的是用户在浏览器上的所有操作及用户所在的操作环境（操作系统与浏览器的版本、IP 地址、页面访问路径、页面停留时间等）。大型系统的用户日志数据量惊人，数据存储与计算的压力都很大，许多网站都逐步开发了基于实时计算框架Apache Storm的日志统计与分析工具。

（2）监控管理，如下所述。

◎ 系统告警。如果监控的某项指标超过了阈值，就意味着系统可能要出现故障，这时就要对相关人员进行告警。在监控管理系统中可以配置告警阈值和值守人员的联络方式（通过邮件、即时通信工具、手机短信等方式），及时发出预警。

◎ 失效转移。监控系统在发现故障时应该主动通知应用，及时进行失效转移。

◎ 自动优雅降级。优雅降级指的是网站为了应付突发的访问高峰，主动关闭一部分功能，释放系统资源。自动优雅降级的监控系统是一种柔性架构的理想状态：监控系统会实时监控所有服务器，如果发现某部分应用负载过高，就会适当卸载低负载应用的一部分服务器，重新安装和启动高负载的应用，使应用负载总体均衡。如果所有应用的负载都很高，就会自动关闭一部分不重要的功能，保证核心功能的正常运行。