當互聯(lián)網(wǎng)吵吵嚷嚷的進入2.0時代，當互聯(lián)網(wǎng)的技術(shù)不再是那么高不可攀，當復制變成家常便飯，互聯(lián)網(wǎng)熱鬧起來了

myspace火了，中國冒出更多的myspace
youtube剛剛起來，中國的視頻網(wǎng)站就遍地開花
51拔地而起，中國出了無數(shù)的sns
facebook則改變了中國站長的抄襲方式，不再學chianren了，校內(nèi)火了

當抄襲變成習慣，我想說的是，模仿，站長，你準備好了嗎？

如果你打算做垃圾站，或者賺點廣告費的網(wǎng)站，請不要點擊這篇文章，我從技術(shù)角度方面談談web2.0網(wǎng)站的模仿問題。

當投資和流量都不是問題的時候，我想說的是，您真的一帆風順嗎？

拿sns網(wǎng)站來說，當匆匆上線的2.0，當一筆筆投資砸進去的時候，當流量上去的時候，您的困惑在什么地方？

我做過多個2.0公司的技術(shù)顧問，簡單的談談2.0公司遇到的問題(涉及隱私，我用a b c d代替)，這里就不再贅述大家眾所周知的頁面靜態(tài)化，緩存和代碼安全等問題了，有點技術(shù)的2.0公司的cto都知道這些東西，我們談點發(fā)展之后的問題

a公司

a公司做的是sns網(wǎng)站，程序是兩個毛頭小伙子做的，目標直指51，程序開發(fā)是一帆風順，功能也比51牛多了，推廣也是一帆風順（a公司有自己獨到的推廣方式。但是當alexa到2w的時候問題出來了，每天下午4點左右，網(wǎng)站速度慢的驚人，基本上打不開，公司三臺服務器cpu100%，讓人郁悶的是公司的網(wǎng)絡配置方式，居然是雙web的集群，而單獨一臺db數(shù)據(jù)庫。整個瓶頸在數(shù)據(jù)庫，于是我建議做db的集群，分析了一下數(shù)據(jù)結(jié)構(gòu)，md，典型的web程序員的作品，沒有一點數(shù)據(jù)庫設計規(guī)范，功能實現(xiàn)是可以，如果要擴展，不可能，集群基本上是不可能的，怎么辦？不能辦，于是，一個月的時間修改程序，數(shù)據(jù)結(jié)構(gòu)基本上換了一遍 前期砸進去的幾十萬打了水飄，用戶走光了。

結(jié)論：web2.0前期設計的時候不應該只考慮功能，應該認真考慮一下底層和數(shù)據(jù)結(jié)構(gòu)了。

b公司

b公司也是做的sns網(wǎng)站，程序是3個人開發(fā)的，ceo是某名牌大學的經(jīng)濟學碩士，有點知己網(wǎng)的味道，又有一些特色出來，說實話，公司的潛力不錯，ceo有很強的運作能力，感覺前景不錯。系統(tǒng)架構(gòu)還行，但是---但是系統(tǒng)崩潰了，why?系統(tǒng)沒有考慮到用戶有個海量的說法，文件也有個海量的說法，用戶的相冊，圖片全部存貯在web服務器的一個分區(qū)上，每個用戶一個目錄，而打開性能監(jiān)視器，磁盤的io高的驚人，基本上無暇響應。眾所周知，文件系統(tǒng)也是一個數(shù)據(jù)庫，單獨大文件無所謂，關鍵是整個是300多個g的零碎文件，大量的讀寫操作，系統(tǒng)崩潰，數(shù)據(jù)丟失，文件系統(tǒng)的一個鏈斷了，用戶數(shù)據(jù)全部丟失！！！這是一個非常沉重的問題，系統(tǒng)整整停了一個月來做數(shù)據(jù)恢復（單獨文件很容易，但是海量文件目前還沒有一個軟件能組織起來軟件架構(gòu)）。解決方案：修改程序架構(gòu)，做分布式文件存貯（程序修改用了8天，但是文件轉(zhuǎn)移卻又用去了將近一個月），20萬用戶損失殆盡

結(jié)論：web2.0前期的設計應該有應付海量存貯的考慮，整個涉及了程序架構(gòu)的修改，前期規(guī)劃不好的話基本上思路一條。

c公司

c公司是一個值得尊敬的公司，ceo技術(shù)出身，和比爾蓋茨一樣，大學未畢業(yè)出來做網(wǎng)絡，01到03年做短信狠賺了一筆，后來做的小項目也小有所成，說實話，我很佩服。公司做的是校友方面，但是更偏重myspace風格，注重個人主頁，推廣方面也下了大手筆。系統(tǒng)崩潰的原因其實很簡單，由于采用的是微軟的sqlserver，而微軟直接就告訴了我們，sqlserver不支持集群，他們的數(shù)據(jù)庫超負載，100%就沒有下去過，只能橫向增加配置，采用了4路4核cpu系統(tǒng)，但是系統(tǒng)還是崩潰了... 高互動注定了高負載。解決方案： 現(xiàn)從基本入手，解決掉幾個程序耗能大戶，對數(shù)據(jù)庫采用橫向切割，將用戶每10萬進行分組，同時對數(shù)據(jù)庫系統(tǒng)進行散列，將多個表垂直分割，同時進行文件分組 ，解決問題. 因為修改了數(shù)據(jù)結(jié)構(gòu)，程序也基本上大動了一下。 好在系統(tǒng)沒有出大錯，損失不算很大，不過對用戶體驗造成了很壞的影響。

