|
|
7大型網(wǎng)站架構(gòu)不得不考慮的10個(gè)問(wèn)題--專業(yè)網(wǎng)站建設(shè)機(jī)構(gòu)
- 發(fā)布日期:2010-08-17 10:06
- 有效期至:長(zhǎng)期有效
- 瀏覽次數(shù):48
- 如果您對(duì) “ 7大型網(wǎng)站架構(gòu)不得不考慮的10個(gè)問(wèn)題--專業(yè)網(wǎng)站建設(shè)機(jī)構(gòu) ” 這個(gè)招商項(xiàng)目感興趣,您可以留言咨詢,或者直接撥打右側(cè)的聯(lián)系電話。
|
這里的大型網(wǎng)站架構(gòu)只包括高互動(dòng)性高交互性的數(shù)據(jù)型大型網(wǎng)站,基于大家眾所周知的原因,我們就不談新聞?lì)惡鸵恍┮揽縃TML靜態(tài)化就可以實(shí)現(xiàn)的架構(gòu)了,我們以高負(fù)載高數(shù)據(jù)交換高數(shù)據(jù)流動(dòng)性的網(wǎng)站為例,比如海內(nèi),開(kāi)心網(wǎng)等類似的web2.0系列架構(gòu)。我們這里不討論是PHP還是JSP或者.NET環(huán)境,我們從架構(gòu)的方面去看問(wèn)題,實(shí)現(xiàn)語(yǔ)言方面并不是問(wèn)題,語(yǔ)言的優(yōu)勢(shì)在于實(shí)現(xiàn)而不是好壞,不論你選擇任何語(yǔ)言,架構(gòu)都是必須要面對(duì)的。 這里討論一下大型網(wǎng)站需要注意和考慮的問(wèn)題 1、海量數(shù)據(jù)的處理 眾所周知,對(duì)于一些相對(duì)小的站點(diǎn)來(lái)說(shuō),數(shù)據(jù)量并不是很大,select和update就可以解決我們面對(duì)的問(wèn)題,本身負(fù)載量不是很大,最多再加幾個(gè)索引就可以搞定。對(duì)于大型網(wǎng)站,每天的數(shù)據(jù)量可能就上百萬(wàn),如果一個(gè)設(shè)計(jì)不好的多對(duì)多關(guān)系,在前期是沒(méi)有任何問(wèn)題的,但是隨著用戶的增長(zhǎng),數(shù)據(jù)量會(huì)是幾何級(jí)的增長(zhǎng)的。在這個(gè)時(shí)候我們對(duì)于一個(gè)表的select和update的時(shí)候(還不說(shuō)多表聯(lián)合查詢)的成本的非常高的。 2、數(shù)據(jù)并發(fā)的處理 在一些時(shí)候,2.0的CTO都有個(gè)尚方寶劍,就是緩存。對(duì)于緩存,在高并發(fā)高處理的時(shí)候也是個(gè)大問(wèn)題。在整個(gè)應(yīng)用程序下,緩存是全局共享的,然而在我們進(jìn)行修改的時(shí)候就,如果兩個(gè)或者多個(gè)請(qǐng)求同時(shí)對(duì)緩存有更新的要求的情況下,應(yīng)用程序會(huì)直接的死掉。這個(gè)時(shí)候,就需要一個(gè)好的數(shù)據(jù)并發(fā)處理策略以及緩存策略。 另外,就是數(shù)據(jù)庫(kù)的死鎖問(wèn)題,也許平時(shí)我們感覺(jué)不到,死鎖在高并發(fā)的情況下的出現(xiàn)的概率是非常高的,磁盤緩存就是一個(gè)大問(wèn)題。 3、文件存貯的問(wèn)題 對(duì)于一些支持文件上傳的2.0的站點(diǎn),在慶幸硬盤容量越來(lái)越大的時(shí)候我們更多的應(yīng)該考慮的是文件應(yīng)該如何被存儲(chǔ)并且被有效的索引。常見(jiàn)的方案是對(duì)文件按照日期和類型進(jìn)行存貯。但是當(dāng)文件量是海量的數(shù)據(jù)的情況下,如果一塊硬盤存貯了500個(gè)G的瑣碎文件,那么維護(hù)的時(shí)候和使用的時(shí)候磁盤的Io就是一個(gè)巨大的問(wèn)題,哪怕你的帶寬足夠,但是你的磁盤也未必響應(yīng)過(guò)來(lái)。如果這個(gè)時(shí)候還涉及上傳,磁盤很容易就over了。 也許用raid和專用存貯服務(wù)器能解決眼下的問(wèn)題,但是還有個(gè)問(wèn)題就是各地的訪問(wèn)問(wèn)題,也許我們的服務(wù)器在北京,可能在云南或者新疆的訪問(wèn)速度如何解決?如果做分布式,那么我們的文件索引以及架構(gòu)該如何規(guī)劃。 所以我們不得不承認(rèn),文件存貯是個(gè)很不容易的問(wèn)題 4、數(shù)據(jù)關(guān)系的處理 我們可以很容易的規(guī)劃出一個(gè)符合第三范式的數(shù)據(jù)庫(kù),里面布滿了多對(duì)多關(guān)系,還能用GUID來(lái)替換INDENTIFYCOLUMN但是,多對(duì)多關(guān)系充斥的2.0時(shí)代,第三范式是第一個(gè)應(yīng)該被拋棄的。必須有效的把多表聯(lián)合查詢降到最低。 5、數(shù)據(jù)索引的問(wèn)題 眾所周知,索引是提高數(shù)據(jù)庫(kù)效率查詢的最方面最廉價(jià)最容易實(shí)現(xiàn)的方案。但是,在高UPDATE的情況下,update和delete付出的成本會(huì)高的無(wú)法想想,筆者遇到過(guò)一個(gè)情況,在更新一個(gè)聚焦索引的時(shí)候需要10分鐘來(lái)完成,那么對(duì)于站點(diǎn)來(lái)說(shuō),這些基本上是不可忍受的。 索引和更新是一對(duì)天生的冤家,問(wèn)題A,D,E這些是我們?cè)谧黾軜?gòu)的時(shí)候不得不考慮的問(wèn)題,并且也可能是花費(fèi)時(shí)間最多的問(wèn)題, 6、分布式處理 對(duì)于2.0網(wǎng)站由于其高互動(dòng)性,CDN實(shí)現(xiàn)的效果基本上為0,內(nèi)容是實(shí)時(shí)更新的,我們常規(guī)的處理。為了保證各地的訪問(wèn)速度,我們就需要面對(duì)一個(gè)絕大的問(wèn)題,就是如何有效的實(shí)現(xiàn)數(shù)據(jù)同步和更新,實(shí)現(xiàn)各地服務(wù)器的實(shí)時(shí)通訊有是一個(gè)不得不需要考慮的問(wèn)題。 7、Ajax的利弊分析 成也AJAX,敗也AJAX,AJAX成為了主流趨勢(shì),突然發(fā)現(xiàn)基于XMLHTTP的post和get是如此的容易??蛻舳薵et或者post到服務(wù)器數(shù)據(jù),服務(wù)器接到數(shù)據(jù)請(qǐng)求之后返回來(lái),這是一個(gè)很正常的AJAX請(qǐng)求。但是在AJAX處理的時(shí)候,如果我們使用一個(gè)抓包工具的話,對(duì)數(shù)據(jù)返回和處理是一目了然。對(duì)于一些計(jì)算量大的AJAX請(qǐng)求的話,我們可以構(gòu)造一個(gè)發(fā)包機(jī),很容易就可以把一個(gè)webserver干掉。 8、數(shù)據(jù)安全性的分析 對(duì)于HTTP協(xié)議來(lái)說(shuō),數(shù)據(jù)包都是明文傳輸?shù)?,也許我們可以說(shuō)我們可以用加密啊,但是對(duì)于G問(wèn)題來(lái)說(shuō)的話,加密的過(guò)程就可能是明文了(比如我們知道的QQ,可以很容易的判斷他的加密,并有效的寫一個(gè)跟他一樣的加密和解密方法出來(lái)的)。當(dāng)你站點(diǎn)流量不是很大的時(shí)候沒(méi)有人會(huì)在乎你,但是當(dāng)你流量上來(lái)之后,那么所謂的外掛,所謂的群發(fā)就會(huì)接踵而來(lái)(從qq一開(kāi)始的群發(fā)可見(jiàn)端倪)。也許我們可以很的意的說(shuō),我們可以采用更高級(jí)別的判斷甚至HTTPS來(lái)實(shí)現(xiàn),注意,當(dāng)你做這些處理的時(shí)候付出的將是海量的database,io以及CPU的成本。對(duì)于一些群發(fā),基本上是不可能的。筆者已經(jīng)可以實(shí)現(xiàn)對(duì)于百度空間和qq空間的群發(fā)了。大家愿意試試,實(shí)際上并不是很難。 9、數(shù)據(jù)同步和集群的處理的問(wèn)題 當(dāng)我們的一臺(tái)databaseserver不堪重負(fù)的時(shí)候,這個(gè)時(shí)候我們就需要做基于數(shù)據(jù)庫(kù)的負(fù)載和集群了。而這個(gè)時(shí)候可能是最讓人困擾的的問(wèn)題了,數(shù)據(jù)基于網(wǎng)絡(luò)傳輸根據(jù)數(shù)據(jù)庫(kù)的設(shè)計(jì)的不同,數(shù)據(jù)延遲是很可怕的問(wèn)題,也是不可避免的問(wèn)題,這樣的話,我們就需要通過(guò)另外的手段來(lái)保證在這延遲的幾秒或者更長(zhǎng)的幾分鐘時(shí)間內(nèi),實(shí)現(xiàn)有效的交互。比如數(shù)據(jù)散列,分割,內(nèi)容處理等等問(wèn)題 10、數(shù)據(jù)共享的渠道以及OPENAPI趨勢(shì) Openapi已經(jīng)成為一個(gè)不可避免的趨勢(shì),從google,facebook,myspace到海內(nèi)校內(nèi),都在考慮這個(gè)問(wèn)題,它可以更有效的留住用戶并激發(fā)用戶的更多的興趣以及讓更多的人幫助你做最有效的開(kāi)發(fā)。這個(gè)時(shí)候一個(gè)有效的數(shù)據(jù)共享平臺(tái),數(shù)據(jù)開(kāi)放平臺(tái)就成為必不可少的途徑了,而在開(kāi)放的接口的情況保證數(shù)據(jù)的安全性和性能,又是一個(gè)我們必須要認(rèn)真思考的問(wèn)題了。