高可用架构的设计方法

Posted 2023-03-30 小二上酒8

概述

高可用(High Availability)，简称HA，是衡量IT系统服务质量的一个极其重要的参考，高可用一直是IT系统设计中需要重点关注的点。本文总结高可用架构中的一些关键设计思想。

衡量指标SLA
SLA是衡量网站服务可用性的一个关键指标，现在互联网公司一般以X个9来表示在系统1年时间的使用过程中，系统可正常使用时间与总时间（1年）之比，9越多代表全年服务可用时间越长、服务更可靠、停机时间越短，反之亦然。

一般而言，如果系统达到4个9就非常优秀了，需要在设计上做足功夫。

冗余

冗余是构建高可用的重要手段。其核心思想是对分布式系统中的节点进行备份。备份会分为冷备和热备。

• 冷备，一般会有主数据中心和备数据中心，正常情况下是主数据中心提供业务服务，备份中心不会有提供业务服务，而是会定期从主数据中心进行备份（非实时备份），也就是说如果主数据中心出现故障，业务也就中断了，需要人工进行干预，将流量从主数据中心切换到备数据中心。

• 热备，主要是对主数据中心进行实时性的备份，以保证在主数据中心出现故障后可以及时的切换，让用户不受影响的继续使用。 关于主数据中心到备数据中心的复制方式，分为同步和异步两种分式。

  • 同步方式，当主节点处理完请求后，会同步向多个备节点实时备份数据，只有所有节点数据同步完成，主节点才会向客户端返回成功。这种方式对可用性有较大损耗，一般不推荐使用，
  • 异步方式，当主节点处理请求后，会向客户端返回成功，同时会异步触发向多个备节点实时备份数据。该情况下，主备节点的数据会存在数据不一致或者延时，业务上需要能容忍一定程度的数据延迟。互联网系统一般会采用这种方式。

从备节点的工作方式划分，又可以分为双机互备和双机热备。

• 双机热备，从狭义上讲是使用互为备份的两台服务器共同执行同一服务，在正常情况下，工作机为应用系统提供服务，备份机监视工作机的运行情况，出故障时备机可迅速接管服务。
• 双机互备，是指主机和备机互为备份，备机上运行与主机不同的应用，例如两台server安装相同的系统、应用软件，主机备机同时工作，主机跑ORACLE，备机跑IIS，任意一台服务器故障时，所有服务会自动切换到正常的服务器上。

集群

集群是相对单机而言的，集群部署是分布式系统的典型特征。集群的作用其实就是分流，这里面不得不提核心的分流技术。

负载均衡

分为硬件负载和软件负载。

• 硬件负载：通过硬件来进行分流，常见的硬件有比较昂贵的F5和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，一般在互联网系统较少使用，主要用于金融行业的核心服务；
• 软件负载：通过软件实现分流，如nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件，这些都是通过软件级别来实现，费用非常低廉。

按所处OSI模型的工作层级，可分为7层负载和4层负载。

• 7层负载，是指工作在网络7层，基于URL等应用层信息的负载均衡，主要代表有Nginx。
• 4层负载，就是基于IP+端口的负载均衡，主要代表有LVS。

DNS

Domain Name System，“域名系统”的英文缩写，是一种组织成域层次结构的计算机和网络服务命名系统，它所提供的服务是用来将主机名和域名转换为IP地址的工作。一般大型网站的域名，背后会绑定多个vipServer的地址，DNS可以通过智能域名解析系统，返回离用户最近的vipServer 的ip。

容错

容错能力也是影响IT系统可用性的一个关键要素。

1. 狭义的容错，一般会在设计上体现在以下方面:

• 对用户的输入进行尽早的校验，不信任外部的输入。
• 程序中尽可能的考虑边界及异常的情况。

2. 广义的容错应该是两个具有明确边界的事物（如服务间，系统间）交互时候针对可能发生的一切主客观异常情况的防御性手段。常见的容错机制有failsafe、failback、failover、failfast。

failfast

快速失败，尽可能的发现系统中的错误，使系统能够按照事先设定好的错误的流程执行，避免资源耗尽或积压导致系统滚雪球式崩溃。我们通常讲的熔断就是这个思想。

failover

