分布式系统异常架构级设计：根治线上故障的全链路规范与落地实践

前言

在分布式系统中，80%的线上故障排查时间，都浪费在异常信息缺失、错误码混乱、异常静默吞噬、跨服务链路信息丢失等问题上。很多开发者对异常的理解仍停留在try-catch的语法层面，却忽略了分布式场景下，异常处理是一套覆盖全链路、贯穿架构全分层的体系化设计。

本文基于Java 21 LTS、Spring Boot 3.4.2、Spring Cloud 2024.0.0等最新稳定技术栈，从底层逻辑到落地实践，完整讲解分布式系统异常体系的架构级设计。

一、分布式系统异常的本质挑战与核心认知

1.1 分布式与单体系统异常的核心差异

单体系统的异常处理是单进程内的闭环，异常堆栈完整、调用链路清晰；而分布式系统的异常具备跨进程、跨网络、多节点、异步化四大核心特征，带来了单体系统不存在的核心挑战：

• 异常链路断裂：跨服务调用时，异常堆栈、链路追踪信息极易丢失
• 异常语义不一致：不同服务的错误码、异常格式不统一，上下游无法正常解析
• 异常传播失控：单个节点的异常会通过RPC、MQ等链路扩散，引发级联故障
• 异常场景复杂化：网络抖动、超时、限流、熔断、数据一致性等分布式特有异常场景

1.2 异常核心概念的权威界定（易混淆点明确区分）

基于《Java Language Specification, Java SE 21 Edition》第11章与《Effective Java 第3版》的权威定义，我们先明确所有开发者必须厘清的核心概念，杜绝概念混用：

1.3 架构级异常设计的核心原则

所有分布式异常体系的设计，都必须严格遵循以下6个核心原则，这是保证体系健壮性的底层逻辑：

1. 异常不可逃逸原则：异常必须被明确处理，严禁静默吞噬（catch后不记录、不抛出），所有未处理的异常必须有兜底机制
2. 职责单一原则：业务异常与系统异常严格分离，每层仅处理本层职责内的异常，非本层异常必须原封不动向上抛出
3. 全链路可追溯原则：所有异常必须携带全链路追踪ID（traceId），跨服务、跨线程场景下必须保证traceId不丢失
4. 最小必要原则：异常信息仅包含排查问题所需的最小内容，严禁泄露数据库地址、账号密码等敏感信息，严禁将完整堆栈返回给前端
5. 快速失败原则：异常必须在最早的合适节点抛出，避免无效的逻辑执行，减少系统资源消耗
6. 异常隔离原则：通过熔断、降级、舱壁模式，限制异常的传播范围，避免单个节点的异常拖垮整个分布式链路

二、分布式异常体系的分层架构设计

分布式系统的异常处理必须按架构分层明确职责边界，严禁越权处理，否则会导致异常逻辑混乱、链路断裂。我们采用经典的四层分布式架构，明确每层的异常处理职责，架构图如下：

2.1 接入层（网关）异常处理职责

接入层是分布式系统的流量入口，核心职责是拦截入口异常、统一协议格式、避免无效流量转发，仅处理以下场景的异常：

• 路由异常：服务不存在、域名解析失败、服务实例不可用
• 流量管控异常：限流、熔断、降级、黑白名单拦截
• 鉴权异常：token失效、签名校验失败、权限不足
• 协议转换异常：HTTP/HTTPS协议转换、请求体格式解析失败

网关层严禁处理业务逻辑异常，所有转发到后端服务后的异常，仅做格式统一封装，不做逻辑修改。

2.2 业务服务层异常处理职责

业务服务层是分布式系统的核心，核心职责是业务异常的定义与管控、跨服务异常的解析与传递、异步异常的兜底，是异常体系的核心管控层：

• 定义本服务的业务异常与错误码，处理业务逻辑中的预期内异常
• 解析下游服务返回的异常，转换为当前服务可识别的异常类型，保证链路语义一致
• 处理RPC、HTTP等跨服务调用的超时、重试、熔断异常
• 统一处理异步方法、线程池、MQ消费等场景的异步异常
• 提供全局异常兜底机制，将所有异常转换为统一格式的响应体

2.3 数据访问层异常处理职责

数据访问层的核心职责是数据操作异常的转换与封装，屏蔽底层存储的差异，遵循《Effective Java》第73条"抛出与抽象相对应的异常"原则：

• 将数据库、缓存、MQ等底层存储的原生异常，转换为上层可识别的系统异常
• 严禁将底层存储的原生异常直接向上抛出，避免上层与底层存储技术耦合
• 处理数据操作的超时、重试、幂等性相关异常
• 记录数据操作异常的完整上下文（如SQL语句、缓存key、消息ID），便于排查问题

2.4 基础设施层异常处理职责

基础设施层是分布式异常体系的支撑层，核心职责是全链路异常的可观测性与闭环管控，不处理具体的业务或系统异常，而是提供全链路的异常管控能力：

• 全链路追踪：通过traceId串联整个分布式链路的异常信息
• 日志收敛：统一异常日志的格式与输出规范，保证异常信息完整可查
• 监控告警：异常指标的采集、统计与告警，实现异常的提前发现
• 熔断隔离：提供熔断、降级、舱壁等能力，限制异常的传播范围

