应用服务器怎样实现高可用

应用服务器（App Server）的高可用（High Availability, HA）目标是在硬件/软件故障、流量激增、网络异常等情况下，依然能持续对外提供服务，且尽量做到无感知切换、数据不丢、性能不降级。

下面从架构层面 → 关键机制 → 具体实现方式系统讲一下。

一、总体架构思路（核心原则）

一句话：消除单点 + 自动故障转移 + 水平扩展

典型高可用架构：

客户端
  ↓
负载均衡（SLB / Nginx / LVS）
  ↓
多台应用服务器（无状态）
  ↓
高可用数据库 / 缓存集群

二、应用服务器自身的高可用设计

1. 应用无状态化（最重要）

• Session 外置
  • Redis / Memcached 存 Session
  • 或 JWT / Token 鉴权
• 任意一台应用服务器挂掉，请求可被其他节点接管

✅ 错误示例：把登录状态放在本机内存

2. 多实例部署（集群）

• 至少 2 台以上（同机房 / 跨机房）
• 使用容器（Docker / K8s）更易于弹性扩缩容

3. 健康检查与自动剔除

• 负载均衡层做：
  • TCP 健康检查
  • HTTP 健康检查（/health）
• 不健康节点自动下线

三、负载均衡层的高可用

1. 负载均衡本身不能单点

方案：

• LVS + Keepalived（VIP 漂移）
• Nginx + Keepalived
• 云厂商 SLB（天然多 AZ）

2. 常见负载策略

• 轮询
• 最少连接
• 一致性哈希（缓存场景）

四、故障转移与容灾

1. 进程级故障

• 使用 Supervisor / systemd 自动重启
• K8s 中 Pod 自动重启 & 调度

2. 主机级故障

• 负载均衡剔除
• 新节点自动扩容（HPA）

3. 机房级故障（异地多活）

• 多可用区（AZ）
• 异地双活 / 多活
• DNS 切换 or 全局流量调度（GTM）

五、依赖组件的高可用（容易被忽略）

1. 数据库

• 主从复制
• 主备切换（MHA / Orchestrator）
• 云 RDS 多副本

2. 缓存

• Redis Cluster
• 哨兵模式

3. 消息队列

• Kafka / RocketMQ 多副本

六、限流、熔断、降级（保命机制）

即使高可用，也要防止雪崩：

• 限流：令牌桶 / 漏桶
• 熔断：Hystrix / Sentinel
• 降级：返回缓存 / 静态页

七、监控与告警（HA 的神经系统）

必须可观测：

• 应用监控（QPS、RT、错误率）
• 日志集中（ELK）
• 告警（Prometheus + Alertmanager）

八、总结：应用服务器高可用 checklist

✅ 无状态
✅ 多实例
✅ 负载均衡高可用
✅ 健康检查
✅ 自动扩缩容
✅ 依赖组件集群化
✅ 限流熔断降级
✅ 监控告警

如果你愿意，我可以：

• 按 Java / Spring Boot 给具体方案
• 按 K8s 场景讲 HA 实现
• 或画一张 高可用架构图

你现在的部署环境是哪种？