鹅厂存储记忆:热血、黑夜与无限大

一群已经告别18岁久矣的“老司机”怎么也没想到,在扛下了无数场激动人心的战役之后,职业生涯竟险些在这样一件事上遭遇“滑铁卢”。

 

 

2017年12月31日,Able还沉浸在跨年的兴奋之中,组内同事的一通电话杀到:大事不妙。QQ后台数据显示,QQ相册访问和调用量陡然上升,临近中午,很快接近存储过载设置的警戒线。

 

原来这一天,最后一批90后即将度过18岁生日。有人在网上发起了一个“晒晒你的18岁”话题活动。为了找回一张18岁的照片,一时间,一大波70后、80后、90后纷纷涌向了QQ空间。

 

每一个访问和下载的动作,就会触发一次数据读取。就像一张回忆光盘,QQ储备的磁盘IO容量很快就要被打满了。

 

“幸福”来得猝不及防。不仅QQ空间保存着一代人的青春回忆,中国近10亿网民,怎么储存好用户在互联网上的每一段记忆,成了一个“甜蜜的负担”。

 

在腾讯20多年的发展历程中,存储不像其他技术那样被聚光灯笼罩,它更像是盖房子时的“地基”,你看不见,却不可或缺。如今,云计算、大数据乃至人工智能很多复杂性的业务实现,底层都需要存储这项技术强有力的保障。

 

干这件事的,正是这样一群充满梦想的技术人。

 

突破“800w”

 

在腾讯,有一个少有人知的秘密组织,也有人称它是程序员的“黄埔军校”。

 

虽然其貌不扬,名叫“系统架构部”;人数也不多,就三四十个人,却集结了腾讯内部最顶尖的开发人员和技术专家。

 

在第一任主帅、现任腾讯技术工程事业群总裁卢山的带领下,他们做的不是开发的工作,更多像是架构评审。如果有部门要上线一个新产品或做一项新的技术改造,就把架构部的人拉过去聊一聊。如果聊得还不够,解决不了问题,就索性冲过去帮忙一起做。

 

2006年,Regan来到腾讯,成为架构部招来的第一批应届生。一个平平无奇的早晨,Regan被卢山叫进办公室,领走了一项秘密任务。

 

2005年开始,QQ空间大火,那时数码相机开始在国内兴起,QQ相册上线后,很快日均上传量超过1000万张,访问量级和用户规模与Facebook分庭抗礼。从几百万到1000万,再到后来的一天1亿的上传量,对带宽、服务器消耗很大。

 

系统架构部的第一个任务,就是解决QQ空间发展所带来的存储问题。

 

那时,腾讯还没有一个统一的存储产品或技术平台,基本上是各个业务自己做一套存储系统。2006年,架构部的七八个人开始研究互联网场景下的海量存储架构,结合自身业务场景自研了分布式存储TFS(Tencent File System)。

 

这是当时国内第一个真正意义上面向互联网海量数据存储的技术平台,承载了公司数10亿客户,大大推动了分布式存储技术的发展。

 

第二年年初,TFS开始接QQ相册。那时,带宽和服务器资源有限,QQ相册每天限量800万张。Regan还记得,那时候一到晚上24点就有大量用户涌进来,守着时间把图片上传上去,慢慢到中午和接近下午的时候,普通用户就传不了了,然后到第二天凌晨再放开。

 

TFS刚开始做时,技术人员制作了一张全国地图,凡是QQ空间打开速度高于5秒的被绘成红色,3秒到5秒之间为黄色,低于3秒的被绘成绿色。地图制作出来后,挂在墙上,大家看到的是“祖国江山一片红”。

 

而随着TFS存储系统的上线,技术团队一块一块地啃,在地图上,绿色和黄色一点一点地增加。到2007年年底,一张绿色的中国地图终于出现在大家的面前。此次速度优化上的闯关,为QQ空间日后流量的倍级增长提供了重要保证。

 

TFS支持了QQ相册每天亿级别的图片上传。不仅解决了存储的问题,相册的索引、访问性能问题和外网下载性能问题也都一一解决了。

 

回顾腾讯技术发展历程,这也是架构部做起来的第一个系统平台。原先专家式、辅导和帮忙式的发展模式慢慢被系统化、更高效的技术体系所取代。

鹅厂存储记忆:热血、黑夜与无限大_第1张图片

 

2009年存储团队合影

 

黑夜行动——一场史无前例的数据迁移

 

2009年,SNS游戏开始兴起。QQ农场创造了当时国民网游的峰值,月活跃用户达到了3.2亿,注册账号占中国人口的2/3。一时间,“偷菜”风靡全国。

 

TFS主要是面向大文件存储,团队后面又陆续开发了面向KV的TDB存储。但是挑战也接踵而来。

 

了解数据库存储的人知道,设计一个缓存系统,读多写少是最好的,一旦读少写多,系统压力就很大。

 

然而,SNS游戏最大的问题就是“写”操作特别多。比如QQ农场的访问量特别大,数亿用户守在电脑前,菜一熟立马就去摘,十几块田,每一块田都是一个写入量。即便TDB已经是高端配置,高并发的压力依然很大。

 

