Dubbo-RPC原理#

核心对比表：

选型建议：

① 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

gRPC Protobuf 示例：

// 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 是阿里开源、现属 Apache 的 RPC 框架，一次同步调用的链路是：消费端通过动态代理拦截接口方法，封装成 Invocation；Cluster 层从 Directory 拿到可用 Invoker 列表，经路由和负载均衡（默认加权随机）选出一个节点，失败按 Failover 等容错策略处理；然后 DubboInvoker 用 Hessian2 序列化，经 Netty 长连接发出。协议是 16 字节定长头加变长 body，头里有魔数 0xdabb 和 body 长度，用来解决 TCP 粘包半包；还有 8 字节 Request ID，发送时把 reqId 和 DefaultFuture 放进全局 Map，业务线程阻塞在 future 上，响应回来 IO 线程按 reqId 找到 future 唤醒，这就是异步转同步，也是单连接多路复用不乱序的原因，超时由时间轮检测。整个框架是微内核加 SPI：Protocol、LoadBalance、Cluster、Filter 都是扩展点，按 key 懒加载，@Adaptive 在运行时按 URL 参数选实现，@Activate 批量激活 Filter。Dubbo 3 又加了 Triple 协议（兼容 gRPC、支持流式）和应用级服务发现。选型上，对外 API 用 REST，内部纯 Java 且要丰富治理选 Dubbo，多语言混合选 gRPC 或 Dubbo Triple。

追问方向：

• “Dubbo SPI 和 Java SPI 区别？”→ Java SPI 一次性加载所有实现类，无法按需加载；Dubbo SPI 支持按 key 按需加载、支持 IoC 和 AOP（自动注入和 Wrapper 增强）、支持 @Adaptive 自适应扩展，扩展性更强
• “Dubbo 服务降级怎么做？”→ 在消费端配置 mock 参数：mock=fail:return+null 先调远程、失败（RpcException）后返回 null（不写前缀的 mock=return+null 等同于 fail 策略）；mock=force:return+null 强制降级、直接返回 null 不调用远程；也可实现 Mock 类做复杂降级逻辑
• “Dubbo 和 Spring Cloud 怎么选？”→ Dubbo 偏 RPC 通信层，性能高（二进制协议+长连接），适合内部服务间高性能调用；Spring Cloud 是完整微服务生态（网关、配置、熔断一站式），适合 REST 风格和快速搭建；两者可混用
• “Dubbo 一条 TCP 连接并发那么多请求，响应回来怎么不乱？”→ 协议头里有 8 字节全局唯一 Request ID，发送时把 reqId→DefaultFuture 存进全局 Map，业务线程阻塞在 future.get；响应回来 IO 线程按响应里的 reqId 找到对应 future 唤醒，所以单连接多路复用乱序也能精确对应
• “Dubbo 怎么解决 TCP 粘包/半包？”→ 16 字节定长头里有魔数 0xdabb 定位帧边界 + 4 字节 body length，先读满头拿到长度再精确读 body，读不够就等下一个包
• “Dubbo 3 相比 2.x 主要变了什么？”→ ① 新增 Triple 协议：基于 HTTP/1、HTTP/2，兼容 gRPC，支持流式，可以直接用 Java 接口定义不强制 Protobuf，解决了 dubbo 协议跨语言和网关穿透差的问题；② 应用级服务发现：注册中心按应用而不是按接口注册，地址数据量大幅下降，也便于和 Spring Cloud、K8s 互通，迁移期默认双注册（接口级 + 应用级）；③ 云原生支持（Proxyless Mesh、K8s 服务发现）
• “@Adaptive 是怎么做到运行时按参数选实现的？”→ ExtensionLoader 用 Javassist 动态生成一个适配类，方法体里从 URL 取参数 key（如 loadbalance），再 getExtension(key) 派发到真实实现，等于把「选哪个实现」延迟到调用时由 URL 决定

易错点：

• ❌ Dubbo 和 Feign 一样——Dubbo 是 RPC Feign 是 HTTP
• ❌ Dubbo 只能用 ZK——支持多种注册中心