WEBKT

微服务架构中 on_failure 的深度实践：服务发现、负载均衡与熔断机制的协同容错

4 0 0 0

为什么需要 on_failure？

on_failure 与服务发现

on_failure 与负载均衡

on_failure 与熔断器

总结与最佳实践

你好，我是“码农老兵”。在分布式系统，尤其是微服务架构中，on_failure 机制扮演着至关重要的角色。它不仅仅是一个简单的错误处理回调，更是保障系统稳定性和可用性的关键。今天，咱们就来深入聊聊 on_failure 如何与服务发现、负载均衡、熔断器等组件协同工作，实现服务间的容错和高可用。

为什么需要 on_failure？

在单体应用中，函数调用失败通常会导致整个请求失败。但在微服务架构下，服务间的调用通过网络进行，网络的不稳定性、服务自身的故障、甚至下游服务的延迟都可能导致调用失败。如果不妥善处理这些失败，可能会引发“雪崩效应”，导致整个系统瘫痪。

on_failure 机制提供了一种优雅的方式来处理这些失败。它允许你在服务调用失败时执行自定义的逻辑，例如：

  • 重试（Retry）：对于瞬态错误（如网络抖动），可以尝试重新发起请求。
  • 降级（Fallback）：当某个服务不可用时，可以返回一个默认值或备用结果，保证核心功能可用。
  • 熔断（Circuit Breaker）：当某个服务的失败率达到一定阈值时，可以暂时停止向该服务发送请求，避免进一步的错误。
  • 记录日志和告警：记录详细的错误信息，并触发告警通知，以便及时发现和解决问题。

on_failure 与服务发现

服务发现是微服务架构的基础组件，它负责维护服务实例的注册信息，并提供服务实例的查询功能。常见的服务发现工具有 Consul、Etcd、Zookeeper 等。

在服务发现的场景下，on_failure 可以用于处理以下情况：

  1. 服务实例不可用：当客户端通过服务发现获取到服务实例列表后，在发起请求时可能会遇到服务实例不可用的情况（例如，服务实例刚刚下线，但服务发现组件尚未感知到）。这时，on_failure 可以触发重试机制，尝试连接其他可用的服务实例。

  2. 服务发现组件故障：服务发现组件本身也可能出现故障。这时，客户端可以使用本地缓存的服务实例列表，并在 on_failure 中尝试重新连接服务发现组件。

    		// 伪代码示例：使用本地缓存和 on_failure 处理服务发现组件故障
    		List<ServiceInstance> instances = discoveryClient.getInstances("my-service");
    		 
    		if (instances == null || instances.isEmpty()) {
    		    // 尝试从本地缓存获取服务实例
    		    instances = localCache.getInstances("my-service");
    		 
    		    if (instances == null || instances.isEmpty()) {
    		      // 服务发现和本地缓存都不可用，执行 on_failure 逻辑
    		      onFailure("无法获取服务实例：my-service");
    		      return;
    		    }
    		}
    		 
    		// 使用获取到的服务实例发起请求
    		try {
    		    // ... 发起请求 ...
    		} catch (Exception e) {
    		    // 请求失败，执行 on_failure 逻辑
    		    onFailure(e);
    		}
    		 
    		// on_failure 实现
    		void onFailure(Exception e) {
    		  // 1. 记录错误日志
    		  log.error("服务调用失败：", e);
    		  // 2. 尝试重新连接服务发现组件
    		  discoveryClient.connect();
    		  // 3. 触发告警
    		  alertService.sendAlert("服务调用失败：" + e.getMessage());
    		  // 4. 其他处理逻辑，如降级、熔断等
    		}
    		 void onFailure(String errorMessage){
    		    //重载，处理string类型的错误
    		 }

on_failure 与负载均衡

负载均衡负责将请求分发到多个服务实例上，以实现水平扩展和提高系统的吞吐量。常见的负载均衡算法有轮询、随机、最少连接等。

在负载均衡的场景下，on_failure 可以用于处理以下情况：

  1. 请求失败：当负载均衡器将请求转发到某个服务实例后，该服务实例可能无法正确处理请求（例如，服务实例内部错误、超时等）。这时，on_failure 可以触发重试机制，尝试将请求转发到其他服务实例。

  2. 服务实例摘除：当某个服务实例的健康检查失败或连续多次请求失败时，负载均衡器可以将该服务实例从可用列表中摘除。on_failure 可以用于触发这个摘除操作，并更新负载均衡器的路由规则。

// 伪代码示例：在负载均衡中结合 on_failure 进行重试和实例摘除
LoadBalancer loadBalancer = new RoundRobinLoadBalancer(serviceInstances);
 
for (int i = 0; i < maxRetries; i++) {
    ServiceInstance instance = loadBalancer.choose();
 
    try {
        // 使用选定的实例发起请求
        Response response = makeRequest(instance, request);
        if (response.isSuccess()) {
            // 请求成功，退出循环
            return response;
        }
    } catch (Exception e) {
      //onFailure 逻辑，注意这里传入了实例和异常
        onFailure(instance, e);
    }
}
 
