Dubbo 服务发现与路由的概念有什么不同？

面试考察点

1. 基础概念区分：这题先看你能不能分清 Dubbo 调用链路里的 “找服务” 和 “选服务”。
2. 调用流程理解：注册中心、目录、路由、负载均衡这些词不能只会背，还得知道它们在一次 RPC 调用里各自站在哪一段。
3. 生产实践意识：服务发现管的是可用实例感知，路由更多用来做灰度、标签、机房、版本、环境隔离这些服务治理。

核心答案

可以先这么答：服务发现回答 “现在有哪些可用服务实例”，路由回答 “这次请求能用其中哪些实例”。

概念	解决的问题	典型输入	典型输出	在调用链路中的位置
服务发现	找到某个接口对应的提供者列表	服务名、接口名、分组、版本、注册中心数据	全量或增量的 Invoker 列表	更靠前，先拿到候选实例
路由	按规则过滤候选实例	候选 Invoker、调用上下文、路由规则	被筛选后的 Invoker 列表	服务发现之后，负载均衡之前

所以别把路由简单理解成服务发现的一部分。它俩经常一起出现，但干的活不一样。

深度解析

一、服务发现：先知道 “去哪找”

Dubbo 的服务发现，说白了就是消费者通过注册中心感知服务提供者的变化。服务提供者启动后，会把自己的地址、接口、版本、分组、元数据等信息注册到注册中心；消费者订阅对应服务，注册中心再把服务实例列表推给消费者。

常见注册中心有 Zookeeper、Nacos、Consul 等。消费者拿到的不是一个写死的地址，而是一组会变化的服务实例。provider 下线、扩容、重启，或者网络有波动，消费者侧都可以通过订阅机制感知到。

二、路由：再判断 “本次能不能调它”

路由发生在已经发现实例之后，它会在这批实例上继续按规则筛一遍。

比如现在发现了 10 个 provider，但当前请求来自上海机房，那就只调用上海机房的 provider；当前用户命中了灰度规则，那就只调用带有 gray=true 标签的 provider；当前消费者是 v2 版本，那就只访问支持 v2 的 provider。

这些场景问的不是 “有没有服务”，而是 “这次调用应该走哪一批服务”。

Dubbo 服务发现与路由流程

这条顺序要记住：服务发现先给候选集，路由把候选集筛小，负载均衡再从剩下的实例里挑一个。

三、路由和负载均衡也别混

这里很多人会顺手混在一起说：服务发现、路由、负载均衡，好像都在 “选 provider”。但它们其实是三层动作。

阶段	重点	举例
服务发现	发现候选实例	这个接口目前有 10 台 provider
路由	过滤候选实例	只允许调用上海机房的 4 台
负载均衡	从剩余实例中选 1 台	按权重、随机、一致性哈希选中某一台

面试时如果能把这三个层次拆开说，面试官一般就知道你不是只背了几个 Dubbo 名词，而是真的理解调用治理这条链路。

常见追问

1. Dubbo 路由有哪些常见类型？

   常见的有条件路由、标签路由、脚本路由、应用级服务发现下的应用级路由等。生产里更常见的是基于标签、机房、环境、版本做流量隔离或灰度发布。

2. 路由发生在负载均衡之前还是之后？

   通常在负载均衡之前。原因也简单：负载均衡要基于路由过滤后的可用 Invoker 列表，再做最后一次选择。

3. 如果路由过滤后没有 provider 怎么办？

   这要看具体配置和容错策略。有些场景会直接报错，有些可以配置是否强制路由、是否允许回退到其他实例。生产灰度时这块要特别小心，规则写错了，真的可能把流量全筛没。

记忆口诀

发现是 “找全”，路由是 “筛掉”，负载均衡是 “挑一个”。

总结

Dubbo 服务发现负责感知服务实例，回答 “服务在哪里”；路由负责按治理规则过滤实例，回答 “这次请求该走哪些实例”。面试时再补一句 “路由在服务发现之后、负载均衡之前”，基本就把这题讲清楚了。