十五年后，重构一个“在线的腾讯”

如果花了十五年时间从无到有建立一个基础技术产品，然后又花两年的时间全部进行重构，那么这算不算是一个技术人的完美职业经历？

腾讯从 2006 年开始研发通用存储平台，在这差不多十五年之间，腾讯绝大部分的业务如 QQ、QZone、微信、流媒体以及针对第三方的云服务，都使用的是这个存储平台。存储作为互联网业务的核心，逐渐演变为跟操作系统和网络一样的底层基础设施。

两年前，腾讯启动了存储平台的重构，并在线将大部分业务成功地切换了过去。

大船难调头？那腾讯这次是怎么做到的？

积累十五年，一朝被重构

2005 年，腾讯 QQ 用户正式突破 1000 万，开启了腾讯业务的海量时代。

QQ 社交也带火了 QQ 相册。当时数码相机开始在国内兴起，QQ 相册上线后，日均上传量很快超过 800 万张。那时国内的存储服务器主要是磁盘柜或刀片机，扩容的效率很低，给当时腾讯的互联网基础架构带来了全新挑战。

2006 年，以满足相册业务为契机，腾讯开始组织人马，从零构建起几套核心的平台：通用性存储平台 TFS，面向 KV 的存储平台 TDB，以及应对在线业务频繁写入的可靠内存存储 CMEM。这些自研平台为腾讯存储的发展奠定了基础，支撑起了 QQ 空间、微云、QQ 等产品的海量存储需求。

2011 年，微信上线。2014 年，微信红包开始火起来了。那一年除夕夜，微信红包摇一摇总次数达到 110 亿次，峰值 1400 万次/秒。不光是微信红包，那个时候朋友圈的图片分享也开始火起来了。电商只需要应付一个秒杀，微信红包意味着天天秒杀，特别是在跨年夜里，用户分享的图片量猛增，给存储系统带来了非常大的压力。腾讯的存储技术团队对大型缓存系统、延时通知等技术进行改进，逐步解决了跨年夜这种突发问题。

发展十多年之后，这个存储平台支撑起公司 90%+的数据存储业务，包括微信、QQ、QZone、邮件、微云等，技术在越来越繁杂的业务下得到成长和验证。

经过公有云建设后，这个平台也对外服务了数十万客户，接受公有云厂商间充分的竞争。这意味着对存储的成本和性能要求越来越高，迫使腾讯技术团队去构思下一代的存储系统，目标是“撑过下一个十年”。

腾讯云架构平台部存储研发中心总监杨奋强是这样形容这个目标的：“要实现能高度自治的超大规模集群。从数据规模、成本、可运维性的角度，集群的规模一定是在不断变大的。所以我们目光要放长远，必须考虑能支撑至少百万节点的超大规模集群。”

这个历经十五年沉淀出来的平台也因此接受了一次大重构。

腾讯从 2017 年开始构思，2018 年底正式启动了下一代的云上存储系统，取名“YottaStore”。名字灵感来自计量单位。计量单位有 K、M、G、T、P、E、Z，再往上面是 Y，也就是 Yotta。目前全世界所有的数据加起来也不超过一个 Yotta Byte。

因为要做成超大规模集群，所以 YottaStore 跟当前业界绝大多数公司的实现方法不同。互联网刚开始做起来的时候，受到传统 IT 行业习惯的影响，初期的系统多数是分布式文件系统。而云上需要的是一个更大的数据存储系统，没有分布式文件系统中的文件、文件名、文件属性、目录、层级关系之类的概念或关系，相比于分布式文件系统，规模大了很多。

经过一年多的研发，YottaStore 现已全面上线并支撑腾讯内外部的存储业务。

升级必须做，但大船掉头不容易

从单机走向分布式，再从分布式走向云。云上的数据量已经是早期互联网的成千上万倍，并且未来数据量只会越来越大。

基础设施在这个过程中也发生着翻天覆地的变化。

其一是硬件的变化。以前硬盘是 500G 每块，后面逐渐增大为 8T、12T、16T。但单个磁盘每 GB 的 IOPS 能力实际上越来越小，因为硬盘的转速实际上是不变的，但是硬盘容积增大，单位的访问能力下降了；其二是企业机房越建越大。腾讯在 2008 年一个机房可能就几百台服务器，大一点的可能就是两三千，现在机房动辄都是几十万台，甚至接近百万台。其三是互联的网络也在变化。十年前网卡是瓶颈，现在百 G 网卡不是问题。以前为减少机房的穿越，尽量不用专线，现在机房之间的互联专线有几百 G，甚至城市跟城市间都有几百 G 的专线连通。

