xxs588 commented on issue #3204:
URL: https://github.com/apache/dubbo-go/issues/3204#issuecomment-4677721649
我负责的测试 dubbo-go-samples/task/shop 微服务商城 demo 的灰度路由功能，这个 demo 有 5
个微服务（frontend/user/order/detail/comment），每个后端有 v1/v2 两个版本，文档是服务于Dubbo
的灰度路由能力，但是用dubbo-go尝试时遇到了一些bug
测试方式：
- 将 go.mod 的 replace 指向本地 dubbo-go（先后测试了快照 v3.3.2-20260419 和最新 main 分支）
- 然后我尝试让 agent 用 Playwright 浏览器自动化模拟真实用户操作
- 逐一验证首页、普通登录、灰度登录、超时登录、下单、用户信息等场景
发现 3 个 sample 代码 bug：
1. CheckItem 和 CheckItemGray 实现反了 ，导致 /login 应该走普通路由却带了灰度标签，/grayLogin
应该走灰度路由却没带标签 已经开了issue在 https://github.com/apache/dubbo-go-samples/issues/1090
修复 ：本地尝试调换两个函数实现部分，然后预期行为是正确的（由于标签的动态路由任务我一直没打通所以一直没交pr）
2. 所有服务缺少 WithConfigCenter 配置 ，
所有服务启动后日志持续输出：
`Config center does not start, Tag router will not be enabled`
`Config center does not start, Condition router will not be enabled`
`Config center does not start, Script router will not be enabled`
然后我尝试看一下 server 代码，发现 dubbo.NewInstance() 只配了 WithRegistry(...)，没有
WithConfigCenter(...)。没有 config center，所有动态路由规则无法从 Zookeeper
下发，Tag/Condition/Script Router 全部禁用。
修复： 本地为所有 8 个服务实例添加 WithConfigCenter(config_center.WithZookeeper(),
config_center.WithAddress("127.0.0.1:2181"))。 然后日志里面没在出现之前的情况
3. v2 服务缺少灰度标签 ，修复了前面两个bug之后 /login 正常返回 v1 数据，但 /grayLogin 仍然 500。检查 v2
服务代码，发现 detail/server_v2、comment/server_v2、order/server_v2 都没有配置任何灰度标签。v1 和 v2
在注册中心里完全一样，tag routing 无法区分它们
修复：本地尝试为 v2 服务添加 dubbo.WithTag("gray")
修完 sample bug 后，灰度路由仍然不工作。 Tag router 只匹配 dubbo.tag，不匹配
application.tag。所以即使 provider 有 application.tag=gray，只要 dubbo.tag 为空，tag router
就找不到它。（之前的v3.3.2-20260419 版本和 2026.6.11最新的main分支版本行为是一致的）
溯源到 dubbo-go 框架层：
| 参数 | 设置方式 | 用途 |
| --- | --- | --- |
| application.tag | dubbo.WithTag("gray") 实例级 | 存入 metadata，走服务发现链路 |
| dubbo.tag | server.WithTag("gray") 服务级 | Tag router 实际匹配的字段 |
tag router 匹配逻辑（cluster/router/tag/match.go）只读 dubbo.tag：
`invoker.GetURL().GetParam(constant.Tagkey, "") != tag // constant.Tagkey =
"dubbo.tag"`
然后 AI 给的尝试方案A是 只用 dubbo.WithTag，走 application.tag → metadata → ZK →
dubbo.tag 传播路径
框架代码中存在这条链路：
1. metadata/metadata.go:44 — 读 application.tag 存入 MetadataInfo.Tag
2. servicediscovery/service_discovery_registry.go:135 — 设置 instance.Tag
3. servicediscovery/customizer/service_instance_tag_customizer.go:40 — 注入
instance metadata 为 dubbo.tag
4. registry/service_instance.go:182 — ToURLs() 读取 dubbo.tag
我试了一下 consumer 发现的 URL 里 dubbo.tag 仍然为空。传播链路在 service-discovery-registry 层断裂。
我又试了方案B 同时用 dubbo.WithTag + server.WithTag， Provider 导出 URL 确实有
dubbo.tag=gray ，但经过 Zookeeper service-discovery-registry 后，consumer 发现的 URL 中
dubbo.tag 仍然变为空 。
然后总结了一下dubbogo现有的问题
1. application.tag → dubbo.tag 传播链路在 service-discovery-registry 层断裂 —
代码路径存在但实际运行不生效，需要在 service_instance_tag_customizer.Customize() 和
service_instance.ToURLs() 中加 debug log 定位具体断裂点 —开了issue #3397
2. MetadataInfo.Tag 缺少 JSON/Hessian
tag（metadata/info/metadata_info.go:62）— Tag string 没有 json:"tag,omitempty" 和
hessian:"tag" tag，序列化时可能丢失
3. convertMetadataInfoV2 丢失 Tag（metadata/client.go:94-113）— 通过 Triple RPC
获取 metadata 时 Tag 字段未从 proto 消息映射 — 2和3两个开了issue #3398
4. Sample 代码 3 个 bug — 已经提交了修复pr
https://github.com/apache/dubbo-go-samples/pull/1111
推进参考方案
短期（定位传播断裂点）：
在 service_instance_tag_customizer.Customize() 和 service_instance.ToURLs()
中加 debug log，确认：
- instance.GetTag() 是否返回 "gray"
- instance.GetMetadata()["dubbo.tag"] 是否被设置
- ToURLs() 构建 URL 时 d.Tag 的值
中期（修复传播链路）：
1. 修复 MetadataInfo.Tag 的 json/hessian tag
2. 修复 convertMetadataInfoV2 的 Tag 映射
3. 确保 service_instance_tag_customizer 在所有 service discovery 路径下都被调用
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
