备战双十一——从架构到细节

淘宝历经多年的发展,尤其近几年双十一出色表现,阿里研发已经在互联网应对高负载大并发树立技术标杆。

大型网站、尤其是淘宝这样的超大型网站,它在技术上的方方面面都是值得认真研究学习的。

这里说的大型网站,是指PV在千万级别以上的,面向全部互联网用户访问的。

简略说:
贴近用户,分布,分层,权责明确,可靠可追溯。

贴近用户:一是体验风格要贴近用户,面对千万的网民,一定要以大众化的方式呈现,过于另类和奇葩的东西大众很难接受。
二是网络资源要贴近用户,你的服务器资源放在南非的某个小国家,国内的网友访问速度怎么也上不去。要与网友在地里位置上贴近,通过自建机房或租用CDN镜像的方式把服务器资源放置在离用户最近的地方。 

分布:一是地域上的分布,二是应用请求的分布。网友访问你的网站首页,服务器响应请求并发送信息到网友浏览器。
这里面有文字的新闻,新闻里的图片/音频/视频,页面样式的文件(css,按钮背景图片等)可能还有脚本引用(jQuery插件等一堆的js文件),网友发表的评论和他收到的来自其他网友的信息等。

这些里面除了最后一个,前面三类都是通用的,通过缓存/镜像等方式提前准备好推送到网友最近的服务器。
文字的东西不大,重点解决图片和CSS类的,图片我们启用多组图片服务器并使用多个域名轮循使用,一来提高速度(浏览器单域名并发请求有限制),二来提高可靠性。

CSS类的,一些按钮啊、边框啊、背景图片什么的,一个网站下来可能有上百个,一个一个地请求加载这100多个文件,哪怕很小也要很长的时间。
我们采用“图片地图”的方式,把这一百个图片拼成一个大图,用的时候通过css取这个图上的不同区域范围显示,拼接得紧凑一些,不会比原来大很多,但只要一次请求就够了,时间就是这么节省的。

分层:网友访问,首先响应的是缓存服务器(Varnish,Squid,nginx),这类响应速度快,负载能力强,易维护扩展,缓存不能提供的再请求动态应用(php,tomcat,weblogic,ASP等),
动态应用也不直接访问数据库,先访问数据缓存(Java缓存,Memcache,ehcache等),这些都没有了再访问数据库(MySQL,Oracle,DB2等)。

一个典型的:varnish>>apache>>tomcat>>ehcache(Memcache)>>MySQL。按平均命中率90%来计算(做好设计的话,这已经很低了),10000次前端访问才带来一次数据库访问。如果数据库能抗几百并发的话,千八百万PV的网站不是轻而易举的么。
发生了访问缓慢,就具体分析瓶颈卡在了哪一层上了,然后扩展即可。
有的前面的分布部署,权责明确就好弄了。
95%以上的网友操作都是浏览,从缓存里直接取就是了,不需要访问数据库。
网友注册慢,就把注册的服务单独拎出去,并扩展优化增强。
而不会因为注册的人多,让整个网站访问都变得困难。

可靠可追溯:互联网拼的就是用户体验。一个网站文章写得非常好,但打开要30秒钟,可能用户等5秒钟还没结果就把浏览器关了。 
一定要可靠,对上面的分层分组,确保每个组里发生一台或多台崩溃的情况下,系统仍能提供服务(可以速度慢),消除单点。

可追溯,通过多种log日志记录,监控记录(Zabbix等)的手段全程记录网站运行情况。尤其能记录到单个或多个崩溃前后系统都发生了什么,
运维人员能够从中分析原因,做好预防。
==================================================================================
[url]http://loveqinghe.iteye.com/blog/1962711[/url]
[url]http://loveqinghe.iteye.com/blog/1969733[/url]

猜你喜欢

转载自loveqinghe.iteye.com/blog/1970848