[转贴]门户级网站的架构设计分析及其效果

简介: 本文作者对各大门户网站的分析主要是通过使用nslookup工具软件返回的结果来判断,因此只是一种评估形式的分析,例如文章关于网易的返回结果,作者认为网易得到的结果可以认为网易没有使用蓝汛的CDN,但其实chinacache与网易在2004年就签署了合作协议,国内三大门户都是chinacache的用户,只不过他采用的分流方式有别于sina和sohu。

本文作者对各大门户网站的分析主要是通过使用nslookup工具软件返回的结果来判断,因此只是一种评估形式的分析,例如文章关于网易的返回结果,作者认为网易得到的结果可以认为网易没有使用蓝汛的CDN,但其实chinacache与网易在2004年就签署了合作协议,国内三大门户都是chinacache的用户,只不过他采用的分流方式有别于sina和sohu。

  1、 新浪

  新浪采用了ChinaCache做的CDN系统,ChinaCache在全国分布了四十多个点,同时采用基于动态DNS分配的全球服务器负载均衡技术。

  从新浪的站点结构可以看出:

  > www.sina.com.cn

  Server: UnKnown

  Address: 192.168.1.254

  Non-authoritative answer:

  Name: libra.sina.com.cn

  Addresses: 61.135.152.71, 61.135.152.72, 61.135.152.73, 61.135.152.74 61.135.152.75, 61.135.152.76, 61.135.153.181, 61.135.153.182, 61.135.53.183, 61.135.153.184, 61.135.152.65, 61.135.152.66, 61.135.152.67, 61.135.12.68, 61.135.152.69, 61.135.152.70

  Aliases: www.sina.com.cn, jupiter.sina.com.cn

  在北京地区ChinaCache将www.sina.com.cn的网址解析到libra.sina.com.cn,然后libra.sina.com.cn做了DNS负载均衡,将libra.sina.com.cn解析到61.135.152.71等16个ip上,这16个ip分布在北京的多台前台缓存服务器上,使用squid做前台缓存。如果是在其它地区访问www.sina.com.cn可能解析到本地相应的服务器,例如pavo.sina.com.cn,然后pavo又对应了很多做了squid的ip。这样就实现了在不同地区访问自动转到最近的服务器访问,达到加快访问速度的效果。

  我们再看一个新浪其它频道是指到哪里的:

  > news.sina.com.cn

  Server: UnKnown

  Address: 192.168.1.254

  Non-authoritative answer:

  Name: libra.sina.com.cn

  Addresses: 61.135.152.65, 61.135.152.66, 61.135.152.67, 61.135.152.68 61.135.152.69, 61.135.152.70, 61.135.152.71, 61.135.152.72, 61.135.152.73 61.135.153.178, 61.135.153.179, 61.135.153.180, 61.135.153.181, 61.135.153.182 61.135.153.183, 61.135.153.184

  Aliases: news.sina.com.cn, jupiter.sina.com.cn

  可以看出,各个频道的前台缓存集群与www.sina.com.cn的前台缓存集群是相同的。

  2、 搜狐

  Sohu与新浪的原理差不多,下面是nslookup的结果:

  > www.sohu.com

  Server: UnKnown

  Address: 192.168.1.254

  Non-authoritative answer:

  Name: pagegrp1.sohu.com

  Addresses: 61.135.132.172, 61.135.132.173, 61.135.132.176, 61.135.133.109 61.135.145.47, 61.135.150.65, 61.135.150.67, 61.135.150.69, 61.135.150.74 61.135.150.75, 61.135.150.113, 61.135.150.145, 61.135.131.73, 61.135.131.91 61.135.131.180, 61.135.131.182, 61.135.131.183, 61.135.132.65, 61.135.

  132.80

  Aliases: www.sohu.com

  只不过libra.sina.com.cn换成了pagegrp1.sohu.com

  我们再来看一下sohu的频道:

  > news.sohu.com

  Server: UnKnown

  Address: 192.168.1.254

  Non-authoritative answer:

  Name: pagegrp1.sohu.com

  Addresses: 61.135.145.47, 61.135.150.65, 61.135.150.67, 61.135.150.69 61.135.150.74, 61.135.150.75, 61.135.150.113, 61.135.150.145, 61.135.131.73 61.135.131.91, 61.135.131.180, 61.135.131.182, 61.135.131.183, 61.135.132.65 61.135.132.80, 61.135.132.172, 61.135.132.173, 61.135.132.176, 61.135.133.109

  Aliases: news.sohu.com

  同新浪相同,用的是同样的服务器群,这可能是因为他们用的都是ChinaCache的服务吧,不过sohu的名字起的有点土,pagegrp1,没有libra,pavo好听,这名字听起来有点像法语,比较浪漫。

  3、 网易

  网易似乎没用ChinaCache的服务,下面是nslookup结果:

  > www.163.com

  Server: UnKnown

  Address: 192.168.1.254

  Non-authoritative answer:

  Name: www.163.com

  Addresses: 202.106.168.103, 202.106.168.104, 202.106.168.109, 202.106.168.121 202.108.36.153, 202.108.36.155, 202.108.36.156, 202.108.36.167, 202.108.36.172 202.108.36.196

  直接在www.163.com 这个域名上做了DNS负载均衡。这样的话就要求服务器必须放的非常靠近主节点,才能保证各地的用户访问的速度。

  但163不同的频道是放在不同的缓存集群上的,这与sina,sohu有些不同,等于sina,sohu是按照地区划分服务器集群,而网易按照频道划分服务器集群。

  > 163.com

  Server: UnKnown

  Address: 192.168.1.254

  Non-authoritative answer:

  Name: 163.com

  Addresses: 202.108.36.205, 202.108.36.206, 202.108.36.207, 202.108.36.201 202.108.36.202, 202.108.36.203, 202.108.36.204

  显然,这和www.163.com不是一个集群,我们再来试一个:

  > sports.163.com

  Server: UnKnown

  Address: 192.168.1.254

  Non-authoritative answer:

  Name: channel.cache.163.com

  Addresses: 202.108.36.136, 202.108.36.208, 202.108.36.209, 202.108.36.210 202.108.36.211, 202.108.36.212, 202.108.36.213

  Aliases: sports.163.com

  可以看出,和上面的集群也是不同的。

  4、 百度

  百度的前台服务器就不是很多了:

  > www.baidu.com

  Server: UnKnown

  Address: 192.168.1.254

  Non-authoritative answer:

  Name: www.baidu.com

  Addresses: 202.108.250.249, 202.108.249.134

  > baidu.com

  Server: UnKnown

  Address: 192.168.1.254

  Non-authoritative answer:

  Name: baidu.com

  Address: 202.108.250.228

  > mp3.baidu.com

  Server: UnKnown

  Address: 192.168.1.254

  Non-authoritative answer:

  Name: mp3.baidu.com

  Address: 202.108.249.131

  只有www.baidu.com做了两台服务器的集群,频道都用了一台服务器做前台

  5、 一搜

  > yisou.com

  Server: UnKnown

  Address: 192.168.1.254

  Non-authoritative answer:

  Name: yisou.com

  Addresses: 202.165.102.114, 202.43.217.14, 202.43.217.15, 202.43.217.16 202.43.217.17, 202.165.102.111, 202.165.102.112, 202.165.102.113

  > www.yisou.com

  Server: UnKnown

  Address: 192.168.1.254

  Non-authoritative answer:

  Name: www.yisou.com

  Addresses: 202.43.217.17, 202.165.102.111, 202.165.102.112, 202.165.102.113 202.165.102.114, 202.43.217.14, 202.43.217.15, 202.43.217.16

  > mp3.yisou.com

  Server: UnKnown

  Address: 192.168.1.254

  Non-authoritative answer:

  Name: www.yisou.com

  Addresses: 202.165.102.113, 202.165.102.114, 202.43.217.14, 202.43.217.15 202.43.217.16, 202.43.217.17, 202.165.102.111, 202.165.102.112

  Aliases: mp3.yisou.com

  前台做了8台服务器的缓存集群,www.yisou.com和 yisou.com以及mp3.yisou.com是用的同一个集群。

  通过前面的分析我们可以得到一个结论:sina和sohu使用了CDN与GSBL与DNS负载均衡技术,每个地区一组前台服务器群,网易,百度使用了DNS负载均衡技术,每个频道一组前台服务器,一搜使用了DNS负载技术,所有频道共用一组前台服务器集群。

   CDN的效果

  广州访问一搜:

  Tracing route to www.yisou.com [202.165.102.112] over a maximum of 30 hops:

  1 6 ms 6 ms 6 ms 此处隐去

  2 <1 ms <1 ms <1 ms 61.177.103.49

  3 <1 ms <1 ms <1 ms 61.177.103.181

  4 <1 ms <1 ms <1 ms 61.177.101.133

  5 <1 ms <1 ms <1 ms 61.177.101.17

  6 3 ms 3 ms 3 ms 202.97.27.153

  7 3 ms 3 ms 3 ms 202.97.27.22

  8 3 ms 3 ms 3 ms 202.97.27.33

  9 10 ms 10 ms 10 ms 202.97.39.109

  10 34 ms 34 ms 33 ms 202.97.34.45

  11 126 ms 127 ms 126 ms 202.97.57.214

  12 307 ms 310 ms 310 ms 219.142.8.230

  13 132 ms 132 ms 132 ms po2.bas1.cnb.yahoo.com [202.165.96.198]

  14 166 ms 165 ms 165 ms m29.search.cnb.yahoo.com [202.165.102.112]

  Trace complete.


  广州访问网易:

  Tracing route to www.163.com [202.108.36.196] over a maximum of 30 hops:

  1 6 ms 5 ms 5 ms 此处隐去

  2 <1 ms <1 ms <1 ms 61.177.103.49

  3 <1 ms <1 ms <1 ms 61.177.103.181

  4 <1 ms <1 ms <1 ms 61.177.101.133

  5 <1 ms <1 ms <1 ms 61.177.101.17

  6 3 ms 3 ms 3 ms 202.97.27.153

  7 3 ms 3 ms 3 ms 202.97.41.226

  8 106 ms 106 ms 106 ms 202.97.35.73

  9 106 ms 106 ms 106 ms 202.97.36.38

  10 266 ms 267 ms 265 ms 219.158.28.117

  11 240 ms 240 ms 240 ms 202.96.12.42

  12 239 ms 241 ms 240 ms 202.106.192.174

  13 241 ms 240 ms 240 ms 210.74.176.150

  14 240 ms 240 ms 241 ms 202.108.36.196

  Trace complete.


  广州访问新浪:

  Tracing route to taurus.sina.com.cn [61.172.201.222] over a maximum of 30 hops:

  1 6 ms 5 ms 5 ms 此处隐去

  2 <1 ms <1 ms <1 ms 61.177.103.49

  3 <1 ms <1 ms <1 ms 61.177.103.181

  4 <1 ms <1 ms <1 ms 61.177.102.5

  5 <1 ms <1 ms <1 ms 61.177.101.5

  6 <1 ms <1 ms <1 ms 202.97.27.117

  7 8 ms 8 ms 8 ms 202.97.39.9

  8 8 ms 8 ms 8 ms 202.109.0.141

  9 8 ms 15 ms 9 ms 202.109.0.38

  10 16 ms 15 ms 21 ms 202.109.0.174

  11 9 ms 9 ms 9 ms 202.96.208.218

  12 23 ms 22 ms 21 ms 61.172.201.222

  Trace complete.

  可以看出,做了CDN按地域划分缓存集群的新浪访问速度明显要比按频道划分缓存集群的网易和yisou要快的多,但CDN的成本也是非常高的。
