Dubbo RPC 体系

• 服务暴露流程
• 服务引用流程
• Invoker 链路

Dubbo 服务暴露流程：ServiceConfig（服务配置）→ ProxyFactory 创建服务代理 → Invoker（服务调用者抽象）→ Protocol.export 暴露（绑定端口、创建网络服务）→ 注册到注册中心（RegistryProtocol 注册 URL）。服务引用流程：ReferenceConfig（引用配置）→ Protocol.refer 创建 Invoker（从注册中心发现服务）→ ProxyFactory 创建客户端代理 → 调用时通过 Invoker 发送 RPC。链路：ServiceConfig → Proxy → Invoker → Protocol → Register；ReferenceConfig → Proxy → Invoker → Protocol → Register。Invoker 是核心抽象，封装服务调用；注册中心管理服务地址。工程上：理解暴露/引用链路，掌握 Invoker 与注册中心协作。

暴露是"配置 → 代理 → Invoker → 协议暴露 → 注册"，引用是"配置 → 代理 → Invoker → 协议引用 → 发现"。Invoker 是核心。

• Dubbo SPI vs JDK SPI
• @Adaptive 自适应
• IoC/AOP

Dubbo SPI 与 JDK SPI 区别：JDK SPI 用 META-INF/services 加载全部实现，无法按需/按名加载；Dubbo SPI 用 META-INF/dubbo/@SPI 约定，支持按名称加载、按需（key 选择实现）、接口默认实现、扩展点分类。自适应扩展（@Adaptive）：@Adaptive 标注方法，Dubbo 动态生成适配代码，根据参数（URL 的 key）选择对应实现，实现"运行时按需选择扩展"。IoC/AOP：Dubbo SPI 支持注入（扩展点通过 setter 注入依赖的扩展）、包装（Wrapper 装饰器实现 AOP，Wrapper 包装扩展）。工程上：Dubbo SPI 比 JDK SPI 强大（按需、自适应、IoC/AOP），用于扩展协议、序列化、负载均衡等。

Dubbo SPI 是"增强版 SPI"：按名加载、@Adaptive 自适应、IoC 注入、Wrapper AOP。比 JDK SPI 灵活。

• 线程模型
• IO vs 业务线程
• 连接与拒绝策略

Dubbo 线程模型：IO 线程（Netty 的 event loop）负责网络读写，业务线程池负责执行业务逻辑（IO 线程把请求交给业务线程池）。连接管理：connections 配置连接数（长连接复用），worker 线程数（IO 线程）。线程池：threadpool 配置（fixed/cached），queues 队列，threads 线程数，拒绝策略——队列满时按 threadpool 配置拒绝（如 AbortPolicy 抛异常、CallerRunsPolicy 调用方执行）。工程上：区分 IO 线程（网络）与业务线程（逻辑），配置连接数与线程池，避免线程池满导致拒绝。虚拟线程/Boot 4 下可优化线程模型。

线程模型是"IO 线程 + 业务线程池"。连接管理、线程池配置、拒绝策略影响性能与稳定性。需合理配置。

• 泛化调用
• GenericService
• 应用场景

Dubbo 泛化调用（GenericService）：不依赖服务接口的 class，通过 GenericService 泛化接口直接调用服务（传入方法名与参数），用于服务端没接口 jar 的场景。泛化引用：客户端用 GenericService 引用服务，无需接口定义。应用场景：网关/路由（统一转发任意服务）、测试平台（调用任意服务）、多语言/脚本（无接口）、服务治理（动态调用）。泛化调用用 Pojo/Map 传参，序列化兼容。工程上：泛化调用适合"无接口的通用调用"（网关、测试、脚本），避免硬依赖接口 jar。

泛化调用是"无接口 jar 的通用调用"。GenericService 泛化接口，适合网关/测试/多语言。参数用 Map/Pojo。

• Dubbo 灰度
• Mesh 化
• Proxyless 迁移

Dubbo 流量灰度在 Mesh 化下的迁移路径：从应用内灰度（Dubbo 中心路由规则、标签路由）迁移到 Mesh 化灰度（Envoy Sidecar 或 Dubbo3 Proxyless）。Mesh 化灰度：Envoy——通过 Sidecar 注入按标签/权重路由（VirtualService/DestinationRule）；Dubbo3 Proxyless——Dubbo 直接与 Istio 控制面集成（xDS），无需 Sidecar，用 xDS 规则灰度。迁移路径：先应用内灰度（Dubbo 标签路由）验证 → 再迁移到 Mesh 灰度（Envoy/Proxyless）→ 用 Mesh 统一流量治理。Proxyless 减少 Sidecar 开销，兼容 Dubbo 治理。工程上：灰度从应用内迁移到 Mesh（Envoy/Proxyless），统一流量治理。