三、分布式异常体系核心规范与落地实现

3.1 自定义异常层级设计规范

自定义异常是分布式异常体系的核心，必须设计清晰的层级结构，保证语义明确、职责单一，严禁一个异常类用于多个场景。

3.1.1 异常层级结构设计

我们采用三层异常结构，所有异常均继承自非受检异常RuntimeException，符合分布式系统快速失败的原则：

1. 基类异常BaseException ：所有自定义异常的父类，定义通用属性与方法
2. 业务异常BusinessException ：用于处理业务逻辑层面的预期内异常
3. 系统异常SystemException ：用于处理系统底层的预期外异常

3.1.2 完整的异常类实现

基于Java 21 LTS实现，保证Jackson序列化与反序列化正常：

package com.distributed.exception.core;

import lombok.Getter;

/**
* 分布式系统自定义异常基类
* 所有自定义异常必须继承此类，保证全链路异常属性统一
* 符合Java序列化规范，支持跨服务传输
*/
@Getter
public class BaseException extends RuntimeException {
   /**
    * 全链路追踪ID
    */
   private final String traceId;
   /**
    * 错误码
    */
   private final String errorCode;
   /**
    * 面向开发人员的错误详情，用于问题排查
    */
   private final String devMessage;
   /**
    * 面向用户的友好提示，用于前端展示
    */
   private final String userMessage;

   /**
    * 必须保留无参构造函数，否则Jackson反序列化会失败
    */
   public BaseException() {
       this.traceId = "";
       this.errorCode = "";
       this.devMessage = "";
       this.userMessage = "系统异常，请稍后重试";
   }

   /**
    * 全参构造函数，用于子类初始化
    */
   public BaseException(String traceId, String errorCode, String devMessage, String userMessage, Throwable cause) {
       super(devMessage, cause);
       this.traceId = traceId;
       this.errorCode = errorCode;
       this.devMessage = devMessage;
       this.userMessage = userMessage;
   }
}


package com.distributed.exception.core;

import com.distributed.trace.TraceContext;
import lombok.Getter;

/**
* 业务异常
* 适用场景：用户操作导致的预期内异常，如参数校验失败、库存不足、权限不足等
* 日志级别：WARN，不触发熔断，无需人工紧急介入
*/
@Getter
public class BusinessException extends BaseException {
   /**
    * 最简构造函数，仅传入错误码与用户提示
    * traceId自动从全链路上下文获取
    */
   public BusinessException(String errorCode, String userMessage) {
       this(errorCode, userMessage, userMessage);
   }

   /**
    * 标准构造函数，区分开发提示与用户提示
    */
   public BusinessException(String errorCode, String userMessage, String devMessage) {
       super(TraceContext.getTraceId(), errorCode, devMessage, userMessage, null);
   }

   /**
    * 带异常根源的构造函数，用于包装业务场景中的原生异常
    */
   public BusinessException(String errorCode, String userMessage, String devMessage, Throwable cause) {
       super(TraceContext.getTraceId(), errorCode, devMessage, userMessage, cause);
   }
}


package com.distributed.exception.core;

import com.distributed.trace.TraceContext;
import lombok.Getter;

/**
* 系统异常
* 适用场景：系统底层的预期外异常，如数据库连接失败、RPC调用超时、缓存宕机等
* 日志级别：ERROR，触发熔断，必须人工介入
*/
@Getter
public class SystemException extends BaseException {
   /**
    * 标准构造函数，系统异常用户提示固定为友好提示，避免泄露系统细节
    */
   public SystemException(String errorCode, String devMessage) {
       super(TraceContext.getTraceId(), errorCode, devMessage, "系统繁忙，请稍后重试", null);
   }

   /**
    * 带异常根源的构造函数，用于包装底层原生异常
    */
   public SystemException(String errorCode, String devMessage, Throwable cause) {
       super(TraceContext.getTraceId(), errorCode, devMessage, "系统繁忙，请稍后重试", cause);
   }
}


3.1.3 关键设计说明

1. 序列化兼容：所有异常类必须保留无参构造函数，且所有属性提供getter方法，保证Jackson序列化与反序列化正常，避免跨服务传输时异常信息丢失
2. traceId自动注入：通过全链路上下文自动注入traceId，无需开发人员手动传入，避免人为遗漏
3. 双消息设计：区分userMessage与devMessage，用户提示友好无敏感信息，开发提示精准包含排查所需的完整信息
4. 异常根源保留：所有构造函数均支持传入Throwable cause，保留原始异常堆栈，避免堆栈断裂

3.2 错误码设计规范

错误码是分布式系统中异常语义传递的核心，混乱的错误码会导致上下游服务无法正常解析异常，是线上故障的重灾区。我们采用分段式、语义化、可扩展的错误码设计规范，完全兼容HTTP状态码语义，便于网关、前端统一处理。

3.2.1 错误码结构设计

采用10位数字字符串的分段式设计，结构如下：

[3位服务标识][2位模块标识][5位错误编码]


