jeffy

當互聯網吵吵嚷嚷的進入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次虧。

一個小型的網站，比如個人網站，可以使用最簡單的html靜態頁面就實現了，配合一些圖片達到美化效果，所有的頁面均存放在一個目錄下，這樣的網站對系統架構、性能的要求都很簡單，隨著互聯網業務的不斷豐富，網站相關的技術經過這些年的發展，已經細分到很細的方方面面，尤其對于大型網站來說，所采用的技術更是涉及面非常廣，從硬件到軟件、編程語言、數據庫、WebServer、防火墻等各個領域都有了很高的要求，已經不是原來簡單的html靜態網站所能比擬的。

大型網站，比如門戶網站。在面對大量用戶訪問、高并發請求方面，基本的解決方案集中在這樣幾個環節：使用高性能的服務器、高性能的數據庫、高效率的編程語言、還有高性能的Web容器。但是除了這幾個方面，還沒法根本解決大型網站面臨的高負載和高并發問題。

上面提供的幾個解決思路在一定程度上也意味著更大的投入，并且這樣的解決思路具備瓶頸，沒有很好的擴展性，下面我從低成本、高性能和高擴張性的角度來說說我的一些經驗。

1、HTML靜態化

其實大家都知道，效率最高、消耗最小的就是純靜態化的html頁面，所以我們盡可能使我們的網站上的頁面采用靜態頁面來實現，這個最簡單的方法其實也是最有效的方法。但是對于大量內容并且頻繁更新的網站，我們無法全部手動去挨個實現，于是出現了我們常見的信息發布系統CMS，像我們常訪問的各個門戶站點的新聞頻道，甚至他們的其他頻道，都是通過信息發布系統來管理和實現的，信息發布系統可以實現最簡單的信息錄入自動生成靜態頁面，還能具備頻道管理、權限管理、自動抓取等功能，對于一個大型網站來說，擁有一套高效、可管理的CMS是必不可少的。

除了門戶和信息發布類型的網站，對于交互性要求很高的社區類型網站來說，盡可能的靜態化也是提高性能的必要手段，將社區內的帖子、文章進行實時的靜態化，有更新的時候再重新靜態化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網易社區等也是如此。

同時，html靜態化也是某些緩存策略使用的手段，對于系統中頻繁使用數據庫查詢但是內容更新很小的應用，可以考慮使用html靜態化來實現，比如論壇中論壇的公用設置信息，這些信息目前的主流論壇都可以進行后臺管理并且存儲再數據庫中，這些信息其實大量被前臺程序調用，但是更新頻率很小，可以考慮將這部分內容進行后臺更新的時候進行靜態化，這樣避免了大量的數據庫訪問請求。

2、圖片服務器分離

大家知道，對于Web服務器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，于是我們有必要將圖片與頁面進行分離，這是基本上大型網站都會采用的策略，他們都有獨立的圖片服務器，甚至很多臺圖片服務器。這樣的架構可以降低提供頁面訪問請求的服務器系統壓力，并且可以保證系統不會因為圖片問題而崩潰，在應用服務器和圖片服務器上，可以進行不同的配置優化，比如apache在配置ContentType的時候可以盡量少支持，盡可能少的LoadModule，保證更高的系統消耗和執行效率。

3、數據庫集群和庫表散列

大型網站都有復雜的應用，這些應用必須使用數據庫，那么在面對大量訪問的時候，數據庫的瓶頸很快就能顯現出來，這時一臺數據庫將很快無法滿足應用，于是我們需要使用數據庫集群或者庫表散列。

在數據庫集群方面，很多數據庫都有自己的解決方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是類似的方案，您使用了什么樣的DB，就參考相應的解決方案來實施即可。

上面提到的數據庫集群由于在架構、成本、擴張性方面都會受到所采用DB類型的限制，于是我們需要從應用程序的角度來考慮改善系統架構，庫表散列是常用并且最有效的解決方案。我們在應用程序中安裝業務和應用或者功能模塊將數據庫進行分離，不同的模塊對應不同的數據庫或者表，再按照一定的策略對某個頁面或者功能進行更小的數據庫散列，比如用戶表，按照用戶ID進行表散列，這樣就能夠低成本的提升系統的性能并且有很好的擴展性。sohu的論壇就是采用了這樣的架構，將論壇的用戶、設置、帖子等信息進行數據庫分離，然后對帖子、用戶按照板塊和ID進行散列數據庫和表，最終可以在配置文件中進行簡單的配置便能讓系統隨時增加一臺低成本的數據庫進來補充系統性能。