当时,SSD介质还没有出来。Regan和团队商量,根据频繁写入的情况设计了TMEM,即先写内存,同时把日志顺序写到磁盘上。这样把“随机写”变成了“顺序写”,一下子提高了性能,解决了频繁写的问题。

 

伴随着腾讯业务的迅猛增长,2009年-2010年,用户增长带来的大量数据已经基本把整个华南地区的骨干网消化完了。

 

当时,腾讯的数据中心主要在深圳,机房也很小,又没有新的地可用。大家高喊着“走出深圳,去西安!”

 

一场史无前例的数据迁移势在必行了。

 

这是腾讯历史上第一次跨城的数据搬迁。“还记得搬第一批数据是100T,现在看来100T不大,但是那时候是腾讯历史上最大的一次数据搬迁了,因为那时候基本上没有专线可以用,所以都是在半夜通过用公网的出口把数据往那边搬。“Regan回忆。

 

另一个挑战是带宽。当时的骨干带宽和现在不可同日而语,虽然没有像现在视频这么大带宽,但是在当年图片占用的带宽也不可小觑,相册高峰时期到50G,就已经把骨干网络塞住了。

 

1G的流量对公网的出口都有很大的挑战。控制不了高峰怎么办?

 

这时候,腾讯技术早期提倡的动态运营、柔性可用等海量之道就被用上了——到了高峰期不要默认展示大图,点击之后再展示;上柔性,从下午7点到9点设置流量阻拦,这样做了之后,带宽确实降下来了。

 

去西安,还有另外的原因——西安是三通机房,对数据中心来说这很宝贵。中国运营商是电信、联通、移动三家,俗称“三通点”。因为要服务不同用户,机房里面三条线都要用,但是运营商之间的互联互通做得并不好。如果是租的一家运营商的机房,另外两家又不太愿意拉线进来。

 

为应对底层机房、带宽等方面的瓶颈,存储团队启动了相册“一通点”项目,海量业务数据开始从深圳向西安、杭州、广州、上海等地数据分布,访问带宽同时调度到天津、南京、东莞等一通机房。 

 

但是“一通点”也有个问题,它的存储成本有点高。三通点的数据,都要复制到一通点去,这个城市租一个电信的机房、那个城市租一个联通的机房,等于是用存储成本换成带宽。

 

眼看带宽快扛不住了,卢山带着Regan等人去跟总办汇报。Regan还记得,当时还准备了一些详细的材料,密密麻麻的,计划把问题和解决方案描述一下。

 

没想到,卢山进去后开门见山地说:“今天我们是来要钱的,三通点不行,要往一通点放。”

 

毫无疑问,这次的数据迁移很成功。QQ后台显示,QQ空间存储量每天都在上涨,存储从最开始从800万到高峰时候的几个亿。到2010年左右,QQ相册最高峰单日已经超过了6亿。

 

一场胜仗之后,架构部的业务日渐繁忙,TFS的业务对接也更加频繁了起来。

鹅厂存储记忆:热血、黑夜与无限大_第2张图片

 

2011年腾讯存储突破50PB

 

 

移动互联网——那些关于“柔性”的加班

 

2014年-2015年,移动互联网潮起,一场时间的抢位战一触即发。Regan第一次感受到明显的变化是在2015年:没想到,春节也开始加班了。

 

“虽然以往也有值班,但是做的事情比较基础,就是大家换换盘,处理一些终端设备。”2015年春节,微信红包兴起,春节微信的流量增长了10倍以上。

 

拜年红包的兴起背后是移动互联网生活方式的转变。因为无论是哪家公司筹谋的大活动,最终大家都会转移都微信朋友圈来“晒”。

 

随着社交方式的不断迭代,慢慢地,微信拜年发红包、录视频,还有了自定义表情,可以发一张自己的照片和红包一起发送给对方。

 

“统一动作还好办,一个热点分发就完了,但现在每个人的动作都不一样,每张图都需要保存下来再去分享,压力就非常大。“Able说。

 

对此,存储团队做了许多柔性策略,包括微信群的柔性、后台存储的柔性,也有接入层的柔性。

 

换句话说,在微信使用高峰期,用户发出的图片并不是即时发送成功,会有一个十几分钟的调整,慢慢地柔性上去。对此,微信也提出了极高的要求。每天凌晨开始计时,三十分钟之内必须要完全发完,最终要落到存储盘底层。

 

2015年春节,微信与央视合作,为观看春晚的微信用户发红包,也让微信的用户量快速增长,除夕凌晨零点的朋友圈等存储场景也达到了数十倍的增长。而由于提前了制定了柔性策略,存储团队抗住了这一次的压力。

 

鹅厂存储记忆:热血、黑夜与无限大_第3张图片

2016年存储团队春节值班

 

之后,腾讯相册、微云、邮件等业务在业务发展中,逐步积累起来较多的UGC历史数据,这些历史数据访问量低、存储量大,对业务的运营成本构成了较大的压力。

 