失效转移，它和前面提到的冗余备份关联很紧密。当主要组件异常时，其功能迅速转移到备份组件。mysql的双主模式、Zookeeper的自动选举、Redis的哨兵模式，都是基于这种思想，目的是尽量减少部分节点故障对用户服务的影响

failback

自动恢复，是相对failover而言的，簇网络系统（有两台或多台服务器互联的网络）中，由于要某台服务器故障进行维修，需要网络资源和服务暂时重定向到备用系统。在此之后将网络资源和服务器恢复为由原始主机提供的过程，称为自动恢复。一般依赖心跳探测技术来实现自动恢复，例如dubbo服务中的应用实例出现down机后，在服务恢复后会自动注册到config server，重新对外提供服务。

failsafe

失效安全，即在故障的情况下也不会造成伤害或者尽量减少伤害。并非所有的故障对用户都是致命的，当这类非关键的故障出现时可以忽略，因为这种故障不会造成损失或损失在可接受范围内。

多活

双活/多活架构，关键点是指不同地理位置上的系统都能够提供服务。“活”是指实时提供服务，与“活”对应的是字是“备”——备是备份，正常情况下对外是不提供服务或只提供部分服务（例如DB读写分离），如果需要提供服务，则需要大量的人工干预和操作，花费大量的时间才能让“备”变成“活。

实现多活有较高的成本，要考虑数据一致性、网络延时问题。

常见的多活方案有同城双活、两地三中心、三地五中心、异地多活等多种技术方案，不同多活方案技术要求、建设成本、运维成本都不一样。

同城双活

是在同城或相近区域内建立两个机房。同城双机房距离比较近，通信线路质量较好，比较容易实现数据的同步复制 ，保证高度的数据完整性和数据零丢失。同城两个机房各承担一部分流量，一般入口流量完全随机，内部RPC调用尽量通过就近路由闭环在同机房，相当于两个机房镜像部署了两个独立集群，数据仍然是单点写到主机房数据库，然后实时同步到另外一个机房。

该架构优点是方案简单、成本较低、网络延时小，缺点是由于双机房都在同城，所在城市出现网络故障或自然灾害时，服务可用性无法保障。

两地三中心

指 同城双中心 + 异地灾备中心。异地灾备中心是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，数据和服务平时都是冷的，当双中心所在城市或者地区出现异常而都无法对外提供服务的时候，异地灾备中心可以用备份数据进行业务的恢复。

该架构的优点是相比同城双活，增加了异地灾备能力；缺点是异地的备份数据中心是冷的，出故障时异地机房是否能顺利接管流量是个大问题。

异地多活

异地的一个核心问题是物理距离带来的延时，因此要避免一次请求在异地的多个机房之间流转，因此异地多活的核心是单元化，要保证单次请求在一个固定机房内封闭。

单元化，在技术上的核心挑战在于流量路由和数据同步。这里还需注意，有些应用和数据是没法单元化的，因此还会衍生出中心机房和单元机房的概念，对于没法单元化的数据必须在中心机房。 阿里的淘宝是国内最早完整成功实施单元化的系统，其在全球化部署上也有较多成功的实践，在此就不展开了。

去中心化

在一个分布有众多节点的系统中，每个节点都具有高度自治的特征。节点之间彼此可以自由连接，形成新的连接单元。任何一个节点都可能成为阶段性的中心，但不具备强制性的中心控制功能。节点与节点之间的影响，会通过网络而形成非线性因果关系。去中心化架构的特征：

• 去中心化，不是不要中心，而是由节点来自由选择中心、自由决定中心。
• 任何中心都不是永久的，而是阶段性的
• 任何中心对节点都不具有强制性

常见的中心化设计：

• ESB
• 单体系统
• 网关

常见的去中心化设计：

• DUBBO、MESH等
• 用SDK替代服务

第07讲：高可用系统架构设计

本课时讲解高可用系统架构，如下图所示，本课时内容主要包括 3 个部分。

1. 互联网系统可用性度量，即如何用指标来衡量系统的可用性，以及进行可用性管理时的一些手段。

2. 高可用架构策略，主要包括负载均衡、备份与失效转移、消息队列隔离、限流与降级、异地多活这样几种架构方法。

