OpenAI用Python扛住每秒七千万次请求

一次真实事故推动了这个结论。当时的任务是把核心数据拆分到多个区域的Azure Cosmos DB账户，以免单个区域故障波及全局，而仅仅把路由逻辑放进客户端、藏在功能开关后面并推送到所有服务，就花了好几天。加上用于验证的影子运行又是几天，修正发现的问题再花几天。就在开关即将打开之前，一个团队因无关原因回滚到了旧版本，他们竭力想避免的那次故障还是发生了。

第二个判断是没有立刻放弃Python。公司明知用Python跑服务会增加网络延迟、大幅推高CPU和内存成本，仍然照旧推进。作者们解释说："我们当时的主要目标不是成本或资源优化，而是解开产品开发者的束缚并让平台稳定下来。"他们同时把这个选择定性为有意背上的技术债，并写明它在百倍规模下行不通，因此重写几乎是必然的。

在靠Python支撑的这段时间里，团队缠斗最久的是尾部延迟。作者们写道："由于平均一次用户请求会引发数百次数据库调用，用户真正感受到的是其中最慢的那一次。"Python的asyncio能让输入输出重叠处理，却无法分摊CPU，所以当压缩、加密、校验和这类CPU工作堆积起来，即便响应已经到达，也轮不到有人去读它。公司称这种排队延迟会拉长到数百毫秒，严重时甚至几秒。于是他们让每个进程只承担极少的并发请求，转而大规模扩充进程数量。

找出原因的方式很具体。服务首次上线时，CPU性能剖析锁定的元凶是功能开关的配置文件。开关工具默认每分钟重新读取一次包含所有服务全部生产规则的大型配置，而且每次都在完全相同的时刻、毫无错峰。一个Pod里最多跑八个Python进程，于是每分钟所有工作进程会同时停下手头的事去解析那个大文件。解决办法是下发更小的定向配置、拉长刷新周期并把时间打散。

改变连接复用顺序的那一段更有意思。某天他们关掉了造成过载的客户端，可部分进程仍在持续恶化，在重启之前反而收到更多请求。原因是Python的aiohttp连接管理器默认优先复用最近归还的连接。服务器越慢，归还连接越晚，那条连接就越容易被下一次请求选中，于是形成了把更多活儿堆给吃力进程的反馈回路。改为按归还顺序复用后，这个回路被切断，连日常波动也随之减小。

设计上也有刻意舍弃的东西。Habitat不让客户端随意编写SQL抛过来，只开放简单的NoSQL接口。作者们写道："缺少强大的API是Habitat设计中有意为之的取舍。"公司承认，在使用Postgres的年代，一条昂贵查询落到热点路径上把整个数据库压垮是常有的事，而现在昂贵查询在客户端一侧就会显得刺眼。

公司自己写下的局限是图结构。对象和挂在该对象上的边会放在同一个存储分区，但并不刻意把边所指向的另一端对象也放在一起。横向扩展因此变得容易，代价是每跨越一条边，就可能要从另一个区域的另一个账户取数据。对需要复杂查询的团队，公司提供由变更记录流式生成的独立分析副本，并承认这种方式给使用方增加了额外负担。

然后在今年第二季度，Python被收起来了。两名工程师借助Codex和GPT-5.5把整个服务用Rust重写，目前95%的生产请求由Rust承接，公司表示Python将在数周内完全下线。按公司自己的数据，Rust版本的CPU效率高6倍、内存效率高15倍，平均延迟和尾部延迟都明显更低。Python支撑的峰值是每秒两千万次以上的请求。METAL此前报道过OpenAI把运行Codex的harness通过API开放，而这篇文章正是该公司先把这件工具用在自家基础设施上的记录。

在METAL通读的这份发布文中，最醒目的一句是做出该决定时的盘算。作者们写道："我们赌的是，等到必须彻底迁出Python的时候，Codex和GPT能够完成这次迁移。这个赌注最终被证明是对的。"这意味着他们在有意背上技术债的同时，把自己正在打造那件偿债工具这一事实也算进了变量里。Habitat目前按核心数计算是OpenAI第二大服务，按Envoy用量计算排第四。

这篇文章留下的教训不在于语言选择。公司写道，围绕简单、可预测、工作量恒定的请求来设计，系统会明显更容易扩展，也更不容易被用错。Habitat之所以能靠Python跑到每秒两千万次以上，正是因为它把接口画得很窄。承接规模的力量不来自更好的材料，而来自一份事先定好的、关于这个系统不做什么的清单。