Golang跨多可用区负载均衡需服务发现、健康感知与区域亲和协同：gRPC必须用DNS格式地址+WithDefaultServiceConfig启用round_robin，Consul注册需带AZ元数据并过滤查询，HTTP轮询需按AZ分组实例+原子索引+健康状态检查。
跨多可用区（Multi-AZ）的容器负载均衡在 Go 微服务中，不能靠单个 http.Client 或默认 grpc.Dial 实现——它需要服务发现、健康感知、区域亲和与故障隔离三者协同。硬编码地址或只用 DNS 轮询会跳过 AZ 边界检查，导致流量打到远端区、延迟飙升甚至脑裂。
gRPC 客户端必须用 DNS + service config 启用 round_robin
新版 gRPC-Go（v1.27+）已废弃 grpc.WithBalancerName("round_robin")，直接写会静默失效。
- 目标地址必须是 DNS 格式：
"dns:///user-service.us-east-1a.svc.cluster.local"（K8s Headless Service 场景），不能是"user-service:8080"或 IP 列表 - 必须显式传入
grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy":"round_robin"}`)，否则默认走pick_first（只连第一个节点） -
round_robin是连接粒度的：一个conn建立后，其内部子连接固定轮询；要真正跨 AZ 负载，得让每个 conn 都能解析出多个 AZ 的实例——这意味着 DNS 必须返回所有可用区的 SRV 记录，且 TTL ≤ 5s
Consul 注册时需带 AZ 标签并过滤查询
Consul 本身不自动区分 AZ，必须人工注入元数据，否则客户端拿到的是混杂列表，无法做亲和或容灾路由。
- 服务注册时加
Tags或Meta：meta: {"az": "us-east-1a"}，不能只靠节点位置推断 - 客户端查询必须带过滤：
service.nodes?filter=Meta[az] == "us-east-1a"，否则consul.ServiceNodes返回全量节点 - 若用 go-micro v2，
micro.Service初始化时需指定registry.Option传入 filter，否则Next()会随机选跨 AZ 实例
HTTP 层轮询需原子索引 + AZ 感知重试
自定义 http.RoundTripper 做轮询时，若后端跨 AZ，失败后不能简单 retry 下一个——可能下一个还在同一故障 AZ。
立即学习“go语言免费学习笔记（深入）”；
- 实例列表应按 AZ 分组：
map[string][]string{"us-east-1a": {"10.0.1.10:8080", "10.0.1.11:8080"}, "us-east-1b": {"10.0.2.10:8080"}} - 索引维护用
atomic.Uint64，但每次RoundTrip前先查当前 AZ 健康状态；若全挂，才 fallback 到其他 AZ - DNS 地址必须禁用系统缓存：
net.DefaultResolver = &net.Resolver{PreferGo: true, Dial: dialContext}，否则10.0.1.10可能被长期缓存，扩缩容不生效
真正难的不是“怎么轮”，而是“怎么知道哪个 AZ 还活着”——Consul 的健康检查路径（如 /health）必须由服务自己暴露，且响应时间 ≤ 2s，否则 AZ 级别剔除延迟会超过云厂商的故障切换窗口。这点容易被忽略，但决定了 Multi-AZ 是否真的可用。