// on_failure 实现
void onFailure(ServiceInstance instance, Exception e) {
    // 1. 记录错误日志
    log.error("服务实例 {} 调用失败：", instance.getAddress(), e);
 
    // 2. 增加失败计数
    failureCounter.increment(instance);
 
    // 3. 判断是否达到摘除阈值
    if (failureCounter.getCount(instance) >= failureThreshold) {
        // 4. 从负载均衡器中摘除该实例
        loadBalancer.removeInstance(instance);
        // 5. 触发告警
        alertService.sendAlert("服务实例已摘除：" + instance.getAddress());
    }
 
    // 6. 其他处理逻辑，如重试其他实例等
}

on_failure 与熔断器

熔断器是一种防止“雪崩效应”的重要机制。当某个服务的失败率或延迟达到一定阈值时，熔断器会进入“打开”状态，阻止对该服务的请求，直接返回错误或执行降级逻辑。经过一段时间后，熔断器会进入“半打开”状态，尝试发送少量请求到该服务，如果请求成功，则关闭熔断器，恢复正常调用；如果请求仍然失败，则继续保持“打开”状态。

on_failure 在熔断器中扮演着核心角色：

  1. 触发熔断：每次服务调用失败时，on_failure 都会被调用。在 on_failure 中，可以更新熔断器的状态（例如，增加失败计数、更新错误率等）。当熔断器的状态满足熔断条件时，就会触发熔断。

  2. 执行降级：当熔断器处于“打开”状态时，所有对该服务的请求都会被拦截。在 on_failure 中，可以执行降级逻辑，例如返回一个默认值、从缓存中读取数据、或者调用备用服务。

// 伪代码示例：使用 Hystrix 实现熔断器和 on_failure
public class MyCommand extends HystrixCommand<String> {
 
    private final String serviceName;
 
    public MyCommand(String serviceName) {
        super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("MyGroup"))
                .andCommandKey(HystrixCommandKey.Factory.asKey("MyCommand"))
                .andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
                        .withCircuitBreakerRequestVolumeThreshold(20)
                        .withCircuitBreakerSleepWindowInMilliseconds(5000)
                        .withCircuitBreakerErrorThresholdPercentage(50)
                ));
        this.serviceName = serviceName;
    }
 
    @Override
    protected String run() throws Exception {
        // 发起对目标服务的请求
        return remoteService.call(serviceName);
    }
 
    @Override
    protected String getFallback() {
        // 熔断器打开时执行的降级逻辑
        // 也可以在这里实现更复杂的 on_failure 逻辑
        return "服务" + serviceName +"不可用，返回默认值";
    }
 
     @Override
    protected void onFailedExecution(HystrixRuntimeException e) {
      //Hystrix提供的onFailedExecution方法
        // 在这里可以进行更细粒度的失败处理，例如：
        // 1. 区分不同类型的异常，采取不同的处理策略
        // 2. 记录更详细的错误信息，包括请求参数、堆栈跟踪等
        // 3. 触发自定义的告警或监控事件
    }
 
}
 
// 调用示例
MyCommand command = new MyCommand("user-service");
String result = command.execute(); // 如果 user-service 不可用，会执行 getFallback() 方法

总结与最佳实践

on_failure 是微服务架构中实现容错和高可用的重要机制。通过与服务发现、负载均衡、熔断器等组件的协同工作，可以有效地处理服务间的调用失败，提高系统的稳定性和可用性。

以下是一些 on_failure 的最佳实践：

  1. 明确失败类型：区分瞬态错误和非瞬态错误。对于瞬态错误（如网络抖动、超时），可以尝试重试；对于非瞬态错误（如参数错误、权限不足），应直接返回错误或执行降级逻辑。

  2. 合理设置重试次数和间隔：避免无限重试导致资源耗尽。重试间隔应逐渐增加，避免对下游服务造成过大的压力。

  3. 实现幂等性：确保重试操作不会产生副作用。对于非幂等操作，应谨慎使用重试机制。

  4. 选择合适的降级策略：根据业务场景选择合适的降级策略。常见的降级策略包括返回默认值、返回空值、返回缓存数据、调用备用服务等。

  5. 监控和告警：记录详细的错误日志，并设置合理的告警规则。及时发现和解决问题，避免故障扩大。

  6. 使用成熟的框架和库：利用现有的框架和库（如 Hystrix、Resilience4j、Sentinel 等）来实现 on_failure 机制，避免重复造轮子，并提高代码的可靠性和可维护性。

  7. 进行充分的测试： 对on_failure逻辑，以及各种失败场景进行充分的测试，确保在真实环境中能够正确处理各种异常情况. 尤其要重视混沌工程的引入.

希望通过今天的分享，你对微服务架构中的on_failure机制有了更深入的理解. 记住, 系统的健壮性不是一蹴而就的, 需要在实践中不断地打磨和优化. 让我们一起构建更稳定、更可靠的分布式系统！

码农老兵 微服务容错高可用

评论点评

打赏赞助
sponsor

感谢您的支持让我们更好的前行

分享

QRcode

https://www.webkt.com/article/8363