3. 高可用运维，如何在开发测试发布以及系统运行过程中，保障系统的高可用，包括自动化部署、自动化监控、自动化测试、预发布测试这几个方面。

系统高可用的挑战

一个互联网应用想要完整地呈现在最终用户的面前，需要经过很多个环节，任何一个环节出了问题，都有可能会导致系统不可用。

 

比如说 DNS 被劫持，域名解析就失败了，系统虽然完好无损，但用户依然不能访问系统。再比如，CDN 服务不可用，前面提过，CDN 服务是用户访问的第一跳，对于大型互联网系统而言，主要的静态资源都是通过 CDN 返回的。如果 CDN 服务不可用，那么大量的用户请求就会到达互联网数据中心，会给互联网数据中心带来巨大的请求负载压力，可能直接导致系统崩溃。还有就是应用服务器及数据库宕机、网络交换机宕机、磁盘损坏、网卡松掉，这样的硬件故障；机房停电了、空调失灵了、光缆被挖掘机挖断了，这些环境故障。以及程序代码 bug 引起的故障，等等。

 

每种故障都是系统不可用的原因之一，在设计系统相关架构的时候，要考虑各个方面的因素。除了系统本身故障导致的可用性问题，还有外部因素导致的系统不可用。比如说系统被黑客攻击了；业务上要做一次大的促销，或者要做一个秒杀的活动，因此带来的访问压力冲击；以及第三方合作伙伴服务不可用等等，各种带来系统故障的原因。

 

系统的高可用架构，说的就是如何去应对这些挑战。

互联网应用可用性的度量

业界通常用多少个 9 来说明互联网应用的可用性。比如说 QQ 的可用性是 4 个 9，就是说 QQ 的服务 99.99% 可用，这句话的意思是 QQ 的服务要保证在其所有的运行时间里只有 0.01% 不可用，也就是说一年大概有 53 分钟不可用。这个 99.99% 就叫做系统的可用性指标，这个值的计算公式是：年度可用性指标= 1 −（不可用时间/年度总时间）×100%。

 

一般说来，两个 9 表示系统基本可用，年度停机时间小于 88 小时；3 个 9 是较高可用，年度停机时间小于 9 个小时；4 个 9 是具有自动恢复能力的高可用，年度停机时间小于 53 分钟；5 个 9 指极高的可用性，年度停机时间小于 5 分钟。事实上对于一个复杂的大型互联网系统而言，对可用性的影响因素是非常多的，能够达到 4 个 9 甚至 5 个 9 的可用性，除了具备过硬的技术、大量的设备资金投入、有责任心的工程师，有时候还需要好运气。

 

我们熟悉的互联网产品的可用性大多是 4 个 9，淘宝、支付宝、微信，差不多都是这样。我们用可用性来描述一个系统是否整体可用，但是实际上很少会出现整个系统在几分钟几个小时内全部不可用的情况，更多的时候是一部分用户全部不可用，或者是全部的用户一部分功能不可用。可用性指标是对系统整体可用性的一个度量。

故障分类

在互联网企业中为了管理好系统的可用性，界定好系统故障以后的责任，通常会用故障分进行管理。一般过程是，根据系统可用性指标换算成故障分，是整个系统的故障分，比如 10万 分，再根据各自团队各个产品各个职能角色承担的责任的不同，会把故障分下发给每个团队，直到每个人，也就是说每个工程师在年初的时候就会收到一个预计的故障分。然后每一次系统出现可用性故障的时候，都会进行故障考核，划定到具体的团队和责任人以后，会扣除他的故障分。如果到了年底的时候，一个工程师，他的故障分被扣为负分，那么就可能会影响他的绩效考核。

 

故障分类的计算方式是用故障时间乘以故障权重来计算得到的。而故障的权重通常是在故障产生以后，根据影响程度，由运营方确定的一个故障权重值。下图是故障权重的示例。

故障处理流程和故障时间

再看一般互联网应用的故障处理流程和故障时间的确定，如下图。

 

      

首先是故障的开始，故障的开始时间是客服报告故障的时间点，或者是监控系统发现故障的时间点，如果客服收到了投诉，说系统不可用，这个时候就开始计算故障时间。或者监控系统发现，用户访问量或者是订单量因系统故障而出现了大幅的下跌，那么监控系统监控到的故障时间点就是故障的开始时间。

 