基础设施产生变化，实际上也需要上层的软件架构去适应这些变化。任何大型的云计算企业都必须经历升级演化，谁也例外不了。

引导了大数据变革的 Google 也是如此。2003 年 Google 公开了第一代文件系统 GFS 的论文。GFS 在当时业界非常成功，Google 各上层业务也都在使用。GFS 诞生近十年后，技术负责人肖恩·昆兰（Sean Quinlan ）却做了一件他从未想到过的事情：用全新架构的文件系统替换了 GFS，“鉴于 Google 的运营规模已超出系统设计时要处理的规模，而这个规模是在 90 年代后期想象不出来的”。

新系统的目标是至少扩大到 GFS 的 100 倍以上，取名“Colossus（巨像）”，不开源且对外资料很少。Google 希望新文件系统能在未来几年发挥重要作用，但没想到的是他们当时没有考虑云服务的需求和规模，这些单一目录层级的分布式文件系统并不适合云服务。于是 Google 再次组建了一个几十人的团队，去做一个新的云存储系统，希望追平并完全替代 Colossus 以满足云服务的需要。因为规模更大，这个系统的设计也比 Colossus 的逻辑复杂不少。

这样的演化是个巨型工程，一个存储系统从无到有，迁移成功，到发展稳定，这个周期非常长。

据内幕人士称，Google 这个团队最终“被解散了”。因为 Google 的所有基础组件、所有业务几乎全部都依赖于 Colossus，从 Gmail、Google 文档和 YouTube，到公司为第三方提供的 Google 云存储服务。要变更最底层的存储大根基，需要挨个推动全公司所有有依赖的业务去做适配。在这个体量的互联网公司里替代掉底层设施，需要花费的人力和难度太大了。船大难掉头，所以这个项目最终难以维系下去。

做面向未来的升级，是每一家做存储的巨头都逃脱不掉的，但每个公司的命运各不相同。至于腾讯这次为什么做成功了，也存在一些与腾讯历史有关的因素。

存储团队是腾讯的黄埔军校

海量之道

早年，腾讯将“在线超过千万、索引超过百亿、数据超过百 P”定义为“海量”。

李开复曾说过，如果 Google 采用 IBM 的行业解决方案的话，Google 会破产。因为在传统行业中，每个交易的造价是很昂贵的，它没有办法放量到这个级别。这就决定了做海量服务的架构取向，不能依赖硬件、中间件。不同量级的服务，需要不同的系统架构来应对，每增加一个量级都会有无数需要优化的地方。

腾讯发展过程中，火爆应用有不少，QQ 业务中相册存储系统很早就达到了百 P 级别存储、千亿图片数量，设备数量达到万级别。2009 年，QQ 空间内嵌的“QQ 农场”、“抢车位”等社交游戏风靡全国，曾创造了当时国民网游的峰值。根据当时的数据，QQ 农场的月活跃用户达到了 3.2 亿，注册账号占到了中国人口的 2/3。偷一次菜、抢一次车位，就得写一次数据库。这种写操作的压力让腾讯用上了全公司所有的闲置服务器，但这些还远远不够，后来又加购了更多的服务器才够用。

QQ 农场

在用户快速增长的发展态势下，存储面临雪崩或系统过载等问题，导致用户偷菜、抢车位不成功，对于用户的投诉，存储团队丝毫不敢怠慢：一方面先扛住再优化，同时疯狂扩容、加大 Cache，另一方面开始了全内存的分布式存储系统的研发，并快速上线、快速验证，并且在业务每天在滚动的情况下将系统进行了切换。

而系统的切换或版本升级，需要在业务无感知的情况下进行数据迁移，不能漏掉数据或产生数据错误。在紧张高压的情况下，技术团队慢慢总结出一套做法：校验校验再校验，在迁移的过程中把老数据、新数据都保留一段时间，形成了数据双写、在线迁移、数据校验等一整套系统流程，再逐渐演化成为一个可以交付运维、点一点鼠标就能实现的事情。

依据这些业务运营经验，在 2014 年左右，腾讯总结出了一套“海量服务之道”：“先抗住再优化”、“干干净净”、“立体监控”、“大系统小做”、“过载保护”、“柔性可用”、“灰度升级”...

