QQ空间的服务器负载能力优化过程简介

QQ空间的服务器负载能力优化过程简介,第1张

QQ空间的服务器负载能力优化过程简介

石器时代M——从十万行到百万行
石器时代M是QQ空之间1.0到3.0稳步发布的全过程。
QZone关键架构研发总监肖旭说:“M在QQ空之间的石器时代遇到的一大困难就是如何生存?怎么让这被子里的货活起来?如何积累第一批宝贵的用户资源?”,2005年,QQ空以传统的分发推荐码的方式,推出了第一批用户。第一个QQ空嵌入在单独的客户端中。看起来像手机客户端,其实是ie内核。里面全是HTML网页,按URL存储。
那时候架构比较简单。Apache用来搭建Web服务器,Mysql用来存储最后的数据信息。用户按照{uin}.qzone.qq.com(uin是用户的qq号)的方法浏览自己的空房间。最初只邀请电信网络用户。不过发布后发现,很多中国北方的网通用户也很期待感受一下。但是如果中国北方的网通用户跨网浏览电信网的服务,会是一种非常不好的感觉。当时整个网络的网络带宽非常有限。
为了更好地考虑网通用户的需求,来自QQ空的精英团队打造了一套与电信网完全相同的服务。电信网的用户数据信息只存储在电信网的服务器上,网通的用户数据信息只存储在网通的服务器上。看似遍布全球,但实际上两部分数据信息是相互分离的,无法留存。当用户申请注册空时,很清楚自己的数据信息存储在哪个服务器上。
用户浏览空之间的逻辑抽象如下(如图2所示):用户根据电脑浏览器的要求浏览每个人的第一个CGI,这个CGI通过串口通信获取用户数据信息,如穿衣数据信息、日志数据信息等。获得所有数据信息后,CGI将所有数据信息组装成一个详细的HTML网页,输出给用户。

另外空之间第一版单一的手机客户端也产生了各种问题和困扰:
一是对精准定位非常不利。
一旦网页元素填写不成功,精确定位就会很不方便。因为它不是网页,所以我们必须使用其他数据包捕获软件,如Ethereal(最初的Ethereal(Wireshark))来抓取互联网数据包进行分析。但当时的互联网软件抓包能力还比较弱,没有高亮度和HTML语法检测的功能,所以整体自然环境有限。
第二:服务连接层压力太大。
因为我们不仅要接受用户的要求,还要反向浏览不同的数据信息。当一个socket请求超时的后端开发严重时,很多用户会离线。这将消耗大量的连接资源和Web服务器的CPU。
第三,服务集群没有充分发挥所需的服务能力
当时30-40台服务器一起使用,只有50万左右的用户可用。无奈之下,精英团队想到了一个无奈的办法:刻意将用户数量限制在50万以上,并明确提出了长龙排队制度,学习培训海底捞的火锅捞方式。当在线游戏总数达到50w时,QQ空会向用户展示一个Flash游戏,让用户在等待时玩。
针对当时存在的诸多问题,精英团队做了以下改进来应对:
首先,采用WebRIA。
当时应用了很多Ajax技术来减轻服务器的负荷。其中一个极端的例子就是所有空的首页都是用JS绘制的,可以减轻用户浏览的CGI丰富的汽车。尽可能简化CGI逻辑,让CGI程序更加健壮高效。另外,当服务出现异常时,可以根据JS脚本绘制错误报告,提醒用户。而且JS开发设计效率更高,调整更方便。
WebRIA后,服务器CPU消耗降低40%,DC输出网络带宽节省30%左右(部分JS脚本可以通过电脑浏览器缓存)。
第二:采取动静分离的对策。静态数据资源全部放在开发的Web服务器qhttpd上,具有当时ApacheSelect实体模型的两个数量级的连通性。
三、Web服务器的研发:QZHTTP是动态分离动态服务必要性的关键。因为Qzhttp是腾讯官方开发的轻量级Web服务器,更适合业务流程本身的逻辑,从而保证了其优异的性能,连接能力比Apache(非FastCGI方式)高三倍。
M在石器时代做出的巨大改进:
当用户在QQ空中申请几个服务时,每个服务都有自己的存储和解决逻辑。只有当所有的服务解决方案执行完毕,QQ空中的服务器才会返还给用户。那会给其他依赖日志、相册、歌曲、留言板的服务造成两个问题:
1)短板效应会被破坏;
2)实际业务流程量不能多样化。
针对这两个问题,做了首页加载性能的优化和系统软件对首页内容静态数据的改进:
用户浏览实体模型的科学研究。呈现和UGC内容的变化比例为7:1。用户经常互相访问,看别人和看自己的比例是5:1。根据以上数据信息可以看出,用户的UGC升级很少,但是用户之间相互浏览频繁。根据用户浏览实体模型,由空精英团队产品开发了一套静态数据系统软件(图3)。这个系统软件会缓存用户主页的所有内容,然后根据用户的浏览情况和用户自身UGC内容的变化,采取一定的对策,对静态数据系统软件的缓存数据信息进行升级。
根据改善首页内容静态数据的系统软件,首页呈现率由5s提升至3s,用户无需玩游戏和等待。此外,在不扩充机器设备的前提下,在线PK用户浏览量增加了100w。

