一个普通旅客订一次旅行，要打开277个页面和应用。这个数字常被用来骂体验烂，但Parag Khanna读出了另一层意思——这是分布式系统故障的用户端症状。酒店确认单在一个系统，签证状态在另一个，体验门票又在别处。数据模型互不兼容，事务边界各自为政。行程中途一变，旅客自己成了人肉集成层：打电话给航司、重订酒店、协调接驳。
Khanna是Booking.com的资深架构师，也是Infinity项目的负责人。他的判断很直接：旅行行业的核心问题不是界面设计，而是没有平台把"一次旅行"当作连贯的实体来管理。现有系统各自为战，旅客被迫在缝隙里手动缝合自己的行程。
为什么不用现成的？
Booking.com试过。他们评估过市面上所有主流方案，结论是每个都被某种根本性的妥协困住。要么为了实时性牺牲一致性，要么为了扩展性放弃事务完整性。旅行场景的特殊性在于：一个订单位置变了，可能触发酒店、租车、保险、签证的连锁调整。这种级联依赖在电商里罕见，在旅行业却是常态。
Khanna团队发现，现有架构把"库存"和"预订"当成两个独立问题处理。库存系统管有没有房，预订系统管扣不扣款。但一次完整的旅行交易，需要同时回答三个问题：资源是否可用？价格是否锁定？支付是否成功？三者必须原子性完成，否则就会出现"扣了钱没订上房"的经典噩梦。
Infinity的解法：把旅行变成状态机
Infinity的核心设计是把一次旅行建模为有限状态机（Finite State Machine，一种通过定义状态和转移规则来管理复杂流程的数学模型）。每个行程组件——航班、酒店、活动——都是状态机中的一个节点。节点之间的依赖关系被显式声明，而非隐式硬编码。
这种设计的妙处在于故障隔离。传统架构里，一个下游系统超时可能拖垮整个预订流程。Infinity把每个组件封装在独立的事务边界内，失败可以局部回滚，成功可以异步确认。Khanna打了个比方：以前的系统像串联电路，一断全断；Infinity像并联电路，局部故障不影响全局。
更关键的是时间维度的引入。旅行不是瞬时交易，而是持续数天甚至数周的状态演变。签证可能在出发前三天才获批，航班可能临时改签。Infinity把"时间"作为一等公民纳入数据模型，每个状态节点都携带有效时间窗口，系统可以主动推送变更而非被动等待查询。
从工具到平台：架构层的野心
Infinity最初是Booking.com的内部项目，但设计目标从一开始就指向开放。Khanna团队正在构建一套供应商接入协议，允许第三方把库存、规则、定价逻辑以声明式方式注册到平台。这意味着一个小型签证服务商，无需自建预订系统，只需描述自己的状态转移规则，就能接入全球旅行网络。
这种架构选择暗含一个判断：旅行行业的护城河不在流量，而在协调复杂度。谁能把分散的状态整合为连贯的行程实体，谁就能定义下一代基础设施。Booking.com显然想赌这一把。
项目目前处于有限公测阶段，首批接入的是欧洲铁路和东南亚体验供应商。Khanna在内部文档里写过一句话：「我们不是在优化预订流程，是在重新定义旅行的数据形态。」这句话没出现在任何新闻稿里，但可能是理解Infinity最精确的切口。
277个页面的数字会不会变成历史？取决于多少供应商愿意把状态机的主导权交出去——或者说，取决于他们有没有更好的选择。
热门跟贴