之后由腾讯联合创始人、前 CTO 张志东亲自挂帅，在公司内部搞了一系列关于海量之道的面授课程。这套海量之道，在业界也颇具领先性。到公有云时代，除了“柔性可用”（对外承诺的不可变更），海量之道大部分仍然可用，这些经验依然被开发人员奉为圭臬。

腾讯的黄埔军校

张志东早期为 QQ 设计了整体架构，这个架构支撑着 QQ 业务从无到有，直到后来上亿用户同时在线。当时“架构平台部”也负责存储平台的研发，所以存储部门也被称之为腾讯的“黄埔军校”，这个叫法最早也是由张志东提出来的。

2006 年前后，“大师兄”张志东招收了一些毕业生放到“架构平台部”进行专门培养，等他们具备了架构师的思维和运营经验以后，再看情况将他们作为“种子选手”分配到其他新战场上去。进“架构平台部”在当时是让人羡慕不来的工作。

那时候腾讯还没有统一的存储技术平台，主要靠各个业务自己去做存储的系统自己使用。

这个团队一开始也并不是做存储的，但团队拥有非常多的专家，比如现任腾讯技术工程事业群总裁卢山，腾讯副总裁姚星，还有那年刚毕业的腾讯云副总裁、云架构平台部总经理谢明博士等。大家年龄差不多，包括老板马化腾，都是 70、80 年代的人。

他们的工作方式之一是跟人“聊天”，哪个部门有技术问题，就以技术专家的身份冲过去跟人家“聊”然后解决掉问题。现任云架构部的研发总监郭振宇当年也是作为毕业生加入到这个团队的，他提到当时印象最深刻的是：“可能跟人家聊的还不够，还解决不了问题，我们就冲过去帮别人做，做出来之后退出来，然后再跟下一个部门聊。”

然而应对 QQ 相册和 QZone 异常火爆的情况，这种专家式、辅导式、帮忙式的方法也跟不上业务的发展速度了，这就倒逼着架构平台部设计出了一套通用存储系统，也就是后来的 TFS。

大家知道在 2003-2004 年的时候 Google 发布了著名的“三驾马车”论文：BigTable、GFS、MapReduce。正好当时架构平台部很多是毕业生，对存储也没有太多的了解，大家就边看论文边学习，同时去解决各种疑难杂症，比如说测试时候数据怎么丢了，硬盘的存储机理，以及不同规格的文件存储格式数据恢复等等。这个过程当中他们从 RPC 框架和通信协议、数据迁移、巡检系统开始，将 TFS 一步步做了出来，最终解决掉了 QQ、QZone 存储不够用的问题。

从业务中来，到业务中去

存储数据是业务的核心，当时各业务线特别是 QZone 对数据存储的需求特别大，因此负责存储平台的架构平台部跟业务部门合作非常紧密。

架构平台部的基本要求是贴合业务、深度了解业务。他们会在 QZone 系统遇到用户高峰期发生崩掉、挂掉的情况时给予支持，帮着业务团队一起解决系统技术问题，优化提升性能。还需要结合业务场景，分析存储需求去实现贴合业务的存储系统。比如：针对 QZone 大量的结构化数据存储需求，设计出了 KV 存储产品 TDB；针对需要频繁删除的一些场景，设计出了 CTFS。

架构平台部的领导们，还要求大家关注业务应用，而不仅仅是去实现一个“存储系统”。同时也要求大家关心用户体验，用户点击图片后应该再显示多少张图片，图片放在哪里、大小怎么设置，都需要心里有数。在设计功能的时候也要了解更多的细节，比如 Load 历史图片的时候，对冷数据访问和带宽流量的性能要求。这样就逼着大家像实际用户一样体验产品，去跟业务团队沟通，参与业务团队的需求会议，参与到业务的设计中去。这样的紧密合作，使得在业务发展很快的情况下，依然能顺利地传承知识。

在设计、实现、迁移到 YottaStore 过程中，这些知识都是一脉相承的。经过业务锤炼的这支技术团队在重构产品时，用存储研发总监杨奋强的话来说就是“能力游刃有余”。

新存储系统的设计挑战

YottaStore 的目标是应对至少未来十年的存储挑战。现在主流互联网企业的数据其实都在 EB 量级，目前全世界所有的数据加起来也不超过一个 Yotta。要做成超大规模集群，就不能依赖人工治理，需要减少人力运维上的投入成本，那么系统必须要有足够高的自治能力。