目录
相关文章
|
3月前
|
缓存 网络协议 数据库连接
C/S架构中HTTP错误状态码原因分析及解决办法
HTTP(Hypertext Transfer Protocol)是用于在客户端和服务器之间传输数据的协议。当在浏览器或其他HTTP客户端中访问网页时,可能会发生各种访问报错。我们需要根据网页提供的错误状态码分析错误原因,以找到相对应的解决办法。
42 0
|
4月前
|
设计模式 前端开发 Java
KnowStreaming系列教程第二篇——项目整体架构分析
KnowStreaming系列教程第二篇——项目整体架构分析
42 0
|
28天前
|
设计模式 安全 Java
【分布式技术专题】「Tomcat技术专题」 探索Tomcat技术架构设计模式的奥秘(Server和Service组件原理分析)
【分布式技术专题】「Tomcat技术专题」 探索Tomcat技术架构设计模式的奥秘(Server和Service组件原理分析)
32 0
|
28天前
|
存储 Java 应用服务中间件
【分布式技术专题】「架构实践于案例分析」盘点互联网应用服务中常用分布式事务(刚性事务和柔性事务)的原理和方案
【分布式技术专题】「架构实践于案例分析」盘点互联网应用服务中常用分布式事务(刚性事务和柔性事务)的原理和方案
51 0
|
1月前
|
监控 JavaScript 安全
监控内网电脑软件设计与实现:基于Node.js的服务器端架构分析
在当今信息技术高度发达的时代,监控内网电脑的需求日益增长。企业需要确保网络安全,个人用户也需要监控家庭网络以保护隐私和安全。本文将介绍一种基于Node.js的服务器端架构,用于设计和实现监控内网电脑软件。
104 0
|
1月前
|
Web App开发 JavaScript 前端开发
分析网站架构:浏览器插件
分析网站架构:浏览器插件
44 1
|
1月前
|
消息中间件 存储 缓存
性能基础之大型网站技术架构模式
【2月更文挑战第15天】性能基础之大型网站技术架构模式
69 3
性能基础之大型网站技术架构模式
|
2月前
|
Unix Linux iOS开发
操作系统透视:从历史沿革到现代应用,剖析Linux与网站服务架构
操作系统透视:从历史沿革到现代应用,剖析Linux与网站服务架构
56 0
|
3月前
|
弹性计算 缓存 并行计算
带你读《弹性计算技术指导及场景应用》——3. Ada Lovelace架构解读及RTX 4090性能测试分析(1)
带你读《弹性计算技术指导及场景应用》——3. Ada Lovelace架构解读及RTX 4090性能测试分析(1)
|
3月前
|
弹性计算 人工智能 并行计算
带你读《弹性计算技术指导及场景应用》——3. Ada Lovelace架构解读及RTX 4090性能测试分析(2)
带你读《弹性计算技术指导及场景应用》——3. Ada Lovelace架构解读及RTX 4090性能测试分析(2)