160 lines
4.6 KiB
Markdown
160 lines
4.6 KiB
Markdown
# rdms-spring-boot-starter-rpc
|
||
|
||
## 1. 模块现状
|
||
|
||
当前模块本体基本是空的。
|
||
|
||
从代码来看，这个模块目前只有：
|
||
|
||
- `pom.xml` 中的依赖声明
|
||
- `config`、`core` 两个包下的占位 `package-info.java`
|
||
|
||
当前没有实际落地的 RPC 代码。
|
||
|
||
## 2. 当前实际作用
|
||
|
||
这个模块目前的作用，主要是统一引入 RPC 相关基础依赖，包括：
|
||
|
||
- `spring-cloud-starter-openfeign`
|
||
- `spring-cloud-starter-loadbalancer`
|
||
- `feign-okhttp`
|
||
- `jakarta.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 规范
|
||
|
||
但以当前仓库代码为准，这些能力都还没有在本模块中实现。
|