迁移是"应用内灰度 → Mesh 灰度"。Envoy Sidecar 或 Proxyless 用 xDS 规则。Proxyless 免 Sidecar 开销。

• Triple vs gRPC
• 协议差异
• 工程差异

Dubbo Triple 协议（HTTP/2 + Protobuf）相较 gRPC 的工程差异：Triple 与 gRPC 都基于 HTTP/2 + Protobuf，协议兼容（Triple 可互通 gRPC），但 Triple 承载 Dubbo 的能力：Dubbo 的治理（负载均衡、路由、灰度、容错）、Dubbo 的序列化（支持 hessian2 等，不限于 Protobuf）、Dubbo 的注册中心集成。工程差异：Triple 兼有 gRPC 的标准化（HTTP/2、跨语言、流式）与 Dubbo 的治理能力；gRPC 是通用 RPC（跨语言），Triple 是 Dubbo 生态的协议。差异：Triple 更贴合 Dubbo 服务治理，gRPC 更通用。工程上：Triple 在 Dubbo 生态内享受治理 + 标准协议，gRPC 适合纯跨语言。

Triple 是"gRPC 协议 + Dubbo 治理"的结合。兼容 gRPC（HTTP/2/Protobuf）又承载 Dubbo 能力。这是工程差异核心。

• 负载均衡策略
• 适用场景
• 选择

Dubbo 负载均衡策略：随机权重（RandomLoadBalance）——按权重随机选实例，默认，适合常规、权重差异化；最少活跃（LeastActiveLoadBalance）——选活跃数最少的（处理中请求少的）实例，适合处理能力差异、负载不均；一致性哈希（ConsistentHashLoadBalance）——按参数哈希到固定实例，适合有状态（会话）、缓存命中；最短响应（ShortestResponseLoadBalance）——选响应时间最短的实例，适合追求低延迟。选择：无状态常规用随机权重；负载不均用最少活跃；有状态/缓存用一致性哈希；低延迟用最短响应。工程上：按状态与负载特征选择负载均衡策略。

各策略适用：随机（常规）、最少活跃（负载不均）、一致性哈希（有状态）、最短响应（低延迟）。按场景选择。

• Triple vs Dubbo2 协议
• HTTP/2
• gRPC 互通

Dubbo 3 的 Triple 协议相比 Dubbo2 协议的变化：Dubbo2 是自定义二进制协议（TCP 长连接 + hessian2），Triple 是 HTTP/2 + Protobuf 协议。变化：传输层从 TCP 自定义变为 HTTP/2（多路复用、流式、标准）；序列化从 hessian2 变为 Protobuf（高效、跨语言）；可观测性（HTTP 语义）。为什么基于 HTTP/2 与 gRPC 互通：HTTP/2 是标准协议（多路复用、跨语言、可观测），gRPC 基于 HTTP/2 + Protobuf，Triple 同构，故可与 gRPC 互通（跨语言、标准化）。价值：跨语言、标准化、可观测、云原生（Mesh 友好）。工程上：Triple 用 HTTP/2 标准化 + gRPC 互通，面向云原生。

Triple 是"HTTP/2 + Protobuf"标准化协议，替代 Dubbo2 私有协议。与 gRPC 同构互通。跨语言、云原生友好。

• 集群容错模式
• 幂等性配合
• 约束

Dubbo 集群容错模式：Failover——失败自动重试其他实例（默认），适合幂等（重试可能重复执行）；Failfast——快速失败，不重试，适合非幂等；Failsafe——失败忽略，返回空，适合不重要的旁路调用；Failback——失败异步重试，适合可异步补偿；Forking——并行调用多个实例取一个成功，适合读多/低延迟。幂等性配合约束：Failover（重试）与 Forking（并行）可能重复执行，只适合幂等操作；非幂等操作（扣款、下单）需用 Failfast 或配合幂等（去重）。工程上：重试型容错（Failover/Forking）需幂等，非幂等用 Failfast。

容错模式决定"失败重试/并行"。重试型（Failover/Forking）放大执行，需幂等；非幂等用 Failfast。配合幂等性约束。

• 暴露与引用
• 本地存根
• 代理创建

