Dubbo

架构与版本

Dubbo 是面向服务的 RPC 框架。Provider 暴露服务接口，Consumer 订阅地址并发起调用，注册中心维护服务发现，配置中心与元数据中心管理配置和接口信息。注册中心通常不转发业务请求；能够注册不代表 Consumer 能访问 Provider 的实际通告地址。

Dubbo 2.x 的接口级注册、dubbo:// 协议和旧版 Admin 部署，与 Dubbo 3.x 的应用级发现、元数据和 Triple 协议存在差异。应用依赖、注册中心客户端、序列化库和 JDK 应采用兼容的版本组合。

Spring Boot 配置

以下为 Dubbo 3.x 的配置片段，前提是应用已经引入兼容的 Dubbo Spring Boot starter、注册中心依赖和接口包。com.example.api、注册中心地址和端口按实际项目替换。

Provider 的 application.yaml：

spring:
  application:
    name: demo-provider
dubbo:
  application:
    name: demo-provider
  registry:
    address: zookeeper://zk-0.zk-hs:2181?backup=zk-1.zk-hs:2181,zk-2.zk-hs:2181
  protocol:
    name: dubbo
    port: 20880
  provider:
    timeout: 2000
    retries: 0
  scan:
    base-packages: com.example.provider

Consumer 的配置：

spring:
  application:
    name: demo-consumer
dubbo:
  application:
    name: demo-consumer
  registry:
    address: zookeeper://zk-0.zk-hs:2181?backup=zk-1.zk-hs:2181,zk-2.zk-hs:2181
  consumer:
    check: true
    timeout: 2000
    retries: 0

Provider 实现接口并通过 @DubboService 导出；Consumer 用 @DubboReference 引用相同接口。接口的 group、version 和序列化配置必须匹配。方法级、引用级与全局配置存在优先级关系，最终超时和重试以有效配置为准。

Triple 使用 HTTP/2，需按目标版本配置 tri 协议和对应端口；不能只修改网关转发方式就把原有 Dubbo 协议变成 Triple。

容器与 Kubernetes 部署

先在 CI 构建应用 JAR 并执行测试，再构建镜像。下面假定构建产物为 app.jar，应用与 JDK 17 兼容：

FROM eclipse-temurin:17-jre
WORKDIR /app
COPY --chown=10001:10001 app.jar /app/app.jar
USER 10001
EXPOSE 20880
ENTRYPOINT ["java", "-XX:MaxRAMPercentage=70.0", "-jar", "/app/app.jar"]

生产镜像固定经过审核的补丁版本或 digest。Provider 的 Deployment 片段：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-provider
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-provider
  template:
    metadata:
      labels:
        app: demo-provider
    spec:
      terminationGracePeriodSeconds: 60
      containers:
        - name: provider
          image: registry.example.com/apps/demo-provider:1.0.0
          ports:
            - name: rpc
              containerPort: 20880
          resources:
            requests:
              cpu: 250m
              memory: 512Mi
            limits:
              memory: 1Gi
          startupProbe:
            tcpSocket:
              port: rpc
            periodSeconds: 5
            failureThreshold: 30
          readinessProbe:
            tcpSocket:
              port: rpc
            periodSeconds: 5

该镜像地址是项目构建产物占位地址，不是公共可下载示例。TCP 探针只能证明端口监听；生产应使用应用提供的健康接口确认依赖和服务就绪。避免把注册中心短暂故障直接变成 liveness 失败，引起所有实例反复重启。

同一 Kubernetes 集群内一般注册 Pod IP，由 Consumer 直接调用。跨集群、NAT 或宿主机网络部署时，明确配置可达的通告地址，并验证注册中心返回的每个地址；单独创建 Service 不会自动改写已注册的 Pod IP。通过 NetworkPolicy 允许 Consumer 到 RPC 端口，以及双方到注册中心的必要流量。

超时、重试与幂等

• 超时从业务延迟目标向下分配，覆盖连接、排队、执行和序列化。避免每层都设置很长超时导致线程和连接堆积。
• retries 通常是首次调用以外的重试次数；不同容错策略和方法配置会影响实际行为。
• 写操作默认关闭框架重试，以请求幂等键、唯一约束和状态机处理超时后的不确定结果。
• 幂等读操作可在延迟预算内有限重试，并配合退避、隔离、限流和熔断；不要由网关、客户端和框架各自无限重试。
• 故障转移策略、负载均衡、线程池和队列容量按接口流量测试，扩大线程池不能解决持续慢下游。

发布与治理

滚动发布时先启动新实例并通过就绪检查，再下线旧实例。应用接收 SIGTERM 后应停止接收新请求、从注册中心注销并排空在途调用；Kubernetes 的终止宽限时间要覆盖注销传播和排空时间。实际停机参数按 Dubbo 与 Spring Boot 版本核对。

管理端仅在内网提供访问控制。RPC 链路采用目标协议支持的认证和 TLS/mTLS，限制反序列化类型及可访问接口；升级时检查依赖漏洞与序列化兼容，不能依靠隐藏端口保护服务。

监控与排障

监控按应用、接口、方法和结果统计调用量、P95/P99、错误率、超时、活跃线程、队列和连接池。Trace 贯通 HTTP、RPC 与数据库，避免将请求 ID、用户 ID 等高基数字段放进指标标签。

升级先在测试环境覆盖接口兼容、注册发现、故障转移、重试和停机。Dubbo Admin 的状态只能辅助判断，验收必须包含真实 Consumer 到 Provider 的完整调用。

• Dubbo 文档
• Dubbo 示例