前言

自從上一篇“ 

前幾次對(duì)去哪兒的源碼感興趣的是在一次我需要航班信息的時(shí)候，那段時(shí)間我對(duì)去哪兒的代碼有過一些時(shí)間的分析，并且成功地抓取去哪兒的航班和酒店數(shù) 據(jù)，僅作學(xué)習(xí)之用，請(qǐng)去哪兒不要找我了，呵呵。

我想這次分析要稍為嚴(yán)謹(jǐn)一丁點(diǎn)兒，要不然會(huì)有較真的人要罵我。我準(zhǔn)備從代碼質(zhì)量、Javascript、CSS、url及網(wǎng)址結(jié)構(gòu)、廣告、圖片等多 個(gè)方面進(jìn)行分析。

架構(gòu)試探

雖然只是分析了前臺(tái)的代碼，但所謂管中窺豹可見一斑，根據(jù)我以前對(duì)qunar的代碼分析，**從這些前臺(tái)的代碼，我們也可以看到系統(tǒng)結(jié)構(gòu)的一些端倪 的。去哪兒整個(gè)網(wǎng)站的重點(diǎn)是在搜索，我想他們是有一個(gè)爬蟲以及和各大航空公司/旅游代理網(wǎng)站的接口在后臺(tái)來做數(shù)據(jù)的采集，這個(gè)是重點(diǎn)。然后對(duì)采集回來的數(shù) 據(jù)進(jìn)行分析之后，定時(shí)生成JSON靜態(tài)數(shù)據(jù)，前臺(tái)調(diào)用采用Ajax的模式，以提高響應(yīng)速度。我覺得去哪兒這種方式非常好，因?yàn)閿?shù)據(jù)都是定時(shí)更新的，把每個(gè) 城市的數(shù)據(jù)都生成靜態(tài)的json，特別是一些不常更新的數(shù)據(jù)，比如航空公司，酒店，航班信息等，有利于提高響應(yīng)速度和降低服務(wù)器的壓力。數(shù)據(jù)和實(shí)現(xiàn)分離也 很**，自己的網(wǎng)站通過WebAPI讀取，有利于產(chǎn)品化，以及方便與第三方合作，實(shí)現(xiàn)公司靈活快速地根據(jù)實(shí)際情況調(diào)整產(chǎn)品。

我自己估計(jì)的 Qunar大體架構(gòu)

這樣做同時(shí)也有缺點(diǎn)，因?yàn)槟愕臄?shù)據(jù)非常的干凈，別人要取就很容易了，反正我是取過去哪兒很干凈的數(shù)據(jù)，干凈而透明，呵呵�？赡苁侨ツ膬河X得這些數(shù)據(jù) 都是比較實(shí)時(shí)的，你就算拿到這些數(shù)據(jù)也沒有用。但是我覺得盡管如此，還是應(yīng)該在服務(wù)器加一些限制，對(duì)請(qǐng)求數(shù)量進(jìn)行限制，或者加一些別的限制，這樣有利于防 止機(jī)器請(qǐng)求，提高服務(wù)器的可用率。

|||

首頁分析

首先還是來看首頁，我覺得去哪兒的網(wǎng)站是優(yōu)化得比較好的網(wǎng)站之一了，去哪兒的首頁一共有114.9k，共41個(gè)請(qǐng)求數(shù)，個(gè)人認(rèn)為請(qǐng)求數(shù)有些過多（主要是廣告部分），可以適當(dāng)降低請(qǐng)求數(shù)。

靜態(tài)文件

去哪兒的靜態(tài)文件似乎并非統(tǒng)一放在前幾立的服務(wù)器上，而是不同的頻道有不同的靜態(tài)內(nèi)容服務(wù)器（我指的是邏輯服務(wù)器），像source.qunar.com，hotel.qunar.com等等，這樣做有好處有壞處，好處是各項(xiàng)目組（我認(rèn)為qunar不同頻道是同不同的項(xiàng)目組前幾立負(fù)責(zé)的，這樣有利于產(chǎn)品化）管各自的靜態(tài)文件就ok了，壞處是不利于統(tǒng)一管理。我建議可以這樣，把靜態(tài)文件統(tǒng)一部署到一臺(tái)/組服務(wù)器，各頻道可以采用不同的邏輯服務(wù)器放置靜態(tài)文件。這樣便于統(tǒng)一管理，特別是去哪兒JS靜態(tài)文件比較多，便于統(tǒng)一做CDN，因?yàn)閯?dòng)態(tài)內(nèi)容和靜態(tài)文件采用的CDN技術(shù)不一樣，價(jià)格也不一樣，有利于節(jié)省成本。

圖片去哪兒首頁的圖片非常少，少得讓人吃驚，但你并不覺得這個(gè)網(wǎng)站太難看，反而覺得很清爽，我認(rèn)為圖片應(yīng)該盡可能少，圖片只是在文字不能傳達(dá)某個(gè)意思的時(shí)候才使用圖片，這樣可以起到畫龍占睛的作用，也有利于SEO，當(dāng)然圖片壁紙站除外。

壓縮

服務(wù)器上有啟用Gzip壓縮，有利于減小傳輸量，特別是對(duì)于去哪兒采用定時(shí)生成JSON靜態(tài)數(shù)據(jù)的情況下，Gzip更能發(fā)揮作用。同時(shí)CSS文件，也有采用去注釋和空行的壓縮方式。但是我不明白的是，為什么有些javascript卻沒有經(jīng)過壓縮呢？例如在文件：http://hotel.qunar.com/scripts/hotel/recommandHotels.js？15182155276，不僅可以看到換行，還可以看到明顯的注釋

