Go 微服务怎么在 Istio 里做金丝雀发布
靠 Istio 的 VirtualService 和 DestinationRule 控制流量分发，Go 服务本身不用改代码，但必须暴露健康检查端点、支持标签化部署（比如用 version: v1 和 version: v2 标签区分 Pod），否则 Istio 没法路由。
常见错误是 Go 服务没加 readiness probe，或者 Deployment 的 label 和 DestinationRule 里的 subsets 对不上——Istio 会静默忽略不匹配的 subset，流量全打到默认版本上，你以为在灰度，其实没生效。
- Go 服务启动后必须监听
/healthz或类似路径，且返回 200；K8s readiness probe 要配对，否则 Pod 不进 Endpoints -
DestinationRule中的subsets名称必须和 Deployment 的labels完全一致，大小写敏感，比如version: v2就不能写成Version: v2 - Istio 默认不启用 mTLS，但如果启用了，Go 服务得用
istio-proxy自动注入 sidecar，不能自己搞 TLS 终止，否则VirtualService的权重路由会被跳过
VirtualService 流量拆分为什么没按预期走
最常踩的坑是权重没生效，比如设了 90/10 却发现新版本根本收不到请求——本质是 VirtualService 的 http.route 必须配合 DestinationRule 的 subsets 才能工作，单独配 VirtualService 是无效的。
另一个隐形限制：Istio 的权重是“尽力而为”，不是精确控制。小流量（比如 5%）在 QPS 低时可能长时间没请求命中，不是 bug，是设计如此；压测时建议用至少 100 QPS 观察分布。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
VirtualService的route目标必须写成host: myservice.default.svc.cluster.local，不能省略命名空间或用短名 - 权重总和必须严格等于 100，写成 90 + 9 就会报错，Istio 不自动归一化
- 如果同时配置了
match（比如 header 匹配）和route权重，header 匹配优先级更高，权重只在匹配后的 subset 内生效
Go 服务要不要在代码里处理金丝雀逻辑
绝大多数情况不用。Istio 已经在 L7 层做完路由，Go 服务收到的请求就是最终目标版本的，不需要解析 header、判断灰度标识、手动转发或降级。
唯一需要代码介入的场景是：你想让 v2 版本主动调用 v1 的某个接口做数据比对（比如双写校验），这时才需要在 Go 里读取 X-Canary-Version 这类自定义 header，或通过环境变量识别自身版本。但这个 header 是你手动加的，Istio 默认不透传，得在 VirtualService 里显式用 headers 注入。
- 别在 Go 里重复实现流量路由逻辑，和 Istio 叠加容易出竞态，比如 v2 收到请求后又去调 v1，形成环路
- 如果真要透传灰度标识，用
VirtualService的headers.request.set注入，而不是依赖客户端带过来的 header（不可信） - 日志里建议打上
version字段，从os.Getenv("VERSION")读取，和 Deployment 的 label 保持一致，方便排查流量是否走到正确实例
本地开发时怎么模拟 Istio 金丝雀效果
没法完全模拟，因为 Istio 的流量策略运行在 K8s + Envoy 上，本地 go run 没有 sidecar。但你可以绕过 Istio，用 Go 自己启两个端口（比如 :8080 和 :8081），再起一个反向代理（如 gin 或原生 net/http/httputil）按权重转发，快速验证业务逻辑是否兼容。
注意这种本地代理只是临时验证，和真实 Istio 行为差异很大：没有重试熔断、不感知实例健康状态、不支持 header 匹配等高级路由。上线前必须在集群里实测。
- 别把本地代理逻辑提交到主分支，它和生产路径无关，容易混淆部署意图
- 用
http.DefaultTransport时记得设置MaxIdleConnsPerHost，否则高并发下代理会卡住 - 如果 Go 服务用了 gRPC，本地模拟更麻烦——gRPC 的负载均衡由 client SDK 控制，和 HTTP 的反向代理不是一回事，这时候建议直接连测试集群的 ingress gateway
真正难的不是配 YAML，而是确保每个环节的标识能串起来：Deployment label → DestinationRule subset → VirtualService route → Pod readiness → 日志 version 字段。漏掉任意一环，金丝雀就变成“薛定谔的灰度”。
