一鍵撥打熱線服務(wù)
前言
自從上一篇“
前幾次對去哪兒的源碼感興趣的是在一次我需要航班信息的時候,那段時間我對去哪兒的代碼有過一些時間的分析,并且成功地抓取去哪兒的航班和酒店數(shù) 據(jù),僅作學(xué)習(xí)之用,請去哪兒不要找我了,呵呵。
我想這次分析要稍為嚴謹一丁點兒,要不然會有較真的人要罵我。我準備從代碼質(zhì)量、Javascript、CSS、url及網(wǎng)址結(jié)構(gòu)、廣告、圖片等多 個方面進行分析。
架構(gòu)試探
雖然只是分析了前臺的代碼,但所謂管中窺豹可見一斑,根據(jù)我以前對qunar的代碼分析,**從這些前臺的代碼,我們也可以看到系統(tǒng)結(jié)構(gòu)的一些端倪 的。去哪兒整個網(wǎng)站的重點是在搜索,我想他們是有一個爬蟲以及和各大航空公司/旅游代理網(wǎng)站的接口在后臺來做數(shù)據(jù)的采集,這個是重點。然后對采集回來的數(shù) 據(jù)進行分析之后,定時生成JSON靜態(tài)數(shù)據(jù),前臺調(diào)用采用Ajax的模式,以提高響應(yīng)速度。我覺得去哪兒這種方式非常好,因為數(shù)據(jù)都是定時更新的,把每個 城市的數(shù)據(jù)都生成靜態(tài)的json,特別是一些不常更新的數(shù)據(jù),比如航空公司,酒店,航班信息等,有利于提高響應(yīng)速度和降低服務(wù)器的壓力。數(shù)據(jù)和實現(xiàn)分離也 很**,自己的網(wǎng)站通過WebAPI讀取,有利于產(chǎn)品化,以及方便與第三方合作,實現(xiàn)公司靈活快速地根據(jù)實際情況調(diào)整產(chǎn)品。
我自己估計的 Qunar大體架構(gòu)
這樣做同時也有缺點,因為你的數(shù)據(jù)非常的干凈,別人要取就很容易了,反正我是取過去哪兒很干凈的數(shù)據(jù),干凈而透明,呵呵?赡苁侨ツ膬河X得這些數(shù)據(jù) 都是比較實時的,你就算拿到這些數(shù)據(jù)也沒有用。但是我覺得盡管如此,還是應(yīng)該在服務(wù)器加一些限制,對請求數(shù)量進行限制,或者加一些別的限制,這樣有利于防 止機器請求,提高服務(wù)器的可用率。
|||
首頁分析
首先還是來看首頁,我覺得去哪兒的網(wǎng)站是優(yōu)化得比較好的網(wǎng)站之一了,去哪兒的首頁一共有114.9k,共41個請求數(shù),個人認為請求數(shù)有些過多(主要是廣告部分),可以適當降低請求數(shù)。
靜態(tài)文件
去哪兒的靜態(tài)文件似乎并非統(tǒng)一放在前幾立的服務(wù)器上,而是不同的頻道有不同的靜態(tài)內(nèi)容服務(wù)器(我指的是邏輯服務(wù)器),像source.qunar.com,hotel.qunar.com等等,這樣做有好處有壞處,好處是各項目組(我認為qunar不同頻道是同不同的項目組前幾立負責(zé)的,這樣有利于產(chǎn)品化)管各自的靜態(tài)文件就ok了,壞處是不利于統(tǒng)一管理。我建議可以這樣,把靜態(tài)文件統(tǒng)一部署到一臺/組服務(wù)器,各頻道可以采用不同的邏輯服務(wù)器放置靜態(tài)文件。這樣便于統(tǒng)一管理,特別是去哪兒JS靜態(tài)文件比較多,便于統(tǒng)一做CDN,因為動態(tài)內(nèi)容和靜態(tài)文件采用的CDN技術(shù)不一樣,價格也不一樣,有利于節(jié)省成本。
圖片去哪兒首頁的圖片非常少,少得讓人吃驚,但你并不覺得這個網(wǎng)站太難看,反而覺得很清爽,我認為圖片應(yīng)該盡可能少,圖片只是在文字不能傳達某個意思的時候才使用圖片,這樣可以起到畫龍占睛的作用,也有利于SEO,當然圖片壁紙站除外。
壓縮
服務(wù)器上有啟用Gzip壓縮,有利于減小傳輸量,特別是對于去哪兒采用定時生成JSON靜態(tài)數(shù)據(jù)的情況下,Gzip更能發(fā)揮作用。同時CSS文件,也有采用去注釋和空行的壓縮方式。但是我不明白的是,為什么有些javascript卻沒有經(jīng)過壓縮呢?例如在文件:http://hotel.qunar.com/scripts/hotel/recommandHotels.js?15182155276,不僅可以看到換行,還可以看到明顯的注釋
數(shù)據(jù)與實現(xiàn)分離
實際上就是指CSS/JS和Html以及數(shù)據(jù),有沒有很好地分離,我覺得這方面,去哪兒還是做得不錯,首頁的HTML代碼非常輕巧,但有點我不明白,為什么去哪兒并未完全采用Div + CSS,而在首頁還摻雜有Table呢,我覺得去哪兒的首頁并沒有需要用到Table的地方,完全可以全部采用Div+CSS進行布局。如果我沒估計錯的話,去哪兒的首頁應(yīng)該也是自動生成靜態(tài)頁面,并且是采用xml+xslt或者類似的方式,因為它源代碼的空行方式很類似于xml+xslt的結(jié)果。
廣告
相比去哪兒的版面來說,首頁廣告是非常之多,我覺得可能比新浪的廣告比例還要高,但你完全沒有不舒服的感覺。我想一方面,是去哪兒的廣告內(nèi)容和網(wǎng)站主題很匹配,主要是機票和酒店類的廣告,另一方面,是由于廣告位置以及廣告與網(wǎng)站的溶入度非常高,說得白一點,就是去哪兒給廣告穿了一件迷彩服,一般人以為不是廣告,實際上他是廣告。
我認為去哪兒的廣告點擊率應(yīng)該很高,起碼不低。首先,在顏色的配置上,去哪兒的廣告顏色與整個頁面一致,廣告沒有太明顯的標識,這樣有利于用戶點擊廣告,特別是對于對網(wǎng)站不熟悉的用戶,很容易受這些廣告的誘惑去點擊廣告。但從另一個角度來說,廣告主所得到的回報率可能會偏少。從我的觀察來發(fā)現(xiàn),越是菜鳥的用戶,越容易點廣告,但點完廣告帶來的價值偏少,而成熟的用戶點擊廣告都是比較理性,給廣告主帶來的回報率會比較高。
URL/域名
去哪兒每個頻道都有一個二級域名,并且還有其它更多的二級域名,一方面,二級域名有得SEO和用戶記憶,但過多的域名,也難于管理。我不覺得目前去哪兒需要這么多的二級域名,縮少到5-8個即可。
總結(jié)
我個人認為,去哪兒的技術(shù)上應(yīng)該是比較不錯的,像一些細節(jié)的地方都有作處理,但是也有些需要改正地方,如沒有防止數(shù)據(jù)采集(或者靈敏度太低),就算不擔(dān)心數(shù)據(jù)被利用,也應(yīng)該考慮到對服務(wù)器的壓力;JS/CSS文件過于分散,JS代碼沒有進行清理與壓縮(不是指gzip);HTML代碼還可以更加簡潔一些,有些代碼完全是很無聊的嵌套,可以再行精簡,加快瀏覽器的解析。
后記
上面的分析報告是在去Qcon大會之前寫成的,為了保證它的原汁原味,我沒有作任何修改。我記得在Qcon大會上的吳永強說他們的數(shù)據(jù)是實時抓取的,就這一點,我談?wù)勎业目捶,我認為實時抓取是不可能的,雖然機票這個東西價格變化很快,但肯定不可能做到實時抓取。原因如下:
前幾、如果是全部都實時抓取,去哪兒的帶寬和服務(wù)器都受不了,就算做到了,也不經(jīng)濟
**、以去哪兒每天100萬以上的訪問量,如果是實時抓取數(shù)據(jù),被抓的網(wǎng)站受不了
我認為比較可行的辦法是這樣的,去哪兒抓取的網(wǎng)站應(yīng)該分為兩種,即合作伙伴和非合作伙伴,合伙伙伴比較好說了,他們可以提供API接口,這部分的機票信息肯定是實時的。另一種是非合作伙伴,這些網(wǎng)站應(yīng)該有一個緩存策略,根據(jù)去哪兒以往去這些網(wǎng)站抓取的數(shù)據(jù)分析他們機票的更新速度來確定緩存失效時間。去哪兒有一個爬蟲根據(jù)更新策略把數(shù)據(jù)抓到緩存中,這樣用戶在請求的時候,實際上是在讀這個緩存(生成JSON數(shù)據(jù))。不知道去哪兒現(xiàn)在是不是這樣的方法呢?
網(wǎng)站技術(shù)分析報告之——去哪兒,希望對您有用。