可用性

可用性金字塔

可靠性

可用性看重的是宕机时长、可靠性看重的宕机次数

稳定性

某个时间段内出错的概率，越高稳定性越差

性能是否逐渐劣化、软件每次的同样行为是否表现一致

本地可用

CAP：

变更管控

变更前：

变更时：分级发布，将变更细化为多个阶段，逐步对特定服务实例或可用区进行操作，以降低整体风险

变更后：检查关键指标，确保变更没有引发问题

预案

为了在系统发生故障或异常时，能够迅速恢复服务，减少业务损失，确保系统的稳定性和可用性

  1. 切流：用于在可用区故障时，通过将流量切换到其他可用区来保持服务的连续性。
  2. 扩容：在系统负载增加时，通过增加资源来保证服务的可用性。
  3. 重启：通过重启服务来恢复故障，但需要谨慎操作，以防扩大故障影响。
  4. 降级：在系统资源不足或故障时，通过降低服务质量来保障核心功能的运行。
  5. 限流：通过控制系统的并发数和请求量，确保系统的稳定性。
  6. 回滚：在新版本部署失败时，通过回滚到旧版本来恢复服务

数据逻辑保护

大部分影响可用性的原因是人为操作的失误

修复

数据变更流程

数据变更都需要被审核

备份

备份需要考虑的内容：

  1. 成本：备份策略需要在确保数据安全的同时，考虑到成本效益。成本包括存储、管理和维护备份系统的费用。为了控制成本，可以减少备份副本的数量，选择性价比高的存储介质，并使用数据压缩技术并根据数据的访问需求进行冷热分存。
  2. 可靠性：备份数据的可靠性至关重要，必须定期验证备份数据的完整性和可恢复性，确保在需要时能够成功恢复数据。通过定期的恢复测试、数据校验和实时监控，保证备份的可靠性。
  3. 时效性：备份的频率应根据数据的重要性和变化速度来确定。为了确保数据的时效性，可以使用全量备份和增量备份的混合模式，并采用自动化的备份工具，以减少人为错误，提升备份的效率

为了保证备份的可靠性，需要：

  1. 定期恢复测试：定期进行数据恢复测试，以验证备份数据的有效性和完整性。
  2. 数据校验：在备份过程中启用数据完整性校验，确保数据在传输和存储过程中未被损坏或发生错误。
  3. 实时监控：建立监控系统，实时监控备份过程，及时发现和处理异常。

容灾多活

技术路线

DRP规划

202192721112

业务影响分析：确定最核心业务

RTO RPO

容灾演练

根据文档内容进行测试与排练

在非生产环境进行模拟测试 在生产环境进行并行测试

中断测试

BCP业务连续性计划

多活方案

冗余

保证高可用的主要手段是使用冗余

使用了冗余之后，如果出现了异常就要采取行动来保证高可用，就需要使用状态决策来保证系统高可用，但是通过冗余来实现的高可用系统，状态决策本质上就不可能做到完全正确，不管是一主多备，主备切换，还是多主选举都会出现不同程度的状态不一致，这是由于网络分区的存在导致的

高可用存储

双机架构

主备复制
stateDiagram-v2  客户端 --> 主机: 读&写  主机 --> 备机: 数据复制  客户端 --> 备机: 主机不可用时读&写

备机主要还是起到一个备份作用，并不承担实际的业务读写操作，如果要把备机改为主机，需要人工操作

这种方式浪费了备机资源，同时主机故障后人工介入操作，人工也是一种故障点

主从复制
stateDiagram-v2  客户端 --> 主机: 读&写  主机 --> 备机: 数据复制  客户端 --> 备机: 读

客户端需要感知主从关系，做读写分离将不同的操作发给不同的机器进行处理

主主复制
stateDiagram-v2  direction LR  客户端 --> 主机1: 读&写  主机1 --> 主机2: 数据复制  主机2 --> 主机1: 数据复制  客户端 --> 主机2: 读&写

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

双机切换

需要考虑的点：

互连式：状态传递通道本身也是不可靠的

stateDiagram-v2  客户端 --> 主机: 读&写  主机 --> 备机: 数据复制  主机 --> 备机: 状态传递  客户端 --> 备机: 主机不可用时读&写

中介式：需要中介本身是高可用

stateDiagram-v2  客户端 --> 主机: 读&写  主机 --> 备机: 数据复制  主机 --> 中介: 状态上报  备机 --> 中介: 状态上报  客户端 --> 备机: 主机不可用时读&写

备机探测式：

stateDiagram-v2  客户端 --> 主机: 读&写  主机 --> 备机: 数据复制  备机 --> 主机: 探测主机是否挂了  客户端 --> 备机: 主机不可用时读&写

数据集群

数据集中集群

stateDiagram-v2  state 数据集中式集群 {    主机 --> 备机1: 数据复制    主机 --> 备机2: 数据复制    主机 --> 备机3: 数据复制  }  客户端 --> 数据集中式集群

数据分散集群：每台服务器都会负责存储一部分数据，又会备份一部分数据

数据分散集群

数据分区

集中式复制:

stateDiagram-v2  北京分区 --> 贵州备份中心: 数据复制  上海分区 --> 贵州备份中心: 数据复制  广州分区 --> 贵州备份中心: 数据复制

互备式复制：

stateDiagram-v2  北京分区 --> 上海分区: 数据复制  上海分区 --> 广州分区: 数据复制  广州分区 --> 北京分区: 数据复制

独立式复制：

stateDiagram-v2  北京分区 --> 北京备份中心: 数据复制  上海分区 --> 上海备份中心: 数据复制  广州分区 --> 广州备份中心: 数据复制

计算高可用

主备

stateDiagram-v2  任务分配器 --> 主机: 计算任务  任务分配器 --> 备机: 计算任务(人工切换)

主从

stateDiagram-v2  任务分配器 --> 主机: 计算任务1  任务分配器 --> 备机: 计算任务2

集群式

stateDiagram-v2  任务分配器 --> 集群  state 集群 {    [*] --> 服务器1: 计算任务    [*] --> 服务器2: 计算任务    [*] --> 服务器3: 计算任务  }
stateDiagram-v2  任务分配器 --> 集群  state 集群 {    [*] --> 服务器1: 计算任务1    [*] --> 服务器2: 计算任务2    [*] --> 服务器3: 计算任务3  }

存储计算分离

将系统的存储职责和计算职责分离开，存储节点只负责数据存储，而计算节点只负责计算，计算节点是无状态的

隔离

指将系统或资源分隔开 在发生故障时尽可能缩小影响范围

线程隔离

主要是在多线程环境下，对线程池进行治理，把核心业务和非核心业务分割开。

使用线程池来进行隔离，不同线程池中的线程是互相隔离的

Tomcat 中的线程隔离：

2020779333

线程隔离，只能保证在分配线程这个资源上进行隔离，并不能保证整体稳定性

进程隔离

java cpu、内存这些资源可以通过不同的虚拟机进程来做隔离。

  1. 集群式
  2. 分布式

集群隔离

一些模块容易在并发量高的时候因为这种功能把整个模块占有的资源全部耗尽

解决方案

机房隔离异地多活

把服务建立整体副本（计算服务、数据存储），在多机房内做异地多活或冷备份、是微服务数据异构的放大版

当在机房层面出现问题的时候，可以通过智能dns、httpdns、负载均衡等技术快速切换

原则

实现

数据（读写）分离

通过主从模式，将mysql、redis等数据存储服务集群化，读写分离，那么在写入数据不可用的时候，也可以通过重试机制临时通过其他节点读取到数据。

多节点在做子网划分的时候，除了异地多活，还可以做数据中心，所有数据在本地机房crud 异步同步到数据中心，数据中心再去分发数据给其他机房

链路隔离

对于正式链路跟压测链路，为了尽量隔离开来，要确保正式链路与压测链路所使用的的数据库、中间件等隔离开来，避免线上压测影响到了正常的业务，这里的隔离主要是为了数据的隔离，避免压测数据跑到正常的业务场景中

动静分离

爬虫隔离

有的系统有时候就会因为爬虫流量过高而导致资源耗尽，服务不可用

熔断

限流是服务方对自己的保护 熔断是调用方对自己的保护

降级

为了保证整体系统可用性，可以牺牲一部分功能依旧提供有损服务

兜底数据

默认值: 设置安全的默认值，不会引起数据问题，比如库存为0

静态值:请求的页面或api无法返回数据，提供一套静态数据展示，比如加载失败提示重试，或默认菜单

缓存: 缓存无法更新便使用旧的缓存

降级原则

距离用户越近 造成损失越小 避免滚雪球效应

降级不是一种具体的技术手段 更多的与业务相关 需要根据业务来决定如何降级

所谓用户友好，就是尽量保证用户的无感知或者若感知，不影响他的功能使用

降级类型

灰度发布与回滚

监控与报警

监控体系：

报警：

预警响应流程

架构健康

应用健康

应用质量

健康指标

过低和过高都是不健康的

应用规范

应用治理

降本提效 增质减损

环境健康

保障环境稳定 拥有自治能力

对环境差异化管理 保持最优状态 进而可以持续升级

开发、测试、预发布、线上等基础环境的建设，为了降低维护成本，使用镜像建成稳定可复用的基础环境，通过配置化来实现一套代码多处部署以降低不确定性，并且需要隔离来保护与约束不同环境

依赖健康

基础软件、三方包、二方包、链路上下游 问题出现概率由低到高，升级频率也是由低到高

依赖管理

依赖保护

可用性流程

Availability = MTBF / (MTBF + MTTR)

202192722726

FMEA

当我们设计出一个架构后，再使用 FMEA 对这个架构进行分析，看看架构是否还存在某些可用性的隐患

功能点故障模式故障影响严重程度故障原因故障概率风险程度已有措施规避措施解决措施后续规划
登录MySQL无法访问当MC中无缓存时，用户无法登录，预计有60%的用户高MySQL服务器断电中中无无无增加备份MySQL
登录MySQL无法访问同上高Server到MySQL的网络连接中断高高慢查询检测重启MySQL无不需要