确定了故障以后，就把故障提交给相关部门的接口人，接口人再把故障现象发送给相关的责任人，责任人接手故障后，进行故障排查和处理。处理完毕以后系统重新启动，或者是代码重新发布上线以后，重新确认系统指标正常或者是功能恢复正常，确认故障处理完毕，这个时间就是故障的结束时间。

 

我们刚才用来计算故障分的故障时间，就是用这个故障结束时间减去开始时间，就是故障时间。这个时间通常以秒为单位，故障处理整个过程是争分夺秒的。故障结束以后，通常要开一个故障复盘会，检讨故障产生的原因，亡羊补牢，避免下次出现类似的故障，同时也要对引起故障的原因进行责任划分，扣除相关责任者的故障分计入绩效考核。

大型系统高可用的一般策略

那么，大型系统高可用的一般策略有哪些？

负载均衡

首先是应用服务器的负载均衡。负载均衡核心要解决的就是通过一个负载均衡服务器，将用户的请求分发给多个应用服务器，将多个应用服务器构建成一个集群，共同对外提供服务。这样的架构可以提高系统的处理能力，以解决高并发用户请求下的系统性能问题。

 

事实上，负载均衡还可以实现系统的高可用。因为用户的请求是通过负载均衡服务器请求分发到不同的应用服务器上的。那么当某个应用服务器宕机的时候，负载均衡服务器可以通过响应超时或者其它的心跳策略，发现这个应用服务器不可用，就可以将请求转发给其它的服务器，保证用户的请求总是能够成功的，整个系统对外看起来是可用的。从而使某个应用的服务器宕机，不会影响到整个系统的可用性。

 

这里面需要注意的一个点是，当我们提到一个应用服务器不可用的时候，并不仅仅是指应用服务器的硬件故障，或者是系统故障导致的系统宕机，更多的可能是应用程序在发布，因为应用程序要发布，必须要关闭以前的应用程序进程，拷贝新的程序代码，重新启动应用程序，这个时间可能需要几分钟或者十几分钟的时间，那么这段时间这台应用服务器对外看起来就是不可用的。

 

而这样的发布在互联网场景中是非常频繁的，一周有几次，甚至一天都有几次这样的发布。应用服务器是需要频繁停机的。所以在架构设计的时候，你不光要考虑到真正的服务器硬件或者系统故障导致的宕级，还要考虑到应用程序发布导致的系统停机，而这个可能更加频繁。

负载均衡实现方法

• HTTP 重定向负载均衡

      

• DNS 负载均衡

 

 

• 反向代理负载均衡

负载均衡的另外一种实现是反向代理负载均衡。我们前面提到用户请求到达数据中心以后，最先到达的就是反向代理服务器。反向代理服务器，除了可以提供请求的缓存功能以外，还可以进行负载均衡，将用户的请求分发到不同的服务器上面去。反向代理是工作在 HTTP 协议层上的一个服务器，所以它代理的也是 HTTP 的请求和响应。而 HTTP 协议相对说来，作为互联网第七层的一个协议，它的协议比较重，效率比较低，所以反向代理负载均衡通常用在小规模的互联网系统上，只有几台或者十几台服务器的规模。工作原理如图所示。

• IP 层负载均衡（四层负载均衡）

• 数据链路层负载均衡

这种通信方式我们从上图看是一个三角形，所以也被形象地称为三角模式。数据链路层的负载均衡是目前大型互联网系统中使用得最多的负载均衡方案。在 Linux 内核中也支持数据链路层负载均衡，也就是说可以用一台 Linux 服务器去配置实现数据链路层负载均衡，通过负载均衡实现应用服务器的高可用。

数据库复制与失效转移

数据库的高可用要比应用服务器复杂很多，因为应用服务器是无状态的，请求可以分发到任何一台服务器去处理，而数据库上必须存储有正确的数据才能将请求分发给它。对于数据库的高可用，通常是使用数据库复制与失效转移来完成的。我们在分布式数据库存储这一讲中提到过 MySQL 的主主复制，以及 MySQL 的主从复制。

 