結(jié)論：web2.0前期設計應該有良好的散列考慮，程序應該能有配合的擴充性，符合數(shù)據(jù)庫的擴充

d公司

d公司是一個各個方面做的比較好的公司，做了cdn加速，圖片也獨立分出了n個服務器，數(shù)據(jù)庫不錯的一個，(cto是個數(shù)據(jù)庫專家），系統(tǒng)崩潰的原因在于web，按道理說web很容易做集群的，但是發(fā)現(xiàn)集群并解決不掉問題，他們的集群只允許做4臺的web集群，但是4臺都當?shù)袅恕Ｗ屑毞治觯业皆颍夜烙嬚麄€也是大部分cto最容易犯的一個錯誤，或者說他們根本就想不到的問題，就是web上傳的問題，上傳的時候由于時間的原因，線程是保持鏈接的，300個線程就可以把一個web server當?shù)袅恕＝鉀Q方案：這個最簡單，把上傳和其他耗能大戶分離出獨立出來。程序改動不是很大，但是之前半個月速度滿對用戶體驗的損失也不可小視。

結(jié)論：沒有什么結(jié)論了，畢竟有海量訪問經(jīng)驗的cto不多，也就是那幾個大站的。

|||

總結(jié)：

不是潑冷水，模仿其實是很容易的，隨便找?guī)讉€web程序員就能做到，并且很簡單，速度可能還很高效，因為web2.0無非就是跟數(shù)據(jù)庫打交道，會操作數(shù)據(jù)庫就會做。但是真正做大并不容易，因為能應付海量訪問的程序并不簡單，現(xiàn)在的程序員都太自命不凡，其實真正有經(jīng)驗的并不多，不要相信一個月薪5k--10k的程序員能給你多大的驚喜，能應付海量訪問的程序員不是那個價格。如果您想做2.0，想做大，有幾個個建議：

一. 找dbms的專家設計好數(shù)據(jù)庫，大部分程序員都不知道分區(qū)視圖，數(shù)據(jù)散列，數(shù)據(jù)組的概念

二. 設計好程序架構(gòu)（這個其實不難，有個高人指導就行了），保持良好的擴展性，成本考慮可以找兼職的系統(tǒng)架構(gòu)設計師做好系統(tǒng)架構(gòu)，確定將來的發(fā)展瓶頸。

三. 考慮好文件存貯的問題。文件存貯的技術(shù)含量看起來很低，其實是很高的，可以考慮反向代理的方案。文件存貯出問題了，站點基本上就完蛋了，不僅僅是raid的問題和存貯服務器的問題，不過道理倒是一點就破的

四. 中國國情考慮，這個最致命，需要考慮電信和網(wǎng)通的問題，cdn并不能解決所有問題。互動性的東西并cdn并不是很有效。最關鍵的是，現(xiàn)有的雙線機房遇到ddos攻擊基本上都會當?shù)簦蚝芎唵危p線機房都是私人機房，本身就不會有太高的帶寬，隨便攻擊一下就可以d掉（順帶提一個笑話，我知道一個雙線機房的老總總共1g的帶寬卻買了4g的金盾墻，很簡單800m的攻擊就可以搞定）。

五. 網(wǎng)絡延遲的問題，這是分布式系統(tǒng)必須要考慮的，程序要能容忍0到100秒的數(shù)據(jù)延遲的功能，也就是同步的問題。不要小看這幾十秒，問題很大的，如果你的站點有交互式功能，比如即時聊天，你可以想象一下是個什么結(jié)果。對于即時聊天的東西，可以用反向代理來解決（成本較高）。但是對于留言和評論的影響不大，但是如果系統(tǒng)為了健壯做了緩存和靜態(tài)化的時候，這個東西可能就是災難性的了。

六. 分散你的程序，如果你沒有太多的資金構(gòu)筑動輒百萬的服務器，建議把功能分散開來，比如相冊一臺服務器，留言一臺服務器

七. 看好你的程序員，如果沒有很好的激勵措施的話你的程序員很容易寫出敷衍性的代碼，而這個可能就是將來的大患，程序架構(gòu)定下來后要修改可能就要費牛勁了。最好你的cto能對你100%的衷心，100%的負責。

八. 文件同步的問題，這個問題可能你覺得沒有必要，如果你看一下網(wǎng)通和電信的ttl就明白了，同步要支持續(xù)傳，并且不能是持續(xù)的，否則你的成本會高出n倍，不要期望能通過你的軟件實現(xiàn)，交給你的程序員吧，把上面的話告訴他他就知道怎么做了。

九. 最狠的一個問題了，也是吃虧最大的問題，不管您跟網(wǎng)警的關系多好，看好你的用戶，審核好你的東西，一被停機可能就致命，本人就吃過n次虧。

十. 最后，祝各位站長一番風順，大展宏圖。