微服务如何保高可用

保证微服务架构下的高可用（High Availability, HA），需要从架构设计、部署、容错、监控等多个层面系统性考虑。下面按“常见手段 + 落地建议”来说明。

一、服务冗余与无单点

核心思想：任何组件都不能是单点

• 多实例部署
  • 同一服务至少 2+ 实例
  • 跨可用区 / 跨机房部署
• 无状态服务
  • session 外置（Redis、JWT）
  • 实例可随时被杀掉和重建
• 基础设施冗余
  • 注册中心（Nacos / Eureka / Consul）集群
  • 配置中心、网关集群

✅ 建议：K8s Deployment + 多副本 + Pod 反亲和

二、服务注册与发现

• 服务自动注册、自动下线
• 消费者只依赖“逻辑名”，不依赖 IP
• 配合健康检查（心跳 / 探针）

✅ 常见组合：

• Spring Cloud + Nacos
• K8s Service + CoreDNS

三、负载均衡

• 服务端 LB：Nginx / API Gateway
• 客户端 LB：Ribbon / LoadBalancer
• 策略：轮询、加权、最少连接、一致性哈希

✅ 目标：流量均匀 + 故障节点自动剔除

四、熔断、降级、限流（最核心）

1. 熔断（Circuit Breaker）

• 错误率过高 → 直接失败，不再调用
• 半开状态试探恢复

工具：Sentinel / Hystrix / Resilience4j

2. 降级

• 非核心功能可关闭
• 返回缓存 / 默认值 / 友好提示

3. 限流

• 防止突发流量打垮系统
• 令牌桶 / 漏桶算法
• 维度：QPS、线程数、用户级

✅ 建议：网关层限流 + 服务层熔断

五、超时与重试（要谨慎）

• 必须设置超时（HTTP / RPC / DB）
• 重试只适用于：
  • 幂等操作
  • 短暂故障
• 重试 + 退避（指数退避）

⚠️ 错误示例：

• 无超时 → 线程堆积
• 无幂等 → 重复下单

六、异步与解耦

• 消息队列（Kafka / RocketMQ / RabbitMQ）
• 削峰填谷
• 服务之间不直接强依赖

✅ 典型场景：

• 下单 → 发消息 → 异步扣库存

七、数据库高可用

• 主从复制 + 读写分离
• 分库分表
• 多副本（MySQL MGR / PostgreSQL Streaming）
• 连接池（HikariCP）

⚠️ 数据库往往是最大单点

八、容器化与编排（强烈推荐）

Kubernetes 提供：

• 多副本
• 自动重启
• 健康探针
• 滚动更新
• 自动扩缩容（HPA）

✅ 微服务高可用的事实标准

九、监控、告警、可观测性

没有监控 = 盲飞

• 指标：Prometheus + Grafana
• 日志：ELK / Loki
• 链路：SkyWalking / Zipkin
• 告警：错误率、延迟、CPU、5xx

十、混沌工程（进阶）

• 主动注入故障
• 验证系统是否真的“高可用”
• 工具：Chaos Mesh / Litmus

一句话总结

微服务高可用 = 冗余 + 解耦 + 容错 + 自动化 + 可观测

如果你愿意，我可以：

• 画一张「微服务高可用架构图」
• 针对某一技术栈（Spring Cloud / K8s / Dubbo）给具体方案
• 结合你当前系统做“高可用体检”

你想从哪一块深入？