Dubbo 服务暴露与引用过程：暴露——ServiceConfig 通过 ProxyFactory 创建服务实现代理，Invoker 经 Protocol（RegistryProtocol）暴露并注册到注册中心；引用——ReferenceConfig 通过 Protocol 从注册中心发现服务创建 Invoker，ProxyFactory 创建客户端代理。本地存根（Stub）：stub 属性，在服务端生成 Stub 类（本地代理，可做本地逻辑如参数校验、缓存），调用前拦截。代理创建：ProxyFactory（Javassist/JDK）生成动态代理，暴露/引用都经代理。注册中心：管理服务地址（URL），暴露时注册、引用时发现。工程上：理解暴露/引用/存根/代理，掌握 Dubbo 调用模型。

暴露/引用经"配置 → 代理 → Invoker → 协议 → 注册中心"。本地存根在客户端做本地逻辑。代理由 ProxyFactory 生成。

• 负载均衡策略
• 集群容错
• 组合

Dubbo 负载均衡（在实例间选）：Random——随机权重；RoundRobin——轮询（加权）；LeastActive——最少活跃（负载感）。集群容错（调用失败后）：Failover——重试其他实例；Failfast——快速失败；Failsafe——忽略；Failback——异步重试；Forking——并行。组合使用：负载均衡决定"选哪个实例"，集群容错决定"失败怎么办"。如 Random 负载均衡 + Failover 容错（默认）：随机选实例，失败重试其他。选型：负载均衡按状态（有状态一致哈希、无状态随机），容错按幂等（幂等 Failover、非幂等 Failfast）。工程上：负载均衡 + 集群容错组合配置，按业务特征选择。

负载均衡管"选哪个"，容错管"失败怎么办"。二者组合。按状态与幂等性选择策略。

• 优雅停机
• 注册中心下线
• 流量摘除

Dubbo 优雅停机流程：先注销注册中心（从注册中心下线，通知消费者不再路由到本实例）→ 停止接收新请求 → 等待处理中的请求完成（排空）→ 关闭连接与资源。注册中心下线通知：Registry 的 unregister 通知消费者实例下线，消费者缓存更新。流量摘除：下线后消费者不再路由到本实例，配合排空保证在途请求完成。顺序：先下线（摘流量）→ 排空 → 关闭。K8s 下配合 preStop/readiness。工程上：优雅停机先摘流量（注册中心下线）再排空，避免中断。

优雅停机是"先下线（摘流量）→ 排空 → 关闭"。注册中心下线通知消费者，排空在途请求。顺序关键。

• injvm 本地调用
• url 直连
• 场景

Dubbo 本地调用（injvm）：scope=local 或 injvm 协议，调用本 JVM 内的服务（不经过网络），适合本地测试/同一进程内调用，避免网络开销。直连（url 直连）：url 直接指定服务地址，绕过注册中心，适合测试/联调（指定目标实例）、注册中心不可用时的临时调用。场景：injvm——本地调试、同进程内调用（避免网络）；url 直连——测试指定实例、联调、绕过注册中心。工程上：injvm 本地调用省网络，url 直连测试/联调，生产用注册中心。

injvm 是"本进程调用"（省网络），url 直连是"绕过注册中心指定地址"（测试/联调）。场景明确。

• 异步调用
• CompletableFuture
• 性能拐点

Dubbo 异步调用：CompletableFuture 异步接口（sayHelloAsync 返回 CompletableFuture）、AsyncContext/RpcContext 异步。异步调用不阻塞调用线程，提高吞吐（IO 等待期间处理其他请求）。同步性能拐点：同步调用在高并发下，调用线程阻塞在等待响应，线程池耗尽成为瓶颈（吞吐下降）；异步调用在较早期就通过非阻塞提升吞吐，拐点后移。异步收益：高并发/IO 密集场景吞吐提升；代价：编程复杂（回调/异步）。虚拟线程下同步调用也高效（虚拟线程阻塞便宜），异步/同步权衡变化。工程上：高并发 IO 场景用异步（CompletableFuture），虚拟线程下同步也可达高吞吐。

异步非阻塞提升吞吐，拐点后移（线程池不耗尽）。虚拟线程下同步阻塞也便宜。权衡异步复杂度与吞吐。

• Dubbo vs OpenFeign
• 性能/生态
• 团队约束

