高可用架构核心是故障隔离、快速恢复、状态可控；需消除单点故障、服务解耦、健康检查与自动切换；容灾须明确RPO/RTO，分数据层、应用层、切换流程落地；稳定性需故障注入验证。
高可用架构的核心设计原则
Linux系统要实现高可用，关键不是堆砌组件，而是围绕“故障隔离、快速恢复、状态可控”三个目标来组织服务。单点故障必须消除，比如数据库不能只依赖一台服务器，Web入口不能只靠一个负载均衡器。服务之间要解耦，避免A服务异常直接拖垮B服务。同时所有关键组件需具备健康检查和自动切换能力，例如Keepalived配合LVS或Nginx实现VIP漂移，或用Pacemaker+Corosync管理资源组。
常用高可用方案选型与部署要点
根据业务规模和一致性要求选择合适方案：
- 轻量级双机热备：适合中小业务，用Keepalived+自定义脚本监控服务状态，注意配置nopreempt防止脑裂，VIP绑定网卡需确认arp_ignore/arp_announce内核参数正确
- 集群化服务管理：如PostgreSQL主从+repmgr或Patroni，确保failover过程不丢事务；MySQL推荐MHA或Orchestrator，重点校验GTID或半同步复制是否启用
- 容器化高可用：Kubernetes本身提供Pod自愈，但需额外保障etcd集群稳定（奇数节点、独立磁盘、定期快照），Service类型建议用ClusterIP+Ingress控制器（如Nginx Ingress）并开启健康检查
容灾设计的关键落地环节
容灾不是备份的简单异地存放，而是可验证的业务接管能力。必须明确RPO（数据丢失量）和RTO（恢复时间）指标，并据此设计链路：
- 数据层：跨机房同步需考虑网络延迟影响，MySQL异步复制RPO可能达分钟级，强一致场景应评估Galera Cluster或分布式数据库（如TiDB）
- 应用层：配置中心（如Nacos、Consul）和消息队列（如Kafka跨集群镜像）需同步部署，避免切换后配置缺失或消息积压
- 切换流程：手动切换易出错，建议用Ansible或自研运维平台封装标准化指令，每次演练后更新切换checklist，记录实际耗时与瓶颈点
稳定性验证不能只靠理论
上线前必须做真实故障注入：
- 用chaosblade或pumba模拟网络分区、进程终止、磁盘IO阻塞等场景
- 观察监控系统（Prometheus+Alertmanager）是否准确触发告警，告警信息是否包含定位线索（如具体节点、服务名、错误码）
- 验证日志集中平台（ELK或Loki）能否在故障期间持续采集，避免因本地磁盘满或网络中断导致日志丢失