• 服务标识：3位数字，唯一标识分布式系统中的每个服务，如网关001、用户服务002、订单服务003
• 模块标识：2位数字，唯一标识服务内的每个业务模块，如用户模块01、订单模块02、支付模块03
• 错误编码：5位数字，唯一标识具体的错误类型，前2位标识错误大类，后3位标识具体错误

3.2.2 错误码大类分段规范

严格对齐HTTP状态码语义，保证全链路语义一致，分段如下：

3.2.3 错误码示例与管理规范

• 示例1：订单服务（003）订单模块（02）参数校验失败（40001），完整错误码：0030240001
• 示例2：用户服务（002）用户模块（01）数据库连接失败（50001），完整错误码：0020150001

管理规范：

1. 错误码必须统一管理，通过配置中心或字典表维护，严禁开发人员随意新增
2. 每个错误码必须对应唯一的错误含义，严禁一个错误码多个场景使用
3. 错误码必须配套完整的文档，说明错误场景、排查方案、处理建议
4. 业务异常与系统异常的错误码必须严格分段，严禁混用

3.3 统一响应体设计规范

分布式系统中，所有服务的响应体必须格式统一，保证前端、网关、上下游服务能统一解析，避免格式混乱导致的异常解析失败。

3.3.1 统一响应体实现

package com.distributed.exception.core;

import lombok.Getter;

import java.io.Serializable;

/**
* 分布式系统统一响应体
* 所有服务的HTTP、RPC响应必须使用此格式，保证全链路格式统一
*/
@Getter
public class Result<T> implements Serializable {
   /**
    * 全链路追踪ID
    */
   private final String traceId;
   /**
    * 响应码，200为成功，其余为失败
    */
   private final String code;
   /**
    * 响应消息，成功为"success"，失败为用户友好提示
    */
   private final String message;
   /**
    * 响应数据，成功时返回，失败时为null
    */
   private final T data;
   /**
    * 请求是否成功
    */
   private final boolean success;

   /**
    * 私有构造函数，禁止外部直接实例化，通过静态方法创建
    */
   private Result(String traceId, String code, String message, T data, boolean success) {
       this.traceId = traceId;
       this.code = code;
       this.message = message;
       this.data = data;
       this.success = success;
   }

   /**
    * 成功响应，无返回数据
    */
   public static <T> Result<T> success() {
       return new Result<>(TraceContext.getTraceId(), "200", "success", null, true);
   }

   /**
    * 成功响应，带返回数据
    */
   public static <T> Result<T> success(T data) {
       return new Result<>(TraceContext.getTraceId(), "200", "success", data, true);
   }

   /**
    * 失败响应，基于业务异常创建
    */
   public static <T> Result<T> failure(BusinessException e) {
       return new Result<>(e.getTraceId(), e.getErrorCode(), e.getUserMessage(), null, false);
   }

   /**
    * 失败响应，基于系统异常创建
    */
   public static <T> Result<T> failure(SystemException e) {
       return new Result<>(e.getTraceId(), e.getErrorCode(), e.getUserMessage(), null, false);
   }

   /**
    * 通用失败响应，用于兜底处理
    */
   public static <T> Result<T> failure(String traceId, String code, String message) {
       return new Result<>(traceId, code, message, null, false);
   }
}


3.3.2 关键设计说明

1. 全链路traceId携带：所有响应均携带traceId，前端可通过traceId快速反馈问题，运维可通过traceId快速定位全链路日志
2. 严格的构造函数封装：禁止外部直接实例化，仅通过静态方法创建，保证响应格式的一致性
3. success标识：提供布尔类型的成功标识，便于前端快速判断请求结果，无需解析code字段
4. 序列化兼容：实现Serializable接口，保证跨服务传输时的序列化兼容性

3.4 全局异常处理器设计规范

全局异常处理器是业务服务层异常兜底的核心，基于Spring Boot 3的@RestControllerAdvice实现，统一拦截所有Controller层抛出的异常，转换为统一响应体，同时完成异常日志的记录。

3.4.1 完整可运行的全局异常处理器实现

基于Spring Boot 3.4.2实现，使用jakarta.servlet规范，兼容Spring MVC 6.x，无编译错误：

package com.distributed.exception.handler;

import com.distributed.exception.core.BaseException;
import com.distributed.exception.core.BusinessException;
import com.distributed.exception.core.Result;
import com.distributed.exception.core.SystemException;
import com.distributed.trace.TraceContext;
import jakarta.servlet.http.HttpServletRequest;
import lombok.extern.slf4j.Slf4j;
import org.springframework.http.HttpStatus;
import org.springframework.validation.BindException;
import org.springframework.validation.FieldError;
import org.springframework.web.bind.MethodArgumentNotValidException;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.ResponseStatus;
import org.springframework.web.bind.annotation.RestControllerAdvice;
import org.springframework.web.servlet.resource.NoResourceFoundException;

import java.util.stream.Collectors;

/**
* 全局异常处理器
* 按异常类型优先级从高到低处理，保证所有异常都有兜底机制
* 符合Spring官方异常处理规范
*/
@Slf4j
@RestControllerAdvice
public class GlobalExceptionHandler {

