Facade、Observer、CircuitBreaker、ServiceDiscovery 是 Go 微服务中高频落地的四大模式：Facade 用于网关层轻量编排多服务调用；Observer 借助消息队列异步解耦服务通知；CircuitBreaker 需合理配置阈值、超时与降级逻辑；ServiceDiscovery 结合单例 gRPC 连接实现动态负载均衡与健康检查。
Facade、Observer、CircuitBreaker、ServiceDiscovery 这四个是真正在 Go 微服务里每天写 main.go、调 grpc.Invoke、加超时、配熔断时会撞上的模式，不是教科书里罗列的 23 种。其他像策略、模板方法等，更多出现在单体业务逻辑里，微服务边界上很少直接落地。
网关层怎么聚合多个服务？用 Facade，但别让它变重
前端一个请求要查用户 + 权限 + 订单，你不可能让前端自己串三个 HTTP 调用——重试、超时、错误码统一都得重复写。网关层（比如用 gin 写的 BFF）用 Facade 封装组合逻辑，才是正解。
- 关键不是“多调几个服务”，而是把协调逻辑收口：比如
a.TestA()失败时要不要跳过b.TestB()？要不要兜底返回部分数据？这些都在apiImpl.Test()里集中决策 - 别在
Facade方法里做业务判断（比如“VIP 就查积分”），那是下游服务的事；它只负责“怎么串”，不负责“为什么串” - 常见坑：把数据库查询或耗时计算塞进
Facade，导致网关变慢——它必须轻量，所有重逻辑下推到对应微服务 - 实操示例中，
context.WithTimeout必须传给每个子调用，且defer cancel()要紧贴上下文创建之后，否则超时不生效
服务间发通知总耦合？用 Observer + 消息队列异步解耦
订单创建后要通知库存、发短信、记日志，但你不该让订单服务 import 库存包或硬编码调短信 SDK——改个渠道就得动订单代码，这就是典型耦合。
- 真实项目中，90% 的
Observer实现其实是 “发布-订阅” + 消息队列（如NATS或Kafka），不是内存里维护[]Observer切片 - 千万别在
Notify()里同步调多个Update()：一个卡住，整个流程就卡死；正确做法是把事件丢进goroutine或队列异步处理 - 注意消息体序列化格式要稳定，推荐用
Protobuf定义事件结构，避免 JSON 字段名变更引发消费者 panic
hystrix-go 配了熔断却更脆？阈值和降级逻辑比开关本身更重要
hystrix-go 不是加了就高可用，配错反而让服务更脆。它本质是“快速失败 + 降级兜底”的开关，不是万能缓存或重试器。
-
ErrorPercentThreshold设太高（比如 50%）会导致熔断太迟，雪崩已开始；设太低（比如 5%）又容易误熔，正常抖动就被拦住 -
Timeout必须小于上游调用方的超时（比如网关给了 800ms，这里最多配 600ms），否则降级永远不触发 - 降级函数不能只是返回空字符串或
nil，得兜得住业务语义：比如用户服务熔断时，返回默认头像 + “暂不可用”状态，而不是让前端炸开 - 别忘了配
MaxConcurrentRequests：防止突发流量打穿下游，这个值要结合下游实例数和单实例 QPS 估算
gRPC 连接反复初始化？用单例 + ServiceDiscovery 复用连接
微服务之间用 gRPC 通信，如果每次调用都新建 grpc.Dial，不仅耗 CPU 和 fd，还会绕过负载均衡策略，直连第一个解析到的 IP。
- 必须配合服务发现（如
etcd或Consul）动态获取实例列表，并用单例模式复用*grpc.ClientConn - 连接要带健康检查：
grpc.WithKeepaliveParams+grpc.WithWatchers，确保断连后自动重连，而不是死连一个挂掉的节点 - 常见坑：在 handler 里每次请求都
grpc.Dial，连接数暴涨，K8s 下 Pod 很快被 OOMKilled - 实操建议：把连接管理封装成
NewUserServiceClient工厂函数，在app.go初始化阶段一次性建立并注入，后续全用它
context.WithTimeout 时有没有顺手传下去，每次发消息时有没有确认序列化是否向后兼容，每次配 hystrix 时有没有看一眼下游最近一周的 P99 延迟——这些细节，才是线上不出事的关键。 
