一、高可用架构三大核心原理

1.FLP 不可能原理

• 分布式领域最出名的定理，在异步通讯场景，即使只有一个进程失败，也没有任何算法能保证非失败进程达到一致性。

• 三大限定条件：

确定性协议：给定一个输入，一定会产生同样的输出。

异步网络通讯：没有统一时钟，不能时间同步、不能使用超时、不能探测失败、消息可任意延迟、消息可乱序。

所有节点存活：所有存活节点必须最终达到一致性。

• safety:系统中非故障节点达成了一致和合法的共识。

• liveness:系统中非故障节点在有限时间内能够达成共识。

• fault tolerance:协议必须在节点故障时同样有效。

• SL 系统：为了达成一致，不允许节点失败。

• SF 系统：为了保证 Safety，需要无限等待，因此无法保证 Liveness。

• LF 系统：为了保证 Liveness，不能无限等待，因此无法保证 Safety。

2.CAP 定理

• 分布式数据存储系统不可能同时满足一致性、可用性和分区容忍性。

• 一致性：每次读取操作都会读取到最新写入的数据，或者返回错误。

• 可用性：每次请求都会得到非错请求，但不保证返回最新的数据。

• 分区容忍性：系统在发生分区的时候继续提供服务。

CA：为了达成数据一致性和系统可用性，不允许分区。

CP：系统分区的时候保证一致性，但无法保证可用性。

AP：系统分区的时候保证可用性，但无法保证数据一致性。

CAP 三大限定条件：

分布式：可能发生网络分区

数据存储：通过复制来实现数据共享的存储系统

同时满足：同时满足 CAP

CAP 细节：复制延迟/描述粒度/

3.BASE 理论

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

• 【Basically Available】读写操作尽可能的可用，但写操作在冲突的时候可能丢失结果，读操作可能读取到旧的值。

• 【Soft State】没有一致性的保证，允许系统存在中间状态，而该中间状态不会影响系统整体可用性，这里的中间状态就是 CAP 理论中的数据不一致。

• 【Eventually Consistent】如果系统运行正常且等待足够长的时间，系统最终将达成一致性的状态。

BASE 是 CAP 中 AP 方案的延伸，考虑了网络时延和系统恢复正常后的状态。

二、如何用 FEMA 方法排除架构隐患

1.定义

FMEA（Failure mode and effectsanalysis，故障模式与影响分析）又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析等，专栏采用“故障模式与影响分析”。

Failure：假设系统某些组件或者模块出现故障。

Mode： 故障发生的方式、可能性。

Effect ：故障的影响。

Analysis：分析系统的可能反应，以及如何改进。

2. 作用

FMEA 之所以能够在这些差异很大的领域都得到应用，根本原因在于 FMEA 是一套分析和思考的方法，而不是某个领域的技能或者工具。FMEA 并不能指导我们如何做架构设计，而是当我们设计出一个架构后，再使用 FMEA 对这个架构进行分析，看看架构是否还存在某些可用性的隐患。

3.FEMA 的应用阶段

4.FEMA 技巧

步骤：画架构图---》FEMA 分析-----》改进/迭代

• 画出架构设计图，如架构图或部署图

• 假设其中某个 role 发生故障，分析此故障对系统功能影响。

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

5.分析维度

• 业务能力：用户角度划分相关业务功能

• 故障模式：出现的故障，故障点和行式

• 故障影响：故障发生后会影响的功能

• 严重程度：故障影响程度

• 故障原因：导致故障现象的原因

• 故障概率：某个具体故障原因发生的概率

• 风险程度：综合严重程度和故障概率来一起判断某个故障的最终等级

• 已有措施：针对具体故障原因，系统现在是否提供了某些措施来应对

• 规避措施：为了降低故障发生概率或者故障影响而采取的一些措施

• 解决措施：为了解决问题而采取的一些措施

• 后续规划：针对 FEMA 分析表格，查漏补缺，优化系统架构。

三、业务级灾备架构设计

1.同城多中心架构

特征： 相同城市，相聚 50KM 以上；光纤互联；机房延时小于 2ms

本质：同城双中心可以当一个逻辑机房；可以应对机房级别灾难

