高可用架构的核心是避免单点故障、保障数据一致、实现自动故障转移；需采用奇数节点（如3节点最低配置）、强一致性元数据同步、多实例负载均衡、健康探针验证及可观测性监控闭环。
确立高可用架构的集群部署规范，核心在于避免单点故障、保障数据一致、实现自动故障转移。不是节点越多越好，而是要让每个组件在失效时有明确的接管机制和可验证的恢复路径。
节点数量与角色分配必须匹配共识协议
多数分布式系统（如Nacos、etcd、Elasticsearch主节点）依赖Raft或类似多数派选举机制。这意味着：
- 节点数必须为奇数（3、5、7），3节点是生产环境最低可行配置，可容忍1个节点宕机
- 所有节点需具备同等通信能力，不能存在网络分区或单向连通情况
- 关键控制面组件（如kube-apiserver、Nacos JRaft Cluster、ES Master Node）需明确区分角色，禁用“混合部署”——例如不建议在同一个进程里同时承担数据存储和选主职责
数据持久化与同步机制要分层设计
高可用不等于数据不丢，而是在故障时仍能保证可读、可恢复、可验证的一致性：
- 元数据（如服务注册表、配置版本、集群拓扑）必须走强一致性路径（如MySQL + Raft日志复制），不可仅依赖内存缓存
- 运行时状态（如客户端连接、临时会话）可采用Distro等最终一致性协议，降低同步开销
- 数据库层必须启用主从或集群模式（如PostgreSQL流复制、MySQL Group Replication），且备份策略需覆盖全量+binlog/ WAL归档
流量入口与健康检查必须解耦且可验证
负载均衡器不是“加一层就高可用”，它本身也可能是单点：
- 对外暴露的入口应使用多实例+浮动IP（如Keepalived）或云厂商SLB，避免单LB节点成为瓶颈
- 后端健康检查不能只看端口通断，需调用真实业务探针（如Nacos的/nacos/v1/ns/operator/metrics、ES的/_cat/health?h=st）
- 客户端应内置重试+熔断逻辑，不依赖服务端兜底；例如Spring Cloud Alibaba Nacos客户端默认启用fail-fast和本地缓存，可在服务端短暂不可用时维持基本功能
运维可观测性是高可用的底线保障
没有监控的高可用，只是延迟暴露问题：
- 必须采集三类指标：节点存活（ping / TCP）、组件状态（leader/follower角色、raft term）、业务SLA（配置拉取耗时、服务发现成功率）
- 告警阈值需结合业务容忍度设定，例如Nacos配置变更推送延迟超过5秒触发P1告警，而非简单判断“是否在线”
- 定期执行故障注入演练（如kill -9 主节点、拔网线、磁盘满），验证切换时效与数据完整性
