Dubbo 的核心架构是怎样的？服务治理如何实现？

Dubbo 架构的五大角色

Dubbo 的架构围绕五个核心角色展开，理解它们之间的协作关系是掌握 Dubbo 的第一步。

调用链路：Consumer 发起调用 → 从 Registry 获取 Provider 地址列表 → 通过负载均衡选一台 Provider → Provider 执行并返回结果 → Monitor 记录调用数据。

Provider（服务提供者） 暴露服务接口，启动时将自己的地址和元数据注册到 Registry。一个服务可以部署多个 Provider 实例，Consumer 端通过负载均衡策略选择调用哪个实例。

Consumer（服务消费者） 从 Registry 订阅所需服务，获取 Provider 列表后缓存在本地。后续调用直接使用本地缓存，即使 Registry 宕机也不影响已有连接。

Registry（注册中心） 是服务发现的核心。Dubbo 支持 Zookeeper、Nacos、Redis 等实现，其中 Zookeeper 和 Nacos 是生产环境最常用的选择。Registry 通过长连接推送机制，在 Provider 上线或下线时实时通知 Consumer 更新本地缓存。

Monitor（监控中心） 负责统计调用次数和耗时，数据先在内存汇总，每分钟发送一次。Monitor 不参与实际调用链路，宕机不影响服务运行，只丢失采样数据。

Container（服务运行容器） 负责启动和加载 Provider，Spring Container 和 Spring Boot 是主流选择。

架构的健壮性设计值得注意：注册中心集群对等部署，任意节点宕机自动切换；注册中心全部宕机后，Consumer 仍能通过本地缓存与 Provider 通信；Provider 无状态，单节点宕机不影响整体服务。

服务调用与协议选择

Dubbo 支持多种通信协议，选择合适的协议直接影响系统性能。

Dubbo 协议是默认选项，基于 Netty 的长连接 + NIO 异步传输，采用单一长连接和 Hessian 二进制序列化，适合小数据量高并发的服务间调用。这也是多数生产环境的首选。

Triple 卆议是 Dubbo 3.x 推出的新协议，基于 HTTP/2，兼容 gRPC，支持流式通信。如果系统需要跨语言调用或与 gRPC 生态对接，Triple 是更好的选择。

其他协议如 HTTP、Hessian、REST 适用于特定场景：HTTP 适合与前端直接交互的网关服务，REST 适合对外暴露 API。

调用方式上，Dubbo 支持同步调用、异步调用和泛化调用。异步调用通过 CompletableFuture 实现，适合需要并行调用多个服务的场景；泛化调用不需要 Provider 端的接口定义，适合网关或测试平台这类通用调用方。

集群容错策略

当 Provider 出现故障时，Dubbo 提供六种容错策略应对不同场景：

Failover（失败自动重试） 是默认策略，自动切换到其他 Provider 重试。通过 retries 参数控制重试次数（不含首次调用），默认重试 2 次。适合读操作，写操作需谨慎——重试可能导致数据重复写入。

Failfast（快速失败） 只发起一次调用，失败立即报错。适合非幂等的写操作，如创建订单、扣款，避免重试带来的副作用。

Failsafe（失败安全） 出现异常时忽略，不抛出异常。适合日志记录、监控上报等非核心操作。

Failback（失败自动恢复） 将失败请求记录到后台队列，定时重发。适合消息通知这类最终一致性场景。

Forking（并行调用） 同时调用多个 Provider，只要一个成功即返回。通过 forks 参数控制并行数。适合对延迟敏感但资源消耗可以接受的场景。

Broadcast（广播调用） 逐个调用所有 Provider，任一失败则报错。适合通知所有节点更新缓存或配置的场景。

实际选型建议：读操作用 Failover，写操作用 Failfast，边缘操作用 Failsafe，这是最常见的选择。

负载均衡机制

Dubbo 内置四种负载均衡策略，核心区别在于请求分发的方式：

Random（加权随机） 是默认策略，按权重设置随机概率。在高并发场景下，随机策略的调用分布趋于均匀，且实现简单、性能开销小。

RoundRobin（加权轮询） 按权重比例依次轮询分配请求。存在慢请求累积问题——某个 Provider 响应慢时，轮询到它的请求都会阻塞。

LeastActive（最少活跃调用数） 优先将请求分配给当前处理中请求数最少的 Provider。这是一种自适应策略，响应越快的 Provider 接收越多请求，能有效避免慢节点堆积。

