RPC 框架看起来都是“远程调用像本地方法”，但真正落到工程里，要关心接口注册、序列化、版本兼容、异常处理和安全边界。
这篇整理 Dubbo 和 Hessian 的几个备忘点。
Dubbo 接口注册要看实现关系
Dubbo 使用时经常会碰到接口和实现类的关系问题。
比如一个类实现多个接口时，要确认实际暴露的是哪个接口；一个接口有多个实现时，也要看服务名、分组、版本和注册配置。
排查这类问题时，可以按顺序看：
- 服务实现类。
- 暴露的接口。
- group 和 version。
- 注册中心里的实际节点。
- 消费方引用配置。
不要只看代码里的实现关系，还要看注册中心最后看到的结果。
Hessian 是什么
Hessian 可以理解为基于二进制协议的 RPC 方案，通常运行在 HTTP 之上。
它的特点是：
- 使用方式相对简单。
- 包体较小。
- 对简单对象序列化比较方便。
- 支持多语言。
- 服务端和客户端都需要对应依赖。
这类方案适合简单 RPC 场景，但工程边界要写清楚。
Hessian 的局限
Hessian 也有明显限制：
- 安全机制弱。
- 传输层本身不负责加密。
- 异常机制不够完善。
- 版本兼容要小心。
- 复杂对象序列化容易出问题。
- 与框架版本可能存在绑定。
如果接口里有 BigDecimal、日期时间、复杂对象、继承结构，就要格外关注序列化兼容性。
RPC 不是只看调用成功
RPC 调用成功只是第一步。长期运行还要看：
- 超时。
- 重试。
- 熔断。
- 限流。
- 幂等。
- 监控。
- 日志脱敏。
- 版本兼容。
- 鉴权。
尤其是跨服务写操作，重试和幂等一定要一起设计。否则网络抖动可能变成重复写入。
维护建议
整理 RPC 资料时，可以按四类沉淀：
- 框架概念：Dubbo、Hessian、HTTP RPC 等。
- 注册发现：注册中心、接口暴露、消费者引用。
- 序列化：对象兼容、日期时间、数字精度。
- 工程治理：超时、重试、限流、安全和监控。
这样以后排查 RPC 问题时，不会只盯着“为什么调用不通”，而是能从注册、协议、序列化和治理四个方向一起看。
正文完
