service层必须显式承担降级决策，需封装服务发现调用、结合gobreaker熔断、context超时、人工开关与本地LRU缓存，三重信号协同判断是否降级。
service 层必须承担降级决策，不能靠框架自动兜底
Golang 框架（如 go-zero、kit、kratos）本身不提供“开箱即用”的服务发现+降级联动能力。所谓“支持优雅降级的服务发现”，本质是把服务发现结果的不确定性（实例下线、健康检查失败、DNS 缓存延迟）和降级逻辑显式耦合起来，而不是指望框架在 Resolve 失败时自动返回默认值。
- 服务发现客户端（如
etcdwatcher、consulagent）返回空列表或超时错误时，框架不会主动触发降级；它只负责抛出err - 如果你在
handler层直接调用discovery.GetInstances("user-svc")后不做判断就 panic 或返回 500，那根本没走降级 - 正确做法是：把服务发现调用封装进
service方法，并接收ctx context.Context，在err != nil分支里显式调用getDefaultUserClient()这类纯内存构造的备用客户端
gobreaker + context.WithTimeout 才是真实兜底组合
单纯依赖服务发现的健康检查（比如 etcd 的 lease TTL 或 consul 的 TTL check）无法覆盖网络分区、客户端 DNS 缓存未刷新、短连接建连超时等场景。必须叠加熔断与上下文控制：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 对每次服务发现查询本身加
context.WithTimeout(ctx, 300*time.Millisecond)，避免卡在GetInstances上 - 把服务发现结果用于构建 RPC 客户端后，该客户端的每一次调用仍需走
gobreaker.CircuitBreaker.Execute -
gobreaker.Settings.Timeout单位是毫秒，填500是 500ms，不是 5 秒——填错会导致请求在熔断器里直接超时退出，根本没机会执行降级函数 - 熔断器打开后，
cb.Execute会直接返回你注册的fallback函数，但前提是这个函数签名严格匹配主逻辑（例如都返回(*User, error)），且内部不发新请求、不调time.Now()
NeedFallback 函数必须融合人工开关与熔断状态
服务发现不可用 ≠ 必须降级。比如运维正在灰度升级 user-svc 实例，所有节点临时下线，这时应该由配置中心强制开启降级开关，而不是等熔断器统计失败次数。
- 实现一个统一判断函数：
func NeedFallback(serviceName string) bool - 内部按优先级检查：
-
config.GetBool("downgrade." + serviceName)为 true → 直接返回 true - 否则查
breaker.State() == gobreaker.StateOpen→ 返回 true - 否则返回 false
-
- 切忌把开关逻辑写死在 handler 里；它必须可被单元测试覆盖，且能响应配置中心的
watch事件实时更新
本地 LRU 缓存服务发现结果才能扛住击穿
当所有 user-svc 实例瞬间宕机，大量请求同时触发服务发现查询，若每次都去 etcd 拉全量列表，会引发下游存储雪崩。
- 在
service层维护一个本地<em>lru.Cache</em>（如github.com/hashicorp/golang-lru），key 是服务名，value 是[]Instance - 查询前先读缓存，命中则直接用；未命中再走远程发现，并写入缓存（TTL 设为 10s，比健康检查周期短）
- 降级分支也复用这个缓存：当需要 fallback 时，直接从本地 LRU 取最近一次成功的实例列表（哪怕已过期），或退化到硬编码的备用地址（如
"localhost:8081"） - 注意：LRU 的
OnEvicted回调里别做任何阻塞操作，否则会拖慢整个服务发现流程
复杂点在于服务发现结果的语义模糊性——空列表可能是“真无实例”，也可能是“查询超时”。没有统一的错误码能区分二者，只能靠组合超时、熔断、人工开关三重信号做决策。这点容易被忽略：很多人只处理了 err != nil，却没深挖 err 的具体类型，导致 DNS 超时和实例全挂两种场景走了同一套降级路径，而后者其实该返回更保守的默认值。