大规模系统最难的是自治能力。足够高的自治所带来的全自动化会产生足够大的混沌态，而在混沌态下又要有足够强的控制能力，即把事情完全交给机器，但机器干的事情人要一清二楚；以及在各种复杂因素的干扰下，保持简洁设计和简洁实现的能力。这是一个熵增和熵减的过程。

因为目标是治理超大规模集群，所以 YottaStore 不能完全依照原来的分布式系统方式去设计，架构上会有所差别。传统分布式系统分为三层，数据从应用层进入系统后，会由 Master 管理节点去分配存储层的 Chunk 服务器，再进行数据存储。读写请求都要通过 Master 节点，Master 也需要存储“元数据”信息，所以集群规模大了后 Master 节点往往就变成了系统的瓶颈。

腾讯在设计超大规模存储系统时，取消掉了原来的这种 Master 节点，数据从 COS 应用层直接进入 YottaStore 存储层中。COS 应用层负责所有用户请求的接入、路由等工作，读写请求不直接经过元数据节点，解决了“读写请求量过载”的问题。

（图片来源：特大号）

在这个架构下，1Byte 元数据可以管理 2GB 的物理空间，所以系统理论的极限是可以管理超上千万台服务器，但元数据管理只需要用 600G 左右的空间，用一台机器就能存下索引结构。同时能做到二十多分钟即可完成十万百万规模的集群的全面升级，并且对用户完全无感；具有全集群均衡能力，资源使用率可以做到 90%以上，尖峰流量压力平稳，也减轻了集群的运营成本。

从功能上划分，YottaStore 又可以分为数据面和控制面两块：

• 数据面包含接入子系统、数据分配子系统、元数据存储的子系统以及数据存储的子系统；系统会分析用户数据的大小、类型、访问频度、趋势模型，相应的优化、调整系统功能。

• 控制面包含数据巡检子系统、数据均衡子系统、数据修复子系统、集群管理子系统、健康监查子系统等等。

其中数据均衡这部分是全新的一套技术逻辑，没有沿用之前的方法。在 TFS 中为了维持各个集群之间的数据的水位大致均衡，除了底层，还要在上层 Master 节点做一部分工作，而 YottaStore 使用全自动方式进行数据均衡。如果集群新扩容了一些机器，为了尽快能对外服务，这时候数据均衡就会自动的去分配数据或搬动数据，同时将过程和结果展示到中控网站上。

大规模系统设计的另一个挑战是，当数据量有巨大变化的时候，对数据可靠性的要求也是不一样的。这就相当于一百个人里面，保证一个人不生病，这还是可以做到的。但是十亿个人里面保证一个人不生病，难度就变得非常大。

集群规模越大，涉及到的逻辑越多。成千上万个逻辑，任何一个逻辑或环境出问题都可能会丢数据，要达到 100%的可靠性并不容易。在数据传输过程中，从上层业务逻辑到达了底层的存储介质，在传输过程中难免有机器的内存或网卡有问题。这种情况下腾讯设计了全路径的数据校验，从上到下，数据传输和转换都带着数据校验，确保用户写进来就不会错。对于数据静默错误或发生硬件寿命的自然故障，设置五层巡检，定期自动对数据进行检查。值得一提的是，这些巡检的正交性设计，让巡检任务不会影响到系统的服务能力，变得足够轻量级。

在激烈竞争下，存储的成本也是云巨头必须考虑的关键因素之一。

• 资源利用率提高：基于前文所述的在超大规模集群和超高资源利用率上的技术突破，随着资源利用率的增高，单位存储的成本随之降低。

• 高密硬件适配：随着磁盘容量扩大，单机磁盘数变多密度增高，成本也随之降低；此外，CPU、网卡等新硬件的变化都会导致成本降低。

• 场景优化：针对海量小文件的用户场景，YottaStore采用多种冗余和数据组织策略持续优化成本。

基于 YottaStore 以上的工作，腾讯推出标准存储、低频存储、归档存储等产品，其中深度归档做到了业界最低价：1 分钱/GB/月。

到现在，腾讯绝大部分的业务都逐渐迁移到了 YottaStore 上，其中包括云服务。腾讯云在云服务的战场上起步晚，没有占到先发优势。但这场竞赛尚在“中场”，腾讯如今做出了创新并全面更换了底层设施，相信未来云服务市场的”排位争夺赛“将会更加激烈。