面试题答案
一键面试Spring Cloud保障系统高可用性的机制
- 断路器（Circuit Breaker）：
- 原理：断路器监控服务调用的健康状况，当失败率达到一定阈值时，断路器会“跳闸”，后续请求不再实际调用下游服务，而是直接返回一个预设的 fallback 响应。例如在电商系统中调用库存服务，如果库存服务频繁出现故障，断路器跳闸后，订单服务可以直接返回“库存服务暂时不可用，请稍后重试”的提示，避免长时间等待或抛出异常。
- 作用：防止因下游服务故障导致上游服务资源耗尽，快速失败并提供降级策略，保证系统整体的可用性。
- 负载均衡（Load Balancing）：
- 原理：分为客户端负载均衡（如 Ribbon）和服务端负载均衡（如 Nginx）。客户端负载均衡在客户端（如微服务实例）维护一个服务实例列表，通过一定的算法（如轮询、随机等）从列表中选择一个实例进行调用；服务端负载均衡则是由专门的负载均衡服务器（如 Nginx）接收请求，根据配置的策略将请求分发给不同的服务实例。例如在一个多实例的用户服务中，负载均衡器可以将用户登录请求均匀地分配到各个用户服务实例上。
- 作用：均匀分配请求，避免单个服务实例负载过高而导致性能下降或崩溃，提高系统的整体处理能力和可用性。
- 服务注册与发现（Service Registry and Discovery）：
- 原理：微服务启动时向服务注册中心（如 Eureka、Consul 等）注册自己的信息，包括服务名称、IP、端口等。其他微服务通过服务注册中心获取需要调用的服务实例列表。例如在一个复杂的分布式电商系统中，订单服务启动后向 Eureka 注册，支付服务就可以从 Eureka 中发现订单服务的实例信息并进行调用。
- 作用：动态管理服务实例，当有新的服务实例上线或下线时，其他服务能够及时感知，保证服务调用的准确性和可靠性，提高系统的可扩展性和可用性。
机制协同工作提高系统健壮性
以电商下单场景为例，当用户发起下单请求，首先订单服务会通过负载均衡（如 Ribbon）从服务注册中心获取库存服务的可用实例列表，并选择一个实例调用检查库存接口。如果库存服务某个实例出现故障，负载均衡器会将请求发送到其他正常实例。若故障实例过多，断路器监控到库存服务失败率达到阈值，断路器跳闸，订单服务不再调用库存服务实际接口，而是执行 fallback 逻辑，如返回库存检查失败的友好提示。同时，服务注册中心实时监控库存服务实例的健康状况，若某个故障实例恢复，会重新将其纳入可用实例列表供订单服务调用。这样，通过负载均衡、断路器和服务注册与发现的协同工作，保障了电商下单流程在面对部分服务故障时的健壮性。
高并发场景下机制面临的挑战及应对策略
- 断路器：
- 挑战：高并发时可能由于瞬间的大量失败请求导致断路器误跳闸；fallback 逻辑在高并发下可能也承受不住压力。
- 应对策略：可以调整断路器的阈值和检测周期，使其更准确地判断服务健康状况；对 fallback 逻辑进行优化，如采用缓存策略减少处理压力，或者增加 fallback 逻辑的实例数进行水平扩展。
- 负载均衡：
- 挑战：高并发时负载均衡算法可能无法及时适应流量变化，导致部分实例负载过重；网络延迟可能影响负载均衡的准确性。
- 应对策略：采用更智能的负载均衡算法，如基于流量预测、资源利用率等动态调整分配策略；在负载均衡器和服务实例之间增加健康检查机制，及时剔除不健康实例，减少因网络延迟等造成的错误分配。
- 服务注册与发现：
- 挑战：高并发下服务注册中心可能成为性能瓶颈，大量的服务注册、心跳检测等操作可能导致注册中心压力过大；服务实例的频繁上下线可能使注册信息同步不及时。
- 应对策略：对服务注册中心进行集群部署，提高其处理能力；采用异步更新、缓存等机制来优化注册信息的同步，减少因实例频繁变化带来的影响。