高可用架构模式

架构里比较重要的是高性能、高可用、高扩展性。上次是高性能，这次是高可用。

对一般的项目而言，高可用主要用公司提供的基建，如多机房部署、主从等。但有些项目确实需要思考更多高可用的事项，如资源不足的情况下要做好限流或者降配（以前做抢购和秒杀梳理出了所有限流和降配方案，分了一二级处理），有的是同时支持普通版和付费版，需要不同的集群部署，提供不同的资源容量。

一、想成为架构师，你必须知道CAP理论

CAP定义：在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。

感想：CAP大家使用的比较少或者经常在无意中已经用到了，只不过很多时候大家会根据具体的业务情况做出合适的设计，如达到最终一致性。几年前公司使用etcd做服务发现，分布式系统与一致性协议，这种系统级的能力确实得好好了解CAP理论。

二、想成为架构师，你必须掌握的CAP细节

CAP关键点

1. CAP 关注的粒度是数据，而不是整个系统。
2. CAP 是忽略网络延迟的。
3. 正常运行情况下，不存在 CP 和 AP 的选择，可以同时满足 CA。
4. 放弃并不等于什么都不做，需要为分区恢复后做准备。

Base定义：BASE 是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（Eventual Consistency），核心思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。

感想：同上

三、FMEA方法，排除架构可用性隐患的利器

定义：FMEA（Failure mode and effects analysis，故障模式与影响分析）又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析等。FMEA 是一种在各行各业都有广泛应用的可用性分析方法，通过对系统范围内潜在的故障模式加以分析，并按照严重程度进行分类，以确定失效对于系统的最终影响。

在架构设计领域，FMEA 的具体分析方法是：

• 给出初始的架构设计图。

• 假设架构中某个部件发生故障。

• 分析此故障对系统功能造成的影响。

• 根据分析结果，判断架构是否需要进行优化。

可以使用下面的表格分析：

功能点	故障模式	故障影响	严重程度	故障原因	故障概率	风险程度	已有措施	规避措施	解决措施	后续规划
指的是用户角度	是系统会出现什么样的故障，包括故障点和故障形式。如MySQL相应时间达3S	功能点具体会受到什么影响。如20%用户无法登录	- 致命 / 高 / 中 / 低 / 无 - 严重程度 = 功能点重要程度 × 故障影响范围 × 功能	涉及概率、检测手段、处理措施	高、中、低	风险程度（高中低） = 严重程度 × 故障概率	检测告警、容错、自恢复	技术手段、管理手段	一般都是技术手段	既可以是技术手段，也可以是管理手段；可以是规避措施，也可以是解决措施

感想：这是第一次知道这个理论，确实很好，能够比较全面的分析出系统的问题。

四、高可用存储架构：双机架构

存储高可用方案的本质都是通过将数据复制到多个存储设备，通过数据冗余的方式来实现高可用，其复杂性主要体现在如何应对复制延迟和中断导致的数据不一致问题。

常见的双机高可用架构：主备、主从、主备 / 主从切换和主主。

感想：可以参考一下《MySQL45讲》里的内容。

五、高可用存储架构：集群和分区

集群：

1. 数据集中集群与主备、主从这类架构相似，我们也可以称数据集中集群为 1 主多备或者 1主多从。
2. 数据分散集群指多个服务器组成一个集群，每台服务器都会负责存储一部分数据；同时，为了提升硬件利用率，每台服务器又会备份一部分数据。

数据分散集群和数据集中集群的不同点在于，数据分散集群中的每台服务器都可以处理读写请求，因此不存在数据集中集群中负责写的主机那样的角色。但在数据分散集群中，必须有一个角色来负责执行数据分配算法，这个角色可以是独立的一台服务器，也可以是集群自己选举出的一台服务器。

分区：

数据分区指将数据按照一定的规则进行分区，不同分区分布在不同的地理位置上，每个分区存储一部分数据，通过这种方式来规避地理级别的故障所造成的巨大影响。采用了数据分区的架构后，即使某个地区发生严重的自然灾害或者事故，受影响的也只是一部分数据，而不是全部数据都不可用；当故障恢复后，其他地区备份的数据也可以帮助故障地区快速恢复业务。

