灰度路由必须依赖HTTP Header或gRPC Metadata，因服务端需据此识别流量特征以路由至对应版本；HTTP常用X-Canary等header，gRPC须用metadata.MD透传，且需确保中间件不过滤。
灰度路由必须依赖 HTTP Header 或 gRPC Metadata
Go 微服务做灰度，核心不是改业务逻辑，而是让网关或服务发现层能识别流量特征。HTTP 场景下，X-Canary、X-User-Id 这类 header 是最常用且低侵入的标识方式；gRPC 则必须用 metadata.MD 透传，比如 md.Set("canary", "true")。不靠这些元信息，服务端根本无从判断该走 v1 还是 v2 版本。
常见错误是前端没传 header，或者中间件（如反向代理）默认过滤了自定义 header——Nginx 需显式配置 proxy_pass_request_headers on;，Istio 的 EnvoyFilter 也要放行对应 key。
go-micro / Kitex / gRPC-Gateway 的灰度实现差异很大
不同框架对流量染色和路由的支持粒度不同：
-
go-microv3+ 已弃用内置 selector，需自己实现Selector接口，在Select方法里解析context.Context中的 metadata 或 header，按权重或规则返回不同Node -
Kitex推荐用extension.Router，在Route函数中读取req.Header.Get("X-Canary")，返回带指定Tag的 instance（需配合注册中心的 tag-aware 能力） -
gRPC-Gateway是 HTTP/JSON 转发层，它本身不路由后端 gRPC 实例，灰度逻辑得往前移到 API 网关（如 Kong、APISIX），或在 gateway 后加一层轻量路由 service
版本标签不能只写在服务注册名里
把服务注册成 user-service-v2 看似简单，但会破坏服务发现的语义一致性——客户端要硬编码版本号，无法做平滑切流。正确做法是所有实例都注册为 user-service，但带上 label：
立即学习“go语言免费学习笔记（深入）”；
- Consul：用
tags: ["version=v1", "env=prod"] - Nacos：用
metadata: {"version": "v2", "canary": "true"} - Etcd：靠目录结构模拟，如
/services/user-service/v2/instance-01，但需 client 自行解析
服务调用方通过 registry.GetService("user-service") 拿到全部实例后，再根据 label 做本地过滤，比依赖注册中心过滤更可控，也避免 label 变更时的同步延迟问题。
灰度策略必须有 fallback 和超时兜底
真实场景中，v2 版本可能 panic、响应慢、或依赖下游未就绪。光靠“5% 流量打过去”不够，还得加两层保护：
- 调用前检查目标实例健康状态：用
registry.Check或主动 ping，跳过连续失败的 canary 实例 - 设置 per-call 超时（比如
ctx, cancel := context.WithTimeout(ctx, 300*time.Millisecond)），避免 v2 延迟拖垮整个链路 - 降级开关要可热更新：用
viper.WatchConfig()监听配置中心，一旦 v2 报错率超阈值，自动关闭灰度路由
最容易被忽略的是日志上下文串联——v1/v2 日志必须带相同 trace_id 和 canary_flag 字段，否则出问题时根本分不清是灰度逻辑缺陷，还是 v2 本身的 bug。
