中国顶级门户网站架构分析.docx
《中国顶级门户网站架构分析.docx》由会员分享，可在线阅读，更多相关《中国顶级门户网站架构分析.docx（13页珍藏版）》请在冰豆网上搜索。
中国顶级门户网站架构分析
中国顶级门户网站架构分析
首先声明，下面的内容都是我个人根据一些工具形成的猜想。
并不保证和现实中各大门户网站所用的架构一摸一样，不过我认为八九不离十了^_^。
整篇文章我想分2个部分来讲：
第一部分是分析国内2大顶级门户网站首页和频道的初步的基本构架。
第二部分我将自己做的实验文档记录下来。
希望每个SA心里都能有这样的架构。
新浪和搜狐在国内的知名度可谓无人不知无人不晓。
他们每天的点击率都在千万以上。
这样大的访问量对于新浪和搜狐来说怎样利用有限的资源让网民获得最快的速度成为首要的前提，毕竟现在网络公司已经离开了烧钱的阶段，开始了良性发展，每一笔钱砸下去都需要一定回响才行的。
另一方面，技术人员要绞尽脑汁，不能让用户老是无法访问、或者访问速度极慢。
这样就算有再好的编辑、再好的销售，他们也很难将广告位卖出去，等待他们的将是关门。
当然这些情况都没有发生，因为他们的技术人员都充分的利用了现有资源并将他们发挥到了极至。
说到底就是用squid做webcacheserver，而apache在squid的后面提供真正的web服务。
当然使用这样的架构必须要保证主页上大部分都是静态页面。
这就需要程序员的配合将页面在反馈给客户端之前将页面全部转换成静态页面。
好了基本架构就这样，下面说说我怎么猜到的以及具体的架构：
法宝之一：
nslookup
实战：
nslookup
Server:
ns-
Address:
202.96.209.5
Non-authoritativeanswer:
Name:
Addresses:
61.172.201.230,61.172.201.231,61.172.201.232,61.172.201.233
61.172.201.221,61.172.201.222,61.172.201.223,61.172.201.224,61.172.201.225
61.172.201.226,61.172.201.227,61.172.201.228,61.172.201.229
Aliases:
这里可以看到新浪在首页上用到了那么多IP，开始有人会想果然新浪财大气粗啊。
其实不然，继续往下看：
nslookup
Server:
ns-
Address:
202.96.209.5
Non-authoritativeanswer:
Name:
Addresses:
61.172.201.228,61.172.201.229,61.172.201.230,61.172.201.231
61.172.201.232,61.172.201.233,61.172.201.221,61.172.201.222,61.172.201.223
61.172.201.224,61.172.201.225,61.172.201.226,61.172.201.227
Aliases:
细心的人可以发现了news这个频道的ip数和首页上一样，而且IP也完全一样。
也就是这些IP在sina的DNS上的名字都叫，那些IP都是这个域的A记录。
而news,sports,jczs.news。
。
。
都是CNAME记录。
用DNS来做自动轮询。
还不信，再来一个，就体育频道好了：
nslookup
Server:
ns-
Address:
202.96.209.5
Non-authoritativeanswer:
Name:
Addresses:
61.172.201.222,61.172.201.223,61.172.201.224,61.172.201.225
61.172.201.226,61.172.201.227,61.172.201.228,61.172.201.229,61.172.201.230
61.172.201.231,61.172.201.232,61.172.201.233,61.172.201.221
Aliases:
其他的可以自己试。
好了再来看看sohu的情况：
nslookup
Server:
ns-
Address:
202.96.209.5
Non-authoritativeanswer:
Name:
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.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:
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
nslookup
Server:
ns-
Address:
202.96.209.5
Non-authoritativeanswer:
Name:
Addresses:
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,61.135.145.47,61.135.150.65
61.135.150.67,61.135.150.69,61.135.150.74,61.135.150.75
Aliases:
情况和sina一样，只是从表面来看sohu的IP数要多于sina的IP数，那么sohu上各个频道用的服务器就要多于sina了？
当然不能这么说，因为一台服务器可以绑定多个IP，因此不能从IP数的多少来判断用了多少服务器。
从上面这些实验可以基本看出sina和sohu对于频道等栏目都用了相同的技术，即squid来监听这些IP的80端口，而真正的webserver来监听另外一个端口。
从用户的感觉上来说不会有任何的区别，而相对于将webserver直接和客户端连在一起的方式，这样的方式明显的节省的带宽和服务器。
用户访问的速度感觉也会更快。
先说那么多了，要去睡觉了，明天还有很多工作要做～有不明白的记得给我留言！
！
！
前天讲了最基本的推测方法，今天稍微深入一些：
）
1.难道就根据几个域名的ip相同就可以证明他们是使用squid的嘛？
当然不是，前面都只是推测。
下面才是真正的证实我上面的猜测。
先nslookup一把sina的体育频道。
nslookup
Server:
Address:
61.151.243.136
Non-authoritativeanswer:
Name:
Addresses:
61.172.201.231,61.172.201.232,61.172.201.233,61.172.201.9
61.172.201.10,61.172.201.11,61.172.201.12,61.172.201.13,61.172.201.14
61.172.201.15,61.172.201.16,61.172.201.17,61.172.201.227,61.172.201.228
61.172.201.229,61.172.201.230
Aliases:
然后直接访问这些ip中的任意一个ip试试看，访问下来的结果应该是如下图所示：
由此可以证明sina是在dns中设置了很多ip来指向域名sqsh-，而其他各种相同性质的频道都只是sqsh-一个别名，用CNAME指定。
dns的设置应该是这样的，然后server方面，通过squid2.5.STABLE5（最新的稳定版为STABLE6）来侦听80端口。
上面这些是根据一些信息分析而出的，应该基本正确的。
下面一些就是我的个人的猜想：
它的真正的webserver也同样是侦听80端口，因为在squid配置文件中有一项是：
httpd_accel_port80
如果你设成其他端口号（比如88）的话，那上图的错误信息就会变成
WhiletryingtoretrievetheURL:
http:
//61.172.201.19:
88
工具2：
nmap扫描程序：
可以用来检查服务器开了什么端口。
我现在用nmap来扫描sina的一个ip：
61.172.201.19来进行分析
bash-2.05$nmap61.172.201.19
Startingnmap3.50（http:
//www.insecure.org/nmap/）at2004-07-3013:
31GMT
Interestingportson61.172.201.19:
（The1657portsscannedbutnotshownbelowareinstate:
filtered）
PORTSTATESERVICE
22/tcpopenssh
80/tcpopenhttp
Nmapruncompleted--1IPaddress（1hostup）scannedin73.191seconds
可以看到他对外只开了2个端口，80端口就是刚才我们说的squid打开的，这点刚才已经验证过了。
而22端口是用来ssh远程连接的，主要是sa用来远程操作服务器用的安全性非常高的方法。
工具3：
lynx或者其他可以读取http头文件的工具及小程序：
直接看例子比较好理解：
）
HTTP/1.0200OK
Date:
Fri,30Jul200405:
49:
47GMT
Server:
Apache/2.0.49（Unix）
Last-Modified:
Fri,30Jul200405:
48:
16GMT
Accept-Ranges:
bytes
Vary:
Accept-Encoding
Cache-Control:
max-age=60
Expires:
Fri,30Jul200405:
50:
47GMT
Content-Length:
180747
Content-Type:
text/html
Age:
37
X-Cache:
HITfromsqsh-
Connection:
close
上面是sina的http头的反馈信息。
里面有很多有价值的东东哦：
）譬如，它后面的apache是用2.0.49，还设了过期时间为2分钟。
最后修改时间。
这些都是要在编译apache的时候载入的，特别是Last-Modified还需要小小的改一把源码--至少我是这样做的。
综上所述
sina的架构应该是前面squid，按照现在的服务器2u，2g内存一般每台服务器至少可以跑4个squid2.5stable5.这样它16个ip就用了4台服务器。
后面一层是apache2.0.49应该会用2台。
这2台可能用的全是私有ip，通过前面的squid服务器在hosts文件中指定。
具体的实现方法我会下次整理出我做实验的文档：
）而apache的htdocs可能是有一个或2个磁盘阵列作nfs。
apachemountnfsserver的时候应该是只读的，然后另外还有服务器转门用来做编辑器服务器，用来编辑人员更新文章。
这台服务器应该对nfsserver是具有可写的权限。
----这就一套完整的sina所运用的方案，当然很多是靠猜测的，我没有和sina的技术人员有过任何沟通（因为一个也不认识），否则我也就不会写出来了。
其他sohu，163应该也有这样的架构。
最后声明：
这只是一些静态页面组成频道的一个架构，sina还有很多其他服务器，什么下载，在线更新等不在这个架构中。
一个疑问：
为何某些门户网站直接输入IP地址却无法访问
嗯~商業版有商業版的Solution..但價值有待商確...
OpenSource的東西基本上就可以解決了
跑的是Squid反向代理,根據我的經驗
及樓主的訊息來看
QUOTE:
GeneratedWed,20Oct200400:
35:
04GMTby108-（squid/2.5.STABLE5）
可以用下面來測試:
[Copytoclipboard][-]
CODE:
telnet218.30.108.5980
Trying218.30.108.59...
Connectedto218.30.108.59.
Escapecharacteris'^]'.
GETHTTP/1.1
你就會看到sina的網頁.但這個command是一般代理的命令
[Copytoclipboard][-]
CODE:
telnet218.30.108.5980
Trying218.30.108.59...
Connectedto218.30.108.59.
Escapecharacteris'^]'.
GET/HTTP/1.0
Host:
這個command則是一般HTTPRequest
他也會導出相同頁面,但這個業面根據上一個例子,我們可以猜測
是運行反向代理（也就是的A記錄指向是ProxyServer,非WebServer）
至於樓主的例子會變成這樣的command
（不懂的話要先研究HTTPProtocol）
[Copytoclipboard][-]
CODE:
telnet218.30.108.5980
Trying218.30.108.59...
Connectedto218.30.108.59.
Escapecharacteris'^]'.
GET/HTTP/1.0
Host:
218.30.108.59
不同的HttpRequest有不同的回應
我們再試一個代理測試:
[Copytoclipboard][-]
CODE:
telnet218.30.108.5980
Trying218.30.108.59...
Connectedto218.30.108.59.
Escapecharacteris'^]'.
GET.twHTTP/1.0
上述是HTTP/1.0會出現AccessDeny
下面是HTTP/1.1
Squid回應302（就是要你自己去找目的,他不代理）
[Copytoclipboard][-]
CODE:
telnet218.30.108.5980
Trying218.30.108.59...
Connectedto218.30.108.59.
Escapecharacteris'^]'.
GET.twHTTP/1.1
同樣的功能Apache本身也有,就在mod_proxy*這個DSO中
不然也可以找Pound:
http:
//www.apsis.ch/pound
原理都一樣,用Layer4+Switch技術的話,也有L4以上的做法
但價錢恐怕就不便宜了
一个疑问：
为何某些门户网站直接输入IP地址却无法访问
這是用新網DNS解到的資料:
[Copytoclipboard][-]
CODE:
.60INCNAME.
.60INCNAME.
.60INA210.51.179.88
.60INA210.51.179.89
.60INA210.51.179.90
.60INA210.51.179.91
這個是用台灣的DNS解到的資料:
[Copytoclipboard][-]
CODE:
;;ANSWERSECTION:
.43INCNAME.
.43INCNAME.
.44INA61.135.153.184
.44INA61.135.152.65
.44INA61.135.152.66
.44INA61.135.152.67
.44INA61.135.152.68
.44INA61.135.152.69
.44INA61.135.152.70
.44INA61.135.152.71
.44INA61.135.152.72
.44INA61.135.152.73
.44INA61.135.153.178
.44INA61.135.153.179
.44INA61.135.153.180
.44INA61.135.153.181
.44INA61.135.153.182
.44INA61.135.153.183
很顯然的,使用view來分流...
另外,上述IP我都測了幾個,都是squid,所以它還用了反向代理功能
反向代理通常也會有LoadBalance/redundancy的效果在
至於有沒有用L4+Switch從這邊我們無法知道.
但若我們看的MX,我估計是有的,因為把那些MX的IP
各加幾碼或減幾碼拿來試,跑的都是qmail
所以,Web有沒有用L4我們不知道,MX估計是有的
若純粹以交換機來做WWW的分流,我相信貴公司一定很有錢
一般來說,WWW負載平衡有幾種做法:
1.交換機做法,依請求來分流,發佈的IP只有一個或少數幾個,但透過交換機的功能,導到交換
機下的某些其他主機
2.透過DNS的RoundRobin機制,隨機選取IP進行連接,意義等同於
（1）,但可跨物理區隔
3.透過DNS的RoundRobin+View功能,達到同
（1）
（2）效果,並且具有依SourceIP不同,
連接到不同WWWServer之功能
4.透過反向代理（ReverseProxy）可以達到負載平衡,減少DiskI/O存取,例如一般的Apache
即有的功能（Apache效能可能沒有squidorpound等好）
5.LVS或HA做法..或其他方法,非本處主題
Ex:
[Copytoclipboard][-]
CODE:
#DNS分別有www1/www2/www3A記錄
#Apache1.3example1,負載平衡需要RewriteMap
;
ProxyRequestsOn
NoCache*
ProxyPassReverse/
ProxyPassReverse/
ProxyPassReverse/
;
[Copytoclipboard][-]
CODE:
#DNS為CNAME,到www1/www2/www3即同上理
#DNS要允許multiplecname
#Apache1.3example1,負載平衡不需要RewriteMap
;
ProxyRequestsOn
NoCache*
ProxyPassReverse/
;
[Copytoclipboard][-]
CODE:
#squiud部份設定,只允許代理到的請求
#例如的Address需設定到這台Proxy
#但此部proxy需
升级会员 