支撑10亿用户：OpenAI在线存储平台Habitat演进实录

OpenAI的每一款产品都高度依赖快速、可靠的数据存取——无论是用户登录、检查配置，还是在ChatGPT中开启新会话，每个动作背后往往伴随着多次数据检索。

为此，OpenAI构建了在线存储平台Habitat。如今，Habitat每秒处理超过7000万次请求，为全球近40个区域、每周逾10亿用户提供支持，承载超过500PB数据。而在两年前，它还只是一个连接单一数据库的简单Python客户端库。

什么是Habitat？

Habitat始于一个核心理念：业务研发工程师不应分心于数据库管理。

2024年年中，Habitat最初以Python客户端库的形式上线，底层对接Azure Cosmos DB。它负责屏蔽模式查找、路由、鉴权、加密、序列化与连接池等底层细节，让产品团队只需专注于存取接口。随着产品需求演进，客户端还逐步加入了本地缓存、压缩与加密等能力。

从客户端库转向独立服务

到了2025年年中，客户端库模式遭遇瓶颈。随着OpenAI微服务数量激增，保持向后兼容的协议变更变得极度繁琐。

在一次跨区域故障隔离改造中，团队需要向客户端引入路由逻辑，并通过特性开关（Feature Flag）逐步灰度。这需要协调数十个服务团队依次上线、部署阴影测试、修复Bug。耗时数日准备就绪后，某个业务团队因无关故障回滚了服务，旧版客户端随即引发了原本试图避免的线上故障。

协调部署的脆断与高风险促使团队做出决定：将Habitat解耦为独立服务。独立服务建立了统一的部署、可观测性与功能升级控制面，同时也构成了强健的安全防线，可集中执行访问控制、审计日志，防范来自外部、内部及AI智能体（Agent）的未授权访问。

将Python服务推向极限

尽管团队深知在高并发场景下使用Python会导致网络延迟、CPU及内存开销剧增，但在超高速增长期，首要目标是快速解耦业务和保障系统稳定。团队选择承担短期技术债务，并押注未来强大的代码大模型能够协助完成底层重写。

在此架构下，核心技术挑战集中在长尾延迟（Tail Latency）治理：

1. 监控asyncio调度延迟：Python虽然通过asyncio支持I/O并发，但在全局解释器锁（GIL）限制下无法实现CPU并行。Habitat承担了大量CPU密集型工作（路由、压缩、加密、校验等），协程经常因CPU被占用而排队挂起。团队通过实时测量事件循环调度抖动，最终采用限制单进程并发数、大规模水平扩展Python工作进程的策略。
2. 优化特性开关解析：排查发现，Statsig默认每分钟无随机抖动（Jitter）拉取全量配置并解析巨型JSON，导致每个Pod的所有工作进程周期性CPU被打满并挂起请求。团队通过缩减配置体积、延长拉取间隔并注入抖动化解了该问题。
3. 防范连接池导致的亚稳态故障：aiohttp的TCPConnector默认使用后进先出（LIFO）连接复用策略。当突发流量到达时，处理较慢的高负载Pod返回连接更晚，反而更容易被后续请求选中，陷入负载越来越重的恶性循环（亚稳态故障）。团队将其改写为先进先出（FIFO）复用，打破了这一反馈环，后续全面引入Istio和Envoy进行负载均衡与连接管理。
4. 借助Envoy缓解下行惊群效应：数以万计的Python进程在日常发布或网络抖动时极易打满底层NAT网关或Cosmos DB。团队通过部署Envoy将Python的HTTP/1连接聚合升级为HTTP/2多路复用，大幅削减底层连接数，并集中实施限流与熔断。

约束API以确保可预测性

Habitat放弃了灵活但高风险的任意SQL查询，转而采用受TAO启发的NoSQL数据模型，仅暴露简单的对象（Object）与边（Edge）接口。每个对象与其边在存储层面就近共存，天然支持水平分片，彻底杜绝了大表扫描与跨节点复杂Join引发的单点级联故障。

针对复杂查询与分析需求，团队利用变更数据捕获（CDC）将在线数据准实时同步至Rockset等离线只读引擎，让在线存储彻底免受重度分析流量的干扰。

借力AI重构为Rust

Python支撑Habitat度过了极速扩张期，峰值处理能力超过每秒2000万次请求。到了2026年第二季度，系统已成为OpenAI CPU核数占用第二大的服务，重构时机终于成熟。

仅由2名工程师借助Codex与GPT-5.5的辅助，团队将整个存储接入服务用Rust彻底重写。目前，Rust服务已承接95%的生产流量，相比Python版本实现了CPU效率提升6倍、内存效率提升15倍，并显著降低了P99长尾延迟。