2名工程师加AI，把500PB存储从Python换成Rust：OpenAI披露Habitat改造细节

9月11日，OpenAI工程团队发了一篇技术博客，讲的是自家在线存储平台Habitat的改造。这台“隐形引擎”现在的体量是：每秒处理超过7000万次请求，承载超过500PB数据，覆盖近40个地理区域，支撑的产品每周用户超过10亿。而完成从Python到Rust整体重写的，是2026年第二季度的两名工程师，借助Codex和GPT-5.5辅助。

Habitat的起点很小。2024年年中，它只是ChatGPT主服务上的一个Python客户端库，背后对接一个Azure Cosmos DB实例，替业务工程师屏蔽掉路由、鉴权、加密、序列化这些琐事。因为省事，内部团队主动放弃自建Postgres和独立数据库实例涌了进来。到2025年年中，它已经不是“一个库”能扛的了：每次改路由都要协调数十个服务的发布顺序，灰度上线，一次故障回滚就能抹掉团队数周的工作。于是它被拆成独立服务，换来统一的部署控制点、可观测性和访问控制。

为什么会碰到天花板，博客讲得比数字有意思。Python的asyncio能并发IO，但受GIL限制，CPU并行能力有限。Habitat干的偏偏是路由、压缩、加密、校验和、影子流量这类重CPU活。负载一高，协程拿不到调度，socket收到数据却读不出来，长尾延迟直接抬起来。团队还揪出两个具体病根：一是功能开关配置每分钟全量拉取、没有时间抖动，同一个Pod里所有Python进程同时解析大JSON，周期性抢占CPU；二是连接池默认的LIFO策略，突发流量过后负载更高、更慢的进程最后归还连接，新请求又被优先分给这些过载实例，形成负反馈，关掉流量源都久久不能恢复。改成FIFO之后，新请求会分散到健康节点，这个循环才被打破。

另一个值得记的工程细节是“连接扇入”。Python进程大规模横向扩容会创建海量TCP连接，容易耗尽NAT网关和数据库连接资源。OpenAI的做法是在中间放Envoy做聚合：把所有Pod的流量收进来，Envoy维护共享连接池，把上游HTTP/1转成HTTP/2多路复用，集群峰值连接数从“随Pod线性膨胀”收敛成个位数长连接，限流和熔断也统一在这一层做，避免各进程自己实现导致效果衰减。

接口设计上，Habitat做了刻意的减法：不开放通用SQL，禁止客户端提交任意SQL，不支持全表扫描和跨表Join，只提供开销可预测的固定代价读写接口。复杂查询通过CDC把数据近乎实时同步到独立的Rockset实例上处理，扩容运维责任划归业务团队，在线负载和分析负载彻底隔离。这套取舍的逻辑很朴素——超大规模系统里，可控的接口换来的是稳定性，代价是牺牲灵活性。

结果方面，官方给出的对比是：Python版本高峰时支撑每秒2000万次以上的请求，Rust版本目前在承载95%生产请求，CPU效率提升6倍，内存效率提升15倍，平均延迟与尾部延迟同步下降，Python版本将在数周内完全下线。有一点需要说清楚：官方并未公布测量条件、延迟的具体差值，也没说明重写代码里AI生成占多大比例，这几个数字应当按“特定系统、特定场景”来读，不能直接推导成“所有Python服务换Rust都能提升15倍”。真正可复用的经验是那条路线图——先用Python快速把功能和接口跑起来，把性能当成有计划的债，等到规模逼近瓶颈再动手清偿；以及超大规模系统里，尾部延迟和连接治理往往比峰值吞吐更值得盯。