8.2
深览指数
产品Bestblogs·OpenAI··AI 生成
快速扩展在线存储以服务超过 10 亿 ChatGPT 用户
OpenAI 工程团队详解其在线存储平台 Habitat 从 Python 客户端库演进为独立微服务的过程。文章的核心贡献在于，它不仅阐述了处理每秒超 7000 万请求、500PB 数据所面临的具体工程挑战（如 asyncio 调度延迟、LIFO 连接池导致的亚稳态故障），更坦诚地讨论了战略性的技术债决策——明知 Python 性能瓶颈却刻意保留，并押注于 AI 辅助迁移。适合有后端系统或分布式系统背景、关心大规模系统真实权衡的工程师阅读。原文 ↗
核心观点
- ▍Habitat 从 Python 客户端库演变为独立微服务，解决了跨服务协调的脆弱性问题，为部署、可观测性和安全提供了单一控制点。
- ▍OpenAI 刻意保留 Python，将其视为'战略性技术债'，并押注 Codex 和 GPT 能让未来的迁移变得可行。
- 01作为客户端库，像区域路由这样的变更需要跨数十个服务进行为期数天的特性标志滚动发布。
- 02团队实时测量事件循环的调度延迟，通过保持每个进程低并发量并横向扩展工作进程来解决 asyncio 下的 CPU 密集型任务阻塞问题。
- 03LIFO 连接复用默认设置导致亚稳态故障：负载重的慢服务器更晚返回连接，从而被更多后续请求选中，形成流量热点。切换到 FIFO 解决了此问题。
- 04通过暴露受限的 NoSQL API 而非任意 SQL，保证了请求成本的可预测性，这是 Python 能扩展到如此规模的原因之一。
- 05通过 Envoy 和 HTTP/2 实现连接汇聚（fan-in），以处理来自多个客户端的大量连接。
- 06文章提到需要处理每秒超过 7000 万次请求，存储超过 500PB 数据，服务超过 10 亿周活跃用户。
反方 / 局限
- — 作者明确承认，Python 在 100 倍规模下无法维持，当前的保留是一种策略性的、有代价的延迟决策。
- — 作者指出，Habitat 暴露的 NoSQL API 功能有限，这本身就是一种明确的设计权衡，限制了客户端的操作能力。
5 分钟 · 3 卡片 · 7 资料
读原文 →