应用：同一个集群，部署在同城两个数据中心；可能出现脑裂，一般用多条光纤线路

2.跨城多中心架构

特征：不同城市；光纤互联

技术本质：一般不把跨城双中心当作同一个逻辑机房；可以应对城市级别灾难

应用：用户区分，南北分区，提供就近接入；异地多活

落地方案 1：选两个近邻城市，广深等；机房延时小于 10ms ,可当作同一个逻辑机房；避免城市级别灾难；可以做异地多活，但不做用户分区

落地方案 2：两个远距离城市；机房延时大于 30ms，不可当作同一逻辑机房；可以避免城市级别和区域级别灾难；适应异地多活架构和分区架构。

跨城多中心：用户分区；就近接入；异地多活

可以应对城市级别故障，最高可靠性；成本高

3.跨国数据中心架构

全球部署；合规监管；区域用户分区；不做异地多活

4.业务灾备架构对比

​ 编辑删除

四、异地多活架构的三种模式

1.业务定制型异地多活

按照业务的优先级进行排序，优先保证核心业务异地多活；基于核心业务的流程和数据，设计定制化的异地多活架构。

【优点】对基础设施无强要求，例如机房部署、存储系统、时延等，一般部署在远距离的两个城市，可以支持区域级别故障处理。

【缺点】1. 不通用，每个业务都需要单独来做异地多活，业务需要改造；2. 难扩展，核心业务如果有重大变化，异地多活方案要重新设计。

2.游戏异地多活设计

3.业务通用型异地多活

通过配套服务来支持异地多活，无需按照业务优先级排序来挑选某些业务实现异地多活，只需要判断业务是否能异地多活。

优点：1. 对硬件基础设施无强要求，例如机房部署、存储系统、时延等，一般部署在远距离的两个城市，可以支持区域级别故障处理。2. 业务基本不用改造，只需判断业务是否支持 BASE，支持就可

以异地多活，不支持就单点部署。

缺点：1. 配套服务复杂，包括流量调度、容灾切换、建站平台、配置管理等；2. 存在全局单点业务，例如库存、卖家等相关业务；3. 机房距离较远的时候，RTO 比较大，可能达到分钟级。

案例一、淘宝单元化架构

案例二、蚂蚁 LDC 架构

LDC 路由

LDC 容灾

LDC 蓝绿发布

单元化架构配套服务

流量调度：负责将用户请求流量分配到对应的 RZone，例如蚂蚁 spanner

配置中心：负责 zone 的配置和容灾切换，例如 rzone 业务范围，访问哪些数据库。

建站平台：快速新建一个完整的 zone，目前都是基于容器技术来实现

发布平台：基于流量调度完成 zone 的蓝绿发布和灰度发布。

4.存储通用型异地多活

采用本身已经支持分布式一致性的存储系统，架构天然支持异地多活。

优点：1. 架构天然就支持异地多活，业务除了切换存储系统外，其它基本不用改造。

缺点：1. 需要分布式一致性的存储系统支持，目前这样的存储系统可选不多，例如 ZooKeeper、etcd、OceanBase；2. 对机房部署有强要求，如果要实现异地多活，只能采用近邻部署。

OCEANbase 三地五中心异地多活架构

4.异地多活架构模式对比

五、业务定制型异地多活架构设计

1.一个原理

CAP ---只可同时满足俩个

2.3 大原则

只保证核心业务：不同业务的数据特征不同，无法全部作到异地多活。

只能作到最终一致性：复制肯定有时间窗，抛弃实时一致性的幻想。

只能保证绝大多数用户

3.4 个步骤

业务分级：例如：访问量；核心场景；收入来源

数据分类：数据修改量；一致性；唯一性；可丢失性；可恢复性；

数据同步：回源读取；二次读取；

异常处理：体验不好由于无法处理；尽力而为减少损失

4.5 个技巧

消息队列同步：适合全局唯一的数据，因为可以覆盖，不适合余额之类的数据，因为数据修改无法作到幂等。

库拆分：库存拆分到不同地方

事务合并：异地事务合并处理

实时改异步：实时改成异步处理

适当容忍：业务上可以稍微开放一些约束。例如允许欠费