云原生lb需用hijacker接管tcp连接实现透传，须在响应写出前劫持、按协议分路径启用、注意http/2限制；一致性哈希应使用动态虚拟节点并线程安全维护；transport需按后端独立配置防连接耗尽；ebpf宜处理固定规则，go专注动态策略，二者需同步状态。
Go net/http.Server 怎么被 hijacked 做连接层负载均衡
云原生 LB 不是简单转发 HTTP 请求，而是接管 TCP 连接，把 net.Conn 按策略分发给后端。标准 http.Server 默认不暴露底层连接，必须用 Hijacker 接口拿到原始 net.Conn，否则没法做连接复用、TLS 透传或长连接保持。
常见错误是直接在 http.HandlerFunc 里调 ResponseWriter.(http.Hijacker).Hijack()，但此时响应头可能已写入，触发 http: Hijack is incompatible with TLS 或 connection closed。正确时机是在请求解析完成、响应尚未写出前——也就是实现自定义 http.Server.Handler，重写 ServeHTTP 方法，绕过默认路由逻辑。
- 只对需要透传的路径（如
/grpc、/ws）启用 hijack，其余走标准 HTTP 流程 - hijack 后务必关闭
ResponseWriter关联的底层 buffer，避免 goroutine 泄漏 - Go 1.22+ 中
http.Hijacker在启用HTTP/2时不可用，需检测r.ProtoMajor == 1再操作
一致性哈希环怎么避免后端扩缩容时大量连接迁移
用 hashicorp/go-memdb 或手写环形结构时，单纯取 hash(key) % len(backends) 会导致增减节点后 90%+ 连接重映射。真正在云原生 LB 里跑得稳的，是带虚拟节点的一致性哈希，比如每台后端映射 100–200 个 vnode，再按 hash 值插入排序环。
容易踩的坑是虚拟节点数固定写死：当后端从 3 台扩到 30 台，若仍用 100 个 vnode/台，总节点数暴增至 3000，查找耗时从 O(log 300) 升到 O(log 3000)，延迟毛刺明显。实际应按后端规模动态调整，例如 max(50, 2000 / backendCount)。
立即学习“go语言免费学习笔记（深入）”；
- key 不能只用客户端 IP，要包含协议类型（
tcp/tls）、SNI 域名、甚至 ALPN 协议名，否则 HTTPS 和 gRPC 流量混在一个环里打散 - 环结构必须线程安全：用
sync.RWMutex保护读多写少场景，别用sync.Mutex拖慢转发路径 - 删除后端时不要立刻从环中清除，先标记
draining状态，等现存连接自然断开后再清理，否则活跃长连接会中断
如何让 Go 的 http.Transport 复用连接又不污染后端指标
LB 自身作为 HTTP 客户端转发时，若直接复用全局 http.DefaultTransport，所有后端共用同一套连接池和超时配置，导致某台后端响应变慢会拖垮整个池子；更糟的是，Prometheus 指标里 http_client_requests_total 完全无法区分目标实例。
解决方案是为每个后端 endpoint 创建独立 http.Transport 实例，但要注意：连接池参数（MaxIdleConns、MaxIdleConnsPerHost）不能照搬默认值。K8s Service 后端通常是 10–100 个 Pod，若每个 Transport 都设 MaxIdleConnsPerHost=100，100 个后端就占满 10000 个空闲连接，内核 net.ipv4.ip_local_port_range 很快耗尽。
- 按后端预期 QPS 动态设
MaxIdleConnsPerHost：低频服务用 5，高频 gRPC 网关用 20–30 - 务必设置
IdleConnTimeout（推荐 30s），否则空闲连接长期驻留，NAT 设备或云厂商 SLB 会静默断连 - 用
RoundTripper包装器注入X-Forwarded-For和后端标识 header，避免业务方自己解析 IP 时误把 LB 地址当真实客户端
为什么 eBPF + userspace 协同模型比纯 Go 实现更适配云原生 LB
纯 Go 实现的 LB 在高并发短连接场景（如每秒 5w+ HTTP GET）下，goroutine 调度和内存分配开销明显：每个连接至少 2–4KB 栈空间，10w 连接就是 200MB+，GC 压力陡增。而生产级云原生 LB（如 Cilium Ingress Gateway）普遍用 eBPF 处理连接建立、TLS 握手分流，Go 只管应用层策略决策。
关键不是“要不要用 eBPF”，而是“在哪切分”。比如把 SYN/FIN 匹配、SNI 提取、连接限速这些 CPU 密集且规则固定的逻辑下沉到 eBPF，Go 层只处理 JWT 校验、AB 测试路由、WAF 规则匹配等动态逻辑。这样既保性能，又不失灵活性。
最容易被忽略的是 eBPF map 与 Go 进程间状态同步：用 bpf_map_lookup_elem 查后端列表时，若 Go 更新了后端 IP 但没及时 sync 到 eBPF map，新连接就会打到已下线节点。必须用 ringbuf 或 perf event 异步通知 Go 进程 reload，不能依赖轮询。
