场景灰度发布流量全量走到旧版本新版本 Provider 零流量registry 机器齐全却路由不到路径DynamicDirectory.doList()→RouterChain.route()→ConditionRouter.route()→MatchPair.isMatch()→UrlUtils.isMatchGlobPattern()【遗迹】Provider 注册了灰度流量就是过不去上篇讲了 Dubbo Filter 顺序导致日志丢失的源码追踪这篇来看另一个同样反直觉的问题。Dubbo2.7.23灰度流量全部打到旧版本——但新版本的 Provider 明明在注册中心在线。翻到ConditionRouter.MatchPair.isMatch()的源码才发现——版本号一个字符的偏差让路由把新版本 Provider 全过滤了。灰度发布当天新版本UserService上线了 2 个实例配上了一条条件路由规则force:trueconditions: -host10.0.1.%version2.0.0预期QA 组的机器10.0.1.x 网段发起的 RPC 请求全量路由到version2.0.0的 Provider。结果 QA 验证直接报错No provider available from registry。第一反应网络不通telnet 注册中心端口——通。各节点间网络——正常。第二反应注册中心挂了zkServer.sh status——Mode: leader正常。第三反应Consumer 缓存没刷新重启 Consumer——没用。重启 Provider——没用。清 Dubbo 本地缓存——没用。第四反应Admin 路由规则没下发翻 Admin 页面——规则在enabledtrueforcetrue。折腾了将近 2 个小时直到有人用 zkCli 看了注册中心的 Provider 列表$ls/dubbo/com.example.UserService/providers provider://10.0.2.10:20880/...version1.0.0 provider://10.0.2.11:20880/...version2.0.0 provider://10.0.2.12:20880/...version2.0provider://10.0.2.13:20880/...versionv2.0.0发现问题了4 个 Provider只有 1 个的 version 精确等于2.0.0。另外 3 个要么少了.0要么多了v前缀要么是旧版本的1.0.0。路由规则要求匹配version2.0.0——其他的全对不上。继续验证——用 Admin API 直接查路由规则和 Provider 版本分布$curl-shttp://dubbo-admin:8080/governance/rules|jq.data[] | select(.servicecom.example.UserService){force:true,conditions:[host 10.0.1.% version 2.0.0],enabled:true}$curl-shttp://dubbo-admin:8080/governance/providers/com.example.UserService|\jq[.[].url | capture(.*version(?ver[^])) | .ver][1.0.0,2.0.0,2.0,v2.0.0]$echo精确匹配 version2.0.0 的 Provider 数量:$(curl-s...|jq[.[].url | test(version2.0.0[ ])] | length)精确匹配version2.0.0 的 Provider 数量:14 个 Provider 只有 1 个满足条件。如果这个 Provider 负载一高就超时——灰度入口只有 1 个节点可用。如果它恰好挂了——doList()返回空列表 → 灰度组的请求全挂。【发掘】源码追踪从路由规则到 isMatch 的全链路Admin 上那行host 10.0.1.% version 2.0.0是怎么变成对 Provider 的版本过滤逻辑的第一步ConditionRouter.init()收到 Admin 下发的规则字符串用拆分为 when 条件和 then 条件ConditionRouter.java#L89-L106, Dubbo 2.7.23对于这条规则when 条件为空匹配所有请求then 条件为host 10.0.1.% version 2.0.0。第二步parseRule()用正则([!,]*)\\s*([^!,\\s])顺序解析 then 条件的每个 tokenhost→ 创建 MatchPair作为 key 存入 condition map10.0.1.%→ 分隔符→ 加入 pair.matchesversion→ 分隔符→ 创建新的 MatchPair2.0.0→ 分隔符→ 加入 pair.matches解析完成后thenCondition结构为{host→ MatchPair{matches[10.0.1.%],mismatches[]},version→ MatchPair{matches[2.0.0],mismatches[]}}第三步ConditionRouter.route()遍历所有 Provider Invoker对每个调用matchThen()matchThen(providerUrl, consumerUrl)→ matchCondition(thenCondition, providerUrl, consumerUrl, null)→ 取 providerUrl 的version参数值 →2.0或2.0.0或v2.0.0→ MatchPair.isMatch(2.0, null)→matches[2.0.0],mismatches[]→ UrlUtils.isMatchGlobPattern(2.0.0,2.0, null)→ pattern 无*→2.0.0.equals(2.0)→false关键认知字符串精确匹配不会因为你只差了一个.0就放过你。2.0.0.equals(2.0)永远等于 false。【路径】zkCli 三步定位 version 格式影响矩阵三命令定位法# 命令 1查所有 Provider 的 version 分布$ zkCli.shls/dubbo/com.example.UserService/providers|\grep-oPversion\K\S(?|$)|sort|uniq-c|sort-rn1v2.0.012.0.012.011.0.0# 命令 2查 Provider 总数和匹配数$ zkCli.shls/dubbo/com.example.UserService/providers|wc-l4$ zkCli.shls/dubbo/com.example.UserService/providers|grepversion2.0.0|wc-l1# 命令 3查灰度路由规则条件$curl-shttp://dubbo-admin:8080/governance/rules|jq.data[] | select(.servicecom.example.UserService) | .conditions[]host 10.0.1.% version 2.0.0三条命令30 秒。结果明确路由规则要求version2.0.0但实际 Provider 版本五花八门。版本格式影响矩阵同一路由规则host 10.0.1.% version 2.0.0不同 version 格式的匹配结果Provider versionisMatch原因灰度影响1.0.0false旧版本值不同正常——旧版本就不该进灰度2.0.0true精确匹配正常——唯一被选中的节点2.0false少.0字符串不等容量减少 50%——灰度只有 1 个节点v2.0.0falsev前缀不等新版本被过滤灰度等于没部署2.0.0-SNAPSHOTfalseSNAPSHOT 后缀开发版本意外进入灰度被过滤V2.0.0false大写 V大小写不敏感不——Java 字符串敏感02.0.0false前导零人类看着一样equals说不一样通配符匹配的工作方式如果把路由条件改成version 2.0*用星号结尾匹配规则变成startsWithProvider versionisMatch(2.0*)原来 isMatch(2.0.0)2.0.0truetrue2.0truefalse ← 修复了2.0.1truefalse ← 可能误伤2.0.0-SNAPSHOTtruefalse ← 可能误伤v2.0.0falsefalse —v前缀依然不行version 2.0*能救回2.0格式偏差但救不了v2.0.0。根源在于——v 前缀说明版本管理系统本身就存在不一致不是路由条件能兜底的。【解读】Dubbo 为什么不用语义化版本比较——以及这个设计决策的代价一个合理的追问Dubbo 做路由匹配时为什么不用语义化版本比较2.0.0 2.0 2而是用字符串精确匹配看UrlUtils.isMatchGlobPattern()的实现——它是路由匹配的统一内核处理所有 URL 参数的比对application、host、interface、version、methods……全走同一套逻辑。如果version要特殊处理——解析三段的 semantic version、做数值比较——那这条流水线就要为version开一个特例分支。这个特例意味着每来一个 key都要判断 “是不是 version”如果是还要判断 “语义化版本格式是否正确”万一有人用gray-20260705做版本号Version类的解析要写正则、要处理SNAPSHOT、要兼容1.0.0.RELEASEDubbo 的选择很明确保持路由匹配逻辑的统一性不为特定参数开特例。version和其他参数一样走equals或startsWith——框架层面不做语义化理解。这不是一个 Bug是一个设计取舍。但问题是这个取舍的代价通常不会在开发阶段暴露而是在灰度发布当天才炸。开发环境所有人用同一个 SNAPSHOT 版本version 写对了没有从来不是 PR review 的内容。直到灰度路由规则需要精确匹配版本号时才发现各团队对 version 的写法从来没有统一过——有人写2.0.0有人写2.0有人写v2.0.0有人压根没写。一句话总结这个设计决策的代价Dubbo 把版本管理的责任完全交给了团队规范。框架不帮你兜底。对比来看Spring Cloud 的版本路由走的是另一条路——通过Eureka的metadata-map做 tag 路由版本只是一个 metadata 键值对匹配逻辑也是字符串比对同样不做语义化版本比较。不是框架不愿意是通用框架不可能预知你用什么版本号格式。统一性优先于特例优化是这类框架的共性选择。版本管理不善的根本原因回到这个案例——问题根源不是ConditionRouter代码写错了而是三个层面的管理缺失没有版本号规范谁写v2.0.0、谁写2.0、谁不写——没有规则没有预检机制灰度规则上线前没有核查 “Provider version 是否与规则条件一致”没有兜底forcetrue放大了问题——如果forcefalse至少还能回退到全部 Provider这三个缺失叠加在一起不规范的版本号 不检直接上 force 不放水 → 灰度失败。【收获】排查锚点 版本管理规范下次遇到灰度流量没到新版本先搜 Provider URL 中的 version 参数。版本号差一个字符路由判不匹配。源码路径速查角色类名方法版本目录服务DynamicDirectorydoList()Dubbo 2.7.23路由入口RouterChainroute()Dubbo 2.7.23条件路由ConditionRouterroute()→matchThen()Dubbo 2.7.23规则解析ConditionRouterinit()→parseRule()Dubbo 2.7.23匹配逻辑ConditionRouter.MatchPairisMatch()Dubbo 2.7.23匹配内核UrlUtilsisMatchGlobPattern()Dubbo 2.7.23版本管理三阶段成熟度级别做法灰度发布时L1 混乱version 随意写、有人不写路由匹配全看运气大概率失败L2 规范统一X.Y.Z格式CI/CD 自动注入精确匹配通过灰度稳定L3 预检自动脚本比对 Provider version 与路由规则条件上线前发现问题而不是上线后灰度上线前预检脚本#!/bin/bash# check-version-match.sh — 灰度前必检SERVICEcom.example.UserServiceTARGET_VER2.0.0# 查 Provider version 分布VERSIONS$(zkCli.shls/dubbo/$SERVICE/providers|grep-oPversion\K\S(?|$))echo Provider version 分布 echo$VERSIONS|sort|uniq-c|sort-rnecho 精确匹配$TARGET_VER的数量 MATCH$(echo$VERSIONS|grep-c^$TARGET_VER$)echo$MATCHif[$MATCH-eq0];thenecho❌ 没有 Provider 匹配 version$TARGET_VER灰度无法工作exit1elif[$MATCH-lt3];thenecho⚠️ 只有$MATCH个 Provider 匹配容量不足exit0elseecho✅$MATCH个 Provider 匹配灰度就绪fi最终建议一条简单规则Consumer 和 Provider 的 version 保持完全一致。2.0≠2.0.0v2.0.0≠2.0.0。Dubbo 不做语义化版本比较——它也做不到因为 version 可以是任何字符串比如gray-20260705。灰度前的每一次发布花 30 秒跑一遍grep version把版本号分布列出来看一眼。版本号差一个字符路由判不匹配——但这个一个字符的代价可能是灰度失败后的 2 小时排查。一个异常堆栈 一个类的某个方法出了问题。下次遇到灰度路由为空先搜 Provider URL 中的 version 参数。下篇我们聊聊 Dubbo 集群负载均衡策略选型不当导致的服务响应不均。