數(shù)據(jù)與實(shí)現(xiàn)分離

實(shí)際上就是指CSS/JS和Html以及數(shù)據(jù)，有沒有很好地分離，我覺得這方面，去哪兒還是做得不錯(cuò)，首頁的HTML代碼非常輕巧，但有點(diǎn)我不明白，為什么去哪兒并未完全采用Div + CSS，而在首頁還摻雜有Table呢，我覺得去哪兒的首頁并沒有需要用到Table的地方，完全可以全部采用Div+CSS進(jìn)行布局。如果我沒估計(jì)錯(cuò)的話，去哪兒的首頁應(yīng)該也是自動(dòng)生成靜態(tài)頁面，并且是采用xml+xslt或者類似的方式，因?yàn)樗�源代碼的空行方式很類似于xml+xslt的結(jié)果。

廣告

相比去哪兒的版面來說，首頁廣告是非常之多，我覺得可能比新浪的廣告比例還要高，但你完全沒有不舒服的感覺。我想一方面，是去哪兒的廣告內(nèi)容和網(wǎng)站主題很匹配，主要是機(jī)票和酒店類的廣告，另一方面，是由于廣告位置以及廣告與網(wǎng)站的溶入度非常高，說得白一點(diǎn)，就是去哪兒給廣告穿了一件迷彩服，一般人以為不是廣告，實(shí)際上他是廣告。

我認(rèn)為去哪兒的廣告點(diǎn)擊率應(yīng)該很高，起碼不低。首先，在顏色的配置上，去哪兒的廣告顏色與整個(gè)頁面一致，廣告沒有太明顯的標(biāo)識(shí)，這樣有利于用戶點(diǎn)擊廣告，特別是對(duì)于對(duì)網(wǎng)站不熟悉的用戶，很容易受這些廣告的誘惑去點(diǎn)擊廣告。但從另一個(gè)角度來說，廣告主所得到的回報(bào)率可能會(huì)偏少。從我的觀察來發(fā)現(xiàn)，越是菜鳥的用戶，越容易點(diǎn)廣告，但點(diǎn)完廣告帶來的價(jià)值偏少，而成熟的用戶點(diǎn)擊廣告都是比較理性，給廣告主帶來的回報(bào)率會(huì)比較高。

URL/域名

去哪兒每個(gè)頻道都有一個(gè)二級(jí)域名，并且還有其它更多的二級(jí)域名，一方面，二級(jí)域名有得SEO和用戶記憶，但過多的域名，也難于管理。我不覺得目前去哪兒需要這么多的二級(jí)域名，縮少到5-8個(gè)即可。

總結(jié)

我個(gè)人認(rèn)為，去哪兒的技術(shù)上應(yīng)該是比較不錯(cuò)的，像一些細(xì)節(jié)的地方都有作處理，但是也有些需要改正地方，如沒有防止數(shù)據(jù)采集（或者靈敏度太低），就算不擔(dān)心數(shù)據(jù)被利用，也應(yīng)該考慮到對(duì)服務(wù)器的壓力；JS/CSS文件過于分散，JS代碼沒有進(jìn)行清理與壓縮（不是指gzip）；HTML代碼還可以更加簡潔一些，有些代碼完全是很無聊的嵌套，可以再行精簡，加快瀏覽器的解析。

后記

上面的分析報(bào)告是在去Qcon大會(huì)之前寫成的，為了保證它的原汁原味，我沒有作任何修改。我記得在Qcon大會(huì)上的吳永強(qiáng)說他們的數(shù)據(jù)是實(shí)時(shí)抓取的，就這一點(diǎn)，我談?wù)勎业目捶�，我認(rèn)為實(shí)時(shí)抓取是不可能的，雖然機(jī)票這個(gè)東西價(jià)格變化很快，但肯定不可能做到實(shí)時(shí)抓取。原因如下：

前幾、如果是全部都實(shí)時(shí)抓取，去哪兒的帶寬和服務(wù)器都受不了，就算做到了，也不經(jīng)濟(jì)

**、以去哪兒每天100萬以上的訪問量，如果是實(shí)時(shí)抓取數(shù)據(jù)，被抓的網(wǎng)站受不了

我認(rèn)為比較可行的辦法是這樣的，去哪兒抓取的網(wǎng)站應(yīng)該分為兩種，即合作伙伴和非合作伙伴，合伙伙伴比較好說了，他們可以提供API接口，這部分的機(jī)票信息肯定是實(shí)時(shí)的。另一種是非合作伙伴，這些網(wǎng)站應(yīng)該有一個(gè)緩存策略，根據(jù)去哪兒以往去這些網(wǎng)站抓取的數(shù)據(jù)分析他們機(jī)票的更新速度來確定緩存失效時(shí)間。去哪兒有一個(gè)爬蟲根據(jù)更新策略把數(shù)據(jù)抓到緩存中，這樣用戶在請(qǐng)求的時(shí)候，實(shí)際上是在讀這個(gè)緩存（生成JSON數(shù)據(jù)）。不知道去哪兒現(xiàn)在是不是這樣的方法呢？

網(wǎng)站技術(shù)分析報(bào)告之——去哪兒，希望對(duì)您有用。

查看更多建站經(jīng)驗(yàn)技術(shù)網(wǎng)站