P90 Dubbo 的整体架构设计及分层

面试题：Dubbo 的整体架构是什么样的？分哪些层？

1. 整体分层（自上而下）

Service 服务层（业务接口）
Config 配置层（XML/注解/API 配置）
Proxy 代理层（服务接口的本地代理）
Registry 注册中心层（服务注册与发现）
Cluster 集群层（容错、负载均衡）
Monitor 监控层（调用统计）
Protocol 协议层（远程调用协议，Dubbo 协议/gRPC/REST...）
Exchange 信息交换层（请求响应模型）
Transport 网络传输层（Netty/Mina）
Serialize 序列化层（Hessian/JSON/Protobuf...）

2. 一次调用的流转

Consumer 业务代码
 → Proxy（本地代理，透明调用）
 → Cluster（选集群策略：容错 + 负载均衡）
 → Directory（从 Registry 拿提供者列表）
 → Protocol/Exchange/Transport（序列化 + 网络发送）
 → Provider 端逆序接收、反序列化、执行
 → 结果返回
 → Monitor 记录调用统计

3. 核心角色

• Provider（提供者）：暴露服务，启动时向注册中心注册；
• Consumer（消费者）：订阅服务，本地持有接口代理；
• Registry（注册中心）：服务注册、发现、变更通知（Zookeeper/Nacos）；
• Monitor（监控中心）：收集调用次数、耗时、异常；
• Container（容器）：服务运行容器（Spring）。

4. 各层职责要点

• Proxy 层：让调用方"像调本地方法一样"调远程（JDK 动态代理/字节码）；
• Cluster 层：Failover（失败重试）、Failfast、Failsafe + 负载均衡（Random/RoundRobin/LeastActive/ConsistentHash）；
• Protocol 层：默认 Dubbo 协议（TCP + Hessian 序列化），可选 RMI/HTTP/gRPC/REST；
• Transport 层：默认 Netty，异步非阻塞；
• 序列化层：Hessian2 默认、可配 JSON/Protobuf/Kryo。

5. 加分点

• 能说出 Dubbo 是分层可插拔设计（SPI 扩展：换注册中心、换协议、换序列化都行）；
• 提到与 SpringCloud 对比：Dubbo RPC 性能好、服务治理强；SpringCloud 生态全、HTTP 更通用；
• 追问"注册中心挂了还能调吗"：本地缓存服务列表，可继续调用但不能感知变化；
• 提到 3.x 的 Triple 协议（gRPC 兼容）和新一代治理。

一句话总结

Dubbo 采用分层架构：Config → Proxy → Registry → Cluster → Protocol → Exchange → Transport → Serialize，各层可插拔（SPI）；一次调用从消费者代理出发，经集群容错、注册发现、协议序列化、Netty 传输到达提供者，监控层全程统计。