高可用架构是让冗余自动发现故障、快速切换且不放大问题；需分层冗余、无状态优先、故障可控、可观测驱动。

高可用架构不是堆砌冗余，而是让冗余真正“活”起来——能自动发现故障、快速切换、不放大问题、也不拖慢增长。扩展性与稳定性表面看有张力，实则互为支撑：没有稳定底座，扩得越快崩得越狠；没有弹性扩展能力，稳也只是一时的脆弱平衡。

分层冗余，拒绝单点依赖

冗余必须覆盖全链路，不能只在应用层加机器，其他环节仍是单点：

• 基础设施层：跨可用区（AZ）部署是底线，关键服务至少分布于两个物理隔离的AZ；对核心业务，可进一步跨地域（Region）部署容灾实例
• 网络层：用VRRP/HSRP实现网关冗余，LB前置健康检查，自动摘除失联节点；避免所有流量经单一Nginx或HAProxy实例
• 数据层：数据库禁用单主单从裸奔模式，应采用MHA、Orchestrator或MySQL Group Replication等支持自动选主的方案；缓存与消息队列同样需集群化（如Redis Cluster、Kafka多副本）

无状态优先，状态外置

服务能否水平扩展，关键看它是否“无状态”。有状态服务天然难扩展，也容易因节点故障丢失上下文：

• 会话（Session）统一存到Redis或分布式Session中间件，而非本地内存
• 临时文件写入共享存储（如对象存储OSS/S3），不依赖某台机器磁盘
• 定时任务通过分布式调度器（如XXL-JOB、ElasticJob）协调，避免多实例重复执行
• 配置中心化管理（如Nacos、Consul），运行时动态更新，无需重启服务

故障可控，不雪崩、可降级

再完善的冗余也防不住连锁故障。真正的稳定性来自“故障被关进笼子”：

• 用熔断器（Sentinel/Hystrix）控制下游依赖超时和错误率，5秒内失败超50%即自动熔断，避免线程池耗尽
• 按业务重要性划分等级，非核心功能（如评论、推荐、日志上报）在压力大时可一键关闭或返回默认值
• 关键路径做舱壁隔离：数据库连接池、HTTP客户端连接池、线程池全部独立配置，互不影响
• 所有外部调用设明确超时（connect/read/write），禁用无限等待

可观测驱动，让扩容与修复有据可依

扩展不是拍脑袋加机器，稳定不是靠祈祷不出事。一切决策应基于真实信号：

• 核心指标必须埋点：接口成功率、P95响应时间、JVM GC频率、DB连接池使用率、消息积压量
• 用Prometheus+Grafana搭建统一监控大盘，设置多级告警（预警→严重→紧急），告警信息含直接定位线索（如异常Pod名、慢SQL哈希）
• 日志结构化并接入ELK或Loki，支持按traceId串联全链路，故障时5分钟内定位根因
• 定期做混沌工程演练（如随机杀Pod、注入网络延迟），验证故障转移是否真有效