Provider 注册了灰度流量就是过不去

上篇讲了 Dubbo Filter 顺序导致日志丢失的源码追踪，这篇来看另一个一样反直觉的问题。

Dubbo灰度流量全部打到旧版本——但新版本的 Provider 明明在注册中心在线。翻到 ConditionRouter.MatchPair.isMatch 的源码才发现——版本号一个字符的偏差，让路由把新版本 Provider 全过滤了。

灰度发布当天新版本 UserService 上线了 1 个实例。配上了一条条件路由规则：

force: true
conditions:
- host = 10.0.% => version = .

预期：QA 组的机器发起的 RPC 请求，全量路由到 version=. 的 Provider。

结果：QA 验证直接报错：No provider available from registry

排查思路与痛点回顾

• #1 网络不通？ telnet 注册中心端口——通。按理说，各节点间网络——正常。
• #2 注册中心挂了？老实说， zkServer.sh status——Mode: leader正常。
• #3 Consumer 缓存没刷新？话说回来， 重启 Consumer、重启 Provider、清 Dubbo 本地缓存——均无效。
• #4 Admin 路由规则没下发？说起来， 打开 Admin 页面——规则在enabled=true。force=true

折腾近 2 小时后有人用 zkCli 查看注册中心的 Provider 列表：

$ ls /dubbo/com.example.UserService/providers
provider://10.1.1.1:20880/com.example.UserService?version=.
provider://10.1.1.2:20880/com.example.UserService?按理说，version=
provider://10.1.1.3:20880/com.example.UserService?version=v2.
...

发现问题：a) 只有 1 个 Provider 的 version 精确等于 “.”；b) 其余 Provider 要么缺少 “.”。要么多了 “v” 前缀，要么是旧版 “.”。路由规则要求匹配 version=.-其他全部不匹配。

#验证步骤：

$ curl -s http://dubbo-admin:8080/governance/rules | jq '.data | select'
{
"force": true,"conditions":。"enabled": true
}
$ curl -s http://dubbo-admin:8080/governance/providers/com.example.UserService \
| jq '.url | capture") | .ver]'
$ echo "精确匹配 version=. 的 Provider 数量:" \
$(curl -s http://dubbo-admin:8080/governance/providers/com.example.UserService \
| jq '.url | test ] | length')
精确匹配 version=. 的 Provider 数量: 1

