多供应商搜索的第一版实现，通常是给供应商客户端数组套一个 Promise.all。Demo 里能跑，架构图上看也优雅，到了生产环境就崩：第七家供应商耗时八秒，第十二家对同一家酒店换了个 ID 返回重复数据，合并后的目录里同一个房型出现三个不同价格，客户根本不知道该信哪一个。

并发扇出不是架构，它只是前置条件。真正的问题在响应开始回来之后。

简单扇出为什么撑不住

酒店分销行业建立在异构数据模型之上。同一家实体酒店，在 A 供应商系统是 HTL-48291，在 B 系统是 PROPERTY_7723，在 C 系统可能是个 SHA256 哈希。同一个房型，A 叫 “Deluxe King with City View”，B 叫 “DLX-K-CV”。一个含早餐的报价，在另一家响应里不含早餐，而差异埋在一段自由文本的策略字段里。

当平台把搜索当成「问所有人，拼接结果」，客户拿到的是一个看起来全面、实际上无法使用的目录。重复 listing 侵蚀信任，不一致的房型描述催生客服工单，跨不兼容价格结构的排序在技术上正确、在商业上毫无意义。

行业对此的应对方式是把问题推给下游。OTA 把同一酒店的多供应商报价拆成独立选项展示；元搜索引擎显示「起价」区间，把结构性差异藏在背后。客户被迫比较苹果和橙子，然后自己做决定。这不是用户体验，是用户负担。

HotelByte 的受控竞争模型

HotelByte 把实时搜索视为供应商之间的受控竞争，而非简单扇出。调度层确实并发发请求——这是基本功——但合并层、处理层和缓存层施加了一套确定性的标准化流水线，把异构响应转化为单一的标准目录。

合并层通过映射层把供应商专属的酒店 ID 解析为主酒店 ID，房型描述通过自动和手动映射集成对齐到标准化分类体系。兼容的报价被聚合到统一条目下，客户看到的是一家酒店、一种房型、一组可比价格。

处理层执行冗余检测、价格排序、每酒店报价上限控制和业务规则转换。冗余包——相同或近似的房型和报价组合——被标记而非删除，保留透明度。Seller-out 和 buyer-out 规则操作的是标准化后的标准模型，而不是原始供应商响应，确保所有买家的一致性。

缓存层通过双维度最低价缓存和会话回退保护延迟。当内容服务不可用时，搜索引擎回退到 30 秒内捕获的会话快照，在瞬时故障期间保持功能可用。

受控竞争的代价

标准化流水线增加了延迟。映射解析、房型合并、规则引擎执行都不是免费的。平台接受这一点，因为替代方案——返回原始未合并的供应商数据——对客户是更差的结果，对平台则意味着更高的客服工单和预订错误成本。

还有覆盖度的取舍。如果某供应商的响应无法映射到主目录——因为酒店未知或房型无法识别——它可能被排除在结果集之外。简单扇出系统会把它包含进来。HotelByte 选择目录正确性而非目录广度。

白皮书阅读路径

Search Aggregation Architecture 章节详细阐述了四层架构——调度、合并、处理、缓存——及其各自的控制点和故障域。Search Request Lifecycle 章节完整走查了一次查询从准入到响应组装的全过程。对运维人员而言，Auditability 章节描述了分布式 trace 关联、结构化质量指标和规则引擎执行日志，使聚合行为可被验证。

完整白皮书见 英文版 和 中文版。全部白皮书索引参见 Whitepaper Index。