本文作者：12叔
我们来总结一下高可用架构的设计 我们主要讨论存储高可用，计算高可用和业务系统的高可用
高可用主要是通过冗余的方式进行的
存储高可用
存储高可用主要这几种方式
主备复制
主备复制是最常见也是最简单的一种存储高可用方案，几乎所有的存储系统都提供了主备复制的功能
主备架构中的“备机”主要还是起到一个备份作用，并不承担实际的业务读写操作。
优点
- 对于客户端来说，不需要感知备机的存在，即使灾难恢复后，原来的备机被人工修改为 主机后，对于客户端来说，只是认为主机的地址换 了而己，无须知道是原来的备机升级为主机了
- 对于主机和备机来说 ， 双方只需要进行数据复制即可，无须进行状态判断和主备倒换这类复杂的操作。
缺点
- 备机仅仅只为备份，并没有提供读写操作 ， 硬件成本上有浪费 。
- 故障后需要人工干预，无法自动恢复。
主从复制
主机负责读写操作，从机只负责读操作，不负责写操作
- 主从复制在主机故障时，读操作相关的业务不受影响；
- 主从复制架构的从机提供读操作，发挥了硬件的性能；
缺点
- 故障时需要人工干预
- 主从复制要比主备复制复杂更多，主要体现在客户端需要感知主从关系，并将不同的操作发给不同的机器进行处理
- 可能导致数据不一致
主备倒换与主从倒换
两个方案就是在原有方案的基础上增加 “倒换”功能， 即系统自动决定主机角色， 并完成角色切换
常见的主备倒换架构有三种形式：互连式、中介式和模拟式
互连式
顾名思义，互连式就是指主备机直接建立状态传递的渠道
互连式主备倒换主要的缺点在于 ： 如果状态传递的通道本身有故障 ，那么备机也会认为主机故障了从而将自己升级为主机，而此时主机并没有故障 ，最终就可能出现两个主机
中介式
中介式指的是在主备两者之外引入第三方中介，主备机之间不直接连接，而都去连接中介， 并且通过中介来传递状态信息
主机和备机不再通过互联通道传递状态信息， 而是都将状态上报给中介这一角色。单纯从架构上看，中介式似乎比互连式更加复杂了 。首先 要引入中介，然后要各自上报状态，然而事实上，中介式架构在状态传递和决策上却更加简单
虽然中介式架构在状态传递和状态决策上更加简单，但并不意味着这种优点是没有代价的， 其关键代价就在于如何实现中介本身的高可用。如果中介自己岩机了，整个系统就进入了双备 的状态，写操作相关的业务就不可用了
模拟式
模拟式指主备机之间并不传递任何状态数据，而是备机模拟成一个客户端，向主机发起模 拟的读写操作，根据读写操作的响应情况来判断主机的状态
模拟式倒换与互连式倒换相比，具有如下优缺点
- 实现更加简单 ，因为省去了 状态传递通道的建立和管理工作
- 模拟式读写操作获取的状态信息只有响应信息，没有互连式那样多样，基于有限的状态来做状态决策，可能出现偏差
主主复制
主主复制指的是两台机器都是主机，互相将数据复制给对方，客户端可以任意挑选其中一 台机器进行读写操作
主复制架构从总体上来看要简单很多，无须状态信息传递，也无须 状态决策和状态切换。然而事实上主主复制架构也并不简单，而是有其独特的复杂性，具体表 现在：如果采取主主复制架构，必须保证数据能够双向复制，而很多数据是不能双向复制的。
主主复制架构对数据的设计有严格的要求， 一般适合于那些临时性、可丢失、可覆盖的数据场景
数据集群
简单来说，集群就是多台机器组合在一起形成一个统一的系统
集群可以分为两类：数据集中集群、数据分散集群
数据集中集群
数据集中集群与主备、主从这类架构相似，我们也可以称数据集中集群为 1主多备或 1主多从
虽然架构上是类似的，但由于集群里面的服务器数量更多，导致了复杂度整体上更高一些，具体体现在：
- 主机如何将数据复制给备机
- 备机如何检测主机状态
- 主机故障后，如何决定新的主机
数据分散集群
数据分散集群指多个服务器组成一个集群，每台服务器都会负责存储一部分数据：同时， 为了提升硬件利用率，每台服务器又会备份一部分数据
数据分散集群的复杂点在于如何将数据分配到不同的服务器上 ， 算法需要考虑如下设计点：
- 数据均衡性
- 容错性
- 可伸缩性
数据分散集群和数据集中集群的不同点：在于数据分散集群中的每台服务器都可 以处理读 写请求，因此不存在数据集中集群中负责写的主机那样的角色。但在数据分区集群中，必须有 一个角色来负责执行数据分配算法
数据分区
对于一些影响非常大的灾难或事故来说，有可能所有的硬件全部故障
这种情况下基于硬件故障而设 计的高可用架构不再适用，我们需要基于地理级别的故障来设计高可用架构，这就是数据分区 架构产生的背景 。
数据分区指将数据按照一定的规则进行分区，不同分区分布在不同的地理位置上，每个分 区存储一部分数据，通过这种方式来规避地理级别的故障所造成的巨大影响
数据量
数据量的大小直接决定了分区的规则复杂度，数据量越大，分区规则会越复杂，考虑的情况也越多
分区规则
地理位置有近有远，因此可以得到不同的分区规则，包括洲际分区、国家分区、城市分区 。 具体采取哪种或哪几种规则， 需要综合考虑业务范围、成本等因素
洲际分区主要用于面向不同大洲提供服务，由于跨洲通信的网络延迟己经大 到不适合提供在线服务了，因此洲际间的数据中心可以不互通或仅作为备份；
国家分区主要用于面向不同国家的用户提供服务，不同国家有不同的语言、法律、业务等，国家间的分区一般 也仅作为备份；
城市分区由于都在同一个国家或地区内，网络延迟较低，业务相似，分区同时 对外提供服务，可以满足业务多活之类的需求
复制规则
数据分区指将数据分散在多个地区，在某些异常或灾难情况下，虽然部分数据受影响，但 整体数据并没有全部被影响，本身就相当于一个高可用方案了 。 但仅仅做到这点还不够，因为 每个分区本身的数据量虽然只是整体数据的一部分，但还是很大，这部分数据如果损坏或丢失， 损失同样难以接受。因此即使是分区架构，同样需要考虑复制方案
常见的分区复制规则有三种 ： 集中式、互备式和独立式
集中式备份指存在一个总的备份中心，所有的分区都将数据备份到备份中心
互备式备份指每个分区各份另外一个分区的数据
独立式备份指每个分区自己有独立的备份中心
计算高可用
计算高可用的主要设计目标是当出现部分硬件损坏时，计算任务能够继续正常运行。 因此计算高可用的本质也是通过冗余来规避部分故障的风险
计算高可用架构的设计复杂度主要体现在任务管理方面 ，即当任务在某台服务器上执行失 败后，如何将任务重新分配到新的服务器进行执行
计算高可用架构设计的关键点有如下两点。
- 哪些服务器可以执行任务
- 任务如何重新执行
主备
主备架构是计算高可用最简单的架构，和存储高可用的主备复制架构类似，但是要更简单 一些，因为计算高可用的主备架构无须数据复制 主备方案详细设计如下：
- 主机执行所有计算任务 。 例如，读写数据、执行操作等。
- 当主机故障（例如 ， 主机右机）时，任务分配器不会自动将计算任务发送给备机
- 如果主机能够恢复（不管是人工恢复还是自动恢复），任务分配器继续将任务发送给主机。
- 如果主机不能够恢复（例如，机器硬盘损坏，短时间内无法恢复），则需要人工操作，将备机升为主机
主备架构又可以细分为冷备架构和温备架构
冷备 机上的业务系统没有启动，需要手动启动 温备 备机上的业务系统己经启动，只是不对外提供服务 人工只需要将任务请求切换为发送到备机即可
主备架构的优点就是简单，主备机之间不需要进行交互，状态判断和倒换操作由人工执行， 系统实现很简单。而缺点正好也体现在“人工操作”这点上，因为人工操作的时间不可控
主从
和存储高可用中的主从复制架构类似，计算高可用的主从架构中的从机也是要执行任务的 。 任务分配器需要将任务进行分类，确定哪些任务可以发送给主机执行，哪些任务可以发送给备机执行
- 正常情况下，主机执行部分计算任务
- 当主机故障（例如，主机岩机）时 ， 任务分配器不会自动将原本发送给主机的任务发 送给从机，而是继续发送给主机，不管这些任务执行是否成功 。
- 如果主机能够恢复（不管是人工恢复还是自动恢复），任务分配器继续按照原有的设 计策略分配任务
- 如果主机不能够恢复，则需要人工操作，将原来的从机升级为主机，增加新的机器作为从机，新的从机准备就绪后 ，任务分配器继续按照原有的设计策略分配任务。
主从架构与主备架构相比，优缺点如下。
- 优点 ： 主从架构的从机也执行任务，发挥了从机的硬件性能 。
- 缺点 ： 主从架构需要将任务分类，任务分配器会复杂一些
对称集群
主备架构和主从架构通过冗余一台服务器来提升可用性，且需要人工来切换主备或主从。 这样的架构虽然简单，但存在一个主要的问题 ： 人工操作效率低、容易出错、不能及时处理故 障。因此在可用性要求更加严格的场景中 ，我们需要系统能够自动完成切换操作
高可用计算的集群根据集群中服务器节点角色的不同，可以分为两类：
一类是对称集群即集群中每个服务器的角色都是一样的，都可以执行所有任务；
一类是非对称集群， 集群中的服务器分为多个不同的角色，不同的角色执行不同的任务
对称集群更通俗的叫法是负载均衡集群
- 正常情况下，任务分配器采取某种策略（随机、轮询等）将计算任务分配给集群中的 不同服务器 。
- 当集群中的某台服务器故障后，任务分配器不再将任务分配给它，而是将任务分配给 其他服务器执行 。
- 当故障的服务器恢复后，任务分配器重新将任务分配给它执行
负载均衡集群的设计关键点在于两点：任务分配器需要检测服务器状态，任务分配器需要 选取分配策略
非对称集群
非对称集群中不同服务器的角色是不同的，不同角色的服务器承担不同的职责 。 以 Master- Slave 为例，部分任务是 Master 服务器才能执行，部分任务是 Slave 服务器才能执行
非对称集群架构详细设计如下：
- 集群会通过某种方式来区分不同服务器的角色
- 任务分配器将不同任务发送给不同服务器
- 当指定类型的服务器故障时，需要重新分配角色
非对称集群相比负载均衡集群，设计复杂度主要体现在两个方面：
- 任务分配策略更加复杂
- 角色分配策略实现比较复杂
业务高可用
异地多活
无论高可用计算架构，还是高可用存储架构，其本质的设计目的都是为了解决部分服务器 故障的场景下，如何保证系统能够继续提供服务。但在一些极端场景下，有可能出现所有服务 器都出现故障
这些极端情况会导致某个系统所有服务器都故障，或者业务整体瘫痪，而且 即使有其他地区的备份，把备 份业务系统全部恢复到能够正常提供业务，花费的时间也比较长，可能是半小时，有可能是 12 小时 。 因为备份系统平时不对外提供服务，可能会存在很多隐藏的问题没有发现。如果业务期 望达到即使在此类灾难性故障的情况下，业务也不受影响，或者在几分钟内就能够很快恢复， 那么就需要设计异地多活架构
顾名思义，异地多活架构的关键点就是异地、多活，其中异地就是指地理位置上不同的地 方 ， 多活就是指不同地理位置上的系统都能够提供业务服务,判断一个系统是否符合异地多活，需要满足如下 两个标准：
- 正常情况下，用户无论访问哪一个地点的业务系统，都能够得到正确的业务服务。
- 某地系统异常情况下，用户访问到其他地方正常的业务系统，也能够得到正确的业务服务。
单纯从异地多活的描述来看，异地多活很强大，能够保证在灾难的情况下业务都不受影响。 那是不是意味着不管什么业务，我们都要去实现异地多活架构呢？其实不然，因为实现异地多 活架构不是没有代价的，而是有很高的代价，具体表现为：
- 系统复杂度会发生质的变化，需要设计复杂的异地多活架构。
- 成本会上升，毕竟要多在一个或多个机房搭建独立的一套业务系统。
异地多活架构
根据地理位置上的距离来划分，异地多活架构可以分为同城异区、跨城异地、跨国异地
同城异区
同城异区指的是将业务部署在同一个城市不同区的多个机房
极端灾难发生概率是比较低的，可能几年或十几年才发 生一次。其次，除了这类灾难，机房火灾、机房停电、机房空调故障这类问题发生的概率更高， 而且破坏力一样很大。而这些故障场景，同城异区架构都可以很好地解决。因此 ， 结合复杂度、 成本、故障发生概率来综合考虑，同城异区是应对机房级别故障的最优架构
跨城异地
跨城异地指的是业务部署在不同城市的多个机房，而且距离最好要远一些
跨城异地虽然能够有效应对极端灾难事件，但“距离较远”这点并不只是一个距离数字上 的变化，而是量变引起了质变，导致了跨城异地的架构复杂度大大上升。距离增加带来的最主 要原因是两个机房的网络传输速度会降低，
业务系统需要考虑部署在不同地点的两个机房。在数据短时间不一致 的情况下，还能够正常提供业务 。 这就引入了 一个看似矛盾的地方：数据不一致业务肯定不会 正常，但跨城异地肯定会导致数据不一致
如何解决这个问题呢？重点还是在“数据”上，即根据数据的特性来做不同的架构。如果 是强一致性要求的数据，例如，银行存款余额，支付宝余额等，这类数据实际上是无法做到跨 城异地多活的,而只能采用同城异区这种架构
而对数据一致性要求不那么高，或者数据不怎么改变，或者即使数据丢失影响也不大的业 务，跨城异地多活就能够派上用场了
跨国异地
跨国异地指的是业务部署在不同国家的多个机房。相比跨城异地，跨国异地的距离更加远 了，因此数据同步的延时会更长，正常情况下可能就有几秒钟了
跨国异地 多活的主要应用场景一般有如下几种情况 ：
- 为不同地区用户提供服务
- 只读类业务做多活
异地多活设计技巧
同城异区 关键在于搭建高速网络将两个机房连接起来，达到近似一个本地机房的效果。架构设计 上可以将两个机房当作本地机房来设计，无须额外考虑 。 跨城异地 关键在于数据不一致的情况下，业务不受影响或影响很小，这从逻辑的角度上来说其实 是矛盾的，架构设计的主要目的就是为了解决这个矛盾。 跨国异地 主要是面向不同地区用户提供业务，或者提供只读业务，对架构设计要求不高。
- 保证核心业务的异地多活
- 核心数据最终一致性
- 采用多种手段同步数据
- 只保证绝大部分用户的异地多活
异地多活设计步骤
业务分级
按照一定的标准将业务进行分级，挑选出核心的业务，只为核心业务设计异地多活
常见的分级标准有如下几种 。
- 访问量大的业务
- 核心业务
- 产生大量收入的业务
数据分类
挑选出核心业务后，需要对核心业务相关的数据进行进一步分析，目的在于识别所有的数 据及数据特征
- 数据量
- 唯一性
- 实时性
- 可丢失性
- 可恢复性
数据同步
确定数据的特点后，我们可以根据不同的数据设计不同的同步方案
- 存储系统同步
- 存储系统同步
- 重复生成
异常处理
无论数据同步方案如何设计，一旦出现极端异常的情况，总是会有部分数据出现异常的。 例如，同步延迟、数据丢失、数据不一致等。异常处理就是假设在出现这些问题时，系统将采 取什么措施来应对。异常处理主要有以下几个目的
- 问题发生时，避免少量数据异常导致整体业务不可用。
- 问题恢复后，将异常的数据进行修正。
- 对用户进行安抚，弥补用户损失。
常见的异常处理措施有如下几类。
- 多通道同步 。
- 同步和访问结合
- 日志记录
- 用户补偿
参考资料
<亿级流量网站架构核心技术> <从零开始学架构> <大型网站技术架构>
架构系列合辑
本文转自：https://my.oschina.net/jayqqaa12/blog/3161734
© 著作权归作者所有