因为有数据复制，所以用户请求可以访问到不同的从服务器上，当某一台从服务器宕机的时候，系统的读操作不会受到影响，实现数据库读操作高可用。而如果实现了主主复制，那么当主服务器宕机的时候，写请求连接到另外一台主服务器上，实现数据库的写操作高可用，而数据库部署的时候，可以同时部署如下图所示这样的主主复制和主从复制，也就是实现数据库的读写都高可用。

   

消息队列隔离

系统高可用的另一种策略是使用消息队列实现异步解耦，即消息队列隔离。我们在分布式消息队列一讲中也提到过这种架构方式的高可用。

 

一方面，消息的生产者和消费者通过消息队列进行隔离，那么如果消费者出现故障的时候，生产者可以继续向消息队列发送消息，而不会感知到消费者的故障，等消费者恢复正常以后再去到消息队列中消费消息，所以从用户处理的视角看，系统一直是可用的。

      

另一方面，由于分布式消息队列具有削峰填谷的作用，所以在高并发的时候，消息的生产者可以将消息缓存在分布式消息队列中，消费者可以慢慢地到消息队列中去处理，而不会将瞬时的高并发负载压力直接施加到整个系统上，导致系统崩溃。

限流和降级

系统高可用的另一个策略是限流和降级。主要针对的是，在高并发场景下，如果系统的访问量超过了系统的承受能力，如何对系统进行保护？

 

限流是指对进入系统的用户请求进行限流处理，如果访问量超过了系统的最大处理能力，就会丢弃一部分的用户请求，保证整个系统可用，保证大部分用户是可以访问系统的。这样虽然有一部分用户的请求被丢弃，产生了部分不可用，但还是好过整个系统崩溃，所有的用户都不可用要好。

 

保护系统的另一种手段就是降级。有一些系统功能是非核心的，但是实际它也给系统产生了非常大的压力，比如说在电商系统中有“确认收货”这个功能，对于大多数互联网电商应用，我们即使是不去确认收货，超时它会自动确认收货。

 

但实际上确认收货这个操作是一个非常重的操作，因为它要更改订单状态，完成支付确认，并进行评价等一系列操作。这些操作都是一些非常重的、对数据库压力很大的操作。如果在系统高并发的时候去完成这些操作，那么会对系统雪上加霜，使系统的处理能力更加恶化。解决办法就是在系统高并发的时候，比如说像淘宝“双11“这样的时候，当天可能整天系统都处于一种极限的高并发访问压力之下，这一天就可以将确认收货、评价这些非核心的功能关闭，将宝贵的系统资源留下来，给正在购物的人，让他们去完成交易。

异地多活机房架构

系统高可用的另一个策略是异地多活的架构。我们前面提到的各种高可用策略，都还是针对一个机房内的系统架构，但是如果整个机房都不可用，比如说机房所在城市遭遇了地震，机房遭遇了火灾或者停电，这样的话，不管我们前面的设计和系统多么的高可用，整个机房都不可访问，看起来系统依然是不可用的。

 

为了解决这个问题，同时也为了提高系统的处理能力和改善用户体验。很多大型互联网应用都采用了异地多活的多机房架构策略，也就是说将数据中心分布在多个不同地点的机房里，这些机房都可以对外提供服务，用户可以连接任何一个机房进行访问。这样每个机房都可以提供完整的系统服务，即使某一个机房不可使用，系统也不会宕机，依然保持可用。

异地多活的架构考虑的一个重点是，用户请求如何分发到不同的机房去。这个主要可以在域名解析的时候完成，也就是用户进行域名解析的时候，会根据就近原则或者其它一些策略，完成用户请求的分发。

 

另一个至关重要的技术点是，因为是多个机房都可以独立对外提供服务，所以也就意味着每个机房都要有完整的数据记录，所以用户在任何一个机房完成的数据操作，都必须要同步传输给其它的机房，需要进行数据实时同步。

 

目前远程数据库同步的解决方法有很多，最需要关注的是数据冲突问题。同一条数据，同时在两个数据中心被修改了，该如何解决？为了解决这种数据冲突的问题，很多异地多活的多机房架构实际上采用的是类似 MySQL 的主主模式，也就是说多个机房在某个时刻是有一个主机房的，某些请求只能到达主机房才能被处理，其它的机房不处理这一类请求，以此来避免关键数据的冲突。

