技术开发 频道

从腾讯微博的成长分析架构的三个阶段

  【IT168专稿】全球系统架构师大会于8月10-12日在深圳万科国际会议中心隆重举行。在今天下午的演讲中,腾讯微博事业部技术总监张国松给大家分享腾讯微博的技术架构,讲解如何应对海量业务的高速发展和高服务质量挑战。据张国松介绍,腾讯微博业务高速发展,2年发展4亿用户,同时对服务质量的要求比以往业务更高,对技术架构形成巨大压力。腾讯微博的架构,从架构成长的角度来讲分成三个阶段:


全球系统架构师大会现场报道

从腾讯微博的成长分析架构的三个阶段
▲腾讯微博事业部技术总监张国松

  微博的业务特点:

  1、多终端,这是现在大部分业务都要面临的新的情况。比如说以前考虑PC终端就可以,新的考虑iphone、ipad和PC终端。

  2、SNS是互联网的大趋势。SNS本身也可以带来很多东西,是很庞大的量。

  3、高速发展,近两年来新的情况,业务的发展非常快。比如说腾讯微博,从2010年4月份上线,经过两年的时间有4亿多的用户,速度相当之快。腾讯的微信也是一年多时间有一亿多的用户。架构上也面临很大的挑战,规模的增长实在太快了。

  4、轻量化。随着移动终端的发展有更高的要求,要求性能更高,不可能很轻量的上面还很重的东西。

  5、高质量。主要跟微博相关。大家可以看到微博上面有很多名人,是一个系统化媒体,消息传播非常快。对于架构不好的是,坏消息传播也非常快,立刻要处理,这也是以往预不到的情况。

  以下是精彩的演讲:

  先看一看架构演进。互联网系统是一个有生命的系统,不停地省长演变。我也推荐大家看一本书《失控》,讲到里面有很多非常新颖的理念,而且可以看到互联网系统非常符合里面讲得生物和机械的结合。在架构里面来看,其实是分了很多小的类别,比如说功能、体验、规模。

  大的架构有一个演进的规律,其实里面每个小项有自己的规律,也是我们在做架构的时候需要注意的地方。

  谈到演进会有一个节奏的问题,宇宙万物都有节奏,包含人也是,有心跳,有白天黑夜,要睡觉。如果没有心跳人就挂了。

  从架构来看分为大结构和小结构。大结构是版本的演进过程,时间比较长,而且大节奏把握有一些基本的规则可以考虑的。至少最基础的部分,需要优先和重点的照顾。腾讯讲,先抗住再优化。任何一个系统不可能刚开始做得非常精细,可以先不要性能那么的优化,性能差一点可以用堆机器或者运维的手段扛过去,然后再优化。小节奏是敏捷迭代,在微博里面体会非常明显。其实每天都有多个版本上线,感觉不会太明显,但是真正后台的更新速度是非常之快。

  不同的分类节奏也可以有不同的自己时间间隔。比如说用户体验,可以非常快的迭代,发现有问题可以立刻调,可以有一个很快迭代的过程。而对于这种功能来说,一般也不会说很快,一个是太快用户会疲劳,另外也不可能太精细,每隔一段时间给用户新功能的刺激还是非常有用的。

  架构结构调整是非常大的工作,不建议非常频繁的调整。腾讯微博从大的方面可以分成三个阶段:

  第一,上线。2010年4月份上线了,上先线前有几个月的时间一直在做开发、测试。对于微博来说比较长的过程,对于小的系统的话,这个过程只需要个把月或者一两个月。

  第二,2010年5月份的时候开始做性能优化,持续了比较长的时间。在性能优化期间做了基本建设、容错建设。

  第三,去年6月份的时候开始做容灾建设。因为那时系统的故障非常多,压力很大,专门启动了这样的过程。

  到现在大家可以看到腾讯微博,刚才的几方面做得相当不错的,性能体验非常好,一点就有。稳定性方面腾讯微博比较少出问题。

  第一个阶段,上线。首先是最基础的功能,肯定是必须的。二是针对平台化的策略。跟刘源讲得服务化很像的。三是基本安全,四是数据统计。容错方面,基本上没有容错,是非常简单的模式。早期会发现腾讯微博还是经常会出问题,还好不是非常大。刚上线的时候我们是千万级的容量,跟每个公司不一样的,可以选择自己基础的目标,因为在腾讯量稍微大一点,像一般大概十几万到百万级别的高。

  现在看到的分为三大部分,蓝色部分是平台部分,里面有很多服务,服务是经过平台统一的接口对外输入处理。这也是平台化的一个基本结构。在上面有各个终端,比如说外部、PC客户端、wap。刚开始上线的时候有这三个终端,右侧有运营支撑系统,有基本的监控、运维、产品统计的功能。

  多终端,对于架构来说,不是好事,大家面临的困难一下大很多,开发效率也要考虑。而且还有多终端引起同样的功能要在三个终端上保持一致性,这对现实造成比较大的困扰。但是,多终端在未来很长一段时间都会存在。现在看不出来平板会不会把电脑吃掉,反而呈现了多终端的趋势。多终端对于架构考虑这些点:

  1、架构一致性和兼容性。在多终端主要面临的问题。一致性是同样的功能,这个终端上有,另外一个也要有,而且还要保持一致性。还有包含设置的东西,在iphone上做了一个设置,在其他终端上看到同样的设置。所以架构上必须要考虑。兼容性,手机屏幕很小,很多功能展现不了,或者采用不同的展现方式,这是架构上需要考虑的。

  2、平台化。用一个平台连接多个终端。

  3、云计算、云存储刚才讲的设置都可以看成云的东西,我们会有一些图片、存储,可以用云存储的方式解决。

  4、开发效率。这也比较困扰,因为一个终端和多个终端做得工作多了很多。

  平台化在一致方面主要是这样几个应对:一个平台,连接多个终端。统一的接口可以保障基础的一致性。

  兼容差异性,在微博方面做了几个工作:

  数据层兼容,可以扩展,并不是一个固定的数据。这样的话,终端也可以在数据加上自己的东西。有些数据只有终端自己可以理解的。

  功能展现方面也要有一定的兼容性。有些消息在一个140字的微博下面,还有一些其他的东西,比如说新闻列表之类的,这种东西手机上看不到了,只会看到正文的部分。

  灰度试错。有些功能是基本的功能,可以在每个终端上做统一的规划,但是其实里面还有大量小的东西,是比较难判断我是不是适合所有的终端,或者说是不是能够成功的。这时采用的方式是一个终端上先做,其他先不做。在这个终端试用成功以后,再去推广。这是一些兼容性。

  数据统计,这是在上线的时候就有的。

  第二个阶段,性能优化,其实这个阶段差不多一年的时间还有其他的工作,比如说容错、功能建设,大部分的工作量是功能建设。

  这个阶段为什么要做性能优化呢?这也是腾讯的一个理念,对响应速度是非常重视的。在整个互联网应用体验里面,可以说是最重要的,这也由于技术障碍造成的。

  腾讯微博刚上线的时候就开始做优化了,在非常短的时间,达到很优化的性能,用起来会非常舒服。

  讲到体验方面、速度方面,你也可以不管它,但是花力气优化到一定程度,用户层次上会感觉到治理,用户感觉非常舒服。不好的用起来总会有一定的心理障碍,我们非常重视。

  优化主要分为三步

  一是建立目标和标准,这点非常重要,决定了你后面达到的高度。

  二是监控指标。我们看到运维系统的图,可以监控到每个区域和时间,可以精确到一个小时,每个省市都会有自己不同的限网的速度。而且每天会有一些日报出来,每天都要看这些数据。当然,我们会采用不同颜色,现在优化还不错,都是绿色的。刚开始有黄色红色。

  优化方面,最基本的是靠近用户的优化最重要,这是对于用户体验来说。靠近用户主要是互联网速度的影响。比如说从游览其到web跑一趟50、60秒,消耗的时间非常长。而在后端服务器到服务器可能十几毫秒就觉得已经是有一点延迟了。在靠近用户端,像wep会跑来回很多趟。腾讯微博是非常简单的界面,但是看请求,首页就会有七八十个请求,再去乘网络消耗的时间,是很恐怖的数字,这方面的优化最最关键的。

  web优化对于整个性能来说是最核心的,还有Cache、逻辑层、数据层。

  Web里面的34条做得非常不错,按照这个来做的话,会有比较好的收效,腾讯微博大部分都会应用到。

  首屏优化,首屏指的是一进网页不滚动的时候看到的这一屏。用户首先是这个,重点优化得到比较好的效果。后台优化也有一定程度的效果。首屏优化很快,几秒,没有等待的过程会非常舒服。我们要对首屏进行单独的测速,必须心里非常清楚,在数据上要知道首屏速度是多少。对于首屏来说,可以进行特别的优化,比如首屏说的元素尽量减少,能够后加载的时候都放到首屏后面的。首屏用不着的东西不要放到首屏上去。微博右侧延迟加载,因为用户看到的是最优先出来的,能够解决用户的根本体验。想对整页优化到非常理想的速度还是挺难的。

  现在看到的是一个具体的例子,大图预加载。每个产品都不一样,如果深究进去,有不少细化的优化点。微博默认是一个小图,一点出一个大图,一开始没有优化,一点有短暂的过程,当然不会太长,但是也会有一点受到阻力的感觉,后来做了一下统计,点击率还是非常之高的,30%多会选择点开图。所以我们做了一个大图的预先加载。实际上看小图的时候大图已经被加载下来了,这样的话就没有等待过程,体验非常舒服了。如果是无线网络、3G,会把预加载关掉。用户在这种情况下对流量非常敏感。

  Cache,微博用了很多级Cache,几乎每个层都会用到Cache,这应该也是极其有用的东西,影响可以处理热点,而且还有容错的能力。我们也是大量的用了Memcache,在实用过程中证明是又简单又稳定的系统。

  逻辑层优化相对比较简单一点。一个是协议的合并,协议拆太散也不是好事,来回太多了。我们会把串型的计算变成并行的处理。

  数据存储,这也是微博里面关键的数据,有四种方式:

  1、内存,在微博大量应用。微博相对好一些,消息比较短小,用内存可以解决很多问题。在微博里面还有索引、账户等东西,会大量使用内存的存储。

  2、noSQL存储,微博消息等都是用noSQL存储,微博的noSQL是自己写的数据库。

  3、MySQL存储,大量小应用没必要特别的存储,MySQL就可以使用了。

  4、云文件系统,存储头像图片,量很高,几百T的量。可以非常快速解决存储的问题。存储也是微博理念关键的东西。

  我发表微博的ID、我收到微博的ID叫做索引,会用来做我的主页聚合计算。微博主页是汇总了所有人发表微博的时间排序。得到这页必须要用到关系链和我收听的人的索引。存在大量的计算,所以放到内存。我的主页计算只会在内存里面进行。SSD有自己的特点,可以定期整理成数据块。在内存里面存了一定时间的数据,可以有失去整理SSD。两个也是相辅相成的。腾讯微博是读扩散的模式,我的主页在读的时候生成。有两个模式,一个是用户发一条,在我的主页插入一条。另外,在独立的时候删除,我的主页没有的。这样的方式优点延时比较小。因为在听众索引里面查数据量很高。比如说刘翔粉丝几千万,他发表微博索引里面查比较恐怖的事情。

  消息聚合计算,我收听的人所有微博本机先汇总一下,得到一个排序列表,检查一下再往上送,上一级又得到多台机器的汇总,逐级进行合并,最终得到了我的主页。第二个阶段采用这些方式整体的性能达到不错的效果。

  第三个阶段,容灾建设。这个阶段去年6月份开始,6月份前的确发生非常多的问题,基本上每个月都会出问题,大大小小的问题都有。而且在6月份,我们团队有一定的规模,这时开始容灾建设。当然这个期间有几项工作,一个是运维,一个是开发效率,还有一个是数据挖掘。

  微博架构调整,把平台分成两大部分,一个叫核心服务,一个叫普通服务。我们加了一个消息中转,实际上就是消息对接的关系。从第二阶段开始增加更多的接入。这是在可靠性方面的策略。故障不可能避免的,互联网更新速度非常快,达到完美程序质量不可能,关键是怎么减少影响范围。

  互联网的应用非常有特色,程序的更新占到最大头。这个统计只是把有影响的故障统计出来,每天都会有更新上线。

  灰度发布,我们发布更新分成几个阶段发布,这样可以极早发现问题,而且范围很小,方法是规定时间和范围。通过这个发布,把z程序更新引起的故障基本上控制下来。

  有损服务,也是腾讯特别强调的东西。在程序里面如果不做有损服务的话,可能一行代码就可以搞跨。但是自然界不一样,比如说手受伤了,还是会干活,无非是哪一个手指头不方便而已。这是有损服务的基本思想,可以通过降低服务,摘掉一些故障点,让一些主体业务还可以继续运作。

  容灾把系统分为几大部分:核心服务、普通服务、外围服务。

  核心服务,主页、微博数据、关系链数据。我们会做一个很强的容灾,即使是一个城市的网络宕掉也不有影响。外围会用一些多IDC的部署,可以分担用户。

  经过调整,会形成现在看到的这种结构。

  在容灾方面,会在多城市里面容灾,因为每个城市都会出问题,多层次容灾可以更快速的期换数据,期换成服务。当然,在网页这一端、平台机构层、数据层至少会有三九层次的异地IDC容灾能力。每当这个城市的服务宕带的时候会自动切换。两侧IDC的容灾基本不能宕掉,两侧会宕掉。我们经常会看到腾讯微博有些小东西突然不见了,就是因为一些宕掉。

  核心功能叶有部分有损能力。

  我的主页计算,如果某台索因所,则忽略该数据。无非少一些听众,其他听众还在,对于用户来说可以接受的。像一些微博数据,如果读取有问题就忽略掉了。早期有空白页,现在不会出现。

  外部接入,早期只有两个点,电信和网通。缺点是什么?用户体验上高。我们部署了很多点,每个点出问题影响范围小很多。

  腾讯微博有些话题会引起很大的访问量,在防止防雪崩上做了很多工作。当外界访问量多的时候丢掉,这种不可行,上层认为抖动,会又回来重视,会返回一个特别的错误代码,表示系统已经过载了。不用再发过来了,这也是细节的推出。

  隔离,也是非常有用的策略,一些应用发现它的业务量比较大或者有些比较重要的,单独隔离一下,不放在一起。比如说内部和外部不要放在一起,否则会互相牵扯,一个挂掉另外一个也会宕掉。

  去中心化。在容灾里面有些东西会绕过刚才讲的东西。有个东西叫做去中心化。在很多动画片里面有这样的情景,敌军有一个核心的东西,有一个司令部,把核心干掉,帝国联盟全跨了。我们系统也遇到同样的问题。首先,DNS,因为域名的原因,简单的配置错了,把整个域名指向错误,宕掉几十分钟的时间,就一条指令。在微博里面采用多域名,腾讯微博里面有多个域名存在。另外,在一些配置方面也会加强管理,通过管理的手段。

  配置中心,在我们的系统里面经常会采用配置中心,几千台机器,如果一台台配置难度太高了。我们会采用多配置中心,不要用一个配置中心,因为配置中心出问题所有的机器都会挂的。

  灰度,灰度发布。

  微博发表的时候,发表消息后面会经过安全的审核进程,有一次发现微博不能写了,另外一个两台机器做安全审核的功能,因为要更新程序,把其中一台机器重启了,另外一台机器顶不住了。本来是备份的后来备份不了,那台机器被压死了,后来导致微博发表不了,后来处理多加一点机器。对于微博这么大的业务用两台机器控制,风险还是挺高的。

  微博的故障处理。老板比我们要先发现问题,这个很奇怪,后来发现真的是这样。很多用户挂在上面,一出问题直接@老板,然后老板说这个有问题。在以往我们自己先得到消息,这也是对我们运维提出更高的要求。

  要做好运维要从三个方面做:人、工具、主动推进的优化。当然,非常好的的是什么事都没有。

  比如说我们加了一个流程,故障知会,每次有故障的时候,发现故障的运维人员,及时通过手机短信要向上知会。以前是悄悄处理掉了,现在老板知道了立刻会下去问,我们在故障知会,发现问题立刻向上报告,至少有一定的时间优势,至少表示知道了,正在处理。

  我们专门针对于微博做了一个日志系统,这个日志系统是一个集中的日志系统,会收集所有的错误日志,而且会特别的加一些东西,比如说每一条错误日志里面都可以看到QQ号码、源文件、函数名、行号,非常精确。在排错的时候会发现这个系统非常有用的。没有这个系统要从几千台机器上查日志速度会非常之慢的。

  在我们经常会发现故障排除过程,最典型的是应了几十分钟或者个把小时发现问题,这样的问题五到十分钟解决问题。前面阶段极其重要的,所以我们用了错误日志,用了搜索引擎,几秒钟以内可以把线上几千台错误日志全部搜索一遍,对于运维来说是强有力的工具。

  流水日志,比如说系统更新有流水的东西,也做了一些日志,为什么要做流水日志,最主要是要提供上下文的查询,因为错误日志不可能提供所有的信息。这两个系统只是做运维,不是统计。系统其实挺简单的,日志系统用到每个IDC,查询在IDC内部进行最后再汇总。这样的话可以得到一个比较强的工具。最主要是要提高运维响应速度,要非常快。一出问题立刻查询、立刻找。找到故障尽快向老板回复,尽快解决问题。

  开发效率,主要是高速发展、多终端。尤其是高速发展对微博的技术团队压力是非常之大的。早期每天加班到十一二点,强度非常大的。我们采用了一些手段,采用了很多开源的架构,比如说LAMP、Memcache、Hadoop,这些本身已经考虑了很多东西,没必要重新写一遍。我们也用了公司内部的一些托管、云文件系统。

  解耦,引入了消息中转系统,早期也有一个系统,大家都不用,做得不好,后面特别加强。

  支撑系统是一些基础的东西。

  消息中转系统,早期也有一个,但是基于UDP经常丢包,丢来丢去大家都不用了,以前大家看到腾讯微博经常会丢出去,跟它有一定的关系。为什么要用这个系统呢?发展到去年的时候,发现同城、热榜、活动等东西,忽然增加到几百个模块。增长速度非常快。看起来微博上没东西,其实小模块非常多。刚开始没有特意的用中转系统,会发现跟刚才人人网很相近。比如说写一条微博,这个微博考虑很多因素,对后面的系统产生很多影响,后面一堆系统都要改,接着引入了中转系统,是一个发布订阅的消息系统。这个系把核心系统和其他系统都会隔离开,承载了系统里面所有的更新动作,都会发到中转系统,其他系统只要接到中转系统,就会得到最新状态。这个解决了我们一大问题,开发效率一下子提高很多,只管自己的东西就行了。系统接到中转可以得到最新的东西。

  数据分析和挖掘。对于微博来说,一些东西对于数据分析极其重要,一个是关系连的相关性,推荐人给你,什么样的人推荐给你?排序什么样的?这里的数据挖掘必须要做的。二是高质量的内容筛选,微博里面有很多高质量的内容,比如说微频道、微博精选、猜你喜欢之类的。

  数据分析上我们用Hadoop平台,这是一个离线系统,并不是在线的。在Hadoop平台用的比较多,有几百台Hadoop机器做微博的数据分析。用Hadoop平台做计算平台是离线的,计算完之后得到相关性数据,扔到数据库里面去。在线应用可以去拿这些数据根据不同的场景做一些推荐。另外,根据他的反馈,推荐给他收听了表示喜欢这类的人,这个数据也会进入到计算平台,更正我们的算法,这是数据分析。上线以后跟关系链有一个比较大的促进作用。数据链推荐很重要的,把老同学、老同事挖掘出来了。

  未来有几个方面:

  一是数据分析和挖掘。我们要顺应形势,对于信息、关系链的挖掘非常重要,还有圈子的建设、用户的价值。都要通过算法挖掘。

  二是安全。会向一些智能方向发展。

  三是开放平台。腾讯微博未来也会向这个方向发展。

0
相关文章