高可用架构核心是“绕”而非“修”，通过冗余+自动切换+健康感知消除单点故障：接入层用VIP+Keepalived实现秒级漂移；数据层依赖MySQL主从+MHA或Group Replication自动选主；逻辑层靠服务注册发现与熔断降级；基础设施层需跨可用区、多线路、多DNS冗余。

高可用架构解决单点故障，核心不是“修”，而是“绕”——不依赖任何唯一组件，让系统天然没有“命门”。只要关键链路中存在一个不可替代的节点（比如一台Nginx、一个数据库主实例、一个DNS解析入口），它宕机，服务就中断。高可用的做法是：用冗余+自动切换+健康感知，把“唯一性”彻底消除。

消除接入层单点：VIP + Keepalived 自动漂移

对外服务入口（如Web服务、API网关）最容易成为单点。常见做法是部署至少两台负载均衡器（如Nginx），通过Keepalived绑定一个虚拟IP（VIP）。两节点间持续心跳，一旦主节点MySQL进程挂掉、网络断开或服务无响应，Keepalived会立即触发VIP漂移到备用节点。整个过程通常在3–5秒内完成，上层应用无需改配置，用户无感知。

• 必须开放防火墙对VRRP协议（协议号112）的支持
• 需配置track_script脚本，真实检测MySQL、Nginx等服务进程是否存活，而非仅靠主机ping通
• 跨机房部署时，需借助VXLAN或专线拉通二层网络，否则VRRP无法工作

消除数据层单点：主从+自动故障转移

MySQL单点最危险——它一停，整个业务写入链路就断。纯主从复制只是数据备份，不算高可用；真正防止单点，需叠加自动切换能力：

• MHA（Master High Availability）可实现10–30秒内自动选主、VIP迁移、从库重连，适合中小规模
• MySQL Group Replication或Galera Cluster支持多主同步，任意节点故障不影响读写，强一致且切换更快
• 云厂商RDS自带高可用版（如阿里云HA版、AWS Aurora），底层已封装跨可用区主备+自动切换，运维成本最低

注意：所有方案都要求binlog格式为ROW、server-id全局唯一、复制用户权限正确，否则切换后数据可能不一致。

消除逻辑层单点：服务多实例+注册发现+熔断降级

微服务或应用服务本身也可能是单点。解决方式不是只靠机器冗余，更要让调用方“知道该找谁”：

• 服务启动时向注册中心（如Nacos、Consul）上报IP+端口+健康状态，调用方通过服务名消费，不硬编码地址
• 调用链路上配置超时（建议≤2s）、指数退避重试（最多2次）、熔断（失败率＞50%持续30秒即熔断）
• 非核心依赖（如短信、推送）必须支持降级：本地缓存兜底、异步补偿、返回默认值，避免被拖垮

消除基础设施单点：跨可用区+多线路+多DNS入口

再完善的软件层高可用，也扛不住机房断电、骨干网中断。因此物理层面必须冗余：

• 应用与数据库至少部署在两个可用区（AZ），网络延迟≤2ms，电力/网络完全隔离
• 公网入口配置双运营商线路（电信+联通），DNS解析启用智能调度（GSLB），用户自动接入最优线路
• 关键域名配置多个权威DNS服务商（如DNSPod + Cloudflare），防止单一DNS故障导致全站不可达

不复杂但容易忽略