Dubbo 使用过程经典踩坑¶
一、超时与重试¶
问题¶
默认 timeout=1000，retries=2（即第一次失败后再试 2 次，共 3 次调用）。如果接口本身慢，会导致：
- 服务端被重复调用（接口不幂等就重复扣款）。
- 调用方超时，服务端其实成功了。
解决¶
- 写操作必须显式设
retries="0"： - 读操作可以保留重试。
- 业务接口必须设计成幂等。
二、泛化调用与序列化¶
问题¶
服务端改了字段（加字段、改类型），客户端没升级，可能反序列化失败。
解决¶
- DTO 只加字段，不改字段类型。
- 不用的字段不要删，用
@Deprecated。 - 接口演进要向后兼容。
三、找不到服务 / No provider¶
常见原因¶
- 注册中心地址不对。
- 服务端没启动 / 没注册成功。
- 客户端 group / version 不匹配。
- 网络不通（安全组、端口）。
排查：dubbo-admin 看提供者列表。
四、慢调用拖垮线程池¶
问题¶
某个下游接口变慢，所有调用线程都阻塞在那里，Tomcat / Dubbo 业务线程池耗尽，整个应用假死。
解决¶
- 超时必须设置，不能无限等。
- 配合 Sentinel / Resilience4j 做熔断降级。
- 隔离线程池：不同服务用不同线程池，互不影响。
五、大对象 / 大附件¶
一次 RPC 传几 MB 的对象会：
- 序列化慢。
- 占满网络连接。
- 触发超时。
解决：用文件存储 + URL 传递，不要直接传大对象。
六、循环依赖 / 启动慢¶
Dubbo 服务引用是懒连接（默认），第一次调用才连。如果启动时就要验证，配 check=true 或 init=true。
七、与 Spring Boot 版本兼容¶
- Dubbo 2.7+ 支持
spring-boot-starter。 - 老版本 XML 配置在 Spring Boot 2.x 可能不生效。
八、序列化协议选择¶
- Hessian2：默认，跨语言，但性能一般。
- Protostuff / Kryo：更快，但要注册。
- 同一集群所有提供者、消费者必须用同一序列化协议。
九、优雅上下线¶
- 应用重启时，先从注册中心注销，等一段时间（如 10s）再停进程，避免请求打过来。
- K8s 环境配合 preStop hook。
一句话
Dubbo 的坑大多来自：超时没设、重试没关、序列化不兼容、下游慢拖垮自己。