   /**
    * 处理自定义业务异常
    * 优先级最高，处理业务逻辑抛出的预期内异常
    */
   @ExceptionHandler(BusinessException.class)
   @ResponseStatus(HttpStatus.OK)
   public Result<Void> handleBusinessException(BusinessException e, HttpServletRequest request) {
       // 业务异常打印WARN级别日志，包含请求路径、错误码、开发提示，不打印堆栈（预期内异常）
       log.warn("业务异常 | 请求路径:{} | 错误码:{} | 错误详情:{}",
               request.getRequestURI(), e.getErrorCode(), e.getDevMessage());
       return Result.failure(e);
   }

   /**
    * 处理自定义系统异常
    * 优先级次高，处理系统底层抛出的预期外异常
    */
   @ExceptionHandler(SystemException.class)
   @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
   public Result<Void> handleSystemException(SystemException e, HttpServletRequest request) {
       // 系统异常打印ERROR级别日志，包含完整堆栈，用于问题排查
       log.error("系统异常 | 请求路径:{} | 错误码:{} | 错误详情:{}",
               request.getRequestURI(), e.getErrorCode(), e.getDevMessage(), e);
       return Result.failure(e);
   }

   /**
    * 处理参数校验异常
    * 处理@Valid注解触发的请求参数校验失败异常
    */
   @ExceptionHandler(MethodArgumentNotValidException.class)
   @ResponseStatus(HttpStatus.BAD_REQUEST)
   public Result<Void> handleMethodArgumentNotValidException(MethodArgumentNotValidException e, HttpServletRequest request) {
       String errorMessage = e.getBindingResult().getFieldErrors().stream()
               .map(fieldError -> fieldError.getField() + ":" + fieldError.getDefaultMessage())
               .collect(Collectors.joining(";"));
       log.warn("参数校验异常 | 请求路径:{} | 错误详情:{}", request.getRequestURI(), errorMessage);
       return Result.failure(TraceContext.getTraceId(), "4000000001", errorMessage);
   }

   /**
    * 处理参数绑定异常
    * 处理GET请求参数绑定失败异常
    */
   @ExceptionHandler(BindException.class)
   @ResponseStatus(HttpStatus.BAD_REQUEST)
   public Result<Void> handleBindException(BindException e, HttpServletRequest request) {
       String errorMessage = e.getFieldErrors().stream()
               .map(FieldError::getDefaultMessage)
               .collect(Collectors.joining(";"));
       log.warn("参数绑定异常 | 请求路径:{} | 错误详情:{}", request.getRequestURI(), errorMessage);
       return Result.failure(TraceContext.getTraceId(), "4000000002", errorMessage);
   }

   /**
    * 处理资源不存在异常
    * 处理请求路径不存在的异常
    */
   @ExceptionHandler(NoResourceFoundException.class)
   @ResponseStatus(HttpStatus.NOT_FOUND)
   public Result<Void> handleNoResourceFoundException(NoResourceFoundException e, HttpServletRequest request) {
       log.warn("资源不存在异常 | 请求路径:{}", request.getRequestURI());
       return Result.failure(TraceContext.getTraceId(), "4040000001", "请求的资源不存在");
   }

   /**
    * 兜底异常处理
    * 处理所有未被上述处理器拦截的异常，保证所有异常都有统一响应
    */
   @ExceptionHandler(Throwable.class)
   @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
   public Result<Void> handleThrowable(Throwable e, HttpServletRequest request) {
       log.error("未捕获的系统异常 | 请求路径:{}", request.getRequestURI(), e);
       return Result.failure(TraceContext.getTraceId(), "5000000000", "系统繁忙，请稍后重试");
   }
}


3.4.2 关键设计说明

1. 优先级设计：按异常类型的具体程度从高到低处理，先处理自定义异常，再处理Spring内置异常，最后用Throwable兜底，保证所有异常都有处理逻辑
2. 日志分级规范：业务异常打印WARN级别日志，不打印堆栈（预期内异常，无排查必要）；系统异常打印ERROR级别日志，包含完整堆栈（预期外异常，需要排查），避免日志冗余与告警轰炸
3. HTTP状态码对齐：异常处理的HTTP状态码与错误码语义对齐，便于网关、CDN、前端统一处理
4. 敏感信息保护：兜底异常处理仅返回友好提示，不泄露任何系统细节，避免安全漏洞

3.5 跨服务异常传输规范

分布式系统中，跨服务调用的异常处理是最大的痛点之一，默认的Feign异常处理仅返回状态码，会丢失完整的异常信息、错误码、traceId，导致上游服务无法正常解析下游异常，链路断裂。

我们基于Spring Cloud OpenFeign 4.x实现自定义异常解码器，将下游服务返回的统一响应体，反序列化为上游服务的自定义异常，保证跨服务异常的语义与信息完整传递。

3.5.1 完整的Feign异常解码器实现

package com.distributed.exception.feign;

import com.distributed.exception.core.BusinessException;
import com.distributed.exception.core.Result;
import com.distributed.exception.core.SystemException;
import com.fasterxml.jackson.core.type.TypeReference;
import com.fasterxml.jackson.databind.ObjectMapper;
import feign.Response;
import feign.codec.ErrorDecoder;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.http.HttpStatus;

