高可用是大型架构核心，下面我详解高可用架构@mikechen
高可用架构
在当今对服务连续性要求极高的业务场景中，达到 99.99%（年停机时间不超过约 52 分钟）的可用性。
需要拆成各层 SLO：入口层、核心服务、数据库等。
分别定义目标（如核心链路 99.99%，非核心服务 99.9% 即可），避免一刀切成本过高。
流量入口高可用
流量入口，是用户请求进入系统的第一道防线，必须做到冗余与智能调度。
常见做法包括：部署多个全局负载均衡器、多活或主备的边缘负载均衡器和防火墙。
用户 ↓ DNS / Anycast ↓ 多 VIP / 多 SLB ↓ 多 Nginx / Gateway
结合健康检查、与自动流量切换策略。
比如：L4/L7 负载均衡器本身通过 Keepalived + VRRP 协议实现主备或双主热备，确保负载均衡器自身不会成为单点故障。
应用层高可用
应用层是处理业务逻辑的地方，是故障最常发生的位置，核心在于无状态、隔离和快速扩容。
以及，常见的“高可用四班斧”：
超时：防止请求无限等待；
限流：系统自保；
熔断：防止级联失败；
降级：保证核心功能。
中间件高可用
中间件如消息队列、缓存、配置中心等往往是架构中的高风险点。
高可用策略，包括：集群化部署、复制与划分（sharding）、仲裁机制与故障转移自动化。
对缓存，应设定高可用方案。
比如：集群模式，采用 Redis Cluster 、或 Sentinel 模式。
对消息队列， Broker 节点必须集群部署。
通常要求至少 3 个副本（Replica Factor 3），来保证数据的高可用性。
数据层高可用
数据层，涉及持久性与一致性，是高可用设计中最具挑战的部分。
必须在数据副本、备份、同步延迟与一致性保障之间进行权衡。
可采用主从复制、多主或分布式一致性存储（如使用 Paxos/Raft 等协议）的方案。
结合同步或半同步复制策略，以降低数据丢失风险。
以及定期冷备、异地容灾与可恢复性演练（演练故障恢复路径、验证数据完整性）是必不可少的实践。
陈睿mikechen
10年+大厂架构经验，资深技术专家，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注作者「mikechen」公众号，获取更多技术干货！
后台回复【架构】，即可获取《阿里架构师进阶专题全部合集》，后台回复【面试】即可获取《史上最全阿里Java面试题总结》