Dubbo-RPC原理#

一句话答案#

Dubbo RPC 调用链：代理拦截→负载均衡选节点→序列化（Hessian2）→网络传输（Netty）→反序列化→执行→返回。

① REST（HTTP/JSON）：
   → 对外暴露 API（面向前端、第三方、移动端）
   → 跨团队、跨组织的 API 协作（OpenAPI 文档）
   → 简单的内部微服务通信（性能要求不高）
   → 需要快速调试和人工排查

② gRPC：
   → 内部高性能微服务通信（延迟敏感、吞吐量大）
   → 多语言微服务（Go + Java + Python 混合架构）
   → 需要流式通信的场景（实时数据推送、双向通信）
   → 强类型约束（.proto 文件强制定义接口）

③ Dubbo：
   → Java 为主的微服务架构
   → 需要丰富的服务治理（路由、权重、灰度）
   → 阿里巴巴技术栈 / Spring Cloud Alibaba 生态
   → 大规模 Java 微服务集群

实际项目中常见组合：
   外部 API → REST（Spring MVC / Spring WebFlux）
   内部高频调用 → gRPC 或 Dubbo
   配置中心 + 注册中心 → Nacos

// order.proto
syntax = "proto3";
package order;

service OrderService {
    // 一元 RPC
    rpc GetOrder (GetOrderRequest) returns (OrderResponse);
    // 服务端流式 RPC
    rpc ListOrders (ListOrdersRequest) returns (stream OrderResponse);
    // 双向流式 RPC
    rpc OrderChat (stream OrderMessage) returns (stream OrderMessage);
}

message GetOrderRequest {
    int64 order_id = 1;
}

message OrderResponse {
    int64 id = 1;
    string product_name = 2;
    double amount = 3;
    string status = 4;
}

Dubbo 调用原理（深挖）#

上面是选型对比，这一节才是「Dubbo-RPC 原理」真正要答的内容：协议帧、调用链路、异步转同步、SPI。

协议帧：16 字节定长头 + 变长 body

Dubbo 协议是「私有 TCP 协议」，每个报文 = 16 字节定长 Header + 变长 Body：

为什么需要 Magic + Length？TCP 是字节流没有消息边界，靠魔数定位帧头、靠长度字段切出完整一帧，这是所有私有协议解决粘包的标准做法。

调用链路（消费端一次同步调用穿过的层）

业务接口（Proxy 代理，JDK/Javassist 动态代理）
   ↓ 拦截方法调用，封装成 Invocation（方法名/参数类型/参数值/attachment）
Cluster（集群容错层）—— Failover 失败重试 / Failfast / Failsafe / Forking
   ↓ 从 Directory 拿到可用 Invoker 列表，交给路由+负载均衡
LoadBalance（选址）—— Random / RoundRobin / LeastActive / ConsistentHash
   ↓ 选出一个 Invoker（一个 Invoker ≈ 一个可调用的远程服务地址）
Protocol → DubboInvoker（协议层，发起真正调用）
   ↓
序列化（Hessian2 默认）把 Invocation 编码成字节
   ↓
Netty Client 发送（长连接，单连接多路复用）

服务端收到后反向走一遍：Netty 解码 → 反序列化出 Invocation → 找到对应 Exporter/Invoker → 反射执行真实方法 → 结果序列化回写。

两个核心抽象：Invoker 与 Invocation

• Invocation：一次调用的「请求参数包」——方法名、参数类型、参数值、附加隐式参数（attachment，如 traceId）。
• Invoker：Dubbo 最核心的抽象，代表「一个可执行的调用实体」，Result invoke(Invocation)。消费端的 Invoker 指向远程服务，服务端的 Invoker 包裹真实实现类。Cluster、Filter、Listener 全是对 Invoker 的层层包装（装饰器模式），所以拦截链、Mock 降级、监控统计都能透明插入。

异步转同步：DefaultFuture + reqId 关联

Dubbo 底层 Netty 调用天生是异步的（发出去就返回，响应稍后由 IO 线程回调），但业务接口看起来是同步阻塞的。怎么把异步变同步？

1. 发送前生成全局唯一 Request ID，创建一个 DefaultFuture 并以 reqId → future 存入全局 FUTURES Map。
2. 把请求写进 Netty 发出去，业务线程在 future.get(timeout) 上阻塞等待。
3. 服务端响应回来时，IO 线程读出响应头里的 Request ID，从 Map 里找到对应的 DefaultFuture，调用 received() 填入结果并唤醒阻塞的业务线程。
4. 超时由时间轮（HashedWheelTimer）扫描未完成的 future，到点设置超时异常。

单连接多路复用为何不乱？ 一条 TCP 长连接上并发跑着成百上千个请求，响应回来的顺序和发送顺序不一定一致。靠 Request ID 把每个响应精确对应回它的请求，所以乱序也不会错乱——这就是 reqId 的根本作用。

SPI 机制（Dubbo 微内核可扩展的基石）

Dubbo 几乎所有组件（Protocol、LoadBalance、Cluster、序列化…）都是 SPI 扩展点，靠 ExtensionLoader 加载：

• 配置位置：META-INF/dubbo/ 下以接口全限定名为文件名，内容是 key=实现类全限定名，按 key 懒加载（区别于 Java SPI 一次性实例化全部）。
• @Adaptive 自适应：Dubbo 在运行时根据 URL 参数（如 loadbalance=roundrobin）决定用哪个实现。ExtensionLoader 会动态生成一个适配类（XxxProtocol$Adaptive，Javassist 字节码生成），方法体里从 URL 取参数 key、再 getExtension(key) 派发到真实实现——实现「运行时按参数选实现」。
• @Activate 自动激活：一批同类扩展（典型是 Filter 链）按条件批量激活，比如 @Activate(group="consumer") 的 Filter 只在消费端生效，无需手动声明。
• IoC + AOP：扩展实例的 setter 依赖会被 SPI 自动注入（IoC）；带包装构造器的 Wrapper 类会自动套在真实扩展外层（AOP），Dubbo 的监控、缓存等增强就是 Wrapper。