import java.io.IOException;
import java.io.InputStream;

/**
* Feign自定义异常解码器
* 解析下游服务返回的异常信息，转换为上游服务可识别的自定义异常
* 保证跨服务异常信息完整传递，避免异常丢失
*/
@Slf4j
@RequiredArgsConstructor
public class FeignExceptionDecoder implements ErrorDecoder {
   private final ObjectMapper objectMapper;
   private final ErrorDecoder defaultDecoder = new Default();

   @Override
   public Exception decode(String methodKey, Response response) {
       // 读取响应体，避免流关闭导致无法重复读取
       try (InputStream inputStream = response.body().asInputStream()) {
           // 将响应体反序列化为统一响应体
           Result<Void> result = objectMapper.readValue(inputStream, new TypeReference<Result<Void>>() {});
           // 响应体解析成功，按错误码前缀区分异常类型
           String errorCode = result.getCode();
           if (errorCode.startsWith("400")) {
               // 400开头为业务异常，直接抛出
               return new BusinessException(errorCode, result.getMessage(), result.getMessage());
           } else if (errorCode.startsWith("500")) {
               // 500开头为系统异常，记录日志后抛出
               log.error("Feign调用下游服务异常 | 方法:{} | 错误码:{} | 错误详情:{}",
                       methodKey, errorCode, result.getMessage());
               return new SystemException(errorCode, "下游服务调用异常:" + result.getMessage());
           }
       } catch (IOException e) {
           // 响应体解析失败，使用默认解码器处理
           log.warn("Feign异常响应解析失败，使用默认解码器 | 方法:{} | 状态码:{}", methodKey, response.status());
       }

       // 非业务异常，使用默认解码器处理
       return defaultDecoder.decode(methodKey, response);
   }
}


3.5.2 Feign配置类实现

将自定义异常解码器注入Spring容器，生效于所有Feign客户端：

package com.distributed.exception.config;

import com.distributed.exception.feign.FeignExceptionDecoder;
import com.fasterxml.jackson.databind.ObjectMapper;
import feign.codec.ErrorDecoder;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class FeignExceptionConfig {

   @Bean
   public ErrorDecoder feignExceptionDecoder(ObjectMapper objectMapper) {
       return new FeignExceptionDecoder(objectMapper);
   }
}


3.5.3 关键设计说明

1. 异常语义完整传递：将下游服务的错误码、错误信息完整转换为上游服务的自定义异常，保证跨服务异常语义一致
2. 异常类型区分：按错误码前缀区分业务异常与系统异常，上游服务可针对性处理，避免业务异常触发熔断
3. 兜底机制：响应体解析失败时，降级使用Feign默认解码器，保证异常不会丢失
4. 流资源安全：使用try-with-resources语法处理响应体输入流，保证流资源正常关闭，避免内存泄漏

3.6 全链路traceId传递规范

全链路traceId是分布式系统异常排查的核心，必须保证traceId在跨服务、跨线程场景下全程不丢失，串联整个调用链路。我们基于Spring Boot 3推荐的Micrometer Tracing 1.4.x实现全链路追踪，兼容OpenTelemetry规范，是Spring Cloud Sleuth停更后的官方替代方案。

3.6.1 全链路上下文工具类实现

package com.distributed.trace;

import io.micrometer.tracing.Tracer;
import org.springframework.stereotype.Component;

/**
* 全链路追踪上下文工具类
* 封装Micrometer Tracing能力，提供traceId的获取与传递能力
*/
@Component
public class TraceContext {
   private static Tracer staticTracer;

   public TraceContext(Tracer tracer) {
       TraceContext.staticTracer = tracer;
   }

   /**
    * 获取当前链路的traceId
    * 无链路时返回空字符串，避免空指针
    */
   public static String getTraceId() {
       if (staticTracer == null || staticTracer.currentSpan() == null) {
           return "";
       }
       return staticTracer.currentSpan().context().traceId();
   }

   /**
    * 获取当前链路的spanId
    */
   public static String getSpanId() {
       if (staticTracer == null || staticTracer.currentSpan() == null) {
           return "";
       }
       return staticTracer.currentSpan().context().spanId();
   }
}


3.6.2 依赖配置

pom.xml中引入最新稳定版依赖，兼容Spring Boot 3.4.2：

<!-- Micrometer Tracing全链路追踪核心依赖 -->
<dependency>
   <groupId>io.micrometer</groupId>
   <artifactId>micrometer-tracing</artifactId>
   <version>1.4.2</version>
</dependency>
<!-- 桥接SLF4J MDC，自动将traceId注入日志上下文 -->
<dependency>
   <groupId>io.micrometer</groupId>
   <artifactId>micrometer-tracing-bridge-brave</artifactId>
   <version>1.4.2</version>
</dependency>
<!-- OpenTelemetry兼容依赖 -->
<dependency>
   <groupId>io.opentelemetry</groupId>
   <artifactId>opentelemetry-api</artifactId>
   <version>1.40.0</version>
</dependency>


3.6.3 日志格式配置

