好文轉載：寫給WEB2.0的站長不僅僅是潑冷水

　　好文原始轉載來源： 站長網(www.admin5.com) （簡體中文網頁）；消息來源： Luar's Flash Playground---[收藏] 給WEB2.0站長的提醒文章 。消息來源的 Luar 大神雖然是繁中頁面（自動判斷語言造成的），但是沒有全文轉載；原始轉載來源則是簡中撰寫的，筆者（阿知足）一字未改的轉換成繁體中文後，才全文轉載過來。希望看原文的網友請點選「站長網」的來源。

＝＝＝＝轉文開始＝＝＝＝
寫給WEB2.0的站長不僅僅是潑冷水

　　當互聯網吵吵嚷嚷的進入2.0時代，當互聯網的技術不再是那麼高不可攀，當複制變成家常便飯，互聯網熱鬧起來了

　　myspace火了，中國冒出更多的myspace

　　youtube剛剛起來，中國的視頻網站就遍地開花

　　51拔地而起，中國出了無數的SNS

　　facebook則改變了中國站長的抄襲方式，不再學chianren了，校內火了
　　..........

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

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

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

　　拿SNS網站來說，當匆匆上線的2.0，當一筆筆投資砸進去的時候，當流量上去的時候，您的困惑在什麼地方？

　　我做過多個2.0公司的技術顧問，簡單的談談2.0公司遇到的問題(涉及隱私，我用A B C D代替)，這裡就不再贅述大家眾所周知的頁面靜態化，緩存和代碼安全等問題了，有點技術的2.0公司的CTO都知道這些東西，我們談點發展之後的問題

A公司

　　A公司做的是SNS網站，程序是兩個毛頭小伙子做的，目標直指51，程序開發是一帆風順，功能也比51牛多了，推廣也是一帆風順（A公司有自己獨到的推廣方式。但是當ALEXA到2W的時候問題出來了，每天下午4點左右，網站速度慢的驚人，基本上打不開，公司三台服務器CPU100%，讓人鬱悶的是公司的網絡配置方式，居然是雙WEB的集群，而單獨一台DB數據庫。整個瓶頸在數據庫，於是我建議做DB的集群，分析了一下數據結構，MD，典型的WEB程序員的作品，沒有一點數據庫設計規範，功能實現是可以，如果要擴展，不可能，集群基本上是不可能的，怎麼辦？不能辦，於是，一個月的時間修改程序，數據結構基本上換了一遍前期砸進去的幾十萬打了水飄，用戶走光了。

　　結論：WEB2.0前期設計的時候不應該只考慮功能，應該認真考慮一下底層和數據結構了。

B公司

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

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

C公司

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

　　結論：WEB2.0前期設計應該有良好的散列考慮，程序應該能有配合的擴充性，符合數據庫的擴充

D公司

　　D公司是一個各個方面做的比較好的公司，做了CDN加速，圖片也獨立分出了N個服務器，數據庫不錯的一個，(CTO是個數據庫專家），系統崩潰的原因在於WEB，按道理說WEB很容易做集群的，但是發現集群並解決不掉問題，他們的集群只允許做4台的WEB集群，但是4台都當掉了。仔細分析，找到原因，我估計整個也是大部分CTO最容易犯的一個錯誤，或者說他們根本就想不到的問題，就是WEB上傳的問題，上傳的時候由於時間的原因，線程是保持鏈接的，300個線程就可以把一個WEB Server當掉了。解決方案：這個最簡單，把上傳和其他耗能大戶分離出獨立出來。程序改動不是很大，但是之前半個月速度滿對用戶體驗的損失也不可小視。

　　結論：沒有什麼結論了，畢竟有海量訪問經驗的CTO不多，也就是那幾個大站的。

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

　　一.找DBMS的專家設計好數據庫，大部分程序員都不知道分區視圖，數據散列，數據組的概念

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

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

　　四.中國國情考慮，這個最致命，需要考慮電信和網通的問題，CDN並不能解決所有問題。互動性的東西並CDN並不是很有效。最關鍵的是，現有的雙線機房遇到DDOS攻擊基本上都會當掉，原因很簡單，雙線機房都是私人機房，本身就不會有太高的帶寬，隨便攻擊一下就可以D掉（順帶提一個笑話，我知道一個雙線機房的老總總共1G的帶寬卻買了4G的金盾牆，很簡單800M的攻擊就可以搞定）。

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

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

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

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

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

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

責任編輯:稻草QQ:449156

＝＝＝＝轉文結束＝＝＝＝

　　雖然這篇文章沒有深談技術面該如何操作，只提到大約如何架構，不過還是能提供網站管理人、網站開發者一些啟發。台灣因為言論自由，「架站」不受任何限制，不論是公開網站、地下網站……不勝枚舉，只是，架一個網站很簡單，管理一個網站可就沒這麼容易了。 WEB 2.0 的精神在「上傳、分享」及伴隨而來的「充份客製化」，一個流量大的網站要能夠處理這麼大量的資料還能有餘力去處理使用者的各項需求，資訊系統的架構務必經過深思熟慮，才能因應所有的操作，不論是資料庫、網站、應用程式……或是以功能分散在不同機器。

　　※本文已在第一段明示轉文來源，僅於轉文前經過一次轉碼（GB->BIG5），原始文章著作權仍歸原著作者－－稻草－－所有，轉碼僅為本站網友方便閱讀，若有任何侵犯著作問題，請來信／留言告知站長以刪除轉碼後的轉錄文章。

keyword:WEB2.0, 前期規畫, 海量存貯, 分散管理, 站長網, 稻草, 轉錄文章