255
QZone 告急，临危受命
2005 年，是中国第二次互联网浪潮的发始之年。刚刚从破碎泡沫中走出的互联网产业，逐渐迎来了“web 2.0”时代。
这个时代的特征，就是去中心化、开放和共享。
越来越多的互联网用户，开始以兴趣为聚合点，组成社群，分享生活，发表观点。他们积极参与话题讨论，渴望获得关注和认同。
在这样的背景下，社交网络应用开始迅速崛起。最具代表性的，就是腾讯推出的 QQ 空间（QZone）。
QQ 空间，作为“展示自我和与他人互动的平台”，推出之后获得了极好的反馈，用户数量快速增长，平台活跃度不断攀升。
根据当时的数据统计，QQ 空间上线的 3 个季度，注册用户数就突破了 5000 万，月活跃用户数约 2300 万，日访问人数超过 1300 万。
用户数量的增长，意味着内容的增长。当时，用户在 QQ 空间上传的海量图片、文件、头像等 UGC 数据，对腾讯的存储能力提出了巨大的考验。
当时的腾讯，并没有统一的存储产品和技术平台，各个业务部门都是自建存储系统，自给自足。
这种方式，对于 QQ 空间这种爆款产品来说，显然是无法满足要求。它带来的直接后果就是，空间开启速度越来越慢，用户体验越来越差，投诉也越来越多。
当时，业务团队购买存储服务器的速度，根本赶不上用户增长的速度。
最典型的例子，就是那时候 QQ 空间只允许所有用户每天上传 800 万张图片，只有黄钻用户才可以无限上传。
与此同时，竞争对手窥觑 QQ 空间的业务增长，很快推出了相应的竞品，意图趁机抢夺用户。
内忧外患之下，一支新成立的年轻团队站了出来，勇挑重担。
这个团队，就是后来被誉为腾讯公司内部“黄埔军校”的存储技术团队。团队的首任组长，就是现在的集团副总裁姚星。
团队成立之后的首要任务，就是解决 QQ 空间发展所带来的存储瓶颈问题。
当时，面对海量数据存储的难题，不仅是国内，就连海外也没有什么可供参考的成熟经验。唯一可供存储技术团队借鉴的，就是此前谷歌公司发表的那几篇关于 BigTable、GFS 和 MapReduce 的论文。
如果稍微了解一点大数据知识，就会知道，这几篇论文是海量数据存储技术的经典之作。谷歌作为一家搜索引擎公司，当时的主要目的，是从昂贵的企业级存储转向大规模廉价分布式存储，以更低的成本，满足搜索引擎业务的需求。
这个目的，显然和腾讯存储技术团队是一致的。
借鉴经验之后，也是团队成立的第二年，他们就上线了自主研发的 TFS 存储系统，全面接管了 QQ 空间的相册业务。
TFS 系统上线之后，虽然缓解了业务部门的存储压力，但并没有彻底解决问题。当时，系统仍然会出现比较高的延迟，影响用户的体验。
高延时的原因，主要是因为相册业务和搜索引擎业务之间存在区别。相册业务中，图片的数据体量更小，索引密集度更高，所以难度更大，完全照搬搜索引擎模式并不可行。
于是，存储技术团队在 TFS 系统基础上进行持续改进，推出了适合不同图片存储场景的系统。其中包括支持实时回收的 CTFS 系统、基于 HDD 的键值对 TDB 存储平台等。
终于，在持续的改进下，存储技术团队彻底解决了 QQ 空间的存储瓶颈问题。
2009 年，QQ 空间成为排在网络游戏之后的腾讯第二大收入贡献部门，并且获得了该年度的腾讯合作文化奖。
这个成绩的背后，存储技术团队功不可没。
2009 年腾讯存储技术团队合影
2009 年，SNS 游戏 QQ 农场正式推出，掀起了全民偷菜的热潮。当时，农场的访问量巨大，在每秒数万的并发访问下，腾讯的底层存储系统的延时和请求吞吐压力非常大，服务器数度崩溃。
当时的腾讯，基本上把公司所有闲置服务器都用在 QQ 农场上，但仍远远不够，需要大量采购服务器。
存储技术团队一方面疯狂扩容设备，另一方面基于数据规模不太大但是访问量极高的业务特点，快速研发了全内存的分布式存储系统。在保障数据安全可靠的前提下，系统的并发访问性能得到极大提升。
快速上线、快速验证、完全自研，存储技术团队“hold”住了局面，再立大功。
一波渐平，一波又起
第一阶段使命的完成，使得存储技术团队积累了丰富的经验。团队成员的架构设计能力和开发能力也得到了充分的锻炼。
很快，他们又迎来了一项新的挑战。这次遇到的，是带宽问题。
2011 年，在 QQ 相册等大体量业务快速增长的刺激下，腾讯的数据存储量达到了 50PB。
这是一个标志性的事件。
当时，腾讯所有的数据中心都在深圳。那时候骨干网络的带宽很小，QQ 相册高峰时占用 40-50Gbps，而 1G 的流量对公司的网络就已经是很大的负担了。
于是，腾讯必须将海量的业务数据分散到全国各地，缓解访问带宽的压力，同时降低成本。
存储平台当时启动了相册一通点等项目，海量业务数据开始从深圳向西安、杭州、广州、上海等地数据迁移，访问带宽也同时调度到天津、南京、东莞等成本更低的一通机房。
当时存储技术团队搬迁的第一台设备，数据量是 100TB。在现在看来，100TB 并不是很大，但是当时已经是腾讯有史以来最大的一次数据搬迁了。
更让人意料之外的是，存储团队搬迁这些数据的方法，并不是通过专线（因为怕影响公司正常业务），而是通过后半夜闲时的公网出口。他们采用蚂蚁搬家式的数据迁移方法，一点一点把数据拷贝到异地数据中心。
后来，随着数据迁移工作的逐步完成，腾讯存储网络的带宽压力明显缓解，成本也得到了有效控制。
到了 2015 年左右，腾讯存储技术团队又迎来了一个新的问题——数据太多了。
那时候，腾讯的数据总量逐渐到了 500PB 的量级。随着时间的推移，此前用户上传的大量数据，都成了冷数据。所谓冷数据，就是很少去读取的数据。
这些冷数据占用了大量的存储空间，为了容灾，还进行多重备份，更加消耗资源。
于是，存储技术团队就开始做分级存储。他们优化了系统的分布式存储架构，研发 BTFS 平台，把数据从三副本降到 1.33 份的纠删存储。他们将 QQ 相册、微云，邮件附件等产品中的历史数据放到 BTFS 里面去，以此来降低存储成本。
除此之外，他们还在数据访问量不大的存储服务器上做虚拟化，利用空闲的 CPU 资源跑计算负载，例如图片的编解码等，充分提升资源的利用率。
微信崛起，存储助力
在 QQ 空间之后，腾讯 TFS 系统逐渐开始为 QQ、邮箱、微云等提供存储服务，成为整个腾讯的基础数据存储平台。
2013 年，腾讯正式发布了微信，开启了新一轮的移动社交网络大战。微信的数据存储需求，同样依赖于 TFS 系统。
用户使用微信，除了文字之外，还会发送海量的图片、音频、视频，甚至红包。这些操作全部离不开对存储系统的读写。发朋友圈也是一样，背后离不开存储系统的支持。
2014 年的春节，用户数快速增长的微信，以及它背后的 TFS，迎来了一场载入中国互联网发展史册的大考——有史以来第一次的红包大战。这场大战当时有 800 万用户参与，业务团队和存储技术团队感受到了前所未有的压力。
压力最大的时刻，就是大年三十晚上 12 点那个时间段，数以亿计的用户会发送祝福，造成井喷级的高并发数据读写需求。如果系统能力不足以应对，就会全面崩溃，影响用户体验，损害腾讯和微信在用户心中的形象，失去用户的信赖。
为了应对这种情况，存储技术团队对系统进行了能力深度挖潜，竭尽全力将磁盘的读写能力开发到极致。与此同时，他们联合微信团队制定了各种柔性策略，开发了很多定制化的服务，也专门开发了服务于微信业务的系统。最终，他们承受住了考验，涉险过关。
后来，到了 2015 年春节，微信月活跃用户达到 5 亿，激烈的红包大战再次打响。这次，积累了丰富经验的存储技术团队胸有成竹，交上了更完美的答卷。
业务开放，发力 B 端
随着腾讯存储系统的不断成熟，加之 2012 年之后逐渐开始的云计算趋势，腾讯开始考虑将 TFS 存储业务面向外部开放，服务第三方业务，争夺 B 端企业用户市场。
初期腾讯云基于已有的存储访问接口和平台架构对外提供服务。经过一段时间的运营，腾讯云发现外部第三方业务在体验、可用性、成本等诸多运营方面有极高的要求。
因此，为支撑云的需求场景，腾讯云对存储的接入层和索引层架构进行重构，架构扁平，模块精简。同时，腾讯云存储开始舍弃私有接口，转为兼容 AWS S3 接口与功能。
重构后，存储架构的开放能力得到了进一步提升，支撑了腾讯云 COS（Cloud Object Storage）业务近几年的发展。
在腾讯看来，对云的理解是不断加深的过程。他们认识到，仅有不错的存储平台并不够，必须深入研究各个行业的需求场景，提供功能、性能、质量和价格要求不同的服务，才能够获得用户的认可。
Yotta 问世，无限赋能
2017 年，腾讯云的数据量突破一个 EB，成为腾讯存储历史上的一个标志性节点。
为了应对未来云计算业务的挑战，腾讯存储团队开始了一个宏大的计划——启动全新的存储架构平台 YottaStore 的开发。
最开始的时候，存储团队内部打算给新平台取名为 BlobStorage。Blob 的意思是一大块连续的二进制数据，像一个视频文件就是一个 Blob 数据。
显然，这是大家印象中程序员的”正常操作”，但最终这个名字被确定为 YottaStore。
对于做存储的同学来说，经常会跟 GB、TB、PB、EB 这些概念打交道。现在全球互联网巨头公司的数据量基本都是在 EB 这个量级。EB 上面是 ZB，全球互联网巨头数据加起来也就几个 ZB。ZB 再往上，就是 YB，也就是 YottaByte。目前全世界所有的数据加起来，也不超过一个 YottaByte。
毫无疑问，这个名字体现了腾讯对这个系统的期待，寄予了厚望。
除了足够大之外，Yotta 的中文译名是“有他”，可以给人安全可靠放心的感觉。在腾讯内部，就有“存储有他，能力无限”的说法。
YottaStore 从 2018 年开始启动研发，2019 年正式上线，完全由腾讯自主研发完成。上线同年，就获得了公司级的业务突破奖。
作为一个云存储系统，YottaStore 的能力可以说是非常强悍：
集群规模
YottaStore 是一个云原生的数据存储系统，这个系统的理论极限是一个集群可以管理超上千万台服务器。而要管理这上千万台的机器，元数据管理只需要用 600G 左右的空间，仅用一台机器就能存下索引结构，这在业界绝无仅有。
资源利用率
当集群规模非常大的时候，1%的剩余空间量都非常大。所以，YottaStore 将硬盘利用率提升到很高的水平，配合实时回收机制，有效数据占比达 90%以上。这在业界非常少见。
另外，由于大集群的全集群均衡能力，服务器资源使用均衡，所以资源使用率也可以做得很高。服务器硬件可以最低位配置，所有尖峰流量在这个超大的池子里，波澜不惊。
所以，无论是成本，还是服务能力，都很大程度受益于超大规模集群带来的红利。
灵活性
YottaStore 单集群可以零研发成本同时支持各种不同的冗余模式，像两副本、三副本、四副本、五副本，任意的 EC 编码，任意的 M、加任意的 N、任意的算法；单 AZ、双 AZ、多 AZ，也都可以灵活支持。
另外，整个集群可以自适应各种各样不同的机型，包括 JBOD；各种硬盘介质，如磁带、HDD、SSD 等，存储的拓扑结构、混合部署也都可以任意指定。
这样的灵活性在业界首屈一指。
运营能力
以存储节点迭代升级为例，十万百万规模的一个集群，上线升级速度都是一样的。如果是同构的数据格式，分钟级就可以完成整个升级过程。如果是异构的数据格式，集群可以在短时间内自动将数据格式透明收敛到最新版。
可用性
可用性达到“数个 9”很容易，但是达到 100%非常难。例如机房网络抖动，如果容错做的不够好，就很容易出现失败。
YottaStore 开始上线大规模支撑业务的前三个月，一直维持 100%的可用性。到现在一年半了，系统一直单人值周零故障运行，在业界是极少见的。
成本控制
基于前文所述的在超大规模集群和超高资源利用率上的技术突破，随着资源利用率的增高，YottaStore 的单位存储成本不断降低。
磁盘容量扩大，单机磁盘数变多，密度增高，成本也随之降低。此外，CPU、网卡等新硬件的变化都会导致成本降低。
针对海量小文件的用户场景，YottaStore 采用多种冗余和数据组织策略持续优化成本。
综上所述，YottaStore 是一个拥有强大能力的超级存储架构平台。目前，YottaStore 已经全面上线并支撑腾讯内外部的存储业务，运行质量远超 SLA。
基于 YottaStore 存储系统的腾讯云对象存储 COS 平台，正在为快手、OPPO、小红书、海康、猎豹、58 同城等几十多万个企业客户提供可靠的存储服务，整体数据量高达 EB 级别。
结语
回顾腾讯存储技术的整个发展历程，不由令人心生感慨。
15 年前，腾讯存储团队成立的时候，一定不曾想到，自己会走过这么蜿蜒曲折的发展之路。
他们不会想到，自己所在的公司会推出比 QQ 空间更爆款的产品，自己会面对更严峻的考验。
他们不会想到，自己的使命，从服务内部，到服务外部，从服务 C 端，到服务 B 端，不断转变。
他们不会想到，自己开发的存储系统，数据体量规模竟然会从 PB 到 EB，覆盖全球范围内 30 多个 region，拥有上万台服务器。
他们不会想到，自己所在的团队，会成为整个公司的“黄埔”军校，走出了无数的技术专家和管理干部。
时代就是这样，前进的步伐太快，永远超出常人的想象。
能够拥有这样的成绩并非偶然。成绩的背后，既离不开他们对用户需求的精准把握，也离不开对产品性能的极致挖潜，更离不开对技术梦想的执着追求。
存储的战争还没有结束，只是进入了一个新的阶段。
未来，有新的挑战在等待着他们。也有新的机遇，在召唤着他们。再过 15 年，又会发生什么样的故事？不如让时间来告诉我们答案吧。
下载ECAD模型
