高可用架构设计总结

本文作者:12叔

我们来总结一下高可用架构的设计 我们主要讨论存储高可用,计算高可用和业务系统的高可用

高可用主要是通过冗余的方式进行的

存储高可用

存储高可用主要这几种方式

主备复制

主备复制是最常见也是最简单的一种存储高可用方案,几乎所有的存储系统都提供了主备复制的功能

主备架构中的“备机”主要还是起到一个备份作用,并不承担实际的业务读写操作。

优点

  • 对于客户端来说,不需要感知备机的存在,即使灾难恢复后,原来的备机被人工修改为 主机后,对于客户端来说,只是认为主机的地址换 了而己,无须知道是原来的备机升级为主机了
  • 对于主机和备机来说 , 双方只需要进行数据复制即可,无须进行状态判断和主备倒换这类复杂的操作。

缺点

  • 备机仅仅只为备份,并没有提供读写操作 , 硬件成本上有浪费 。
  • 故障后需要人工干预,无法自动恢复。

主从复制

主机负责读写操作,从机只负责读操作,不负责写操作

  • 主从复制在主机故障时,读操作相关的业务不受影响;
  • 主从复制架构的从机提供读操作,发挥了硬件的性能;

缺点

  • 故障时需要人工干预
  • 主从复制要比主备复制复杂更多,主要体现在客户端需要感知主从关系,并将不同的操作发给不同的机器进行处理
  • 可能导致数据不一致

主备倒换与主从倒换

两个方案就是在原有方案的基础上增加 “倒换”功能, 即系统自动决定主机角色, 并完成角色切换

常见的主备倒换架构有三种形式:互连式、中介式和模拟式

互连式

顾名思义,互连式就是指主备机直接建立状态传递的渠道

互连式主备倒换主要的缺点在于 : 如果状态传递的通道本身有故障 ,那么备机也会认为主机故障了从而将自己升级为主机,而此时主机并没有故障 ,最终就可能出现两个主机

中介式

中介式指的是在主备两者之外引入第三方中介,主备机之间不直接连接,而都去连接中介, 并且通过中介来传递状态信息

主机和备机不再通过互联通道传递状态信息, 而是都将状态上报给中介这一角色。单纯从架构上看,中介式似乎比互连式更加复杂了 。首先 要引入中介,然后要各自上报状态,然而事实上,中介式架构在状态传递和决策上却更加简单

虽然中介式架构在状态传递和状态决策上更加简单,但并不意味着这种优点是没有代价的, 其关键代价就在于如何实现中介本身的高可用。如果中介自己岩机了,整个系统就进入了双备 的状态,写操作相关的业务就不可用了

模拟式

模拟式指主备机之间并不传递任何状态数据,而是备机模拟成一个客户端,向主机发起模 拟的读写操作,根据读写操作的响应情况来判断主机的状态

模拟式倒换与互连式倒换相比,具有如下优缺点

  • 实现更加简单 ,因为省去了 状态传递通道的建立和管理工作
  • 模拟式读写操作获取的状态信息只有响应信息,没有互连式那样多样,基于有限的状态来做状态决策,可能出现偏差

主主复制

主主复制指的是两台机器都是主机,互相将数据复制给对方,客户端可以任意挑选其中一 台机器进行读写操作

主复制架构从总体上来看要简单很多,无须状态信息传递,也无须 状态决策和状态切换。然而事实上主主复制架构也并不简单,而是有其独特的复杂性,具体表 现在:如果采取主主复制架构,必须保证数据能够双向复制,而很多数据是不能双向复制的。

主主复制架构对数据的设计有严格的要求, 一般适合于那些临时性、可丢失、可覆盖的数据场景

数据集群

简单来说,集群就是多台机器组合在一起形成一个统一的系统

集群可以分为两类:数据集中集群、数据分散集群

数据集中集群

数据集中集群与主备、主从这类架构相似,我们也可以称数据集中集群为 1主多备或 1主多从

虽然架构上是类似的,但由于集群里面的服务器数量更多,导致了复杂度整体上更高一些,具体体现在:

  • 主机如何将数据复制给备机
  • 备机如何检测主机状态
  • 主机故障后,如何决定新的主机

数据分散集群

