dubbo

Dubbo RPC 服务治理与运维

补充说明

dubbo 是 Apache 的 Java RPC 框架，核心角色是 Provider、Consumer 和注册中心。Provider 暴露接口与协议端口，Consumer 从注册中心订阅地址并负载均衡调用；注册中心只保存元数据，不转发业务流量。

它解决服务发现、负载均衡、超时、重试、熔断、泛化调用和多协议接入。默认 dubbo 协议基于长连接和 Hessian2 序列化，适合内部 Java 服务；Triple 协议基于 HTTP/2 和 protobuf，适合跨语言与网关。与 gRPC 相比，Dubbo 的治理能力和 Java 接口绑定更强；与 REST 相比，它更适合低延迟的内部调用。

注册中心常用 Nacos 和 ZooKeeper：ZooKeeper 是 CP、临时节点加 Watch，会话过期会摘除实例；Nacos 支持 AP/CP、推送和健康检查，配置中心与注册中心可合一。Dubbo 3 的应用级服务发现会减少注册中心地址数量，但接口级路由与治理规则仍需理解。

常用示例

java -jar provider.jar --dubbo.protocol.port=20880
java -jar consumer.jar --dubbo.registry.address=nacos://127.0.0.1:8848
telnet 127.0.0.1 22222
ls
ps
cd com.example.UserService
ls
invoke sayHello("world")
online
offline
shutdown

QoS 的 invoke 是泛化调用，参数按 JSON 风格书写；online/offline 控制 Provider 上下线。代码侧泛化调用：

ReferenceConfig<GenericService> reference = new ReferenceConfig<>();
reference.setInterface("com.example.UserService");
reference.setGeneric("true");
GenericService service = reference.get();
Object result = service.$invoke(
    "sayHello", new String[]{"java.lang.String"}, new Object[]{"world"});

注解与超时重试：

@DubboService(version = "1.0.0")
public class UserServiceImpl implements UserService { }

@DubboReference(version = "1.0.0", check = false, timeout = 500, retries = 0, cluster = "failfast")
private UserService userService;

常见配置

dubbo.application.name=order-service
dubbo.application.qos-enable=true
dubbo.application.qos-port=22222
dubbo.application.qos-accept-foreign-ip=false
dubbo.registry.address=nacos://127.0.0.1:8848
dubbo.registry.group=dubbo
dubbo.protocol.name=dubbo
dubbo.protocol.port=20880
dubbo.protocol.serialization=hessian2
dubbo.consumer.timeout=1000
dubbo.consumer.retries=2
dubbo.consumer.check=false
dubbo.consumer.cluster=failover
dubbo.consumer.loadbalance=random

默认值：dubbo 协议端口 20880、调用超时 1000ms、重试 2 次（共 3 次调用）、集群容错 failover、负载均衡 random；QoS 端口 22222，qos-accept-foreign-ip 默认 false。Triple 协议默认端口 50051，切换协议时客户端与防火墙都要改。

易错点与排错

No provider available：版本/分组不匹配、Provider 未启动、注册中心 namespace/group 不一致。用 QoS ls、注册中心控制台和启动日志三方对照。
默认超时 1000ms 对数据库或下游调用往往太短；超时触发 failover 重试，非幂等写接口应设置 retries=0 或 cluster=failfast。
重试发生在超时之后，不只是失败之后；一次写请求可能执行多次，必须用业务唯一键保证幂等。
序列化不一致：Hessian2 要求类可序列化且字段兼容，Provider/Consumer 的 API jar 版本要一致；serialization 配置不同会直接调用失败。
注册中心地址写错 scheme（zookeeper:// 与 nacos://）或漏掉 namespace/group，会订阅到空地址列表；多地址用逗号分隔并确认网络。
本地注册缓存可能让 Provider 下线后仍被调用；检查 ~/.dubbo/dubbo-registry-*.cache，必要时清理并重启。
QoS 默认只允许本机访问；qos-accept-foreign-ip=true 会暴露 invoke、shutdown 等命令，等同于远程代码执行，务必加防火墙或禁用。
同类自调用或 new 出来的对象不经过 Spring/Dubbo 代理，超时、重试、过滤器全部失效；改用注入的代理或拆分 Bean。
Provider 线程池耗尽会报 Thread pool is exhausted；检查 dubbo.protocol.threads、队列长度和下游慢调用，盲目加大线程数可能压垮数据库。
Triple 与 dubbo 协议端口不同（Triple 默认 50051），切换协议后 Consumer 配置、端口和防火墙要同步修改。
ZooKeeper 会话超时会删除临时节点，Nacos 临时实例靠心跳健康检查；两者故障表现不同，排查时先确认注册中心自身状态。
泛化调用重载方法必须传精确的参数类型数组，基本类型与包装类型不匹配会报找不到方法。

读完自测

Dubbo 的默认超时和重试次数是多少，为什么非幂等接口要关闭重试？
ZooKeeper 与 Nacos 作为注册中心的关键差异是什么？
QoS 的 invoke 和 online/offline 分别有什么风险或用途？

答案

默认 timeout 1000ms、retries 2（共 3 次）；超时也会重试，非幂等写会产生重复数据。
ZooKeeper 是 CP、临时节点加 Watch；Nacos 支持 AP/CP、推送和健康检查，并可兼作配置中心。
invoke 可泛化调用任意方法，暴露公网风险极高；online/offline 用于优雅上下线，会改变注册中心可见性。