我做過(guò)多個(gè)2.0公司的技術(shù)顧問(wèn)，簡(jiǎn)單的談?wù)?.0公司遇到的問(wèn)題(涉及隱私，我用A B C D代替)，這里就不再贅述大家眾所周知的頁(yè)面靜態(tài)化，緩存和代碼安全等問(wèn)題了，有點(diǎn)技術(shù)的2.0公司的CTO都知道這些東西，我們談點(diǎn)發(fā)展之后的問(wèn)題
A公司
A公司做的是SNS網(wǎng)站，程序是兩個(gè)毛頭小伙子做的，目標(biāo)直指51，程序開(kāi)發(fā)是一帆風(fēng)順，功能也比51牛多了，推廣也是一帆風(fēng)順（A公司有自己獨(dú)到的推廣方式。但是當(dāng)ALEXA到2W的時(shí)候問(wèn)題出來(lái)了，每天下午4點(diǎn)左右，網(wǎng)站速度慢的驚人，基本上打不開(kāi)，公司三臺(tái)服務(wù)器CPU100%，讓人郁悶的是公司的網(wǎng)絡(luò)配置方式，居然是雙WEB的集群，而單獨(dú)一臺(tái)DB數(shù)據(jù)庫(kù)。整個(gè)瓶頸在數(shù)據(jù)庫(kù)，于是我建議做DB的集群，分析了一下數(shù)據(jù)結(jié)構(gòu)，MD，典型的WEB程序員的作品，沒(méi)有一點(diǎn)數(shù)據(jù)庫(kù)設(shè)計(jì)規(guī)范，功能實(shí)現(xiàn)是可以，如果要擴(kuò)展，不可能，集群基本上是不可能的，怎么辦？不能辦，于是，一個(gè)月的時(shí)間修改程序，數(shù)據(jù)結(jié)構(gòu)基本上換了一遍 前期砸進(jìn)去的幾十萬(wàn)打了水飄，用戶走光了。
結(jié)論：WEB2.0前期設(shè)計(jì)的時(shí)候不應(yīng)該只考慮功能，應(yīng)該認(rèn)真考慮一下底層和數(shù)據(jù)結(jié)構(gòu)了。
B公司
B公司也是做的SNS網(wǎng)站，程序是3個(gè)人開(kāi)發(fā)的，CEO是某名牌大學(xué)的經(jīng)濟(jì)學(xué)碩士，有點(diǎn)知己網(wǎng)的味道，又有一些特色出來(lái)，說(shuō)實(shí)話，公司的潛力不錯(cuò)，CEO 有很強(qiáng)的運(yùn)作能力，感覺(jué)前景不錯(cuò)。系統(tǒng)架構(gòu)還行，但是---但是系統(tǒng)崩潰了，why?系統(tǒng)沒(méi)有考慮到用戶有個(gè)海量的說(shuō)法，文件也有個(gè)海量的說(shuō)法，用戶的相冊(cè)，圖片全部存貯在WEB服務(wù)器的一個(gè)分區(qū)上，每個(gè)用戶一個(gè)目錄，而打開(kāi)性能監(jiān)視器，磁盤(pán)的IO高的驚人，基本上無(wú)暇響應(yīng)。眾所周知，文件系統(tǒng)也是一個(gè)數(shù)據(jù)庫(kù)，單獨(dú)大文件無(wú)所謂，關(guān)鍵是整個(gè)是300多個(gè)G的零碎文件，大量的讀寫(xiě)操作，系統(tǒng)崩潰，數(shù)據(jù)丟失，文件系統(tǒng)的一個(gè)鏈斷了，用戶數(shù)據(jù)全部丟失。！這是一個(gè)非常沉重的問(wèn)題，系統(tǒng)整整停了一個(gè)月來(lái)做數(shù)據(jù)恢復(fù)（單獨(dú)文件很容易，但是海量文件目前還沒(méi)有一個(gè)軟件能組織起來(lái)軟件架構(gòu)）。解決方案：修改程序架構(gòu)，做分布式文件存貯（程序修改用了8天，但是文件轉(zhuǎn)移卻又用去了將近一個(gè)月），20萬(wàn)用戶損失殆盡
結(jié)論：WEB2.0前期的設(shè)計(jì)應(yīng)該有應(yīng)付海量存貯的考慮，整個(gè)涉及了程序架構(gòu)的修改，前期規(guī)劃不好的話基本上思路一條。
C公司
C公司是一個(gè)值得尊敬的公司，CEO技術(shù)出身，和比爾蓋茨一樣，大學(xué)未畢業(yè)出來(lái)做網(wǎng)絡(luò)，01到03年做短信狠賺了一筆，后來(lái)做的小項(xiàng)目也小有所成，說(shuō)實(shí)話，我很佩服。公司做的是校友方面，但是更偏重myspace風(fēng)格，注重個(gè)人主頁(yè)，推廣方面也下了大手筆。系統(tǒng)崩潰的原因其實(shí)很簡(jiǎn)單，由于采用的是微軟的 SqlServer，而微軟直接就告訴了我們，SQLSERVER不支持集群，他們的數(shù)據(jù)庫(kù)超負(fù)載，100%就沒(méi)有下去過(guò)，只能橫向增加配置，采用了4路 4核CPU系統(tǒng)，但是系統(tǒng)還是崩潰了... 高互動(dòng)注定了高負(fù)載。解決方案：現(xiàn)從基本入手，解決掉幾個(gè)程序耗能大戶，對(duì)數(shù)據(jù)庫(kù)采用橫向切割，將用戶每10萬(wàn)進(jìn)行分組，同時(shí)對(duì)數(shù)據(jù)庫(kù)系統(tǒng)進(jìn)行散列，將多個(gè)表垂直分割，同時(shí)進(jìn)行文件分組，解決問(wèn)題. 因?yàn)樾薷牧藬?shù)據(jù)結(jié)構(gòu)，程序也基本上大動(dòng)了一下。 好在系統(tǒng)沒(méi)有出大錯(cuò)，損失不算很大，不過(guò)對(duì)用戶體驗(yàn)造成了很壞的影響。
結(jié)論：WEB2.0前期設(shè)計(jì)應(yīng)該有良好的散列考慮，程序應(yīng)該能有配合的擴(kuò)充性，符合數(shù)據(jù)庫(kù)的擴(kuò)充
D公司
D公司是一個(gè)各個(gè)方面做的比較好的公司，做了CDN加速，圖片也獨(dú)立分出了N個(gè)服務(wù)器，數(shù)據(jù)庫(kù)不錯(cuò)的一個(gè)，(CTO是個(gè)數(shù)據(jù)庫(kù)專家），系統(tǒng)崩潰的原因在于 WEB，按道理說(shuō)WEB很容易做集群的，但是發(fā)現(xiàn)集群并解決不掉問(wèn)題，他們的集群只允許做4臺(tái)的WEB集群，但是4臺(tái)都當(dāng)?shù)袅恕Ｗ屑?xì)分析，找到原因，我估計(jì)整個(gè)也是大部分CTO最容易犯的一個(gè)錯(cuò)誤，或者說(shuō)他們根本就想不到的問(wèn)題，就是WEB上傳的問(wèn)題，上傳的時(shí)候由于時(shí)間的原因，線程是保持鏈接的，300 個(gè)線程就可以把一個(gè)WEB Server當(dāng)?shù)袅。解決方案：這個(gè)最簡(jiǎn)單，把上傳和其他耗能大戶分離出獨(dú)立出來(lái)。程序改動(dòng)不是很大，但是之前半個(gè)月速度滿對(duì)用戶體驗(yàn)的損失也不可小視。
結(jié)論：沒(méi)有什么結(jié)論了，畢竟有海量訪問(wèn)經(jīng)驗(yàn)的CTO不多，也就是那幾個(gè)大站的。
總結(jié)：不是潑冷水，模仿其實(shí)是很容易的，隨便找?guī)讉(gè)WEB程序員就能做到，并且很簡(jiǎn)單，速度可能還很高效，因?yàn)閃EB2.0無(wú)非就是跟數(shù)據(jù)庫(kù)打交道，會(huì)操作數(shù)據(jù)庫(kù)就會(huì)做。但是真正做大并不容易，因?yàn)槟軕?yīng)付海量訪問(wèn)的程序并不簡(jiǎn)單，現(xiàn)在的程序員都太自命不凡，其實(shí)真正有經(jīng)驗(yàn)的并不多，不要相信一個(gè)月薪5K- -10K的程序員能給你多大的驚喜，能應(yīng)付海量訪問(wèn)的程序員不是那個(gè)價(jià)格。如果您想做2.0，想做大，有幾個(gè)個(gè)建議：
一.找DBMS的專家設(shè)計(jì)好數(shù)據(jù)庫(kù)，大部分程序員都不知道分區(qū)視圖，數(shù)據(jù)散列，數(shù)據(jù)組的概念
二.設(shè)計(jì)好程序架構(gòu)（這個(gè)其實(shí)不難，有個(gè)高人指導(dǎo)就行了），保持良好的擴(kuò)展性，成本考慮可以找兼職的系統(tǒng)架構(gòu)設(shè)計(jì)師做好系統(tǒng)架構(gòu)，確定將來(lái)的發(fā)展瓶頸。
三.考慮好文件存貯的問(wèn)題。文件存貯的技術(shù)含量看起來(lái)很低，其實(shí)是很高的，可以考慮反向代理的方案。文件存貯出問(wèn)題了，站點(diǎn)基本上就完蛋了，不僅僅是RAID的問(wèn)題和存貯服務(wù)器的問(wèn)題，不過(guò)道理倒是一點(diǎn)就破的
四.中國(guó)國(guó)情考慮，這個(gè)最致命，需要考慮電信和網(wǎng)通的問(wèn)題，CDN并不能解決所有問(wèn)題；(dòng)性的東西并CDN并不是很有效。最關(guān)鍵的是，現(xiàn)有的雙線機(jī)房遇到DDOS攻擊基本上都會(huì)當(dāng)?shù)，原因很?jiǎn)單，雙線機(jī)房都是私人機(jī)房，本身就不會(huì)有太高的帶寬，隨便攻擊一下就可以D掉（順帶提一個(gè)笑話，我知道一個(gè)雙線機(jī)房的老總總共1G的帶寬卻買(mǎi)了4G的金盾墻，很簡(jiǎn)單800M的攻擊就可以搞定）。
五.網(wǎng)絡(luò)延遲的問(wèn)題，這是分布式系統(tǒng)必須要考慮的，程序要能容忍0到100秒的數(shù)據(jù)延遲的功能，也就是同步的問(wèn)題。不要小看這幾十秒，問(wèn)題很大的，如果你的站點(diǎn)有交互式功能，比如即時(shí)聊天，你可以想象一下是個(gè)什么結(jié)果。對(duì)于即時(shí)聊天的東西，可以用反向代理來(lái)解決（成本較高）。但是對(duì)于留言和評(píng)論的影響不大，但是如果系統(tǒng)為了健壯做了緩存和靜態(tài)化的時(shí)候，這個(gè)東西可能就是災(zāi)難性的了。
六.分散你的程序，如果你沒(méi)有太多的資金構(gòu)筑動(dòng)輒百萬(wàn)的服務(wù)器，建議把功能分散開(kāi)來(lái)，比如相冊(cè)一臺(tái)服務(wù)器，留言一臺(tái)服務(wù)器
七.看好你的程序員，如果沒(méi)有很好的激勵(lì)措施的話你的程序員很容易寫(xiě)出敷衍性的代碼，而這個(gè)可能就是將來(lái)的大患，程序架構(gòu)定下來(lái)后要修改可能就要費(fèi)牛勁了。最好你的CTO能對(duì)你100%的衷心，100%的負(fù)責(zé)。
八.文件同步的問(wèn)題，這個(gè)問(wèn)題可能你覺(jué)得沒(méi)有必要，如果你看一下網(wǎng)通和電信的TTL就明白了，同步要支持續(xù)傳，并且不能是持續(xù)的，否則你的成本會(huì)高出N倍，不要期望能通過(guò)你的軟件實(shí)現(xiàn)，交給你的程序員吧，把上面的話告訴他他就知道怎么做了。
九.最狠的一個(gè)問(wèn)題了，也是吃虧最大的問(wèn)題，不管您跟網(wǎng)警的關(guān)系多好，看好你的用戶，審核好你的東西，一被停機(jī)可能就致命，本人就吃過(guò)N次虧。
十.最后，祝各位站長(zhǎng)一番風(fēng)順，大展宏圖。（轉(zhuǎn)載）
[此貼子已經(jīng)被EnjoyIT于2007-12-7 14:35:22編輯過(guò)]
加好友 
發(fā)短信
Post By：2007/12/6 21:04:03
