多数据中心部署核心是region-aware路由控制而非简单多注册中心；需通过服务打标、显式查询本region实例、分级健康检查及自定义gRPC解析器实现可控多活， fallback须设硬性限制且切换必须可验证。
多数据中心部署不是“多注册中心”，而是 region-aware 路由控制
Go 微服务跑在杭州和深圳两个机房，不代表你只要在两地各起一套 Consul 就算多活——关键在于客户端能否感知 region 并按需路由。etcd 或 Consul 本身不带 region 意识，必须显式打标、显式查询、显式 fallback。
常见错误现象：connection refused 或 rpc error: code = Unavailable desc = transport is closing，往往不是网络不通，而是客户端从深圳机房的 resolver 里拿到了杭州机房的 endpoint，而该 endpoint 因跨 region 延迟高或防火墙被丢包。
- 启动时向注册中心注册带标签的实例：Consul 中写
tags: ["region=sh", "zone=sh-b"]；etcd 中路径设计为/services/user-svc/sh/和/services/user-svc/hz/ - 客户端调用前，先查本 region 实例列表（如
consul.Health().Service("user-svc", "region=sh", true, &q)），只在返回为空时才查 fallback region - fallback 必须设硬性限制：最多尝试 1 个其他 region、最多重试 1 次、总 timeout 不得超过原 region timeout 的 2.5 倍（实测低于 2 倍易误切，高于 3 倍拖慢正常请求）
gRPC 多数据中心路由不能靠拦截器临时改 Target
在 UnaryInterceptor 里根据 context 解析出 region、再手动选一个 endpoint 是典型误区。gRPC 的连接复用机制会让后续请求继续走已建立的连接，完全绕过你的路由逻辑，导致流量“粘”在错误 region。
真正可行的做法是把 region 当作 resolver 的一级分组维度，让每个 region 对应独立的子 channel：
立即学习“go语言免费学习笔记（深入）”；
- 实现自定义
resolver.Builder，解析target中的region=sh参数，并据此构造不同resolver.State - 每个子 channel 管理自己 region 内的 endpoints，彼此隔离，不共享连接池
- 务必禁用
grpc.WithBlock()—— 多数据中心下某个 region 不可用时，WithBlock会卡死整个 dial 流程，应改用grpc.FailOnNonTempError()+ 异步 reload
健康检查必须区分“节点存活”和“跨 region 可达”
Consul 默认的 passing 检查只确认本地进程活着，但无法反映跨 region 网络质量。如果你用它做服务剔除，杭州机房的服务可能明明能连数据库，却因深圳到杭州链路延迟突增到 800ms 而被误判为不可用。
真实场景中，健康检查要分层：
- 底层：TCP 连通性检查（确保端口可连）
- 中层：跨 region 探针（例如从深圳机房发起对杭州
/health?region=hz的 HTTP 请求，timeout 设为 3s，失败连续 2 次才标记为不可用） - 上层：业务级探活（如查依赖 DB 是否可写、缓存是否可读）
所有层级都通过 Consul 的 check 注册，但仅中层和上层结果参与 region-aware 路由决策——底层只用于防止进程僵死。
容灾切换的关键不是自动化，而是可验证的手动路径
真正的多数据中心能力，不体现在故障瞬间自动切走，而在于你能在 30 秒内手动验证并确认切换生效。很多团队花大量时间写自动切换脚本，却没暴露一个能直接 curl 的验证接口。
每个服务必须提供：/health?region=sh 返回当前实例所属 region、上游依赖状态、以及本 region 内最近一次成功调用其他服务的耗时；同时提供 /switch?to=sh（带鉴权）强制刷新 resolver 缓存并 reload endpoints。
最容易被忽略的是：切换后没有验证点。比如你改了 resolver，但没在日志里打印实际 dial 的 endpoint 地址，也没在 metrics 中暴露 per-region 的 success rate，那所谓“切换成功”只是日志里的一行文字，不是可观测的事实。
