Go微服务需绑定localhost或0.0.0.0以被Envoy透明代理，透传B3/W3C追踪头及x-request-id，提供无重定向200健康检查端点，限流熔断由Envoy配置驱动， readiness probe应延迟3–5秒避免503。
Go 微服务本身不直接“配置 Envoy”，而是通过标准方式暴露接口、透传头、响应健康检查，让 Envoy Sidecar 能正确拦截和治理流量。关键在适配，不在嵌入。
Go 服务监听地址必须绑定到 localhost 或 0.0.0.0
Envoy 的 iptables/eBPF 流量劫持只对进出 Pod 网络栈的包生效。若 Go 服务绑定到 127.0.0.1:8080，Envoy 才能透明代理；若绑定到具体网卡 IP（如 10.244.1.5:8080）或使用 hostNetwork: true，流量会绕过 Sidecar。
- ✅ 正确写法：
http.ListenAndServe("localhost:8080", handler)或http.ListenAndServe(":8080", handler) - ❌ 错误写法：
http.ListenAndServe("10.244.1.5:8080", handler)（绕过 Envoy） - ⚠️ 注意：Kubernetes 中
localhost在容器内即指 Pod 网络命名空间，安全且可被 Envoy 拦截
必须透传 B3/W3C 追踪头与 x-request-id
Envoy 默认不修改请求头，但 Istio 等控制平面依赖这些头做链路追踪和采样。Go 服务若作为中间调用方，不透传就会断链。
- 入参中提取：
r.Header.Get("x-b3-traceid")、r.Header.Get("traceparent") - 出参中写入：
req.Header.Set("x-b3-traceid", traceID)（手动透传） - 更稳妥做法：用
otelhttp.NewClient包裹 HTTP client，它自动处理 W3C/B3 头双向注入 - 漏掉
x-request-id会导致 Envoy access log 中-占位，影响日志关联分析
健康检查端点需返回 200 且无重定向
Envoy 和 Istio Pilot 会周期性调用 /healthz 或 /readyz 判断实例是否就绪。若返回 302、超时或非 200，Sidecar 会将其从上游集群摘除。
立即学习“go语言免费学习笔记（深入）”；
- ✅ 推荐实现：
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) { w.WriteHeader(200) }) - ❌ 常见错误：handler 内部调用数据库/Redis 检查，导致超时或 5xx；或返回
http.Redirect（302） - ⚠️ 不要依赖
livenessProbe替代该端点——Envoy 的主动探测是独立于 K8s probe 的
限流/熔断策略由 Envoy 配置驱动，Go 服务无需实现逻辑
Envoy 的 circuit_breakers 和 rate_limit_policy 是数据平面原生能力，Go 服务只需按协议响应即可。强行在 Go 层再加一套限流，反而造成双重控制、阈值冲突。
- ✅ 正确姿势：在 DestinationRule 中配置
max_requests: 100，Envoy 自动返回503 UO - ❌ 反模式：Go 里用
golang.org/x/time/rate做令牌桶，同时 Envoy 也在限流 → 实际 QPS 变成 min(两套阈值) - ⚠️ 注意：Envoy 的熔断是连接/请求数硬限制，不是错误率统计；错误率类策略需用 VirtualService + Fault Injection 或自定义 WASM 插件
真正容易被忽略的是：Envoy 的配置生效依赖于服务启动顺序和 readiness probe 就绪时间。Go 服务进程启动快，但若 readinessProbe 检查太激进（比如刚 bind 就返回 200），而 Envoy 还没完成 cluster 初始化，会导致短暂 503。建议 readiness probe 延迟 3–5 秒再开始探测。
