初始设计回顾

功能

本次设计旨在实现全局错误捕获、错误日志记录以及错误码管理。可以将其想象成一个系统的“健康监测员”，它能及时发现系统运行过程中的错误，详细记录这些错误信息，并通过特定的错误码对错误进行精准标识和分类。

需求

希望提供统一的异常捕获机制以及通用的ErrorCode，各个服务只要引用这个包，就能轻松进行异常处理。同时，各服务还能通过继承ErrorCode来定制属于自己的异常代码，就像给每个服务配备了一把可以根据自身需求调整的“错误处理钥匙”。

设计

1. 提供跨微服务的统一异常处理机制：如同建立了一套通用的“错误处理规则”，无论在哪个微服务中出现问题，都能按照这套规则进行处理，确保整个系统处理错误的方式一致。
2. 标准化错误响应格式：使得不同微服务返回的错误信息具有相同的格式，方便开发人员快速理解和定位问题，就像所有错误信息都穿上了统一的“外衣”。
3. 简化各服务的异常处理逻辑：让各服务在处理异常时更加轻松，无需每个服务都从头设计复杂的异常处理流程，只需遵循统一的规则即可。

3.1 异常类层次结构

// 基础异常接口
public interface ErrorCode {
    String getCode();
    String getMessage();
    String getCategory();
}

// 基础异常类
public abstract class BaseException extends RuntimeException {
    private final ErrorCode errorCode;
    private final Object[] args;
    private final String traceId;
    
    // 构造方法、getter等
}

// 业务异常
public class BusinessException extends BaseException {
    // 业务逻辑相关异常
}

// 系统异常
public class SystemException extends BaseException {
    // 系统级异常，如数据库连接失败等
}

// 参数校验异常
public class ValidationException extends BaseException {
    private final Map<String, String> fieldErrors;
    // 参数校验失败异常
}

这段代码构建了一个清晰的异常类层次结构。ErrorCode接口定义了获取错误码、错误信息和错误类别的方法，为所有异常类型提供了统一的规范。BaseException作为基础异常类，继承自RuntimeException，包含了错误码、参数和追踪ID等关键信息，为具体的异常类型提供了通用的属性和行为。BusinessException、SystemException和ValidationException分别针对业务逻辑、系统级以及参数校验方面的异常进行了具体定义。
这种分层结构使得异常处理更加有序和易于维护。

3.2 错误码设计

3.2.1 通用错误码 (CommonErrorCode)

public enum CommonErrorCode implements ErrorCode {
    // 系统级错误 (SYS001-SYS999)
    SYSTEM_ERROR("SYS001", "系统内部错误", "SYSTEM"),
    PARAM_INVALID("SYS002", "参数校验失败", "SYSTEM"),
    UNAUTHORIZED("SYS003", "未授权访问", "SYSTEM"),
    FORBIDDEN("SYS004", "禁止访问", "SYSTEM"),
    NOT_FOUND("SYS005", "资源不存在", "SYSTEM"),
    METHOD_NOT_ALLOWED("SYS006", "请求方法不支持", "SYSTEM"),
    TOO_MANY_REQUESTS("SYS007", "请求过于频繁", "SYSTEM"),
    
    // 网络通信错误 (NET001-NET999)
    NETWORK_TIMEOUT("NET001", "网络超时", "NETWORK"),
    SERVICE_UNAVAILABLE("NET002", "服务不可用", "NETWORK"),
    FEIGN_CLIENT_ERROR("NET003", "服务调用失败", "NETWORK"),
    
    // 数据处理错误 (DATA001-DATA999)
    DATA_INTEGRITY_VIOLATION("DATA001", "数据完整性约束违反", "DATA"),
    DUPLICATE_KEY("DATA002", "数据重复", "DATA"),
    OPTIMISTIC_LOCK_FAILURE("DATA003", "乐观锁冲突", "DATA");
}

通用错误码的设计涵盖了系统级、网络通信以及数据处理等多个常见的错误场景。每个错误码都有其特定的编码、错误信息以及所属类别。例如，SYSTEM_ERROR表示系统内部错误，NETWORK_TIMEOUT表示网络超时错误。这种设计方式有助于快速定位和区分不同类型的错误，方便开发人员进行调试和处理。你在项目中遇到过哪些频繁出现的通用错误呢？

3.2.2 各服务错误码分配规范

由于是先开发的，就先不定义了，等每个服务开发得差不多了重新整合一遍分配就好了，不过在这里还是给个例子。

SYS (1000 - 1999): 系统通用错误
NET (2000 - 2999): 网络通信错误  
DATA (3000 - 3999): 数据处理错误
FS (4000 - 4999): 文件服务错误
US (5000 - 5999): 用户服务错误
CT (6000 - 6999): 合同服务错误
OR (7000 - 7999): 订单服务错误
PM (8000 - 8999): 支付服务错误
NT (9000 - 9999): 通知服务错误

这种分配规范为各服务的错误码划分了明确的范围，使得不同服务的错误码具有唯一性和可辨识度。比如，文件服务的错误码范围在4000 - 4999之间，用户服务的错误码范围在5000 - 5999之间。这样在系统出现错误时，通过错误码就能快速定位到是哪个服务出现了问题。

总结

总体而言，本次开发的难度并不大，简单概括就是注册了一个全局异常捕获器，并设计了一套错误码。通过这些操作，为系统构建了一个相对完善的错误处理体系。

下期将会进入另一个模块contract - ai的介绍，从某种意义上来说，这个模块的开发过程让我有些头疼。你有没有在开发过程中遇到过一开始觉得困难重重，但最后成功解决的模块呢？