推薦：站長的樸實 站長的共鳴
不說話的站長 租一間房子，拉一條網線，借錢買一臺電腦，很多個人站長就這樣開始了自己的站長生涯。 站長是沒有早晨的，當早市上人潮洶涌的時候，他們才剛剛入睡，在夢中他們擁著QQ上那個遠方的女孩，假如這時候有人在他們旁邊，定會看到他們臉上燦爛的笑臉。 中午醒來

結論：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次虧。

分享：什么是垂直搜索？
垂直搜索是針對某一個行業的專業搜索引擎，是搜索引擎的細分和延伸，是對網頁庫中的某類專門的信息進行一次整合，定向分字段抽取出需要的數據進行處理后再以某種形式返回給用戶。 垂直搜索引擎和普通的網頁搜索引擎的最大區別是對網頁信息進行了結構化信息抽取，也就是