Dubbo

Dubbo 是阿里巴巴开源的高性能 Java RPC 框架，核心设计是"接口定义服务 + 注册中心寻址 + 长连接调用 + 内置治理"。与 Spring Cloud 的 HTTP 短连接风格不同，Dubbo 用 TCP 长连接 + 二进制序列化（Hessian/Kryo），性能高一个量级，且服务发现、负载均衡、集群容错、限流降级全部内置——这是它适合大型分布式系统的原因。

调用模型

Dubbo 的核心角色与调用链路：

角色	职责
Provider	服务提供者，启动时把服务接口注册到注册中心
Consumer	服务消费者，从注册中心订阅服务列表
Registry	注册中心，默认 ZooKeeper（也可 Nacos/Redis），维护服务与地址映射
Monitor	监控中心，统计调用次数与耗时

调用流程：Provider 启动注册 → Consumer 启动订阅并缓存地址列表 → Consumer 按负载均衡策略选一个 Provider 建立长连接调用 → 注册中心推送变更（Provider 上下线）→ 调用数据上报 Monitor。

快速开始

<!-- Provider 引入 -->
<dependency>
    <groupId>org.apache.dubbo</groupId>
    <artifactId>dubbo-spring-boot-starter</artifactId>
    <version>3.2.0</version>
</dependency>

dubbo:
  application:
    name: order-service
  registry:
    address: zookeeper://127.0.0.1:2181
  protocol:
    name: dubbo
    port: 20880

// Provider：实现并暴露服务
@Service
public class OrderServiceImpl implements OrderService {
    @Override
    public Order getById(Long id) { return ...; }
}

// Consumer：注入接口即可调用（框架生成代理）
@DubboReference
private OrderService orderService;

Consumer 端注入的 @DubboReference 是动态代理——调用时把方法名、参数序列化后通过长连接发给 Provider，机制详见 DubboSPI 的代理扩展与 代理模式。

注册中心与配置中心

注册中心	特性	适用
ZooKeeper	默认选择，CP 强一致（ZAB），节点多时推送性能下降	通用首选
Nacos	同时提供配置管理，CP/AP 双模式	与 Nacos 配置中心一起用
Redis	AP，简单场景	小规模

Dubbo 3.0 引入应用级服务发现（对比 2.x 的接口级）：一个应用发布一个服务，注册中心条目从"接口×实例"降为"应用×实例"，解决大规模集群注册中心压力问题。

负载均衡

策略	算法	适用
random（默认）	加权随机	通用
roundrobin	加权轮询	请求均匀
leastactive	选活跃数最少的	处理能力不均
consistenthash	一致性哈希	有状态服务（Session）

集群容错

Provider 调用失败时的处理策略，默认 failover：

策略	行为	适用场景
failover（默认）	失败重试其他节点（默认重试 2 次）	读操作、幂等写
failfast	失败立即报错	非幂等写（新增）
failsafe	失败静默忽略	日志上报等非关键
failback	失败异步重试	消息通知
forking	并行调用多个节点，第一个成功即返回	要求高实时性

failover 与幂等

failover 重试的前提是服务幂等：非幂等操作（下单）重试会产生重复数据，必须配合幂等方案（见 RPC框架 的幂等性设计）或改用 failfast。

泛化调用与多版本

能力	说明
泛化调用	Consumer 不依赖 Provider 接口 jar，用 GenericService 按方法名+参数类型调用——网关、测试平台常用
多版本	@DubboService(version = "1.0")，同接口多版本并存，实现灰度发布
分组	同接口按 group 隔离，不同业务线用不同 group

Dubbo 与 RPC框架 的序列化、ZooKeeper 的注册中心机制、DubboSPI 的扩展机制、服务治理 的注册发现体系相互关联。