application.yml中配置日志格式，自动打印traceId与spanId：

logging:
 pattern:
   console: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level [%X{traceId:-},%X{spanId:-}] %logger{50} - %msg%n"
   file: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level [%X{traceId:-},%X{spanId:-}] %logger{50} - %msg%n"


3.6.4 关键设计说明

1. 自动跨服务传递：Micrometer Tracing会自动将traceId注入HTTP请求头，Feign、RestTemplate等HTTP客户端会自动传递，无需开发人员手动处理
2. MDC自动注入：traceId与spanId会自动注入SLF4J的MDC上下文，日志中无需手动拼接，保证所有日志都携带traceId
3. 空指针安全：无链路上下文时，返回空字符串，避免业务代码出现空指针异常
4. 兼容行业标准：兼容OpenTelemetry与Zipkin规范，可无缝对接主流的全链路追踪系统

3.7 异步场景异常处理规范

分布式系统中，异步场景（@Async异步方法、线程池任务、MQ消息消费）的异常最容易被静默吞噬，因为异步线程的异常无法被主线程的全局异常处理器捕获，是线上问题排查的重灾区。我们针对不同异步场景，提供完整的异常处理方案，保证异步异常不丢失、可追溯。

3.7.1 @Async异步方法异常处理

Spring Boot 3中，@Async异步方法的异常必须配置自定义异常处理器，否则异常会直接抛出到JVM的UncaughtExceptionHandler，导致异常丢失。

完整配置实现：

package com.distributed.exception.config;

import com.distributed.trace.TraceContext;
import lombok.extern.slf4j.Slf4j;
import org.springframework.aop.interceptor.AsyncUncaughtExceptionHandler;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.scheduling.annotation.AsyncConfigurer;
import org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor;

import java.util.concurrent.Executor;
import java.util.concurrent.ThreadPoolExecutor;

/**
* 异步线程池配置，包含异步异常处理
* 保证@Async异步方法的异常不丢失，traceId可追溯
*/
@Slf4j
@Configuration
public class AsyncExecutorConfig implements AsyncConfigurer {

   @Bean(name = "asyncExecutor")
   @Override
   public Executor getAsyncExecutor() {
       ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
       // 核心线程数
       executor.setCorePoolSize(10);
       // 最大线程数
       executor.setMaxPoolSize(50);
       // 队列容量
       executor.setQueueCapacity(1000);
       // 线程空闲时间
       executor.setKeepAliveSeconds(60);
       // 线程名称前缀
       executor.setThreadNamePrefix("async-");
       // 拒绝策略：调用方线程执行，避免任务丢失
       executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
       // 等待任务完成后关闭线程池
       executor.setWaitForTasksToCompleteOnShutdown(true);
       // 等待任务完成的超时时间
       executor.setAwaitTerminationSeconds(60);
       // 初始化线程池
       executor.initialize();
       return executor;
   }

   /**
    * 异步方法未捕获异常处理器
    * 处理@Async异步方法中未捕获的异常，保证异常不丢失
    */
   @Override
   public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() {
       return (ex, method, params) -> {
           log.error("异步方法执行异常 | 方法:{} | traceId:{} | 异常详情:",
                   method.getName(), TraceContext.getTraceId(), ex);
       };
   }
}


3.7.2 通用线程池异常处理

对于手动创建的线程池，必须配置UncaughtExceptionHandler，保证子线程的异常不丢失，同时实现traceId的跨线程传递。

完整线程池工厂实现：

package com.distributed.thread;

import com.distributed.trace.TraceContext;
import lombok.extern.slf4j.Slf4j;

import java.util.concurrent.ThreadFactory;
import java.util.concurrent.atomic.AtomicInteger;

/**
* 自定义线程工厂，配置异常处理器与traceId传递
* 保证线程池中的任务异常不丢失，全链路可追溯
*/
@Slf4j
public class TraceableThreadFactory implements ThreadFactory {
   private final String threadNamePrefix;
   private final AtomicInteger threadNumber = new AtomicInteger(1);
   private final Thread.UncaughtExceptionHandler exceptionHandler;

   public TraceableThreadFactory(String threadNamePrefix) {
       this.threadNamePrefix = threadNamePrefix;
       // 配置默认异常处理器，记录异常日志与traceId
       this.exceptionHandler = (t, e) -> {
           log.error("线程执行异常 | 线程名:{} | traceId:{} | 异常详情:",
                   t.getName(), TraceContext.getTraceId(), e);
       };
   }

   public TraceableThreadFactory(String threadNamePrefix, Thread.UncaughtExceptionHandler exceptionHandler) {
       this.threadNamePrefix = threadNamePrefix;
       this.exceptionHandler = exceptionHandler;
   }

   @Override
   public Thread newThread(Runnable r) {
       // 包装任务，传递traceId
       Runnable traceableTask = wrapTaskWithTrace(r);
       // 创建线程，配置名称、异常处理器
       Thread thread = new Thread(traceableTask, threadNamePrefix + "-" + threadNumber.getAndIncrement());
       thread.setUncaughtExceptionHandler(exceptionHandler);
       thread.setDaemon(false);
       return thread;
   }