If that single Provider spikes or crashes,DyanmicDirectory.doList` returns an empty list → 灰度请求全挂。

再看源码追踪。从路由规则到 isMatch 的全链路

下面一步步拆解：

Step 1 – ConditionRouter.init

`ConditionRouter.init` 接收 Admin 下发的规则字符串，用 “=>” 分割为 when 条件和 n 条件。此例中 when 条件为空，n 条件为 “host = 10.% version = .”。

Step 2 – parseRule

`parseRule` 使用正则 `\s*` 按顺序解析 n 条件的每个 token：

• "host" → 创建 MatchPair，放入 condition map。
• "10.%” → 分隔符 “=” → 加入 pair.matches。
• "version" → 同理创建新的 MatchPair。
• "." → 分隔符 “=” → 加入 pair.matches。

The resulting `nCondition` structure:

{
"host" -> MatchPair { matches=,mismatches= },"version"-> MatchPair { matches=,mismatches= }
}

`ConditionRouter.route` 遍历所有 Provider Invoker。对每个调用 `matchThen`：

matchThen
-> matchCondition
-> providerUrl.getParameter // "" / "." / "v2."
-> MatchPair.isMatch
matches=
mismatches=
-> UrlUtils.isMatchGlobPattern
// pattern 无 "*" → exact equals
".".equals // false
".".equals// false
".".equals // true only for single good provider

Cognitive takeaway: String exact match fails if you are off by a single dot.

zkCli 三步定位 + version 格式影响矩阵

三命令定位法

# 步骤①：查看所有 Provider 的 version 分布
zkCli.sh ls /dubbo/com.example.UserService/providers |
grep -oP 'version=\K\S+' |
sort | uniq -c | sort -rn
# 步骤②：统计总数和匹配数
zkCli.sh ls /dubbo/com.example.UserService/providers | wc -l
zkCli.sh ls /dubbo/com.example.UserService/providers |
grep "version=." | wc -l
# 步骤③：确认灰度路由规则条件
curl -s http://dubbo-admin:8080/governance/rules |
jq '.data | select | .conditions'
#=> "host = 10.% => version = ."

The three commands finish in seconds and clearly show mismatch 娱乐ween rule and actual versions.

版本格式影响矩阵

02.false 同理前导零不相等。

Provider version	isMatch	原因
.0	false	A missing dot makes string unequal.
.	true	Crisp exact match – only this node is selected.
.0	false	Lacks trailing dot.
	false	'v' 前缀导致不等。
-SNAPSHOT	false	SNAPSHOT 后缀未被规则覆盖。不过，
false

通配符匹配工作方式

Provider versionisMatch vs isMatch	说明 /tr>
.0	true	equals works because * becomes startsWith	.0	true		false	* still not match leading 'v' true	* catches but may cause unintended traffic

Takeaway: Using * can rescue missing/extra dots but cannot compensate for prefix differences like v.

Dubbo 为什么不用语义化版本比较——还有这个设计决策的代价

The core matching engine is `UrlUtils.isMatchGlobPattern`. It treats every URL parameter—including `application`,`host`,`interface`,**`version`**,`methods`—with same generic logic .

• If Dubbo wanted semantic‑aware comparison,it would have to add a special‑case branch for key “version”. That entails:
  • Dynamically detecting key at runtime.
  • PARSING a semantic string .}
  • The framework deliberately avoids such specialization to keep routing logic uniform and lightweight.This design choice shifts all version‑management responsibility onto teams .
  }
  • The cost becomes visible only during gray releases when an off‑by‑one typo breaks routing entirely.
  }

Resulting risk: Without a shared convention,developers may use .,empty string,v2. or nothing at all—leading to silent routing failures.

根本原因概览

No version naming standard: team A uses “.”,team B uses “vX.”,team C omits it.No pre‑deployment validation: gray rules are pushed without checking that any provider satisfies m.No fallback safety net: force=true amplifies impact—if no match。traffic dies instead of falling back to all providers.

Combined y produce gray release failure.

If gray traffic never reaches new version,first grep **`version=`** parameter from provider URLs—one character difference means no match.

角色	类名	方法	Dubbo版号
目录服务	DynamicDirectory	doList	Dubbo 2.x/tr>
路由入口	RouterChain	route	Dubbo 2.x/tr>
条件路由	ConditionRouter	route → matchThen	Dubbo 2.x/tr>
规则解析	ConditionRouter	init → parseRule	Dubbo 2.x/tr>
匹配逻辑	ConditionRouter.MatchPair	isMatch	Dubbo 2.x/tr>
匹配内核	UrlUtils	isMatchGlobPattern	Dubbo any/tr>

级别 & 行为 & 灰度表现 & 推荐措施/th>

L1 

...

灰度上线前预检脚本示例

bash

SERVICE="com.example.UserService" TARGET_VER="."

VERSIONS=$(zkCli.sh ls "/dubbo/$SERVICE/providers" | grep -oP 'version=\K\S+')

echo "=== Provider version 分布 ===" echo "$VERSIONS" | sort | uniq -c | sort -rn

MATCH=$ echo "=== 精确匹配 $TARGET_VER 的数量 === $MATCH"

if;n echo "❌ 没有 Provider 匹配 version=$TARGET_VER，灰度无法工作！" exit 1 elif;n echo "⚠️ 匹配数量不足，仅 $MATCH 台机器可用" else echo "✅ $MATCH 台 Provider 匹配。灰度就绪" fi

最终建议

• C​onsumer 与 Provider 的 version 必须保持完全一致。 空字符串 ) ≠ 点。点 ≠ 前缀 . Dubbo 不做语义化比较，因为它只能处理任意字符串。
• 在每次灰度发布前，用上面的脚本或类似命令检查一次 grep version` 输出。
• 若需要更灵活的分流。可改用通配符 或基于自定义 tag，而不是依赖精确点号。
• 最根本的是在团队层面制定《Version 命名规范》并在 CI 中强制校验。

A single character discrepancy may look trivial in code review but can cost hours of production troubleshooting during gray releases.

---