如何在Golang中实现微服务的灰度发布_Golang微服务版本控制与发布策略-Golang

灰度路由必须依赖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-micro v3+ 已弃用内置 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：