Dubbo 与 OpenFeign 选型对比：性能——Dubbo 基于 TCP 长连接 + 高效序列化（hessian2/Protobuf），性能高于 OpenFeign（HTTP/1.1 + JSON）；协议——Dubbo RPC 协议（Triple/Dubbo2），OpenFeign HTTP/JSON；生态——Dubbo 治理丰富（路由、灰度、容错、泛化），OpenFeign 契合 Spring Cloud 生态（与 LoadBalancer/Sentinel 集成）；团队约束——Java 团队通 Dubbo 更高效，跨语言/对外用 OpenFeign（HTTP 标准）。选型：高性能内部调用、Java 团队选 Dubbo；跨语言/对外/Spring Cloud 生态选 OpenFeign。工程上：纯 Java 内部高性能 Dubbo，对外/跨语言 OpenFeign。

对比是"性能协议 vs 生态标准"。Dubbo 高性能 Java 专注，OpenFeign HTTP 标准贴合 Spring Cloud。按团队与场景选。

• 协议对比
• 治理差异
• 生态

Dubbo 与 gRPC/Spring Cloud 对比：协议——Dubbo 用 Dubbo2/Triple（HTTP/2），gRPC 用 HTTP/2 + Protobuf，Spring Cloud 用 HTTP/JSON；治理——Dubbo 治理丰富（路由、灰度、容错、泛化、注册中心），gRPC 治理弱（需依赖外部），Spring Cloud 治理在框架（LoadBalancer/Sentinel）；生态——Dubbo Java 生态 + 阿里，gRPC 跨语言通用，Spring Cloud 契合 Spring 生态。差异：Dubbo 强在"治理 + 性能"，gRPC 强在"跨语言标准"，Spring Cloud 强在"Spring 生态"。选型：Java 高性能治理选 Dubbo，跨语言选 gRPC，Spring 生态选 Spring Cloud。工程上：按协议、治理、生态选择。

三者差异是"协议、治理、生态"。Dubbo 治理强、gRPC 跨语言、Spring Cloud 生态。按需求选型。

• 路由规则
• 权重
• 容错配置

Dubbo 服务治理配置：路由规则——通过 RuleRouter（条件路由/标签路由）配置按条件（IP、tag、参数）路由到指定实例，实现灰度/隔离；权重——实例权重（weight）配置影响负载均衡（随机/轮询按权重）；容错——集群容错（Failover/Failfast）、负载均衡策略、重试次数（retries）、超时（timeout）。配置方式：注解/application.yml/动态配置中心（RuleRouter 通过配置中心下发）。治理：路由（去哪些实例）、权重（分配比例）、容错（失败怎么办）。工程上：动态配置路由/权重/容错，实现灰度与治理。

治理是"路由（去哪）+ 权重（分配）+ 容错（失败）"。动态配置中心下发，实现灰度与容错治理。

• 扩展点加载
• @Adaptive
• 机制

Dubbo 的 SPI 机制：扩展点加载——通过 ExtensionLoader 加载接口的扩展实现（META-INF/dubbo 接口名文件，@SPI 标注接口），支持按名称（key）加载、缓存、按需。自适应扩展（@Adaptive）：@Adaptive 标注方法，Dubbo 生成动态适配代码，运行时根据 URL 参数（如 protocol、loadbalance）选择对应扩展实现，实现"运行时不写死实现"。机制：ExtensionLoader.getExtensionLoader(接口).getAdaptiveExtension() 获取自适应实例，调用时按 URL 的 key 分发到具体实现。工程上：@SPI + @Adaptive 实现扩展点按需与自适应选择，是 Dubbo 可扩展性的核心。

SPI 按名加载扩展，@Adaptive 生成自适应代码按 URL 分配。ExtensionLoader 是核心。实现可扩展性。

• hessian2 序列化
• 兼容性
• 性能

Dubbo 的 hessian2 序列化：Dubbo2 协议默认用 hessian2 序列化。兼容性——hessian2 是跨语言二进制序列化（与 Hessian 兼容），但 Java 特有类型（如某些集合、泛型）兼容性有坑；版本兼容需要注意（hessian2 不同版本差异）。性能——hessian2 比 Java 原生序列化快、体积小，但比 Protobuf/Kryo 略慢（通用序列化）。问题：hessian2 对复杂对象、泛型、跨语言兼容性弱；性能不如 Protobuf/Kryo。优化：Dubbo3 用 Triple + Protobuf（性能/兼容更好），或用 Kryo/FST 高性能序列化。工程上：hessian2 通用但性能/兼容有限，Dubbo3 用 Protobuf 优化。

hessian2 是"Dubbo2 默认序列化"。兼容性（跨语言/Java 类型）与性能（不如 Protobuf/Kryo）是问题。Dubbo3 用 Protobuf 优化。