这篇文章讲述了现代航空订票系统背后依赖的古老基础设施。作者在预订机票时发现，支撑全球每年45亿人次出行的系统，竟源自1960年代设计、至今仍在运行的陈旧技术。这一发现引发了他对这套持续运转60年、每秒处理万笔交易的老系统的好奇，并决定通过六部分系列文章深入探究其背后的故事。

构建一个行业的难题

《铁核系列》六部曲首篇——这套运行60年的基础设施每年承载45亿旅客

2025年12月，Technogise员工通过MakeMyTrip企业平台为我预订伦敦往返机票，全程耗时不足一分钟。确认邮件中的六位预订编码DDTCIV和DHB4AL，将带我前往2026年ContainerDays大会——这个探讨容器化、编排与云原生基础设施的会议，本应展现现代无状态系统的精髓。

直到飞行途中我才惊觉：这套预订系统诞生于1960年，运行在比Unix更古老的操作系统上，使用电传打字机时代的指令语言。它持续运转六十余年未经重构，峰值时每秒处理万笔交易。

前SABRE时代

1950年代中期，美国航空使用索引卡管理预订。跨大西洋订票需90分钟，日均处理8.5万请求。1953年，美航总裁与IBM销售代表在航班上的偶遇，催生了1964年问世的SABRE系统（半自动商业研究环境）。当时IBM System/360尚未面世，ATM未发明，阿波罗计划仍在筹备。

随后十年间，全球分销系统（GDS）矩阵形成：

| 系统 | 创立年 | 所有者 | 技术基础 | |---------|--------|----------------------|----------------| | SABRE | 1964 | 美航+IBM | IBM ACP/TPF | | Apollo | 1971 | 联合航空 | IBM TPF | | Galileo | 1987 | 多国航司联盟 | IBM TPF | | Amadeus | 1987 | 欧洲航司联盟 | 大型机→Unix |

不朽的TPF系统

事务处理设施（TPF）是专为航空交易设计的操作系统，与Unix有本质差异：

| 特性 | TPF | 现代操作系统 | |-------------|------------------------------|---------------------------| | 进程模型 | 瞬时执行的"程序" | 进程/线程/协程 | | 内存模型 | 固定内存单元 | 虚拟内存/垃圾回收 | | 事务处理 | 单笔事务回滚（系统永不崩溃） | 应用级容错 | | 性能表现 | 日常1万TPS，促销期5万TPS | 通常难以匹敌 |

1990年代当各行业转向Unix时，航空业因TPF的极致性能选择坚守。如今IBM Z系列主机仍运行z/TPF，只因六十年来未有替代方案能超越。

现代预订链解密

我的行程触发了以下跨系统协作： 企业差旅平台→OTA接口→Amadeus GDS→航司PSS系统→国际航协结算→电子票证生成 这串跨越不同年代、国家、协议的交互，最终凝结为六位PNR编码。而印度靛蓝航空等廉航采用的Navitaire系统，则展现了针对高频点对点航班的架构取舍。

核心启示

1. 适用性优于时髦架构：TPF虽不符合现代架构评审标准，却能以更低成本实现5万TPS的亚百毫秒响应，持续六十年验证其价值。
2. 趋同进化存在：主流GDS最终均采用相同底层平台，反映市场对特定问题的最优解选择。
3. 迁移成本巨大：印度航空2023年PSS系统迁移耗时数年，涉及历史数据、常旅客计划等复杂整合。

（系列第二篇将揭秘PNR编码DDTCIV背后的航空业数据密度之谜）

本文作者Ajitem Sahasrabuddhe系Technogise软件工程师，曾于2026年伦敦ContainerDays大会发表演讲。

以下是评论内容的总结：

1. 对传统系统性能的肯定

   • 多位评论者赞赏SABRE系统的高效性能，指出其60年来保持低成本高吞吐量（5万次交易/秒，延迟<100ms）
   • 引用："handles 50,000 transactions per second...costs a fraction of an equivalent cloud footprint"
   • 引用："SABRE is a reminder that things that are well designed just work"

2. 关于技术发展速度的讨论

   • 有评论指出实际开发耗时远超文章描述（1953年构思→1959年合作→1964年上线）
   • 引用："Over a decade after...sat next to each other"
   • 引用："a reminder that things take time"

3. 现代技术栈的反思

   • 批评现代技术过度抽象化（虚拟机→容器→运行时等多层堆叠）
   • 认为Rust/Go等编译型语言是正确方向
   • 引用："Do we really need to stack all these turtles"
   • 引用："Every one of those layers...adds to complexity"

4. AI对未来系统设计的潜在影响

   • 提出AI可能推动专用系统复兴，根据输入输出自动构建定制方案
   • 引用："will we see a return to built for purpose systems"

5. 其他观点

   • 对架构评审标准的质疑："What kind of review would it fail? Sounds well designed"
   • 技术语言选择的重要性：Lisp对ITA Software成功的关键作用
   • 简单架构的推崇："No daemons. No background threads"

（注：原评论均无评分数据，故未体现认可度量化指标）