灰度发布核心在于请求路由的可控分流，需通过网关或服务发现层按user_id、header等规则将流量分发至不同版本实例，服务代码无需硬编码版本标识。
灰度发布核心在于请求路由的可控分流
Golang 微服务做灰度，本质不是改服务本身，而是让网关或服务发现层能根据特定规则（如 user_id、header、cookie 或 query）把流量打到不同版本的实例上。服务代码里不需要硬编码“我是灰度版”，而是通过外部标识被识别和路由。
用 Go-kit / gRPC Middleware 做上下文透传
常见错误是只在入口解析灰度标识，但后续调用链丢失。必须确保 X-Gray-Version 或 gray-tag 这类 header 在 HTTP 或 gRPC 调用中逐跳透传。
- HTTP 服务：在中间件中从
r.Header.Get("X-Gray-Version")提取，并写入context.Context，再通过req.Header.Set()向下游转发 - gRPC 服务：用
metadata.FromIncomingContext()读，metadata.AppendToOutgoingContext()写，避免用context.WithValue手动塞——它不跨 RPC 边界 - 注意：Kubernetes Ingress 或 API 网关（如 Kong、APISIX）可能默认 strip 自定义 header，需显式配置
enable-access-log或preserve-host类似选项放行
服务注册时带灰度标签，Consul/Etcd/Nacos 都支持
注册中心是灰度路由的数据源。Golang 服务启动时，别只调 Register()，得附带元数据。
- Consul 示例：
service.Tags = []string{"version:v1.2", "gray:true"}，查询时用services?tag=gray:true - Etcd：把灰度信息存为 key 的后缀，比如
/services/order/v1.2-gray，客户端 watch 时按前缀过滤 - 关键点：不要靠 IP 或端口区分灰度，而要靠标签。否则扩容、滚动更新时标签会漂移，路由失效
- 风险点：若用 DNS 做服务发现（如 CoreDNS），它不支持按标签筛选，必须换用支持 metadata 的 client SDK
Envoy + xDS 是生产级灰度最稳的组合
纯 Go 实现路由规则容易陷入状态同步、热更新延迟、权重抖动等问题。实际高并发场景下，建议把灰度逻辑下沉到 Sidecar。
立即学习“go语言免费学习笔记（深入）”；
- 用 Envoy 的
route.match.headers匹配X-User-Id范围，或用runtime_key动态开关灰度比例 - Golang 服务只需专注业务，不再维护
if gray { call v2 } else { call v1 }这类分支逻辑 - 验证方式：直接
curl -H "X-User-Id: 12345" http://svc/，看 Envoy access log 是否命中cluster_name: order-v2-gray - 容易忽略的坑：Envoy 默认不转发未声明的 header，需在
http_protocol_options中显式添加headers_with_underscores_action: REJECT或设为ALLOW，否则X_Gray_Tag会被静默丢弃
灰度最难的不是代码怎么写，而是标识从用户端一路穿透到后端每个 hop 的完整性。Header 名称、大小写、下划线处理、网关 strip 行为、注册中心 tag 同步延迟——任何一个环节断掉，灰度就变成“玄学发布”。
