遇到供应商接口失败，第一反应几乎总是同一个：加重试。加个指数退避，再配个熔断器——如果团队读过那几篇经典博客的话。但很少有人先问一句：供应商到底在报什么类型的错误？重试是让情况变好，还是更糟？

这个区分之所以关键，是因为不是所有失败都等价，但大多数平台把它们倒进同一个桶里。包房商的超时属于瞬态基础设施故障，重试合理；HTTP 429 是供应商在明确喊”慢点”，立刻重试等于攻击对方容量；HTTP 4xx 业务错误——无效目的地代码、房态已满、价格变动——是预期内的应用结果，重试只会浪费资源并误导监控；凭证失效是安全或配置问题，反复重试可能触发账号锁定并留下审计隐患。没有分类，重试策略就变成一把钝刀，在平台最该卸压的时刻反而放大负载。

HotelByte 的供应商韧性工程层建立在相反的假设上：任何韧性决策之前必须先完成失败分类。平台把出站失败分为四类——瞬态基础设施错误、限流信号、业务级 4xx 结果、凭证或配置失败——并把它们路由到不同的控制路径。业务错误不计入熔断阈值；限流响应触发自适应学习而非盲目重试；凭证失败立即暴露给运维人员，而不是藏在重试循环里。

熔断器的实现粒度是 supplier:apiName 维度，而不是整家供应商。这是一个细微但致命的边界。假设某供应商的取消接口异常，不应该消耗同一家供应商搜索接口的失败预算——后者可能完全健康。维度隔离防止了交叉污染，确保在部分降级时控制仍然精确。

限流采用双引擎架构。配置驱动引擎按凭证维度强制执行静态限速，可全局生效也可按 API 名细分。自适应学习引擎则响应实时 HTTP 429 信号，从近期请求窗口计算安全阈值并持久化到分布式缓存。严格的 QPM 调度器平滑请求准入，避免区间边界的突发-饥饿模式。结果是供应商侧的配额变化可以被自动吸收，无需人工调参或紧急发布。

录制与回放层提供了让一切可验证的取证能力。边界检测器把请求分为边界触发类和正常流量类：边界事件 100% 录制，正常流量采样存储。脱敏器在存储前清除 PII 和凭证。回放播放器可以对历史请求在当前实现上重新执行，用于供应商侧变更或平台更新后的回归验证。没有这一层，韧性控制就成了信仰——你相信熔断器工作，只是因为代码看起来对，而不是因为你有证据。

中间件链的顺序是刻意且不可绕过的：缓存查询 → 限流 → 熔断器 → 代理 → HTTP 传输 → 错误映射 → 缓存写入。每次供应商请求都流经完全相同的序列。缓存查询跳过下游控制以提升效率；限流排在熔断器之前，避免队列中的请求被过早拒绝；熔断器保护实际的 HTTP 传输；错误映射在响应返回后执行。这个顺序不是建议，而是由统一执行器强制实施，且架构上禁止使用裸 HTTP 客户端。

如果你正在评估这套系统，白皮书中最值得细读的章节是：

  • 核心设计原则 —— 理解快速失败与优雅恢复、从反馈中学习、维度隔离背后的 reasoning。
  • 限流层 —— 了解自适应学习引擎的机制和严格 QPM 调度器的工作方式。
  • 熔断器层 —— 弄清 4xx 与 5xx 的分类逻辑，以及按端点细分的熔断范围规则。
  • 录制层 —— 掌握边界检测、采样策略、脱敏处理和回放验证路径。
  • 中间件集成层 —— 确认控制点的精确顺序，以及为什么裸 HTTP 客户端被架构层面禁止。

完整中文白皮书请见 WP07 — 供应商韧性工程，英文版本见 WP07 Original。全部白皮书索引请访问 HotelByte 白皮书索引。

持久的教训是：韧性不是一堆机制的集合，而是一种分类纪律。重试、熔断和限流的好坏，完全取决于喂养它们的失败分类体系。没有这个体系，每一次韧性策略都是在赌博。