ConsistentHash（一致性哈希） 相同参数的请求总是路由到同一 Provider。当某个 Provider 下线时，其请求会平滑迁移到相邻节点，不会引起大面积重新分配。适合有状态依赖的场景，如用户会话、分片数据。

权重调节是线上运维的常用手段：通过 Dubbo Admin 或配置中心动态调整权重，可以实现灰度发布和流量倾斜，无需重启服务。

服务治理的核心能力

服务治理是 Dubbo 区别于简单 RPC 框架的关键，涵盖降级、限流、路由三大能力。

服务降级

降级是在 Provider 不可用或响应过慢时，提供兜底方案避免级联故障。

Mock 降级是最常用的方式。在 Consumer 端配置 Mock 类，当调用失败时返回预设数据而非抛出异常：

java
// Mock 类命名规则：接口名 + Mock
public class UserServiceMock implements UserService {
    @Override
    public User getUserById(Long id) {
        return new User(id, "default_user");
    }
}

// 配置方式
<dubbo:reference interface="com.example.UserService" mock="true"/>

也可以使用 force:return 强制返回指定值，不发起远程调用，用于手动降级。

服务限流

限流从 Provider 和 Consumer 两个维度控制流量：

Provider 端通过 executes 限制每个方法的并发执行数，超出拒绝请求。Consumer 端通过 actives 限制每个服务的并发调用数。Dubbo 3.x 还支持基于 QPS 的限流配置。

生产环境中，限流配置通常放在配置中心，根据监控数据动态调整。

服务路由

路由规则决定请求分发给哪些 Provider，是实现流量控制的核心机制：

条件路由是最基础的规则，支持按 IP、应用名、服务名等条件过滤。典型场景：将测试流量路由到灰度机器，线上流量路由到正式机器。

标签路由是 Dubbo 3.x 推荐的方式，通过给 Provider 打标签实现流量隔离。例如给灰度机器打上 gray 标签，Consumer 端指定 gray 标签即可将流量路由到灰度环境。

脚本路由支持通过 JavaScript 等脚本编写复杂路由逻辑，灵活性最高但维护成本大，生产环境慎用。

注册中心与服务发现

注册中心的选择直接影响服务发现的稳定性和功能：

Zookeeper 是最早支持且使用最广泛的实现，基于树形节点存储服务数据，支持临时节点自动清理下线服务。CAP 模型中偏向 CP，在 Leader 选举期间不可用。适合对一致性要求高的场景。

Nacos 是阿里推出的注册中心，同时支持 AP 和 CP 模式切换，内置配置中心功能，与 Spring Cloud 生态兼容。如果项目同时使用 Spring Cloud 和 Dubbo，Nacos 是统一注册中心的最佳选择。

服务发现流程：Provider 启动 → 向 Registry 注册 → Consumer 启动 → 从 Registry 订阅 → Registry 推送 Provider 列表 → Consumer 本地缓存并监听变更。关键点是 Consumer 会缓存 Provider 列表，Registry 推送变更时增量更新，即使 Registry 全部宕机，Consumer 仍能通过本地缓存调用 Provider。

配置中心的作用

Dubbo 3.x 将配置中心独立出来，与注册中心解耦。配置中心负责外部化配置管理、动态配置推送和配置版本管理，支持 Nacos、Zookeeper、Apollo 等实现。

动态配置是配置中心的核心价值。修改服务超时时间、负载均衡策略、权重等参数后，配置中心实时推送到所有节点，无需重启服务。这在处理线上问题时非常关键——某个服务响应变慢，可以立即调大超时时间而不是等待发布。

面试追问方向

Q：Dubbo 和 Spring Cloud 如何选型？ Dubbo 专注 RPC 通信和服务治理，性能优于 Spring Cloud 的 HTTP 通信；Spring Cloud 提供更完整的微服务解决方案（网关、配置、链路追踪等）。内部服务间调用选 Dubbo，需要完整微服务栈选 Spring Cloud，两者也可以通过 Nacos 共存。

Q：Dubbo 3.x 相比 2.x 有哪些重大变化？ Triple 协议替代 Dubbo 协议成为推荐协议；应用级服务发现替代接口级服务发现，减少注册中心压力；服务路由引入标签路由作为推荐方案。理解这些变化有助于理解 Dubbo 的演进方向。