Golang怎么做负载均衡策略_Golang负载均衡教程【指南】-Golang-PHP中文网

go客户端负载均衡需自实现roundrobintransport或grpc balancer，因默认不支持；须用atomic维护索引、复用defaulttransport、避免硬编码与dns缓存，并在生产环境加入健康检查。

golang怎么做负载均衡策略_golang负载均衡教程【指南】

Go 本身不提供开箱即用的负载均衡器，客户端侧必须自己组合 http.RoundTripper 或 grpc.Balancer，服务端侧得靠外部组件（如 Envoy、Nginx）或 Service Mesh；硬编码地址、直接复用 http.DefaultClient 或只传多个 endpoint 给 grpc.Dial，全都不生效。

怎么用 `http.RoundTripper` 实现轮询（Round Robin）

这是最可控、也最容易落地的客户端负载方式。核心不是改 http.Client，而是实现一个带状态的 RoundTripper，每次请求前动态选后端。

不能在 RoundTrip 里直接用 rand.Intn —— 没有种子控制会导致测试不可重现，且并发下原子性难保；必须用 atomic.AddUint64 维护索引
后端列表建议用 []string 存 IP:Port，避免 DNS 缓存问题；若非要用域名，得重写 Transport.DialContext + 自定义 DNS 解析逻辑
http.DefaultTransport.RoundTrip(req) 可复用连接池和 TLS 复用，别自己 new http.Transport —— 否则会丢掉连接复用、超时、Keep-Alive 等关键能力
简单场景可先跳过健康检查；但生产环境务必加失败标记（比如用 sync.Map 记录 "10.0.1.10:8080" → lastFailAt），否则挂掉的节点仍会被轮到

示例片段：

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

type RoundRobinTransport struct {
    backends []string
    index    uint64
}
func (r *RoundRobinTransport) RoundTrip(req *http.Request) (*http.Response, error) {
    backend := r.backends[atomic.AddUint64(&r.index, 1)%uint64(len(r.backends))]
    req.URL.Scheme = "http"
    req.URL.Host = backend
    return http.DefaultTransport.RoundTrip(req)
}

为什么 `grpc.Dial("10.0.1.10:8080,10.0.1.11:8080")` 不会轮询

gRPC Go 客户端默认行为是 pick_first：只连第一个地址，其余被静默忽略。即使你传入逗号分隔的字符串，它也不会自动解析或分发——这是常见误解根源。

必须显式启用名字解析（resolver）+ 负载均衡器（balancer）协同机制，缺一不可
想用内置轮询，得配 grpc.WithBalancerName("round_robin")，同时确保 resolver 返回的是多个有效 address.Address（不能含空字符串或非法格式）
推荐绕过自研 resolver：用 passthrough:///10.0.1.10:8080,10.0.1.11:8080 协议，再配合 WithBalancerName，简单可靠
错误现象包括：rpc error: code = Unavailable desc = connection closed、监控里流量始终打在同一台、日志里没看到 round_robin switched to READY

什么时候该用 `go-kit/sd` 而不是手写轮询

当你需要服务发现、健康检查、策略热切换三者闭环时，手写 RoundTripper 或 Balancer 就容易失控。这时候 go-kit/sd 提供了更工程化的抽象。

sd.Instancer 负责拉取/监听节点（支持 Consul、Etcd、静态列表等），lb.Balancer 负责策略，两者解耦
lb.NewOpportunist(balancer) 是关键：它不是每次都换节点，而是在首次调用失败后 fallback 到下一个，天然适配重试逻辑
如果后端扩缩频繁、需熔断、要按 CPU 权重调度，或希望策略可插拔（比如从轮询切到最少连接数不重启进程），那就别省这点封装成本
注意：它不替代 HTTP 层逻辑，只是把 “选哪个实例” 和 “怎么发请求” 分离；endpoint 还是得用 httptransport.NewClient 构建

真正麻烦的从来不是算法本身，而是节点列表怎么来、健康状态怎么维护、地址变更后连接是否平滑迁移——这些细节一旦漏掉，再漂亮的轮询代码上线半天就变单点故障。