【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平台做计算平台是离线的，计算完之后得到相关性数据，扔到数据库里面去。在线应用可以去拿这些数据根据不同的场景做一些推荐。另外，根据他的反馈，推荐给他收听了表示喜欢这类的人，这个数据也会进入到计算平台，更正我们的算法，这是数据分析。上线以后跟关系链有一个比较大的促进作用。数据链推荐很重要的，把老同学、老同事挖掘出来了。
未来有几个方面：
一是数据分析和挖掘。我们要顺应形势，对于信息、关系链的挖掘非常重要，还有圈子的建设、用户的价值。都要通过算法挖掘。
二是安全。会向一些智能方向发展。
三是开放平台。腾讯微博未来也会向这个方向发展。