4、緩存

緩存一詞搞技術的都接觸過，很多地方用到緩存。網站架構和網站開發中的緩存也是非常重要。這里先講述最基本的兩種緩存。高級和分布式的緩存在后面講述。
架構方面的緩存，對Apache比較熟悉的人都能知道Apache提供了自己的緩存模塊，也可以使用外加的Squid模塊進行緩存，這兩種方式均可以有效的提高Apache的訪問響應能力。
網站程序開發方面的緩存，Linux上提供的Memory Cache是常用的緩存接口，可以在web開發中使用，比如用Java開發的時候就可以調用MemoryCache對一些數據進行緩存和通訊共享，一些大型社區使用了這樣的架構。另外，在使用web語言開發的時候，各種語言基本都有自己的緩存模塊和方法，PHP有Pear的Cache模塊，Java就更多了，.net不是很熟悉，相信也肯定有。

5、鏡像

鏡像是大型網站常采用的提高性能和數據安全性的方式，鏡像的技術可以解決不同網絡接入商和地域帶來的用戶訪問速度差異，比如ChinaNet和EduNet之間的差異就促使了很多網站在教育網內搭建鏡像站點，數據進行定時更新或者實時更新。在鏡像的細節技術方面，這里不闡述太深，有很多專業的現成的解決架構和產品可選。也有廉價的通過軟件實現的思路，比如Linux上的rsync等工具。

6、負載均衡

負載均衡將是大型網站解決高負荷訪問和大量并發請求采用的終極解決辦法。
負載均衡技術發展了多年，有很多專業的服務提供商和產品可以選擇，我個人接觸過一些解決方法，其中有兩個架構可以給大家做參考。
硬件四層交換
第四層交換使用第三層和第四層信息包的報頭信息，根據應用區間識別業務流，將整個區間段的業務流分配到合適的應用服務器進行處理。　第四層交換功能就象是虛IP，指向物理服務器。它傳輸的業務服從的協議多種多樣，有HTTP、FTP、NFS、Telnet或其他協議。這些業務在物理服務器基礎上，需要復雜的載量平衡算法。在IP世界，業務類型由終端TCP或UDP端口地址來決定，在第四層交換中的應用區間則由源端和終端IP地址、TCP和UDP端口共同決定。
在硬件四層交換產品領域，有一些知名的產品可以選擇，比如Alteon、F5等，這些產品很昂貴，但是物有所值，能夠提供非常優秀的性能和很靈活的管理能力。Yahoo中國當初接近2000臺服務器使用了三四臺Alteon就搞定了。

軟件四層交換

大家知道了硬件四層交換機的原理后，基于OSI模型來實現的軟件四層交換也就應運而生，這樣的解決方案實現的原理一致，不過性能稍差。但是滿足一定量的壓力還是游刃有余的，有人說軟件實現方式其實更靈活，處理能力完全看你配置的熟悉能力。
軟件四層交換我們可以使用Linux上常用的LVS來解決，LVS就是Linux Virtual Server，他提供了基于心跳線heartbeat的實時災難應對解決方案，提高系統的魯棒性，同時可供了靈活的虛擬VIP配置和管理功能，可以同時滿足多種應用需求，這對于分布式的系統來說必不可少。

一個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建squid集群，這種思路在很多大型網站包括搜索引擎上被采用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構里面增減節點都非常容易。這樣的架構我準備空了專門詳細整理一下和大家探討。

對于大型網站來說，前面提到的每個方法可能都會被同時使用到，我這里介紹得比較淺顯，具體實現過程中很多細節還需要大家慢慢熟悉和體會，有時一個很小的squid參數或者apache參數設置，對于系統性能的影響就會很大，希望大家一起討論，達到拋磚引玉之效。