可用性

可用性金字塔

可靠性

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

稳定性

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

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

本地可用

CAP：

数据逻辑保护

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

修复

数据变更流程

数据变更都需要被审核

备份

、快照、CDP、事件溯源

容灾多活

技术路线

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 无 不需要