Service Mesh核心能力需数据平面与控制平面严格分离，Go适合开发控制平面或轻量数据平面组件，但不可用net/http直接暴露业务端口；xDS实现须手动处理版本、nonce及资源类型；Sidecar注入依赖Webhook证书合规；指标采集需独立Registry并规范标签。

Service Mesh 核心能力必须由数据平面和控制平面分离实现

单纯用 Go 写一个“带路由的 HTTP 代理”不等于实现了 Service Mesh。真正可用的组件（如 Envoy 的替代或轻量控制面）需要明确区分：data plane 负责流量劫持、TLS 终止、指标上报；control plane 负责下发 xds 配置、维护服务拓扑、处理健康检查。Go 适合写 control plane（如基于 go-control-plane 实现 xdstool 类工具）或轻量 data plane（如 linkerd2-proxy 的 Rust 主体之外，其 admin server 和部分插件常用 Go 编写）。

• 别用 net/http 直接暴露业务端口做 mesh 入口——它无法支持 HTTP/2 多路复用、gRPC 流控、连接池熔断等关键能力
• 真正落地时，data plane 建议用 Envoy/Cilium eBPF 或成熟 proxy；Go 更适合作为 control plane 的配置生成器、策略校验器、可观测性聚合层
• 若坚持用 Go 实现简易 data plane，必须替换底层网络栈：用 golang.org/x/net/http2 手动管理流，配合 net.Conn 层级劫持（如 SO_ORIGINAL_DST 获取原始目标），否则无法完成透明重定向

用 go-control-plane 实现 xDS v3 接口必须手动处理版本与资源增量

go-control-plane 不自动做资源 diff 或版本管理，所有 DeltaDiscoveryRequest 和 DeltaDiscoveryResponse 都要自己维护 nonce、version_info、resource_names_subscribe。漏掉任一字段会导致 Envoy 拒绝更新或无限重试。

func (s *Server) StreamEndpoints(stream ads.EndpointDiscoveryStream) error {
    for {
        req, err := stream.Recv()
        if err != nil {
            return err
        }
        // 必须显式构造响应，不能只返回资源列表
        resp := &envoy_service_discovery_v3.DiscoveryResponse{
            VersionInfo:   s.version(), // 自增字符串，非时间戳
            Resources:     s.endpoints(), // []any，需是 proto.Message 实例
            TypeUrl:       envoy_type_v3.EndpointType,
            Nonce:         req.GetNode().GetId() + "-" + strconv.FormatInt(time.Now().UnixNano(), 10),
            ControlPlane:  &envoy_core_v3.ControlPlane{Identifier: "go-cp"},
        }
        if err := stream.Send(resp); err != nil {
            return err
        }
    }
}

• VersionInfo 必须每次变更都递增（哪怕只是加个空格），Envoy 会比对它决定是否接受新配置
• Resources 中每个元素必须是已注册的 proto.Message（如 *envoy_config_endpoint_v3.ClusterLoadAssignment），不能传 raw JSON 或 map
• 如果启用 delta xDS，必须在首次请求后记录客户端订阅的 resource_names，后续只推送这些名字对应的变更，否则会触发全量同步风暴

Sidecar 注入失败常因 Kubernetes MutatingWebhookConfiguration 权限或证书问题

Go 编写的 webhook server（如用 kubebuilder 或原生 net/http）一旦返回非 200，K8s 就拒绝注入。最常见原因是：caBundle 未正确注入到 MutatingWebhookConfiguration，或 webhook server TLS 证书域名不匹配 service.namespace.svc。

• 生成证书时，CommonName 必须为 webhook-service.webhook-ns.svc，不能省略 .svc
• 调用 kubectl apply -f webhook.yaml 前，先用 openssl x509 -in cert.pem -text -noout | grep DNS 确认 SAN 包含完整 service FQDN
• Webhook response 中 patchType: JSONPatch 是强制要求，且 patch 字段必须是合法 JSON 数组（不是字符串），否则 K8s apiserver 解析失败并静默丢弃

指标采集需绕过 Go runtime 默认指标的干扰

直接用 promhttp.Handler() 暴露 /metrics 会混入 go_gc_cycles_automatic_gc_cycles_total 这类通用指标，而 Service Mesh 要求的是 per-service、per-route 的延迟、错误率、连接数。必须用独立 prometheus.Registry 并禁用默认收集器。

立即学习“go语言免费学习笔记（深入）”；

reg := prometheus.NewRegistry()
reg.MustRegister(
    prometheus.NewGoCollector(
        prometheus.WithGoCollectorRuntimeMetrics(
            prometheus.GoRuntimeMetricsRule{Matcher: regexp.MustCompile("^/process/"), Action: prometheus.GoRuntimeMetricsRuleUnregister},
        ),
    ),
)
// 再注册自定义指标：mesh_request_duration_seconds、mesh_upstream_rq_time_ms 等
reg.MustRegister(requestDuration)
http.Handle("/metrics", promhttp.HandlerFor(reg, promhttp.HandlerOpts{}))

• Mesh 场景下，requestDuration 的 label 必须包含 source_service、destination_service、response_code，否则无法做服务依赖分析
• 避免在 handler 里调用 time.Sleep 或阻塞 IO——Go 的 metrics handler 默认使用 http.DefaultServeMux，并发采集时易引发锁竞争
• 如果 sidecar 和 control plane 共用一个进程（不推荐），必须为两者分配不同 registry，否则指标命名冲突导致上报失败