数据分散集群指多个服务器组成一个集群,每台服务器都会负责存储一部分数据:同时, 为了提升硬件利用率,每台服务器又会备份一部分数据

数据分散集群的复杂点在于如何将数据分配到不同的服务器上 , 算法需要考虑如下设计点:

  • 数据均衡性
  • 容错性
  • 可伸缩性

数据分散集群和数据集中集群的不同点:在于数据分散集群中的每台服务器都可 以处理读 写请求,因此不存在数据集中集群中负责写的主机那样的角色。但在数据分区集群中,必须有 一个角色来负责执行数据分配算法

数据分区

对于一些影响非常大的灾难或事故来说,有可能所有的硬件全部故障

这种情况下基于硬件故障而设 计的高可用架构不再适用,我们需要基于地理级别的故障来设计高可用架构,这就是数据分区 架构产生的背景 。

数据分区指将数据按照一定的规则进行分区,不同分区分布在不同的地理位置上,每个分 区存储一部分数据,通过这种方式来规避地理级别的故障所造成的巨大影响

数据量

数据量的大小直接决定了分区的规则复杂度,数据量越大,分区规则会越复杂,考虑的情况也越多

分区规则

地理位置有近有远,因此可以得到不同的分区规则,包括洲际分区、国家分区、城市分区 。 具体采取哪种或哪几种规则, 需要综合考虑业务范围、成本等因素

洲际分区主要用于面向不同大洲提供服务,由于跨洲通信的网络延迟己经大 到不适合提供在线服务了,因此洲际间的数据中心可以不互通或仅作为备份;

国家分区主要用于面向不同国家的用户提供服务,不同国家有不同的语言、法律、业务等,国家间的分区一般 也仅作为备份;

城市分区由于都在同一个国家或地区内,网络延迟较低,业务相似,分区同时 对外提供服务,可以满足业务多活之类的需求

复制规则

数据分区指将数据分散在多个地区,在某些异常或灾难情况下,虽然部分数据受影响,但 整体数据并没有全部被影响,本身就相当于一个高可用方案了 。 但仅仅做到这点还不够,因为 每个分区本身的数据量虽然只是整体数据的一部分,但还是很大,这部分数据如果损坏或丢失, 损失同样难以接受。因此即使是分区架构,同样需要考虑复制方案

常见的分区复制规则有三种 : 集中式、互备式和独立式

集中式备份指存在一个总的备份中心,所有的分区都将数据备份到备份中心

互备式备份指每个分区各份另外一个分区的数据

独立式备份指每个分区自己有独立的备份中心

计算高可用

计算高可用的主要设计目标是当出现部分硬件损坏时,计算任务能够继续正常运行。 因此计算高可用的本质也是通过冗余来规避部分故障的风险

计算高可用架构的设计复杂度主要体现在任务管理方面 ,即当任务在某台服务器上执行失 败后,如何将任务重新分配到新的服务器进行执行

计算高可用架构设计的关键点有如下两点。

  • 哪些服务器可以执行任务
  • 任务如何重新执行

主备

主备架构是计算高可用最简单的架构,和存储高可用的主备复制架构类似,但是要更简单 一些,因为计算高可用的主备架构无须数据复制 主备方案详细设计如下:

  1. 主机执行所有计算任务 。 例如,读写数据、执行操作等。
  2. 当主机故障(例如 , 主机右机)时,任务分配器不会自动将计算任务发送给备机
  3. 如果主机能够恢复(不管是人工恢复还是自动恢复),任务分配器继续将任务发送给主机。
  4. 如果主机不能够恢复(例如,机器硬盘损坏,短时间内无法恢复),则需要人工操作,将备机升为主机

主备架构又可以细分为冷备架构和温备架构

冷备 机上的业务系统没有启动,需要手动启动 温备 备机上的业务系统己经启动,只是不对外提供服务 人工只需要将任务请求切换为发送到备机即可

主备架构的优点就是简单,主备机之间不需要进行交互,状态判断和倒换操作由人工执行, 系统实现很简单。而缺点正好也体现在“人工操作”这点上,因为人工操作的时间不可控

主从