   /**
    * 包装任务，传递traceId到子线程
    */
   private Runnable wrapTaskWithTrace(Runnable task) {
       // 获取主线程的traceId
       String traceId = TraceContext.getTraceId();
       return () -> {
           try {
               // 子线程中设置traceId
               if (traceId != null && !traceId.isEmpty()) {
                   org.slf4j.MDC.put("traceId", traceId);
               }
               // 执行原任务
               task.run();
           } finally {
               // 任务执行完成后清除MDC，避免线程复用导致的traceId混乱
               org.slf4j.MDC.clear();
           }
       };
   }
}


3.7.3 关键设计说明

1. 异常兜底机制：所有异步场景都配置了专用的异常处理器，保证异常不会被静默吞噬，所有异常都会被记录日志
2. traceId跨线程传递：通过包装任务，将主线程的traceId传递到子线程，保证异步任务的日志也携带traceId，全链路可追溯
3. MDC上下文清理：任务执行完成后清除MDC上下文，避免线程池线程复用导致的traceId混乱
4. 拒绝策略安全：线程池的拒绝策略采用CallerRunsPolicy，避免任务丢失，同时起到限流作用

3.8 熔断降级与异常隔离规范

分布式系统中，必须通过熔断降级限制异常的传播范围，避免单个服务的异常拖垮整个链路。我们采用Spring Boot 3官方推荐的Resilience4j 2.2.x实现熔断降级，替代已停更的Hystrix，重点解决业务异常误触发熔断的行业痛点。

3.8.1 核心配置实现

pom.xml依赖引入：

<!-- Resilience4j熔断降级核心依赖 -->
<dependency>
   <groupId>io.github.resilience4j</groupId>
   <artifactId>resilience4j-spring-boot3</artifactId>
   <version>2.2.0</version>
</dependency>
<dependency>
   <groupId>io.github.resilience4j</groupId>
   <artifactId>resilience4j-circuitbreaker</artifactId>
   <version>2.2.0</version>
</dependency>


application.yml配置：

resilience4j:
 circuitbreaker:
   configs:
     default:
       # 滑动窗口大小
       slidingWindowSize: 100
       # 滑动窗口类型：COUNT_BASED(计数)
       slidingWindowType: COUNT_BASED
       # 熔断触发的失败率阈值
       failureRateThreshold: 50
       # 最小调用次数
       minimumNumberOfCalls: 10
       # 熔断打开后，等待进入半开状态的时间
       waitDurationInOpenState: 10000
       # 半开状态下允许的调用次数
       permittedNumberOfCallsInHalfOpenState: 10
       # 自定义异常判定器，仅系统异常算失败，业务异常不算
       recordExceptionPredicate: com.distributed.resilience4j.Resilience4jExceptionPredicate
   instances:
     # 订单服务熔断配置
     order-service:
       base-config: default


自定义异常判定器实现：

package com.distributed.resilience4j;

import com.distributed.exception.core.BusinessException;

import java.util.function.Predicate;

/**
* Resilience4j自定义异常判定器
* 核心逻辑：仅系统异常算熔断失败次数，业务异常不算
* 避免正常的业务校验触发熔断，解决行业通用痛点
*/
public class Resilience4jExceptionPredicate implements Predicate<Throwable> {
   @Override
   public boolean test(Throwable throwable) {
       // 业务异常不算失败，不触发熔断
       if (throwable instanceof BusinessException) {
           return false;
       }
       // 系统异常、其他异常算失败，触发熔断
       return true;
   }
}


3.8.2 业务使用示例

package com.distributed.service;

import com.distributed.exception.core.BusinessException;
import io.github.resilience4j.circuitbreaker.annotation.CircuitBreaker;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Service;

@Slf4j
@Service
@RequiredArgsConstructor
public class OrderService {
   private final ProductFeignClient productFeignClient;

   /**
    * 订单创建方法，配置熔断降级
    */
   @CircuitBreaker(name = "order-service", fallbackMethod = "createOrderFallback")
   public String createOrder(Long productId, Integer num) {
       // 1. 业务参数校验，抛出业务异常，不会触发熔断
       if (num <= 0) {
           throw new BusinessException("0030240001", "购买数量必须大于0");
       }
       // 2. 调用下游商品服务，系统异常会触发熔断
       Result<ProductDTO> productResult = productFeignClient.getProductById(productId);
       if (!productResult.isSuccess()) {
           throw new BusinessException("0030240002", "商品不存在");
       }
       // 3. 订单创建逻辑
       return "订单创建成功";
   }

   /**
    * 熔断降级方法，熔断触发时执行
    */
   public String createOrderFallback(Long productId, Integer num, Throwable e) {
       log.warn("订单服务触发熔断降级 | productId:{} | 异常详情:{}", productId, e.getMessage());
       return "系统繁忙，请稍后重试";
   }
}


3.8.3 关键设计说明

