go-micro/v2通过service.Client().Call()实现客户端负载均衡，需配合consul.NewRegistry()注册服务、全小写服务名、默认轮询策略，健康剔除由Consul Agent完成。
Go 本身不提供微服务级的负载均衡能力，所有可用方案都依赖外部协同或手动集成——要么靠注册中心（如 Consul）+ 客户端 SDK，要么靠 gRPC 内置策略，要么用反向代理前置分流。
go-micro/v2 怎么做客户端负载均衡
它把服务发现和节点选择封装在 service.Client().Call() 里，但前提是注册中心已就位：
-
micro.NewService()初始化时必须传入registry实例（比如consul.NewRegistry()），否则服务不会注册，调用方也拉不到节点列表 - 服务名必须全小写，Consul 对大小写敏感，
UserSrv和usersrv是两个不同服务 - 默认策略是轮询（
selector.RoundRobin），想换随机策略得显式调用selector.WithStrategy(selector.Random) -
Mark()方法用于标记某次调用失败，触发自动剔除逻辑；但健康检查由 Consul Agent 主动执行，不是 Go 进程内做的
gRPC 的 round_robin 策略怎么启用
这个策略只在连接建立时生效，且要求地址可解析为多个后端：
- 必须用
grpc.WithBalancerName("round_robin")，缺了这句就退化成直连单点 - 目标地址不能写死 IP，得是 DNS 名，例如
dns:///user-service.default.svc.cluster.local；Kubernetes 下配合 Headless Service 才能返回全部 Pod A 记录 - 如果手动构造地址列表（
resolver.NewAddress()），健康状态需自行维护，round_robin不会自动跳过宕机节点 - 注意它是连接粒度的：一个
grpc.ClientConn内部复用 TCP 连接，请求不会跨 conn 轮询
为什么 net/http.Client 不能直接做微服务负载均衡
因为它的设计目标是单点 HTTP 请求，没有服务发现、节点列表管理、健康探测这些能力：
-
http.Client的Transport默认只发往一个*url.URL，不感知后端集群 - 即使你手写轮询逻辑选 IP，也无法自动剔除故障节点——没有心跳或健康检查钩子
- 重试机制（
CheckRedirect或自定义RoundTripper）只管单次请求失败，不管实例是否长期不可用 - 若硬要基于
http.Client自研，就得补全注册中心监听、节点缓存、熔断计数器等一整套逻辑，成本远高于接入 go-micro 或 gRPC
轻量级 LB（如 codex-lb）和传统代理的区别在哪
它们定位不同：codex-lb 是嵌入式组件，适合跑在服务进程内或边缘节点上；Nginx/HAProxy 是独立网关，承担 TLS 终止、限流、日志等职责：
- codex-lb 启动快、内存占用低（几 MB），但只做核心转发+基础健康检查，不支持 WAF、JWT 验证等扩展功能
- 它通常通过配置文件或代码注入后端列表，不对接 Consul/Etcd，也没有服务发现能力
- 健康检查默认是 HTTP GET 探针，超时和失败阈值需手动设，不像 Istio 那样能联动 Sidecar 做细粒度指标采集
- 如果你的场景是本地多实例调试、CI 环境快速分发，它很合适；但生产环境面对百万 QPS 和复杂路由规则，还是得靠成熟网关
真正容易被忽略的是“健康状态同步时机”——注册中心的 TTL、gRPC 的连接重建间隔、自研 LB 的探针周期，三者不同步就会导致流量打到刚宕机但还没被踢出列表的节点上。这个窗口期没法完全消除，只能靠缩短检测周期+合理设置重试次数来收敛。