根据不断的改进和推广,QQ空Room3.0在2006年年中稳步发布。
冷兵器时代——功能的锤炼
冷兵器时代是线上总兵力从百万连接到千的全过程。这个环节做的是锤炼功能,提高可用性的全过程。
但是除此之外,QQ空里的精英团队又遇到了新的问题:
1。网通,教育信息网的用户感觉很不好;
2。版本号迭代更新快,导致外网地址bug持续;版本号发布后,所有开发设计必须保留两个小时;
3。后端开发服务质量不稳定导致服务器频繁宕机。
前面说过空之间的用户数据信息分布在中国电信和中国网通两个管理系统中。但由于企业在网通的服务机器设备相对有限,随着用户数量的不断提高,很快实现了对数控机器设备服务的限制。网通无法扩充机器设备,但用户数量持续增加。对付这种情况,只能把网通和电信网的数据信息合为一套。当网通用户浏览服务时,他们将根据一个代理把用户的需求分享给内部网电信网络服务。这种方法展示了一套通用的解决方案,可以处理国外运营商的问题,如网通、教育信息网、铁通等。
但是这种跨网浏览的静态数据资源注册量非常大,静态数据资源需求:CGI需求的频率接近10:1。因此,使用CDN来展示静态数据资源的共享,以提高用户网站的打开速度。其实逻辑就是根据用户手机客户端的IP来区分用户属于哪个ISP服务商,按照URL的方式把用户的静态数据资源浏览到ISP的服务机上。
就这样,跳出CDN系统软件的束缚,改进思路,解决了教育信息网大部分用户的问题,多层次应用的思路成为了一个公共计划。
但还是有很多通病:
1)ARPU低,成本降低,设备便宜,集群大
2)版本号迭代更新,每周发布版本号
3)用户对通病和低效率的容忍度极低
。一般1s内打开网页。所以要按照以下对策来保证服务质量:
1)区分重点线路,规定重点线路的服务质量要在4个9以上。非关键线路服务不成功,不利于我们的感情;
2)采用动态请求超时控制系统,保证所有程序进程在可控时间内响应;
3)多级容错纠错机制,从后端开发服务到CGI,再到前端接收JS脚本,所有不正确的容错机制全部解决;
4)采用软功能对策,不成功套接字采用默认设置数据信息。
为了更好地保证版本号的服务质量,在空中采用了灰度发布措施。新功能很可能是根据用户手机的尾号公布的,每个新功能只对少部分人可见。经过一段时间的用户意见反馈,问题会被不断还原和改进,然后逐渐扩大用户新功能的可见性。最后,新功能将对所有用户可见。另外,根据对JS版本信息的 *** 纵,达到灰度发布的目的。
按此推广,QQ空已成功进入数千万线上势力,QQ空5.0已经公布。在关键变化中,后端开发服务进行了重建,前端开发网页也进行了升级。
现代战争期间——百万在线到亿级在线
不断改进升级,QQ空之间的服务质量大幅提升。但是新的问题接踵而至:
不适合发日志和照片的用户,想另外,企业其他精英团队应该在QQ空开发设计应用,但是QQ空之间的应用设备是写在QQ空之间的服务平台的逻辑里。为了配合其他精英团队发布,发布号必须要一个星期,而且在工作中不能并行处理,耗时长,受到很大挑战。对于这种情况,我们采取了几种对策:将服务平台与应用架构分离,简单配置后发布。

深圳的IDC有一天用不上了怎么办?
为了更好的应对这个问题,空精英团队在全国其他地方部署IDC,采用“一点写,一点读”的框架实体模式,将服务部署到深沪津和Xi安。深圳是一个装货点。按照QQ空自己的一套系统软件,会加载到全国每一个IDC上。此外,QQ空呈现出多方位立体监管,服务7*24小时监管。
如何才能发现并处理用户的问题?【/br/】准确定位用户的问题,肯定要花很多钱,这就需要精英团队做很多监管工作:服务器流量管理,监管socket激活,监管前端开发限速,监管不正确的前端开发激活。
另外,在几千万到几亿条线的全过程中,精英团队要具备遍布全国甚至全世界的业务能力;问题可以快速激光切割,多方位系统化监督能力;每个逻辑层都在不断提升自己的能力。只有持续改进,用户才能认可功能的改进,用户才会改进。
经过反复推敲和不断完善,QQ空的服务能力已经能够满足成千上万用户的在线需求,可以向用户展示7*24小时的连续服务。向十亿线上势力的最后冲刺也将指日可待!
总结:
百万在线:
当时如何支持服务,让用户进来,然后在QQ空中积累第一批用户,按照用户实体模型进行升级,让QQ空中的框架有更强的连接能力,保证性能优秀。
甘湾在线:
根据各层的软服务和灰度释放的对策,服务会更加稳定,用户水平会达到一个新的高度。
亿级在线:
服务应该以更灵活、更智能的方式改变。此外,它还具有更强的监管和运营能力。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/785128.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-05-04
下一篇 2022-05-04

发表评论

登录后才能评论

评论列表(0条)

保存