大型系统存储层迁移实践

大型系统存储层迁移实践

摘要

作为一个以新闻、资讯为主的 App，今日头条上的主要内容都是由文章组成，文章服务自然伴随着今日头条 App 的产生就已出现，之后又逐步扩展为目前的内容云，为头条、西瓜、小说、懂车帝等多个 App 服务的业务内容中台。截止 2021 年底，内容云接入子业务已经达到数百个，高峰期主要读服务 QPS 数百万，维护超过 2200 个属性，存量数据达到百亿条级别。然而由于历史悠久，经手人众多，加上历史上一些环境或周边系统的特殊性，业务模式发生转变等，使得内容云成为一个标准的大型遗留系统，早期的一些存储、架构上的设计已经逐渐无法满足当前的业务场景，并给维护者带来了较大维护和迭代成本。

因此我们启动了内容云存储层的迁移项目，随着调研和与其他业务的讨论的不断深入，发现各业务对存储层的痛点及需求基本一致，存储模型和实现方案逐渐趋同，因此决定基于 ByteKV 开发一个宽表数据服务（本文主要聚焦在遗留系统存储层迁移的过程，暂不涉及新存储层的设计与实现细节），下沉存储层通用逻辑，供其他业务接入，并替换内容云原有的存储层。最终历时将近 1 年时间将在线流量切换至新的存储层。

迁移一个系统的存储能有多复杂？无非是双写、迁移数据、切读、停写罢了，为何内容云存储层的迁移竟花费将近一年时间？本文主要分享内容云存储层迁移的血泪史，过程中的一些坑和经验，望能给其他大型系统迁移存储或做重构带来一些流程上的参考。