设计一个高可用的分布式服务，要求故障时能快速切换，请描述服务注册与发现、负载均衡、熔断降级等机制。
深圳大学中国航天难度：中等
答案
1) 【一句话结论】
设计高可用分布式服务需通过高可用的服务注册中心（主从复制/多数据中心）实现动态服务发现，结合负载均衡算法（加权轮询、一致性哈希）分发请求，并配置熔断降级策略（慢调用次数/错误率阈值/冷却时间），确保故障时快速切换至健康实例，避免级联故障。
2) 【原理/概念讲解】
老师讲解：
- 服务注册与发现：核心是高可用注册中心（如Nacos主从复制、多数据中心同步）。服务启动时注册IP/端口/健康状态，客户端通过发现客户端查询服务列表。类比：企业人事系统，员工入职后登记，其他部门通过系统快速找到。
- 负载均衡：服务发现后，客户端从列表选实例，需先健康检查（如HTTP 200、TCP存活），不健康实例移除。算法如加权轮询（性能高的实例优先）、一致性哈希（有状态请求避免会话丢失）。类比：餐厅服务员按桌位和顾客数量分配顾客，优先分配到空桌或高容量桌。
- 熔断降级：当实例频繁超时（如慢调用次数≥5）或错误率≥50%，熔断器触发“断路”。后续请求直接返回默认值（如“服务不可用”），故障恢复后（冷却时间5秒）“合闸”。类比：电路保险丝，故障时切断电路，避免整个系统过载。
3) 【对比与适用场景】
| 特性 | 服务注册中心高可用方案 | 负载均衡算法 | 熔断降级配置 |
|---|---|---|---|
| 定义 | 注册中心主从复制（如Nacos）、多数据中心同步（如Eureka集群） | 根据实例性能/请求哈希值分发请求 | 故障时降级，正常时恢复 |
| 特性 | 数据持久化（MySQL）、多数据中心同步 | 加权轮询（性能优先）、一致性哈希（有状态） | 慢调用次数（5次）、错误率（50%）、冷却时间（5秒） |
| 使用场景 | 企业级高可用（如Nacos+MySQL）、多地域服务（多数据中心） | 实例性能差异大（加权轮询）、有状态请求（一致性哈希） | 高并发场景（如电商秒杀）、依赖服务故障（如服务A调用B） |
| 注意点 | 避免单点故障（主从同步）、多数据中心延迟（同步时间） | 一致性哈希需预分配实例（避免扩容后会话丢失） | 冷却时间过短导致频繁切换，过长影响恢复速度 |
4) 【示例】
伪代码（故障切换流程）：
- 客户端通过
DiscoveryClient获取“user-service”实例列表（实例1: 192.168.1.1:8081，实例2: 192.168.1.2:8081）。 - 健康检查：实例1 HTTP 200，实例2 TCP存活。
- 负载均衡：加权轮询（实例1性能高，权重2；实例2权重1），选择实例1。
- 实例1超时（慢调用次数达5次），熔断器触发“断路”。
- 客户端请求直接返回“服务不可用”。
- 实例1恢复后（冷却时间5秒），熔断器“合闸”，后续请求正常调用。
5) 【面试口播版答案】
面试官您好，设计高可用分布式服务需围绕服务注册与发现、负载均衡、熔断降级三个核心机制。首先，服务注册中心要高可用，比如用Nacos主从复制+MySQL持久化，服务启动时注册信息，客户端通过发现客户端动态获取服务列表，就像公司的人事系统，确保服务能被快速找到。然后是负载均衡，从服务列表选实例时，先健康检查（如HTTP 200），不健康的移除。用加权轮询（性能高的实例优先），比如实例1性能好就多分配请求，避免单实例过载。接着是熔断降级，当实例频繁超时（如5次），或错误率超过50%，熔断器触发“断路”，后续请求直接返回默认值（如“服务不可用”），防止故障扩散。比如用户登录时，后端服务超时，熔断器直接返回“登录失败”，而不是等待超时，保证前端体验。这样三个机制结合，故障时能快速切换到健康实例，提升系统可用性。
6) 【追问清单】
- 问题1：服务注册中心的高可用部署方案（如Nacos主从复制）如何保证故障时服务仍能发现？
回答要点：主从复制时，主节点故障，从节点自动切换为主，客户端通过发现客户端查询时，能获取到从节点的服务列表，实现故障切换。 - 问题2：熔断降级的慢调用次数和错误率阈值如何根据业务场景调整？
回答要点：电商秒杀场景，慢调用次数设为3次（响应慢即触发），错误率设为30%（允许少量错误）；普通查询场景，慢调用次数设为5次，错误率设为50%，避免误判。 - 问题3：负载均衡算法中实例健康检查的频率和失败后移除策略如何设计？
回答要点：健康检查频率设为1秒（快速检测故障），失败后实例从负载均衡池移除，等待5秒后重新健康检查，避免不健康实例继续接收请求。
7) 【常见坑/雷区】
- 坑1：服务注册中心未做高可用部署（如单节点Nacos），导致注册中心故障时服务发现失效，影响系统可用性。
- 坑2：熔断降级未配置冷却时间，故障恢复后熔断器频繁切换，导致新实例无法接收请求（冷启动问题）。
- 坑3：负载均衡算法未健康检查，直接分配请求到不健康实例，导致请求失败，影响用户体验。
- 坑4：熔断降级与限流混淆，将限流功能放在熔断降级中，导致正常请求被限制，影响业务流量。
- 坑5：一致性哈希未预分配实例，服务扩容时导致会话丢失，影响用户连续性体验。