北京
OpenAI的工程博客最近发了一篇讲Habitat的文章。Habitat是ChatGPT背后的存储平台，服务着每秒7000万次以上请求、500PB以上数据、约40个区域，连续三年每年增长10倍。
但真正让人坐不住的，不是这个体量。文章里描述的四个事故，没有一个是容量问题。没人耗尽CPU、内存、磁盘或带宽。四个全是规模化之后才冒出来的协调效应，其中三个的根源，是一个在小系统上完全正确的库默认值。
四个坑，一个比一个阴
第一个：一个响应已经准备好了，却因为线程忙而没被解析。这种状态在任何数据库监控面板上都看不见。
第二个：某个功能开关SDK每60秒轮询一次，没有加抖动，结果整个Pod集群步调一致地卡住。
第三个：连接池的后进先出默认策略，制造了一场自我强化的故障——即使把触发它的原因移除，故障依然持续。
第四个：为了服务6个并发请求，开了18个连接。因为进程数会成倍放大连接数。
这四个坑，都不需要每秒7000万请求才能咬到你。它们需要的是很多进程——而你的系统里大概率已经有了。
Habitat是什么
Habitat是OpenAI的在线存储平台。它负责在任何产品渲染之前，回答“加载这个用户的设置”和“取回这段对话”。它夹在OpenAI所有产品和底层存储之间，掌管路由、鉴权、加密、缓存、数据驻留、多租户和限流。
它起步于2023年DevDay，当时只是一个连单个数据库的小型Python客户端库。今天它服务着500PB以上的数据。
文章里最可信的一个说法是：难的不是绝对规模，而是规模一直在动。大多数基础设施按10倍规模来建，预期能撑几年。Habitat拿到的是连续三年、每年10倍。
库，是一个你控制不了的部署
到2025年年中，Habitat已经不适合继续做一个客户端库了。原因不是技术问题，是部署问题。
为了缩小爆炸半径，团队想把关键数据分片到按区域分布的Cosmos账户上。这需要在客户端里加新的路由逻辑。于是：把逻辑藏在功能开关后面，花几天在几十个服务里铺开，再花几天加影子流量验证分片是否正确，再花几天修影子流量发现的bug。
然后，在终点线上，一个团队因为无关原因回滚了自己的服务——回滚到了带旧版有bug客户端的版本，恰好制造了这个项目本来要防止的那场故障。
这是支持“把存储做成服务”最清晰的论据。不是因为性能，不是因为抽象。仅仅是因为：如果你的逻辑发布在别人的二进制文件里，你就控制不了它。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
