高可用是大型架构核心，下面我重点详解千万级高可用架构@mikechen
流量入口高可用
流量入口是系统的咽喉，必须通过多层分发和冗余来保证流量平滑进入。
DNS 级高可用： 使用 GSLB（全局负载均衡），根据地理位置将用户解析到最近的数据中心。
配置多家 DNS 服务商备份，防止运营商级别的故障。
边缘节点（CDN）： 通过 CDN 缓存静态资源。
并在边缘节点进行流量清洗（WAF），过滤恶意攻击，减轻后端压力。
四层负载（L4）： 使用 LVS 或 DPVS 集群，结合 Keepalived 实现 VIP（虚拟 IP）漂移。
千万级用户需考虑 ECMP（等价多路径路由） 配合 BGP 协议，实现多机房物理负载均衡。
七层网关（L7）： 使用 Nginx 或 Kong/APISIX。
集群化： 网关必须集群部署，节点间无状态。
动态发现： 自动感知后端服务上下线。
应用层高可用
应用层的关键是“无状态 + 冗余实例 + 自动拉起和扩缩容”。
会话统一放到 Redis/Token（JWT）等共享存储，应用节点不持久化用户状态，宕机可随时替换。
每个务至少 N+1 部署（最少 2 个实例），跨机架或跨 AZ，放到容器平台（如 K8s）做自动扩缩容和自愈。
服务治理：限流 / 熔断 / 降级
使用 Sentinel、Envoy/Service Mesh、或网关插件实践熔断和限流，避免单个依赖异常拖垮整个集群。
中间件高可用
中间件包括网关、消息队列、缓存、配置中心等，都是“基础设施”。
一旦挂掉影响面极大，必须集群化 + 自动故障切换。
消息队列（Kafka/RocketMQ/RabbitMQ 等）
Topic 分区多副本，副本分布在不同 Broker 与不同 AZ，启用自动 Leader 选举与故障转移。
生产端和消费端都实现幂等与重试控制，确保即便消息系统发生 failover，也不会导致业务错误放大。
配置中心（如 Nacos、Apollo）集群部署、跨 AZ，数据库也做高可用。
客户端本地缓存配置并具备降级策略（如读取本地快照）。
服务注册中心至少 3 节点以上（如 Eureka/Consul/Etcd 集群），采用 quorum 协议保证在少数节点故障时继续工作。
数据层高可用
99.99% 的难点往往在数据层，既要不丢数据，又要高可用、高性能。
关系型数据库（如 MySQL）
主从 / MGR / Galera 等集群模式，至少 3 节点跨 AZ 部署。
配合中间件（如 ProxySQL、读写分离代理）实现自动故障转移。
对于核心库，可以采用“多机房同步复制 + 异地异步复制备份”的模式，结合延迟可接受范围选择同步/半同步复制策略。
备份、恢复与演练
定期全量备份 + 持续增量备份，备份存放在独立存储和异地，确保单 AZ / 单机房灾难时可恢复。
多地域与多活
为追求更高可用（甚至多于 4 个 9）：多区域、多副本分布，减少同一故障域内的关联故障概率。
mikechen睿哥
10年+一线大厂架构实战经验，操盘多个亿级大厂核心项目，就职于阿里、淘宝等一线大厂。