即使是分区架构，同样需要考虑复制方案。

• 集中式备份指存在一个总的备份中心，所有的分区都将数据备份到备份中心
• 互备式备份指每个分区备份另外一个分区的数据
• 独立式备份指每个分区自己有独立的备份中心

感想：很多时候服务可能多机房部署，但是底层存储一般使用一主多从的结构，一旦主库出现问题，则将从库变主库。无论主库还是从库，都存储全部数据，可用性和易用性会更高一些。

六、如何设计计算高可用架构？

计算高可用的主要设计目标是当出现部分硬件损坏时，计算任务能够继续正常运行。

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

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

常见的计算高可用架构：主备、主从和集群。

1. 主备架构是计算高可用最简单的架构，和存储高可用的主备复制架构类似，但是要更简单一些，因为计算高可用的主备架构无须数据复制

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

3. 集群：高可用计算的集群方案根据集群中服务器节点角色的不同，可以分为两类：一类是对称集群，即集群中每个服务器的角色都是一样的，都可以执行所有任务；另一类是非对称集群，集群中的服务器分为多个不同的角色，不同的角色执行不同的任务，例如最常见的Master-Slave 角色。

感想：一般看到的都是对称集群

七、业务高可用的保障：异地多活架构

异地就是指地理位置上不同的地方，类似于“不要把鸡蛋都放在同一篮子里”；多活就是指不同地理位置上的系统都能够提供业务服务。

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

1. 同城异区指的是将业务部署在同一个城市不同区的多个机房。例如，在北京部署两个机房，一个机房在海淀区，一个在通州区，然后将两个机房用专用的高速网络连接在一起。

2. 跨城异地指的是业务部署在不同城市的多个机房，而且距离最好要远一些。例如，将业务部署在北京和广州两个机房，而不是将业务部署在广州和深圳的两个机房。

3. 跨国异地指的是业务部署在不同国家的多个机房。相比跨城异地，跨国异地的距离就更远了，因此数据同步的延时会更长，正常情况下可能就有几秒钟了。这种程度的延迟已经无法满足异地多活标准的第一条：“正常情况下，用户无论访问哪一个地点的业务系统，都能够得到正确的业务服务”

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

感想：公司现在是跨城异地，对称集群，不知道上游是否会根据用户IP打到最近机房。也做过跨国异地，做了IP就近访问，主要目的是为了相近的用户能快速访问，同时还能做一下容灾处理。

八、异地多活设计4大技巧

跨城异地多活架构设计的一些技巧和步骤

技巧 1：保证核心业务的异地多活

技巧 2：保证核心数据最终一致性

技巧 3：采用多种手段同步数据

技巧 4：只保证绝大部分用户的异地多活

异地多活设计的理念可以总结为一句话：采用多种手段，保证绝大部分用户的核心业务异地多活！

九、异地多活设计4步走

1. 业务分级：访问量大的业务、核心业务、产生大量收入的业务

2. 数据分类：数据量、唯一性、实时性、可丢失性、可恢复性

3. 数据同步：存储系统同步、消息队列同步、重复生成

4. 异常处理：多通道同步、同步和访问结合、日志记录、用户补偿

十、如何应对接口级的故障？

接口级故障的典型表现就是系统并没有宕机，网络也没有中断，但业务却出现问题了。例如，业务响应缓慢、大量访问超时、大量访问出现异常（给用户弹出提示“无法连接数据库”），这类问题的主要原因在于系统压力太大、负载太高，导致无法快速处理业务请求，由此引发更多的后续问题。

优先保证核心业务和优先保证绝大部分用户。

1. 降级：系统后门降级、独立降级系统
2. 熔断：实现的关键是需要有一个统一的 API 调用层，由 API 调用层来进行采样或者统计，如果接口调用散落在代码各处就没法进行统一处理了。一旦达到阈值，A服务请求B服务的时候立即返回错误，不再真正请求，防止被拖死。
3. 限流：基于请求限流（限制总量、限制时间量）、基于资源限流
4. 排队：是限流的一个变种，限流是直接拒绝用户，排队是让用户等待一段时间

感想：这类其实是业务开发人员接触最多的，有很多限流方案限流实现(1)、限流实现2。