云原生如何保障高可用

云原生通过架构设计、技术选型、运维体系三个层面协同，构建“预防-容错-恢复”的全链路高可用能力。以下是核心保障机制及实践要点：

一、架构设计：从根源降低故障影响

1. 微服务与解耦

• 按业务域拆分服务，避免“单体故障拖垮全局”。
• 服务间通过API/消息队列通信，减少强依赖。

2. 无状态设计

• 业务服务尽量无状态，状态外置到Redis、数据库等。
• 无状态服务可快速扩缩容、任意迁移，重启即恢复。

3. 冗余与多副本

• 每个服务至少多副本部署（≥2）。
• 跨可用区（AZ）/跨区域部署，避免单机房故障。

二、容器与编排：Kubernetes 核心高可用能力

1. 副本与自愈

• Deployment/StatefulSet：通过 replicas 维持实例数量。
• 健康检查：
  • livenessProbe：失败则重启容器。
  • readinessProbe：失败则不接入流量。
• 节点故障：Pod 自动调度到其他健康节点。

2. 负载均衡与服务发现

• Service：提供稳定访问入口，自动负载到多个Pod。
• Ingress：七层流量分发，支持重试、熔断。

3. 自动扩缩容

• HPA：基于CPU/内存/自定义指标自动扩容。
• VPA：垂直调整Pod资源（谨慎使用）。
• 集群自动扩缩：节点不足时自动扩容Node。

4. 故障隔离与驱逐

• Pod Disruption Budget（PDB）：限制同时不可用Pod数量。
• 节点污点/容忍、亲和性：控制调度，避免集中风险。

三、流量治理：防止故障扩散

1. 服务网格（如Istio）

• 超时控制：避免长时间等待。
• 重试策略：有限次重试+退避。
• 熔断：下游故障时快速失败，保护上游。
• 限流：防止流量突刺压垮服务。

2. 灰度发布与回滚

• 滚动更新：逐步替换Pod，减少中断。
• 金丝雀/蓝绿发布：小流量验证，异常快速回滚。
• K8s 自动回滚：更新失败自动恢复旧版本。

四、存储与数据高可用

1. 存储选型

• 云盘/分布式存储：多副本、跨AZ冗余（如Ceph、云厂商存储）。
• 对象存储：天然多副本、高持久性。

2. 数据库高可用

• 主从复制、读写分离。
• 云托管数据库（RDS）自带主备切换、备份恢复。
• 定期备份+异地容灾。

五、可观测性：快速发现与定位

1. 监控

• Prometheus + Grafana：指标监控、告警。
• 关键指标：QPS、错误率、延迟、资源使用率。

2. 日志

• EFK/ELK：集中日志，便于排查。

3. 链路追踪

• Jaeger/Zipkin：定位跨服务性能瓶颈与故障点。

六、运维与容灾：应对极端故障

1. 混沌工程

• 主动注入故障（Pod删除、网络延迟），验证系统韧性。

2. 自动备份与恢复

• 定期备份配置、数据。
• 演练恢复流程，确保RTO/RPO达标。

3. 多集群与异地容灾

• 多集群部署，故障切换流量。
• 跨区域容灾，应对大规模故障。

七、典型高可用架构示例

用户 → 云负载均衡（多AZ）
        ↓
    Ingress（多副本）
        ↓
  K8s Service（多AZ）
        ↓
  业务Pod（多副本、无状态）
        ↓
  分布式存储/云数据库（主备、多AZ）

总结：云原生高可用核心原则

云原生不是单一技术，而是设计理念+技术体系+运维文化的结合，通过多层防护实现“故障常态化下的业务连续性”。