1. 异常类型精准区分：通过自定义异常判定器，仅系统异常会被计入熔断失败次数，业务异常不会触发熔断，解决了行业内普遍存在的业务校验误触发熔断的痛点
2. 降级兜底机制：每个熔断方法都配置了fallback降级方法，保证熔断触发时服务仍能返回友好响应，而不是直接抛出异常
3. 配置复用：通过base-config实现默认配置复用，不同服务可基于默认配置自定义参数，避免配置冗余
4. 符合Spring官方规范：基于Spring Boot 3的注解式配置，无需硬编码，接入成本低

四、全链路异常处理流程

我们通过流程图完整展示分布式系统从请求进入到响应返回的全链路异常处理流程，确保每个环节的异常都有对应的处理逻辑，无遗漏、无逃逸：

五、分布式异常处理避坑指南（高频错误总结）

5.1 异常静默吞噬

错误场景：catch异常后不记录日志、不向上抛出，直接返回null或空对象，导致异常完全丢失，线上问题无法排查。正确规范：

• 严禁catch异常后不做任何处理，除非是明确需要忽略的场景，且必须添加注释说明
• 如果不需要重新抛出异常，必须记录ERROR级别日志，包含完整堆栈
• 如果需要向上抛出异常，必须保留原始异常根源，避免堆栈断裂

5.2 异常过度捕获

错误场景：大段代码用try-catch Throwable包裹，导致正常的业务异常、系统异常被捕获，无法触发熔断、全局异常处理器等兜底机制。正确规范：

• 只捕获需要处理的具体异常类型，严禁直接捕获Throwable或Exception
• try代码块仅包含可能抛出异常的代码，避免大段代码包裹
• 非本层职责的异常，必须原封不动向上抛出，严禁越权处理

5.3 受检异常滥用

错误场景：自定义异常继承受检异常，导致跨服务调用时序列化失败，同时强制上游调用方捕获处理，增加代码耦合。正确规范：

• 分布式系统中，仅当调用方可明确恢复的场景，才使用受检异常
• 业务异常、系统异常全部使用非受检异常，继承RuntimeException
• 严禁在RPC接口中声明抛出受检异常，避免上下游耦合

5.4 异常信息泄露

错误场景：将数据库异常堆栈、SQL语句、账号密码、服务器地址等敏感信息直接返回给前端，导致安全漏洞。正确规范：

• 面向用户的提示信息仅返回友好内容，严禁泄露任何系统细节
• 敏感信息仅记录在服务端日志中，严禁在响应体中返回
• 系统异常的用户提示统一为"系统繁忙，请稍后重试"，不暴露具体错误原因

5.5 异步异常丢失

错误场景：异步方法、线程池任务未配置异常处理器，导致异常被静默吞噬，线上问题无法排查。正确规范：

• 所有异步场景必须配置专用的异常处理器，保证异常被记录
• 异步任务必须传递traceId，保证全链路可追溯
• 线程池必须配置拒绝策略，避免任务丢失

5.6 业务异常触发熔断

错误场景：未区分业务异常与系统异常，正常的业务参数校验异常被计入熔断失败次数，导致服务被误熔断。正确规范：

• 熔断降级必须自定义异常判定器，仅系统异常计入失败次数
• 业务异常属于预期内异常，不触发熔断、不打印ERROR级别日志
• 异常类型必须严格区分，严禁业务异常与系统异常混用

六、异常监控与告警闭环

架构级的异常设计，最终必须形成监控与告警的闭环，实现异常的提前发现、快速定位、及时处理，而不是等用户反馈后才被动排查。

6.1 核心异常监控指标

基于Prometheus+Grafana实现异常指标采集，核心监控指标包括：

1. 异常QPS：按服务、模块、错误码维度统计异常的请求量，监控异常突增情况
2. 异常占比：异常请求数占总请求数的比例，核心SLA指标
3. 错误码分布：按错误码维度统计异常分布，定位高频异常场景
4. 熔断触发次数：按服务维度统计熔断触发次数、持续时间，监控服务稳定性
5. 全链路异常拓扑：基于traceId统计异常链路的分布，定位故障根因节点

6.2 告警规则设计

告警规则必须精准，避免告警轰炸，核心告警规则如下：

1. 系统异常告警：系统异常QPS超过阈值，立即触发P1级告警，必须人工介入
2. 异常占比突增告警：服务整体异常占比较基准值突增超过30%，触发P2级告警
3. 熔断持续告警：服务熔断状态持续超过30秒，触发P2级告警
4. 业务异常突增告警：特定业务异常QPS较基准值突增超过100%，触发P3级告警
5. 错误码高频告警：单个错误码1分钟内出现次数超过阈值，触发P3级告警

6.3 异常排查流程规范

1. 告警触发后，通过traceId定位异常链路的根因节点
2. 通过错误码匹配对应的异常场景与排查方案
3. 查看异常日志的完整堆栈与上下文信息，定位根因
4. 处理故障后，更新异常处理规范，补充对应的错误码与兜底方案
5. 形成故障复盘报告，优化异常体系设计，避免同类问题重复发生

结语

分布式系统的异常处理，从来不是简单的try-catch语法使用，而是一套覆盖架构全分层、贯穿请求全链路的体系化设计。好的异常体系，能让线上故障的排查时间从小时级降到分钟级，甚至秒级，是分布式系统稳定性的核心基石。