和存储高可用中的主从复制架构类似,计算高可用的主从架构中的从机也是要执行任务的 。 任务分配器需要将任务进行分类,确定哪些任务可以发送给主机执行,哪些任务可以发送给备机执行

  1. 正常情况下,主机执行部分计算任务
  2. 当主机故障(例如,主机岩机)时 , 任务分配器不会自动将原本发送给主机的任务发 送给从机,而是继续发送给主机,不管这些任务执行是否成功 。
  3. 如果主机能够恢复(不管是人工恢复还是自动恢复),任务分配器继续按照原有的设 计策略分配任务
  4. 如果主机不能够恢复,则需要人工操作,将原来的从机升级为主机,增加新的机器作为从机,新的从机准备就绪后 ,任务分配器继续按照原有的设计策略分配任务。

主从架构与主备架构相比,优缺点如下。

  1. 优点 : 主从架构的从机也执行任务,发挥了从机的硬件性能 。
  2. 缺点 : 主从架构需要将任务分类,任务分配器会复杂一些

对称集群

主备架构和主从架构通过冗余一台服务器来提升可用性,且需要人工来切换主备或主从。 这样的架构虽然简单,但存在一个主要的问题 : 人工操作效率低、容易出错、不能及时处理故 障。因此在可用性要求更加严格的场景中 ,我们需要系统能够自动完成切换操作

高可用计算的集群根据集群中服务器节点角色的不同,可以分为两类:

一类是对称集群即集群中每个服务器的角色都是一样的,都可以执行所有任务;

一类是非对称集群, 集群中的服务器分为多个不同的角色,不同的角色执行不同的任务

对称集群更通俗的叫法是负载均衡集群

  1. 正常情况下,任务分配器采取某种策略(随机、轮询等)将计算任务分配给集群中的 不同服务器 。
  2. 当集群中的某台服务器故障后,任务分配器不再将任务分配给它,而是将任务分配给 其他服务器执行 。
  3. 当故障的服务器恢复后,任务分配器重新将任务分配给它执行

负载均衡集群的设计关键点在于两点:任务分配器需要检测服务器状态,任务分配器需要 选取分配策略

非对称集群

非对称集群中不同服务器的角色是不同的,不同角色的服务器承担不同的职责 。 以 Master- Slave 为例,部分任务是 Master 服务器才能执行,部分任务是 Slave 服务器才能执行

非对称集群架构详细设计如下:

  1. 集群会通过某种方式来区分不同服务器的角色
  2. 任务分配器将不同任务发送给不同服务器
  3. 当指定类型的服务器故障时,需要重新分配角色

非对称集群相比负载均衡集群,设计复杂度主要体现在两个方面:

  1. 任务分配策略更加复杂
  2. 角色分配策略实现比较复杂

业务高可用

异地多活

无论高可用计算架构,还是高可用存储架构,其本质的设计目的都是为了解决部分服务器 故障的场景下,如何保证系统能够继续提供服务。但在一些极端场景下,有可能出现所有服务 器都出现故障

这些极端情况会导致某个系统所有服务器都故障,或者业务整体瘫痪,而且 即使有其他地区的备份,把备 份业务系统全部恢复到能够正常提供业务,花费的时间也比较长,可能是半小时,有可能是 12 小时 。 因为备份系统平时不对外提供服务,可能会存在很多隐藏的问题没有发现。如果业务期 望达到即使在此类灾难性故障的情况下,业务也不受影响,或者在几分钟内就能够很快恢复, 那么就需要设计异地多活架构

顾名思义,异地多活架构的关键点就是异地、多活,其中异地就是指地理位置上不同的地 方 , 多活就是指不同地理位置上的系统都能够提供业务服务,判断一个系统是否符合异地多活,需要满足如下 两个标准:

  • 正常情况下,用户无论访问哪一个地点的业务系统,都能够得到正确的业务服务。
  • 某地系统异常情况下,用户访问到其他地方正常的业务系统,也能够得到正确的业务服务。

单纯从异地多活的描述来看,异地多活很强大,能够保证在灾难的情况下业务都不受影响。 那是不是意味着不管什么业务,我们都要去实现异地多活架构呢?其实不然,因为实现异地多 活架构不是没有代价的,而是有很高的代价,具体表现为:

  • 系统复杂度会发生质的变化,需要设计复杂的异地多活架构。
  • 成本会上升,毕竟要多在一个或多个机房搭建独立的一套业务系统。

