Go服务中Facade模式的应用实践

Facade模式在Go微服务中解决调用方对多个下游服务依赖分散的问题，通过组合+导出接口统一收口跨服务调用，降低认知负担与出错概率。

Facade模式在Go微服务中解决什么问题

它不是为了解耦接口和实现，而是为了收口调用方对多个下游服务或模块的依赖。当你发现一个业务函数里反复写 userSvc.GetUser()、orderSvc.GetOrdersByUID()、notifySvc.SendSMS() 这类跨包调用时，就该考虑加一层 Facade 了。

Go 没有抽象类或继承驱动的 Facade，它的实现本质是「组合+导出接口」：把底层依赖注入到结构体中，再统一暴露简洁的方法。关键不在“模式名称”，而在是否真的减少了调用方的认知负担和出错概率。

如何定义一个可测试、易替换的Facade接口

别直接暴露 struct，必须先定义 interface。否则单元测试时无法 mock，重构时也会卡住。

• 接口方法名要面向业务动作，比如 PlaceOrderWithUserCheck()，而不是 CallUserAndOrderSvc()
• 入参尽量用 value 类型（如 int64、string）或不可变 DTO（如 type PlaceOrderReq struct{ UID int64; Items []Item }），避免传指针导致副作用难追踪
• 返回值优先用具体 error（如 *user.NotFoundError）而非泛化 error，方便调用方做类型断言处理
• 接口定义放在调用方能 import 的位置（通常是 facade 包下），而不是被封装的服务包里

初始化Facade时依赖注入的常见陷阱

很多人会把 new 函数写成无参的 NewOrderFacade()，内部直接 new 各个 service 实例——这会让测试完全失控，也违反了依赖倒置。

• 必须显式接收依赖：比如 func NewOrderFacade(u user.Service, o order.Service, n notify.Service) *OrderFacade
• 如果某依赖是可选的（如通知服务降级），不要用 nil 判断，而是提供带默认行为的 wrapper，例如 notify.NoopSender{}
• 避免在 Facade 初始化时做 heavy init（如连接池预热），应延迟到首次调用时，或由上层统一管理生命周期
• 注意循环依赖：facade 包不能 import controller 或 handler 包，否则编译失败；所有依赖方向必须单向指向底层

Facade方法里要不要做重试、熔断、超时控制

要做，但只做“调用粒度”的控制，不做“业务逻辑重试”。比如 PlaceOrderWithUserCheck() 内部对 userSvc.GetUser() 设置 2s 超时 + 1 次重试是合理的；但对整个下单流程做重试就错了——那是上层事务或 saga 的事。

• 超时建议用 context.WithTimeout() 透传，不要硬编码 time.Sleep
• 熔断推荐用现成库（如 sony/gobreaker），状态存储独立于 Facade 实例，否则重启即失效
• 错误聚合要分层：底层 service 返回 user.ErrRateLimited，Facade 可转为 facade.ErrUpstreamRateLimited，保持语义清晰
• 日志打点必须包含 traceID 和关键参数（如 UID、OrderID），否则线上排查时根本串不起链路

最常被忽略的一点：Facade 不是万能胶，它不该承担数据转换、缓存组装、权限校验等职责——那些应该由单独的 domain 层或 adapter 处理。越想让它“啥都干”，就越容易变成难以维护的上帝对象。