go微服务中不能直接用net/http实现负载均衡，因其无客户端lb能力；应通过服务发现（如consul）+客户端lb（如kitex）或service mesh（如istio）分层解决。
Go 微服务中直接用 net/http 做负载均衡行不通
Go 标准库的 net/http 本身不提供客户端侧负载均衡能力，http.Client 只会把请求发给单个固定地址。如果你在服务 A 里硬编码 http.Post("http://service-b:8080/api", ...)，那所有流量都压到一个实例上，根本谈不上“均衡”。真要实现，必须自己选节点、做健康检查、处理失败重试——这不是业务逻辑该干的事。
常见错误现象：connection refused 或超时后整个请求失败，没有 fallback 到其他实例；服务扩容后流量不自动分摊；某台机器 CPU 爆了，请求还在往它身上打。
- 别手动拼 URL +
http.Client轮询，没健康检查、没熔断、没权重支持 - 别依赖 DNS 轮询（如
service-b.default.svc.cluster.local），Kubernetes 的 DNS 默认不支持 SRV 记录或权重，且 TTL 缓存导致故障收敛慢 - 真实场景需要区分：是服务间调用（in-cluster）还是网关入口（ingress）？前者走客户端 LB，后者通常由 Ingress Controller 或 Service Mesh 承担
用 go-kit 或 kitex 配合 consul 实现服务发现 + 负载均衡
这是 Go 生态最落地的组合：服务启动时向 consul 注册自身地址和健康端点，调用方从 consul 拉取可用实例列表，再用本地策略（如随机、轮询、最少连接）选一个发起请求。关键在于“服务发现”和“客户端负载均衡”解耦。
示例片段（kitex 客户端）：
立即学习“go语言免费学习笔记（深入）”；
client, err := echo.NewClient("echo", client.WithMux(&rpcinfo.Mux{
Discovery: consul.NewDiscovery("127.0.0.1:8500", "echo-service"),
LoadBalance: loadbalance.NewWeightedRandomLoadBalance(),
}))
-
consul.NewDiscovery负责定时同步健康实例列表，自动剔除失联节点 -
WeightedRandomLoadBalance支持按实例指标（如 CPU 使用率）动态设权重，需配合自定义 reporter 上报 - 注意
consulACL 开启后，client 必须带 token，否则GetInstances: rpc error: code = Unknown desc = failed to get instances from consul - 如果不用 consul，etcd +
grpc-go/resolver也能做，但 etcd v3 的 watch 机制对长连接更友好，适合高频率变更场景
HTTP 服务用 gorilla/reverseproxy 自建网关级负载均衡
当你的 Go 服务充当前置网关（比如聚合多个下游 HTTP 微服务），可以用 gorilla/reverseproxy 手动构造负载均衡代理。它不依赖注册中心，适合小规模或配置驱动的场景，但得自己维护后端列表和健康状态。
核心要点：
- 用
httputil.NewSingleHostReverseProxy只能代理单台，必须继承ReverseProxy并重写Director和RoundTrip方法来实现多后端选择 - 健康检查不能只靠
http.Get，要加超时和重试，否则一次网络抖动就误判下线；建议用 goroutine 定期探活，结果缓存在 map 中供Director查询 - 默认 round-robin 是无状态的，若需 sticky session，得解析 cookie 或 header，把
req.Header.Set("X-Forwarded-For", ...)传下去，并在 Director 里做哈希路由 - 注意
Transport的MaxIdleConnsPerHost要调大（比如 100），否则高并发下连接复用不足，大量connect: cannot assign requested address
Service Mesh 方案中 Go 服务怎么参与负载均衡
如果你已在用 Istio 或 Linkerd，Go 服务本身几乎不用改代码——只要确保它监听在 localhost、不暴露到集群外，Sidecar（Envoy）会自动接管所有出入流量，并基于目标服务的 Kubernetes Endpoints 或 Istio DestinationRule 做负载均衡。这时候真正的复杂点在配置而非 Go 代码。
容易被忽略的细节：
- Go 服务的 readiness probe 必须真实反映业务就绪状态（比如检查 DB 连接池是否 warmup 完成），否则 Envoy 可能在服务刚启动时就把流量导过去，触发大量 503
- Istio 默认用
ROUND_ROBIN，但若下游是 gRPC，需显式在DestinationRule中设置connectionPool.http2MaxRequests: 1000，否则 HTTP/2 流控可能让负载看起来不均 - Linkerd 的 tap 功能能实时看到每个实例的 success rate 和 p99 latency，比自己埋点更准；但前提是 Go 服务返回标准 HTTP 状态码，不要全用 200 + body.code 区分业务错误
真正难的不是选哪个库，而是搞清“谁该负责哪层均衡”：服务发现层管存活，网络层管连接复用，应用层管业务语义（比如按用户 ID 散列）。混在一起做，最后谁都兜不住底。