异地多活架构

根据地理位置上的距离来划分,异地多活架构可以分为同城异区、跨城异地、跨国异地

同城异区

同城异区指的是将业务部署在同一个城市不同区的多个机房

极端灾难发生概率是比较低的,可能几年或十几年才发 生一次。其次,除了这类灾难,机房火灾、机房停电、机房空调故障这类问题发生的概率更高, 而且破坏力一样很大。而这些故障场景,同城异区架构都可以很好地解决。因此 , 结合复杂度、 成本、故障发生概率来综合考虑,同城异区是应对机房级别故障的最优架构

跨城异地

跨城异地指的是业务部署在不同城市的多个机房,而且距离最好要远一些

跨城异地虽然能够有效应对极端灾难事件,但“距离较远”这点并不只是一个距离数字上 的变化,而是量变引起了质变,导致了跨城异地的架构复杂度大大上升。距离增加带来的最主 要原因是两个机房的网络传输速度会降低,

业务系统需要考虑部署在不同地点的两个机房。在数据短时间不一致 的情况下,还能够正常提供业务 。 这就引入了 一个看似矛盾的地方:数据不一致业务肯定不会 正常,但跨城异地肯定会导致数据不一致

如何解决这个问题呢?重点还是在“数据”上,即根据数据的特性来做不同的架构。如果 是强一致性要求的数据,例如,银行存款余额,支付宝余额等,这类数据实际上是无法做到跨 城异地多活的,而只能采用同城异区这种架构

而对数据一致性要求不那么高,或者数据不怎么改变,或者即使数据丢失影响也不大的业 务,跨城异地多活就能够派上用场了

跨国异地

跨国异地指的是业务部署在不同国家的多个机房。相比跨城异地,跨国异地的距离更加远 了,因此数据同步的延时会更长,正常情况下可能就有几秒钟了

跨国异地 多活的主要应用场景一般有如下几种情况 :

  • 为不同地区用户提供服务
  • 只读类业务做多活

异地多活设计技巧

同城异区 关键在于搭建高速网络将两个机房连接起来,达到近似一个本地机房的效果。 上可以将两个机房当作本地机房来设计,无须额外考虑 。 跨城异地 关键在于数据不一致的情况下,业务不受影响或影响很小,这从逻辑的角度上来说其实 是矛盾的,架构设计的主要目的就是为了解决这个矛盾。 跨国异地 主要是面向不同地区用户提供业务,或者提供只读业务,对架构设计要求不高。

  • 保证核心业务的异地多活
  • 核心数据最终一致性
  • 采用多种手段同步数据
  • 只保证绝大部分用户的异地多活

异地多活设计步骤

业务分级

按照一定的标准将业务进行分级,挑选出核心的业务,只为核心业务设计异地多活

常见的分级标准有如下几种 。

  • 访问量大的业务
  • 核心业务
  • 产生大量收入的业务

数据分类

挑选出核心业务后,需要对核心业务相关的数据进行进一步分析,目的在于识别所有的数 据及数据特征

  • 数据量
  • 唯一性
  • 实时性
  • 可丢失性
  • 可恢复性

数据同步

确定数据的特点后,我们可以根据不同的数据设计不同的同步方案

  • 存储系统同步
  • 存储系统同步
  • 重复生成

异常处理

无论数据同步方案如何设计,一旦出现极端异常的情况,总是会有部分数据出现异常的。 例如,同步延迟、数据丢失、数据不一致等。异常处理就是假设在出现这些问题时,系统将采 取什么措施来应对。异常处理主要有以下几个目的

  • 问题发生时,避免少量数据异常导致整体业务不可用。
  • 问题恢复后,将异常的数据进行修正。
  • 对用户进行安抚,弥补用户损失。

常见的异常处理措施有如下几类。

  • 多通道同步 。
  • 同步和访问结合
  • 日志记录
  • 用户补偿

参考资料

<亿级流量网站架构核心技术> <从零开始学架构> <大型网站技术架构>

架构系列合辑

架构设计流程

高性能架构设计

高可用架构设计

可扩展架构设计

本文转自:https://my.oschina.net/jayqqaa12/blog/3161734

© 著作权归作者所有

人已赞赏
0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
有新消息 消息中心
搜索