高可用运维

自动化测试

除了高可用的架构，还有保障系统高可用的运维。

 

其中一种高可用的运维是自动化测试。对于一个成熟的互联网系统，任何一次代码变更，都可能需要执行大量的回归测试，才能够保证系统没有 bug，而这种更新又是非常频繁的，如果依赖手工操作，测试效率和测试资源都难以满足如此大量的回归测试需求。所以对于成熟的互联网产品，很多时候采用自动化测试，通过自动化脚本自动对 APP 或者是服务接口进行测试。

 

一开始的时候要写自动化的测试脚本，工作量会比较大，投入也会比较大。但是随着脚本的不断的积累，自动化测试的成本会比手工测试的成本要更低。一般说来，在实践中，对于比较成熟的互联网产品，也就是说每次变更相对影响比较小的互联网产品，使用自动化测试是比较划算的。自动化测试和手工测试的总体成本对比如下图。

自动化监控

还有一种是自动化监控。系统在线上运行的时候，必须要实时的监控系统的各项指标，包括业务指标和技术指标。业务指标包括用户访问量、订单量、查询量这些主要的业务指标，技术指标包括 CPU、磁盘、内存的使用率等。通过这些指标可以实时监控业务是否正常，系统是否正常。如果指标不正常，通过监控报警的手段，通知相关的人员，还可以在自动化监控的基础上去，触发自动化的运维工具，进行自动化的系统修复。

预发布

高可用运维的另一种手段是预发布。虽然在系统上线之前，系统在代码更新以后，要经过测试才会上线，但是还有一些情况在测试环境是无法复现的。比如对第三方服务的调用，数据库结构的变更，以及一些线上的配置参数变更等等，只有线上才能够发现。

 

但是一旦发布到线上以后，如果有这些问题，就会导致系统不可用，解决方法就是进行预发布。在线上的服务器集群里面有一台服务器，是专门的预发布服务器，这台服务器不配置在负载均衡服务器，也就是说外部的用户是无法访问到这台服务器的，但是这台服务器跟其它的应用服务器，使用的配置、连接的数据库、连接的第三方服务都是完全一样的，它是一个完全线上的一个服务器，而这个服务器只有内部的工程师才可以访问到。

 

在系统发布的时候，先发布到这台预发布服务器上，然后工程师通过域名绑定的方式，直接访问这台服务器，进行一些关键的业务操作，看系统是否正常。如果正常，那么就将代码同步到其它的服务器上，这时候外部服务器才能够访问到最新的代码。如果发现问题，那么就可以重新进行修复。这个问题虽然是线上的，但是并不会影响到外部用户的使用。预发布的工作原理如下图。

     

灰度发布

对于大型互联网系统，虽然有前面的各种保障措施，但还是可能发生上线以后用户报告出现故障，对于用户报告的故障或者监控到的故障，就需要对系统进行回滚到原来的代码，系统退回到前一个版本。但是对于大型互联网系统而言，它的服务器特别多，可能有数万台服务器，这个时候即使是进行系统回滚，也可能要花很长的时间。这段时间系统一直处于某种不可用的故障状态。

 

为了避免上述情况，大型互联网系统，会使用一种灰度发布的手段，也就是说每天都只发布一部分服务器，如果出现问题，那么只需要回滚这一部分服务器就可以。发布以后观察一天，第二天再发布一部分服务器。如果没有故障报告，那么就继续发布，如果有故障报告就进行回滚，减少故障的影响力和影响时间。灰度发布流程如下图。

总结回顾

系统可用性是通过可用性指标来进行衡量的。当我们说一个系统 4 个 9 可用的时候，就是指这个系统 99.99% 的时间都是可用的，也就意味着一年中的不可用时间只占 53 分钟。

 

为了对故障进行管理和考核，很多互联网企业还引入了故障分这样一个手段。保障系统高可用的主要策略有应用服务器的负载均衡、数据库的备份与失效转移、消息队列隔离，限流、降级以及异地多活的多机房架构。

 

除了这些高可用的架构策略，还通过一系列的自动化手段，实现运维的高可用，包括自动化测试、自动化监控，预发布以及灰度发布这些手段。

 

本课时内容至此结束，下一课时讲解系统的安全架构。