为了应对这些历史冷数据存储的成本挑战,2015年前后,腾讯基于纠删码研发了BTFS平台(Backup-TFS)。对业务进行了数据分层,增量数据访问量大,用TFS存储3份;历史冷数据再从TFS平台剥离出来,从3副本存储转向1.33副本的纠删存储,降低了存储成本。

 

这个阶段中,腾讯又改进了BTFS,使得部分低访问量业务的增量数据也可以直接存储进来。

 

云时代来临——从PB到无限大

 

从2006年起至今,TFS作为数据存储的底层平台,一直承载着包括QQ相册、微云、微信朋友圈等业务的非结构化大规模数据。

 

而过去十多年,腾讯存储技术也承载了数十亿用户负载,完成了海量互联网场景下存储系统研发、大规模数据迁移,形成了强大的技术沉淀和积累。

 

随着云计算业务量增大,为满足存储市场的需求,腾讯存储平台于2013年以云服务的方式对外提供了安全可靠的高性能云存储服务,并构建出最具代表性的对象存储等产品。

 

2014到2015年,腾讯在云存储领域飞速发展,随着用户数量越来越多,数据规模也越来越大,从2014年存储量的500PB,上升到了2015年存储量的1EB。

 

到了2017年,腾讯云的存储服务经受住了来自自身业务数十亿用户大规模复杂应用的检验,目前已经形成了开放的商用标准化能力。

 

在云计算早期发展的过程中,人们更注重的是“计算”、“流量” 等无状态类型的服务,当大家把比较容易摘到的“果实”摘完之后,巨大的存储市场才显露出来。

 

这时才发现,云计算作为一项相对灵活的技术,对于业务来说,所有的流量可以切走,计算可以迁移,但是存储一旦选择之后,很少再会“挪动”,否则会对业务产生非常大的影响。

 

不过,云时代对存储技术也提出了新的要求:用户对质量、性能和成本控制的要求越来越高,这意味着要把性能、可靠性、可用性要往极致的方向去逼;而腾讯云服务的客户又各有不同,用户本身的容灾能力也有很大差异。

 

同时,城市的基础设施也发生了很大变化,如今机房之间的互联专线非常快,甚至城市与城市之间都有几百G的专线互动。基础设施的更新,也需要上层的软件架构去调整和适应。

 

“是时候做一款真正为云而生的存储产品了。“

 

用Regan的话说,云上需要的是一个更大的数据存储系统,它没有文件、文件名、文件属性、目录、层级关系之类的概念或关系;相比于分布式文件系统,它的规模大很多,除了数据以外,可以组合各种不同的索引结构,像分布式文件系统中的目录树只是索引中的其中一种,而对象存储就是更灵活、更丰富、功能更强大的另一种索引结构。

 

从2017年开始,腾讯存储团队计划做一套全新的存储系统,在质量、性能、功能、成本、灵活性方面全方位超越,同时适用于腾讯云和腾讯各种自研场景(包括微信、QQ、微云、相册等等)的百万级超大规模集群,取名叫YottaStore。

 

对于做存储的同学来说,经常会跟GB、TB、PB、EB这些概念打交道。现在全球互联网非常大的巨头公司的数据量基本都是在EB这个量级。EB上面是ZB,全球互联网巨头数据起来也就几个ZB;ZB上面是YB,也就是YottaByte,目前全世界所有的数据加起来也不超过一个YottaByte。另外这个单词中文译名“有他”,给人安全可靠放心的感觉,系统的Slogan就是“存储有他,能力无限”。

 

2018年,YottaStore正式启动研发。

 

作为YottaStore的设计者,Richie介绍道,YottaStore是一个云原生的数据存储系统,这个系统理论的极限是一个集群可以管理超上千万台服务器。而要管理这上千万台的机器,原数据管理只需要用600G左右的空间,用一台机器就能存下的索引结构,管理上千万台的存储节点服务器,这个在业界是绝无仅有的。

 

在灵活性上,YottaStore集群可以零研发成本同时支持各种不同的冗余模式,无论是单AZ、还是双AZ、还是多AZ都可以灵活支持,还可以适应各种不同的机型和硬盘介质,包括存储的拓扑结构都可以任意指定、混合部署。

 

在运营能力上,YottaStore十万、百万规模的集群,20多分钟即可完成全集群的全面升级;如果是异构的数据格式,集群可以短时间内自动将数据格式透明收敛到最新版。

 

在稳定性上,系统上线前三个月,YottaStore一直维持了100%的可用性,上线一年半以来,一直保持单人值周零故障运行。

 

其实所有的技术问题,从本质上来说,关键是在时间、成本、需求、技术之间做好的权衡。

 

目前,YottaStore已经全面上线并支撑腾讯内外部的存储业务。腾讯云不久前发布的深度归档产品单价已经降到了1分钱/GB/月,刷新了业界存储的最低价。

鹅厂存储记忆:热血、黑夜与无限大_第4张图片

 

YottaStore团队合影

 

而当年从架构部走出的这批人也分散到了腾讯内部各个部门,成为腾讯AI、服务器、运管、研效、搜索、CDN、视频编码等许多技术方向的带头人,继续迎接产业互联网的挑战。

 

 

—END—

 

你可能感兴趣的:(云计算,腾讯,大数据,腾讯云,程序人生)