📚 课程目录第4章高可用架构设计原则

4. 高可用架构设计原则

在金融行业，Kubernetes 集群承载的是支付、清算、风控、行情推送等核心链路，任何一次非计划停机都可能直接转化为资金损失与合规风险。因此，高可用不是“多买几台机器”这么简单，而是一组需要被显式设计、验证和持续运营的架构原则。本节围绕六条原则展开：冗余、故障域隔离、健康检查、自动恢复、容量规划与混沌工程。它们不是并列的清单，而是从“预防”到“兜底”再到“验证”的递进关系。

一、核心原理：六条原则的层次关系

冗余解决“单点必然失效”的问题，故障域隔离解决“失效不要扩散”的问题，健康检查解决“系统如何知道失效”的问题，自动恢复解决“知道之后如何自愈”的问题，容量规划解决“自愈时是否有资源可用”的问题，混沌工程则解决“以上假设是否真的成立”的问题。前五条是设计与建设，第六条是验证与反哺。

关键认知：高可用 = 冗余度 × 隔离度 × 检测速度 × 恢复速度 × 容量余量。任何一个因子趋近于零，整体可用性都会被拉低。金融场景通常要求核心服务达到 99.99%（年停机约 52 分钟），这意味着上述每个环节都必须有量化指标。

二、方法流程：从设计到落地的关键动作

把原则转化为可执行动作，需要落到具体的 Kubernetes 对象与参数上。以下流程按“设计—配置—验证”三段推进。

冗余设计：核心 Deployment 副本数不少于 3，且必须跨节点分布。使用 PodDisruptionBudget 限制自愿中断时的可用副本下限。
故障域隔离：通过 topologySpreadConstraints 或 podAntiAffinity 将副本打散到不同可用区与机架；etcd 集群跨 AZ 部署，避免同域多成员。
健康检查：为每个容器配置 livenessProbe、readinessProbe，有状态服务补充 startupProbe，避免启动慢被误杀。
自动恢复：依赖 ReplicaSet 重建、节点自愈、HPA 扩容与 restartPolicy 组合，形成多级恢复链。
容量规划：按峰值 QPS 的 1.5 倍预留资源，节点水位控制在 70% 以下，确保单节点故障后剩余节点可承接。
混沌工程：在预发与生产低峰期注入 Pod 删除、网络延迟、节点宕机等故障，验证上述假设。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: payment-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: payment-service
---
apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 3
  template:
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: payment-service

三、案例场景：支付网关的高可用改造

某支付网关最初以 2 副本部署在单一可用区，一次机房网络抖动导致全部实例失联，交易中断 18 分钟。改造后采取以下措施：副本提升至 4，跨 3 个可用区打散；readinessProbe 指向真实业务健康接口而非 TCP 端口；配置 PDB 保证滚动升级时至少 3 副本在线；节点池预留 30% 资源；每月执行一次混沌演练，随机删除一个可用区的 Pod。

原则	改造前	改造后	关键指标
冗余	2 副本	4 副本	可用副本 ≥ 3
故障域隔离	单 AZ	跨 3 AZ	单 AZ 故障不影响
健康检查	仅 TCP 探针	业务级 HTTP 探针	误判率下降
自动恢复	人工介入	自愈 + HPA	MTTR < 2 分钟
容量规划	无预留	N+1 水位 70%	单节点故障可承接
混沌工程	无演练	月度演练	发现 5 类隐患

四、误区与复盘

常见误区一：把 livenessProbe 当成业务健康检查。若探针依赖下游数据库，数据库抖动会引发大规模重启，反而放大故障。liveness 只应判断进程是否僵死，业务可用性交给 readiness。

常见误区二：只做冗余不做隔离。3 副本全部落在同一节点或同一机架，节点宕机时冗余形同虚设。必须用反亲和与拓扑分布约束强制打散。

复盘时建议围绕三个问题：故障发生时，系统是否在预期时间内检测到？恢复动作是否自动完成？恢复过程中是否有足够容量承接流量？如果任一答案为否，说明对应原则未真正落地。混沌工程的价值正在于把“我们以为的高可用”变成“被验证过的高可用”。在金融场景中，建议将混沌演练纳入变更流程，每次重大版本上线前执行一次针对性故障注入，并将结果沉淀为容量与探针参数的调整依据。

最后需要强调，六条原则必须协同工作。冗余提供副本，隔离限制爆炸半径，健康检查提供感知，自动恢复提供动作，容量规划提供资源，混沌工程提供验证。缺少任何一环，高可用都只是纸面承诺。