<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
<channel>
<title><![CDATA[静怡家园]]></title> 
<link>http://www.zhanghaijun.com/index.php</link> 
<description><![CDATA[书山有路勤为径，学海无涯苦作舟！]]></description> 
<language>zh-cn</language> 
<copyright><![CDATA[静怡家园]]></copyright>
<item>
<link>http://www.zhanghaijun.com/post//</link>
<title><![CDATA[大中型网站架构探秘]]></title> 
<author>碟舞飞扬 &lt;webmaster@zhanghaijun.com&gt;</author>
<category><![CDATA[服务器类]]></category>
<pubDate>Thu, 19 May 2011 08:26:28 +0000</pubDate> 
<guid>http://www.zhanghaijun.com/post//</guid> 
<description>
<![CDATA[ 
	相信很多IT人士都有过搭建自己主页的经验，10多年前的个人主页都非常简单，很多由Frontpage构建，多属于静态HTML页面，最多加一点 特效而已。不过10年间，技术的进步是惊人的。现在，一个网站绝不可能仅仅由几个HTML页面构成。我们随便举一个例子，国内图片网站 yupoo.com，在 chinarank排名1000左右，而Alexa排名则为5000左右，这个网站不算大，就是这样一个中型站点，拥有超过60台服务器，架构中涉及的 Web服务器就包括了Lighttpd、Apache和 nginx。Yupoo的流量不算大，就已经拥有了60台服务器，事实上，排名前几位的网站，都拥有成千上万台服务器，如何协调这些服务器之间的工作负 载，如何统一指挥调度，如何维护这些服务器硬件都是棘手的挑战。<br/><br/>负载均衡：<br/> <br/>负载均衡是所有大中型网站必备的部署。显然，大型网站每天上千万独立IP的访问量，一个Web服务器根本承担不了，网站后台必需有多台服务器共同工 作，因此各种负载均衡技术就应运而生了。<br/> <br/>较早的负载均衡是DNS负载均衡。原理很简单，只要在域名解析的时候，将多个地址配置成同一个域名，负载均衡就完成了。不同用户点击同一个域名的时 候，实际上只解析给用户一个地址，这样用户实际上访问的是不同的Web服务器，就减轻了每个服务器的负担。这个DNS负载均衡方法，一般而言是随机抽取地 址。DNS负载均衡早期被广泛使用，优点是简单易用，但是DNS负载均衡还是有一些问题存在。如果某一台服务器发生了故障，而DNS的下一个刷新周期又没 到，这样就可能导致某些用户无法访问站点的情况发生。而另一个缺点在于DNS负载均衡随机性太强，比如一段时间内众多访问都被指向同一个地址，而另外的地 址却闲置，就造成了局部繁忙的不良现象。而且有时某处服务器正在运行其他应用而处于繁忙状态，DNS负载均衡也无从得知，而依旧平均的解析域名。<br/> <br/>稍微复杂一点的负载均衡，是反向代理，当外部有请求到代理服务器，代理服务器再将该请求均匀的转发到内网的服务器上。这种方式被广泛采用，比如说上 面提到的又拍网yupoo.com，就采用了nginx作为反向代理。此外，现在还可以购买专业的硬件设备，比如 Plentyoffish.com(全球最大的婚介网站)就采用了网捷网络公司的Web交换器ServerIron作为硬件负载均 衡，ServerIron 能够有效地处理 16，000，000个并发连接，并且可以改善服务器负载均衡和缓冲转换，像ServerIron这类的硬件产品并非只有网捷一家提供，由于大型网站预算 充裕，因此也可以选择一些其他的硬件设备来做负载均衡。当然了，我们也别忽略了最基本的软件负载均衡——Windows Server就带有这样的功能。<br/> <br/>负载均衡还有一个极为简单的方法，就是建立镜像站点。比如华军软件或者天空软件，都直接采用了镜像站点。这个方式很直接，省去了很多麻烦。以华军软 件园为例，登陆华军软件园的时候，我们将有多种选择，可选电信、网通等网络；而下载某一软件的时候，为了使用户得到更快的速度，天空和华军在中国各地都安 排了服务器，可以提供距离最近的下载服务。不过，也有一些麻烦，就是每一次选择都是人工手动选择。总之，这一系列负载均衡方法，都得以让大型网站的负载均 匀，不会有哪个服务器有太大的压力。<br/> <br/>CDN：<br/> <br/>CDN( Content Delivery Network)，内容分发网络也是大型网站必备的部署之一。CDN的原理不难理解，就是将网页内容存放到离用户更近的缓存服务器上，减少路由，从而加快 远距离的访问速度。比如说，你随意登陆一个国外小站，速度可能很慢。因为国外网站到国内的最终客户端的路径冗长，但是如果你登陆部署了CDN的网站，比如 Plentyoffish.com，你会发现速度非常快，跟国内的网站访问速度差异已经无法从感知上判断。依照Cache存放的位置不同，CDN也有一些 类别，不同的网站会根据具体需求，有不同的选择。CDN通常是由独立的CDN商提供的。举一个例子，就是网易，我的查询时间是2008年2月28日，我们 发现，同一个域名下的有很多个IP地址，这就说明了首页CDN的部署。<br/> <br/>C:>nslookup www.163.com<br/> <br/>Server: ns.lnpta.net.cn<br/> <br/>Address: 202.96.64.68<br/> <br/>Non-authoritative answer:<br/> <br/>Name: www.cache.split.netease.com<br/> <br/>Addresses: 202.108.9.37, 202.108.9.38, 202.108.9.39, 202.108.9.51<br/> <br/>202.108.9.52, 202.108.9.31, 202.108.9.32, 202.108.9.33, 202.108.9.34<br/> <br/>202.108.9.36<br/> <br/>Aliases: www.163.com<br/> <br/>而我们如果查询一个简单的个人网站，则不可能有CDN；另外，如果有兴趣，我们也可以仔细察看一个网站多个二级域名的CDN情况。<br/> <br/>平台设计：<br/> <br/>大型网站一般都有着非常复杂的与用户交互的内容，必须大量调用数据库，因此一个完善的数据库设计对于大型网站非常重要。例如上面提到的 Plentyoffish.com，这个站其实是个人网站，但流量大的惊人，该网站有一个主要的数据库，两个搜索数据库，早些时 候，plentyoffish.com的数据库设计问题频频，经常到数据库堵塞，所以站长花费时间最多的地方就是数据库优化。数据库优化没有什么特别的捷 径，其实很少有一次成型的完美数据库构建，只能是按照特定的需要来设计数据库，如有不足再去着手改进。不过大型网站还是有一些共性，比如说图片存储单独使 用图片数据库，尽量使用静态页面来减少数据库调用等等。<br/> <br/>还有很多大型网站，都有着非常深厚的技术实力，可以开发属于自己的平台。比如说谷歌，Google.com就有着自己独特的平台，主要包括 GFS、MapReduce和 BigTable。因为海量数据存储，所以常规的数据库调用查询是非常恐怖的，每次查询都将调用百亿个页面，成千上万个并发检索足以使得谷歌系统崩溃，因 此Google File System将大量页面以独特的方法压缩之后再提供检索；整个系统一共包括超过两百个集群，再由MapReduce来协同作业。不仅仅谷歌，比如百度、中 搜等等网站也都有自己研发的独特的平台。<br/> <br/>硬件配置：<br/> <br/>大型网站的硬件配置一定就好吗？答案是否定的。比如说全球最大的网站谷歌，google.com的整个架构的基础是几十万台普通的PC级别服务器。 谷歌一些服务器的细节为商业机密，但是根据谷歌已经披露的资料显示，在2006年之前谷歌拥有45万台服务器，这些服务器都是非常普通的PC级服务器，甚 至硬盘接口都还是有些过时的IDE接口。这也是谷歌的独特架构决定的，而对比谷歌，维基百科则拥有非常强势的服务器，全部为SCSI硬盘，而且主要的主机 中都有多达6块硬盘，超过16GB内存。这比较容易理解，因为谷歌在全球拥有很多个数据中心，员工数量众多，完全有能力管理数以万计服务器的运行，而维基 百科则为非营利机构，主要依靠捐赠生存，员工数量非常稀少，因此必须配备强势的服务器。其实，每个网站都应该根据自己独特的情况来配置硬件，目前 1TB SATA硬盘已经步入了量产阶段，可是2年以前1TB的硬盘只能通过RAID 0来实现，可见硬件的更新速度非常惊人，所以即便预算充裕，在配置服务器的时候也应该多考虑实际用途，而不一定要拥有最好的配置。<br/> <br/>总结：<br/> <br/>以上只是大型网站的概括总结，其实每个网站都有自己独特的一面，所以以上的每一条规则都未必是死规定。比如说着重沟通的Twitter.com，本 质就是一个异步聊天室，因此静态页面就不见的有必要。总之，网站架构没有死定律，只要合适网站的，就是好的架构。
]]>
</description>
</item><item>
<link>http://www.zhanghaijun.com/post//#blogcomment</link>
<title><![CDATA[[评论] 大中型网站架构探秘]]></title> 
<author> &lt;user@domain.com&gt;</author>
<category><![CDATA[评论]]></category>
<pubDate>Thu, 01 Jan 1970 00:00:00 +0000</pubDate> 
<guid>http://www.zhanghaijun.com/post//#blogcomment</guid> 
<description>
<![CDATA[ 
	
]]>
</description>
</item>
</channel>
</rss>