C. 高可用架构 --- 连锁故障处理

C. 高可用架构 — 连锁故障处理

概述

• 由于整个系统的一小部分出现故障，进而导致系统其他部分也出现故障

原因

• 服务器过载：原本均衡的两个系统，由于其中一个服务出现问题，导致另外一个服务出现过载
• 资源耗尽
  • CPU，副作用：
    • 正在处理的请求数量上升
    • 队列过长
    • 线程卡住
    • CPU死锁或者请求卡住
    • RPC超时
    • CPU缓存效率下降
  • 内存，副作用：
    • 任务崩溃
    • Java垃圾回收速率加快，从而导致CPU使用率上升
    • 缓存命中率下降
  • 线程
  • 文件描述符
  • 资源之间的相互依赖
• 慢启动
  • 必需的初始化过程
  • 运行时性能优化，尤其是java
• 冷缓存
  • 原因
    • 上线一个新的集群
    • 在某个集群维护之后恢复服务状态
    • 带缓存的任务重启
  • 措施
    • 过量配备该服务。
    • 使用限流降级机制
    • 当为一个集群增加负载时，需要慢慢增加。初期的小流量会加热缓存，一旦缓存热起来，就可以增加更多的请求。

常见触发条件

• 进程崩溃
• 进程更新
• 新的发布
• 业务自然增长
• 计划中或计划外的不可用
• 请求特征的变化：负载均衡配置改动，导致用户流量发生变化
• 资源限制

测试，发现薄弱环节 — 压力测试

• 测试直到出现故障，还要继续测试
  • 测试环境测试
    • 如果一个组件在高负载条件下进入了降级模式，它是否能哦鼓在无人干预的情况下退出该模式
    • 如果高负载情况下几个服务器崩溃，负载需要降低多少才能使系统重新稳定下来
  • 生产测试：确保有足够的可用额外容量依备自动保护措施失败，需要人工进行切换
    • 快速或者缓慢地降低任务数量，超越之前预期的流量模式
    • 快速去掉某一个集群的容量
    • 屏蔽不同的后端（试验超时等因素对系统的影响）
• 测试最常用的客户端
• 测试非关键性后端：确保它们的不可用不会影响到系统值的其他关键性组件

预防措施

• 限流降级

解决方案

• 增加资源
• 停止健康检查导致的任务死亡
• 重启软件服务器
• 丢弃流量
• 进入降级模式
• 消除批处理负载
• 消除有害的流量