Go 微服务里怎么让灰度流量只打到特定版本？
灰度发布不是靠“改代码重启”，而是靠请求路由时动态识别版本标签，把带 v2 标签的流量导向新服务实例。关键不在 RPC 框架本身有多强，而在你能不能在 context 里透传和解析路由决策所需的元数据。
常见错误是：在 HTTP 入口加了 X-Service-Version: v2，但 gRPC 的 UnaryInterceptor 没读取 metadata，下游服务压根收不到版本信息；或者读了但没传给负载均衡器，导致轮询还是均匀打到所有实例。
- HTTP 层（如 gin）需将 header 映射为 gRPC metadata，用
metadata.Pairs("version", r.Header.Get("X-Service-Version")) - gRPC 客户端调用前必须显式注入 metadata：
ctx = metadata.AppendToOutgoingContext(ctx, "version", "v2") - 服务端拦截器中提取：
md, ok := metadata.FromIncomingContext(ctx)，再取md["version"] - 别依赖服务名后缀（如
user-service-v2）做路由——注册中心通常不支持按 service name 正则匹配，得靠标签路由
gRPC Go 怎么实现基于权重的流量切分？
标准 grpc-go 不提供开箱即用的权重路由，它默认用 round_robin，而权重需要自定义 balancer.Builder。直接改 balancer 是最稳的路，比在业务层 if-else 分流更可靠，也避免重复逻辑散落在各个 client 包里。
容易踩的坑是：用随机数 + 权重比例做客户端软分流（比如 80% 走 v1，20% 走 v2），看似简单，实则无法保证单个连接上的流量稳定，且无法配合熔断、重试等机制——gRPC 的 retry 是基于 single RPC，不是基于连接池。
立即学习“go语言免费学习笔记（深入）”；
- 实现一个
weighted_round_robinbalancer，核心是维护每个 subConn 的权重和当前剩余配额 - 注册时用
balancer.Register(&weightedBuilder{})，启动 client 时指定grpc.WithBalancerName("weighted_round_robin") - 服务发现返回的 endpoint 需携带权重字段（如 etcd key
/services/user/v1?weight=80），balancer 初始化时解析 - 注意：gRPC v1.60+ 已弃用
balancer.GRPCResolverWrapper，要用resolver.Builder配合serviceconfig.ParseJSON注入配置
RPC 版本号该写死在函数签名里吗？
不该。把版本塞进函数名（如 GetUserV2）或参数结构体字段（如 req.Version = "v2"）会污染业务契约，违背 gRPC 的接口稳定性原则。版本应作为传输层/治理层元数据存在，与 protobuf 定义解耦。
典型反模式：proto 文件里定义 message GetUserRequestV2，结果 v3 又来个 GetUserRequestV3，客户端一升级就得全量重编译，还无法兼容老服务。
- 保持 proto 接口不变，用 metadata 控制行为分支（例如是否启用新校验逻辑）
- 如果确实要变更字段语义，用
oneof或可选字段 + 默认值兼容，而不是新增 message - 服务端根据
versionmetadata 决定走哪套 handler，而不是靠函数名 dispatch - 特别注意：gRPC 的
UnknownServiceHandler和UnknownStreamHandler无法捕获版本不匹配——它们只管 service/method 是否注册，不管 metadata
etcd 服务发现怎么存多版本实例并支持权重？
etcd 本身不理解“版本”或“权重”，它只存 key-value。你要存的是能被 balancer 解析的结构化信息，key 设计决定你后续路由是否灵活。别用扁平 key（如 /services/user/v1/10.0.0.1:8080），那样没法原子更新权重。
常见错误是把权重硬编码在 client 配置里，导致每次调权都要发版；或者把所有实例塞进一个 value JSON 里，结果某个实例下线时整个 key 被删，引发雪崩。
- 推荐 key 格式：
/services/user/instances/10.0.0.1:8080，value 是 JSON：{"version":"v2","weight":20,"healthy":true} - client 端 watcher
/services/user/instances/前缀，实时同步实例列表，并按 value 中的weight构建 balancer 状态 - 更新权重只需 put 单个 key，不影响其他实例；下线实例用 delete，balancer 收到事件后自动剔除
- 注意 etcd lease 续约：每个 instance key 必须绑定独立 lease，避免一个实例掉线导致整个服务被批量踢出
真正难的不是写几个函数，而是让 metadata 从入口请求一路无损透传到 balancer，中间任何一层漏掉（HTTP middleware、gRPC interceptor、resolver、balancer）都会让灰度失效。链路越长，漏点越多。
