4.7 KiB
rdms-spring-boot-starter-rpc
1. 模块现状
当前模块本体基本是空的。
从代码来看，这个模块目前只有：
pom.xml中的依赖声明config、core两个包下的占位package-info.java
当前没有实际落地的 RPC 代码。
2. 当前实际作用
这个模块目前的作用，主要是统一引入 RPC 相关基础依赖，包括：
spring-cloud-starter-openfeignspring-cloud-starter-loadbalancerfeign-okhttpjakarta.validation-api
所以更准确地说，它现在是一个“RPC 依赖聚合模块”，而不是一个已经实现完整功能的 RPC starter。
3. 当前不包含的能力
这个模块当前没有提供以下能力：
- 没有自动配置类
- 没有
@EnableFeignClients封装 - 没有请求拦截器
- 没有统一异常处理
- 没有统一重试策略
- 没有统一降级处理
- 没有自定义编码器、解码器
- 没有任何业务侧 RPC 工具类
也就是说，单看这个模块本身，当前还谈不上“功能实现”。
4. 如何理解这个模块
如果结合当前仓库结构来理解，这个模块更适合看作：
- 先把 RPC 相关依赖收进来
- 给后续扩展预留模块位置
- 暂时还没有继续往里面建设实际能力
因此，这个模块当前的关键词不是“功能”，而是“占位”和“依赖聚合”。
5. 这个模块后续适合承接的内容
如果后续要继续建设，这个模块比较适合承接“各业务模块都可能共用的 RPC 通用能力”。
5.1 Feign 统一配置
适合放在这里的内容包括：
- 统一开启 Feign 所需的基础配置
- 统一配置超时、连接池、日志级别
- 统一切换底层 HTTP 客户端
这类内容属于基础设施层，通常不应该散落在各业务模块中。
5.2 请求拦截
这部分正是比较典型、也比较适合放在本模块中的能力。
例如可以统一实现：
- 请求头透传
- Token 透传
- 用户信息透传
- TraceId / 请求链路标识透传
- 租户编号透传
常见做法是基于 RequestInterceptor，在所有 Feign 请求发出前统一补充请求头。
5.3 返回结果统一处理
如果希望对所有 OpenFeign 调用结果做统一拦截和异常处理，也适合放在这个模块。
常见做法包括：
- 通过
ErrorDecoder统一处理非 2xx 响应 - 通过自定义
Decoder统一解析返回体 - 对返回结果做统一业务异常转换
- 对远程服务错误码做统一包装
例如：
- 对方服务返回 404、500 时，统一转成项目内部异常
- 对方服务返回统一响应结构时，统一判断是否成功
- 对远程调用超时、连接失败做统一异常封装
5.4 调用日志与问题排查
这类通用能力也适合放在这里：
- 统一打印 RPC 请求日志
- 统一打印 RPC 响应日志
- 记录调用耗时
- 记录失败原因
这样做的好处是，排查跨服务问题时不需要每个模块各写一套。
5.5 重试、降级与容错
如果项目后续需要增强 RPC 稳定性，也可以在这里统一建设：
- 重试策略
- 熔断策略
- 降级处理
- 超时兜底
不过这部分是否要做，需要结合项目实际复杂度决定；如果当前系统调用链不复杂，也可以先不引入。
5.6 统一 RPC 规范
这个模块也适合沉淀一些统一约定，例如：
- 统一返回结构
- 统一异常码映射
- 统一 Header 命名
- 统一调用方与被调用方的接口规范
这样可以避免不同模块各自定义一套 RPC 风格。
6. 是否适合把拦截器和异常处理放在这里
如果这些能力是“针对所有或大多数 OpenFeign 调用都生效”的公共能力，那么放在这个模块是合适的。
原因很直接：
- 它属于 RPC 基础设施，不属于某个单独业务模块
- 放在这里可以统一维护，避免重复实现
- 后续任何模块接入 Feign 时，都可以复用同一套规则
例如你提到的这类需求，就很适合落在这里：
- 所有 Feign 请求统一加请求头
- 所有 Feign 返回统一做异常判断
- 所有远程调用失败统一转换成项目内部异常
如果某个拦截逻辑只服务于单一业务模块，那更适合放在该业务模块自己的 RPC 配置中；如果是全局通用规则，则更适合放在本模块。
7. 结论
rdms-spring-boot-starter-rpc 当前没有真正的功能代码。
如果后续要把它做成一个真正的 RPC starter，通常才会逐步补这些内容：
- 自动装配
- Feign 统一启用
- 请求头透传
- 调用日志
- 异常处理
- 超时与重试配置
- 统一 RPC 规范
但以当前仓库代码为准，这些能力都还没有在本模块中实现。