外观模式通过定义高层接口封装多个微服务调用逻辑，使客户端仅对接单一入口；外观类仅协调已有服务客户端、不实现业务规则、不暴露原始接口、统一处理共性逻辑、适配异构协议、支持灰度演进。
外观模式通过定义一个高层接口，把多个微服务子系统的调用逻辑封装起来，让客户端只需对接这一个入口，不用关心内部有多少服务、调用顺序、异常处理或协议转换。
明确职责边界：外观类不实现业务，只做协调
外观类本身不处理订单校验、库存扣减或支付逻辑，它只负责按正确顺序组合调用已有的微服务客户端（如 OrderServiceClient、InventoryClient、PaymentClient）。每个子服务仍由各自模块独立维护，外观层只持有它们的引用并编排流程。
- 避免在外观里写业务规则（比如“库存不足时降级走备用通道”应放在库存服务内，而非外观中）
- 不暴露子服务的原始接口，例如不把 FeignClient 或 RestTemplate 直接返回给上层
- 统一处理跨服务的共性逻辑：鉴权透传、链路ID注入、超时配置、熔断兜底响应
封装调用链与错误场景
一个下单请求涉及库存预占、创建订单、发起支付三个远程调用。没有外观时，Controller 需手动处理每个调用的 success/fail、回滚逻辑、重试策略；有了外观，这些都收口到一个方法里：
- 自动按事务语义编排：先调库存 → 成功再调订单 → 成功再调支付
- 失败时统一执行补偿：库存已扣但订单创建失败 → 调用库存服务回滚接口
- 将分散的 HTTP 状态码、RPC 异常、业务码（如 inventory_full）统一转为标准 Result<OrderDto>
适配异构协议与数据格式
微服务间可能混用 REST、gRPC、Dubbo、消息队列。外观类作为“翻译中枢”，对外提供统一 DTO，对内适配不同协议：
立即学习“Java免费学习笔记（深入）”；
- 接收 JSON 请求 → 转成 InventoryRequest 对象 → 调 gRPC 接口
- 从 Kafka 消费的事件 → 封装为内部事件对象 → 触发外观提供的 notifyStatusChange() 方法
- 把各服务返回的 userId、openId、dingUserId 等不同标识，在外观层做映射归一
支持灰度与可插拔演进
当某个子服务要升级版本或替换技术栈（如支付从支付宝 SDK 切到银联云闪付），只需修改外观类内的具体实现，Controller 层完全无感：
- 用策略模式 + Spring Profile 控制不同环境下的支付客户端实例
- 新增一个 PaymentV2Impl，外观类根据配置自动切换，老代码无需重编译
- 对外保留 createOrder(request) 方法签名，内部可逐步将同步调用改为异步事件驱动
