詳述百萬級訪問網站前期的技術準備(上篇)
51CTO編者按：IT技術人員在工作年限到達一定層次，比如十年就會考慮自己創業的問題。在這創業的前期，盡管我們有很高的熱情，但是現實是殘酷的。萬事開頭難，究竟我們該如何準備一個百萬級的網站所需的技術資源，請看本文。我們將介紹如何進行開發語言，機房，數據庫，緩存等方面的選擇。
作為一個技術從業者十年，逛了十年發現有些知識東一榔頭西一棒槌的得滿世界看個遍才整理出個頭緒，那咱就系統點的從頭一步一步的說，一個從日幾千訪問的小小網站，到日訪問一兩百萬的小網站，怎么才能讓它平滑的度過這個階段，別在 技術上出現先天不足，寫給一些技術人員，也寫給不懂技術的創業者。
對互聯網有了解的人都有自己的想法，有人就把想法付諸實現，做個網站然后開始運營。其實從純網站技術上來說，因為開源模式的發展，現在建一個小網站 已經很簡單也很便宜。當訪問量到達一定數量級的時候成本就開始飆升了，問題也開始顯現了。因為帶寬的增加、硬件的擴展、人員的擴張所帶來的成本提高是顯而 易見的，而還有相當大的一部分成本是因為代碼重構、架構重構，甚至底層開發語言更換引起的，最慘的就是數據丟失，辛辛苦苦好幾年，一夜回到創業前。
減少成本就是增加利潤。很多事情，我們在一開始就可以避免，先打好基礎，往后可以省很多精力，少操很多心。
假設你是一個參與創業的技術人員，當前一窮二白，什么都要自己做，自己出錢，初期幾十萬的資金，做一個應用不是特別復雜的網站，那么就要注意以下幾點：
一、開發語言
一般來說，技術人員（程序員）創業都是根據自己技術背景選擇自己最熟悉的語言，不過考慮到不可能永遠是您一個人寫程序，這點還得仔細想想。無論用什么語言，最終代碼質量是看管理，所以我們還是從純語言層面來說實際一點。現在流行的Java、PHP、.NET、python、ruby都有自己的優劣，python和ruby，現在人員還是相對難招一些，性能優化也會費些力氣，.NET平臺買不起Windows server。Java、PHP用的還是最多。對于初期，應用幾乎都是靠前端支撐的網站來說，PHP的優勢稍大一些，入門簡單、設計模式簡單、寫起來快、 性能足夠等，不過不注重設計模式也是它的劣勢，容易變得松散，隱藏bug稍多、難以維護。Java的優勢在于整套管理流程已經有很多成熟工具來輔助，強類 型也能避免一些弱智BUG，大多數Java程序員比較注重設計模式，別管實不實際，代碼格式看起來還是不錯的。這也是個劣勢，初學者可能太注重模式而很難 解決實際需求。
前端不只是html、css這類。整個負責跟用戶交互的部分都是前端，包括處理程序。這類程序還是建議用PHP，主要原因就是開發迅速、從業人員廣泛。至于后端例如行為分析、銀行接口、異步消息處理等，隨便用什么程序，那個只能是根據不同業務需求來選擇不同語言了。
二、代碼版本管理
如果開發人員之間的網絡速度差不多，就SVN；比較分散例如跨國，就hg。大多數人還是SVN的.
假設選了SVN，那么有幾點考慮。一是采用什么樹結構。初期可能只有一條主干，往后就需要建立分支，例如一條開發分支，一條上線分支，再往后，可能要每個小組一個分支。建議一開始人少時選擇兩條分支，開發和線上，每個功能本地測試無誤后提交到開發分支，最后統一測試，可以上線時合并到上線分支。如果 喜歡把SVN當做移動硬盤用，寫一點就commit一次也無所謂，就是合并的時候頭大一些，這些人可以自己建個分支甚至建立個本地代碼倉庫，隨便往自己的 分支提交，測試完畢后再提交到開發分支上。
部署，可以手工部署也可以自動部署。手工部署相對簡單，一般是直接在服務器上SVN update，或者找個新目錄SVN checkout，再把Web root給ln -s過去。應用越復雜，部署越復雜，沒有什么統一標準，只要別再用ftp上傳那種形式就好，一是上傳時文件引用不一致錯誤率增加，二是很容易出現開發人員 的版本跟線上版本不一致，導致本來想改個錯字結果變成回滾的杯具。如果有多臺服務器還是建議自動部署，更換代碼的機器從當前服務池中臨時撤出，更新完畢后 再重新加入。
不管項目多小，養成使用版本管理的好習慣，最起碼還可以當做你的備份，我的http://zhiyi.us雖然就是一個wordpress，可還是SVN了，只改動一兩句css那也是勞動成果。
三、服務器硬件
別羨慕大客戶和有錢人，看看機房散戶區，一臺服務器孤獨的支撐的網站數不清。如果資金稍微充足，建議至少三臺的標準配置，分別用作Web處理、數據 庫、備份。Web服務器至少要8G內存，雙sata raid1，如果經濟稍微寬松，或靜態文件或圖片多，則15k sas raid1+0。數據庫至少16G內存，15k sas raid 1+0。備份服務器最好跟數據庫服務器同等配置。硬件可以自己買品牌的底板，也就是機箱配主板和硬盤盒，CPU內存硬盤都自己配，也可以上整套品牌，也可 以兼容機。三臺機器，市場行情6、7萬也就配齊了。
Web服務器可以既跑程序又當內存緩存，數據庫服務器則只跑主數據庫（假如是MySQL的話），備份服務器干的活就相對多一些，Web配置、緩存配置、數據庫配置都要跟前兩臺一致，這樣Web和數據庫任意一臺出問題，把備份服務器換個ip就切換上去了。備份策略，可以drbd，可以rsync，或者其他的很多很多的開源備份方案可選擇。rsync最簡單，放cron里自己跑就行。備份和切換，建議多做測試，選最安全最適合業務的，并且盡可能異地備份。
四、機房
三種機房盡量不要選：聯通訪問特別慢的電信機房、電信訪問特別慢的聯通機房、電信聯通訪問特別慢的移動或鐵通機房。那網通機房呢？親，網通聯通N久 以前合并改叫聯通了。多多尋找，實地參觀，多多測試，多方打探，北京、上海、廣州等各個主節點城市，還是有很多優質機房的，找個網絡質量好，管理嚴格的機 房，特別是管理要嚴格，千萬別網站無法訪問了，打個電話過去才知道別人維護時把你網線碰掉了，這比DOS都頭疼。自己扯了幾根光纖就稱為機房的，看您抗風 險程度和心理素質了。機房可以說是非常重要，直接關系到網站訪問速度，網站訪問速度直接關系到用戶體驗，我可以翻墻看風景，但買個網游vpn才能打開你這 個還不怎么知名的網站就有難度了。或許您網站的ajax很出色，可是document怎么也不ready，一些代碼永遠絕緣于用戶。
五、架構
初期架構一般比較簡單，Web負載均衡+數據庫主從+緩存+分布式存儲+隊列。大方向上也確實就這幾樣東西，細節上也無數文章都重復過了，按照將來 會有很多Web，N多主從關系，很多緩存，很多xxx設計就行，基本方案都是現成的，只是您比其他人厲害之處就在于設計上考慮到緩存失效時的雪崩效應、主從同步的數據一致性和時間差、隊列的穩定性和失敗后的重試策略、文件存儲的效率和備份方式等等意外情況。緩存總有一天會失效，數據庫復制總有一天會斷掉， 隊列總有一天會寫不進去，電源總有一天會燒壞。根據墨菲定律，如果不考慮這些，網站早晚會成為廢品。
六、服務器軟件
Linux、nginx、PHP、MySQL，幾乎是標配，我們除了看名字，還得選版本。Linux發行版眾多，只要沒特殊要求，就選個用的人最多的，社區最活躍的，配置最方便的，軟件包最全最新的，例如debian、uBuntu。 至于RHEL之類的嘛，你用只能在RHEL上才能運行的軟件么？剩下的nginx、PHP、MySQL、activemq、其他的等等，除非你改過這些軟 件或你的程序真的不兼容新版本，否則盡量版本越新越好，版本新，意味著新特性增多、BUG減少、性能增加。總有些道聽途說的人跟你說老的版本穩定。所謂穩 定，是相對于特殊業務來說的，而就一個PHP寫的網站，大多數人都沒改過任何服務器軟件源代碼，絕大多數情況是能平穩的升級到新版本的。類似于jdk5到 jdk6，python2到python3這類變動比較大的升級還是比較少見的。看看ChangeLog，看看升級說明，結合自己情況評估一下，越早升級 越好，別人家都用PHP6寫程序了這邊還PHP4的逛游呢。優秀的開源程序升級還是很負責任的，看好文檔，別怕。
以上這六點準備完畢，現在我們有了運行環境，有了基本架構骨架，有了備份和切換方案，應該開始著手設計開發方面的事情了。
七、數據庫
幾乎所有操作最后都要落到數據庫身上，它又最難擴展（存儲也挺難）。對于MySQL，什么樣的表用myisam，什么樣的表用innodb，在開發之前要確定。復制策略、分片策略，也要確定。表引擎方面，一般，更新不多、不需要事務的表可以用myisam，需要行鎖定、事務支持的，用innodb。myisam的鎖表不一定是性能低下的根源，innodb也不一定全是行鎖，具體細節要多看相關的文檔，熟悉了引擎特性才能用的更好。現代Web應用越來越復雜了，我們設計表結構時常常設計很多冗余，雖然不符合傳統范式，但為了速度考慮還是值得的，要求高的情況下甚至要杜絕聯合查詢。編程時得多注意數據一致性。
復制策略方面，多主多從結構也最好一開始就設計好，代碼直接按照多主多從來編寫，用一些小技巧來避免復制延時問題，并且還要解決多數據庫數據是否一致，可以自己寫或者找現成的運維工具。
分片策略。總會有那么幾個表數據量超大，這時分片必不可免。分片有很多策略，從簡單的分區到根據熱度自動調整，依照具體業務選擇一個適合自己的。避免自增ID作為主鍵，不利于分片。
用存儲過程是比較難擴展的，這種情形多發生于傳統C/S，特別是OA系統轉換過來的開發人員。低成本網站不是一兩臺小型機跑一個數據庫處理所有業務的模式，是機海作戰。方便水平擴展比那點預分析時間和網絡傳輸流量要重要的多的多。
NoSQL。這只是一個概念。實際應用中，網站有著越來越多的密集寫操作、上億的簡單關系數據讀取、熱備等，這都不是傳統關系數據庫所擅長的，于是就產生了很多非關系型數據庫，比如Redis/TC&TT/MongoDB/Memcachedb等，在測試中，這些幾乎都達到了每秒至少一萬次的寫操作，內存型的甚至5萬以上。例如MongoDB，幾句配置就可以組建一個復制+自動分片+failover的環境，文檔化的存儲也簡化了傳統設計庫結構再開發的模式。很多業務是可以用這類數據庫來替代mysql的。
八、緩存
數據庫很脆弱，一定要有緩存在前面擋著，其實我們優化速度，幾乎就是優化緩存，能用緩存的地方，就不要再跑到后端數據庫那折騰。緩存有持久化緩存、內存緩存，生成靜態頁面是最容易理解的持久化緩存了，還有很多比如varnish的分塊緩存、前面提到的memcachedb等，內存緩存，memcached首當其沖。緩存更新可用被動更新和主動更新。被動更新的好處是設計簡單，緩存空了就自動去數據庫取數據再把緩存填上，但容易引發雪崩效應，一旦緩存大面積失效，數據庫的壓力直線上升很可能掛掉。主動緩存可避免這點但是可能引發程序取不到數據的問題。這兩者之間如何配合，程序設計要多動腦筋。
九、隊列
用戶一個操作很可能引發一系列資源和功能的調動，這些調動如果同時發生，壓力無法控制，用戶體驗也不好，可以把這樣一些操作放入隊列，由另幾個模塊去異步執行，例如發送郵件，發送手機短信。開源隊列服務器很多，性能要求不高用數據庫當做隊列也可以，只要保證程序讀寫隊列的接口不變，底層隊列服務可隨時更換就可以，類似Zend Framework里的Zend_Queue類，java.util.Queue接口等。
十、文件存儲
除了結構化數據，我們經常要存放其他的數據，像圖片之類的。這類數據數量繁多、訪問量大。典型的就是圖片，從用戶頭像到用戶上傳的照片，還要生成不同的縮略圖尺寸。存儲的分布幾乎跟數據庫擴展一樣艱難。不使用專業存儲的情況下，基本都是靠自己的NAS。這就涉及到結構。拿圖片存儲舉例，圖片是非常容易產生熱點的，有些圖片上傳后就不再有人看，有些可能每天被訪問數十萬次，而且大量小文件的異步備份也很耗費時間。
為了將來圖片走cdn做準備，一開始最好就將圖片的域名分開，且不用主域名。很多網站都將cookie設置到了.domain.ltd，如果圖片也在這個域名下，很可能因為cookie而造成緩存失效，并且占多余流量，還可能因為瀏覽器并發線程限制造成訪問緩慢。
如果用普通的文件系統存儲圖片，有一個簡單的方法。計算文件的hash值，比如md5，以結果第一位作為第一級目錄，這樣第一級有16個目錄。從0到F，可以把這個字母作為域名，0.yourimg.com到f.yourimg.com（客戶端dns壓力會增大），還可以擴展到最多16個NAS集群上。第二級可用年月例如，201011，第三級用日，第四級可選，根據上傳量，比如am/pm，甚至小時。最終的目錄結構可能會是 e/201008/25/am/e43ae391c839d82801920cf.jpg。rsync備份時可以用腳本只同步某年某日某時的文件，避免計算大量文件帶來的開銷。當然最好是能用專門的分布式文件系統或更專業點的存儲解決方案。
原文鏈接：http://zhiyi.us/internet/thinking-twice-before-building-your-site-one.html
【編輯推薦】
