當今從純網(wǎng)站技術上來說，因為開源模式的發(fā)展，現(xiàn)在建一個小網(wǎng)站已經(jīng)很簡單也很便宜，所以很多人都把創(chuàng)業(yè)方向定位在互聯(lián)網(wǎng)應用。這些人里大多數(shù)不是很懂技術，或者不是那么精通，而網(wǎng)站開發(fā)維護方面的知識又很分散，學習成本太高，所以這篇文章將這些知識點結合起來，系統(tǒng)的來說，一個從日幾千訪問的小小網(wǎng)站，到日訪問一兩百萬的小網(wǎng)站，中間可能會產(chǎn)生什么問題，以及怎么才能在一開始做足工作盡量避免這些問題。

你的網(wǎng)站因為努力經(jīng)營，訪問量逐漸升高，在升高的過程中，問題也可能開始顯現(xiàn)了。因為帶寬的增加、硬件的擴展、人員的擴張所帶來的成本提高是顯而易見的，而還有相當大的一部分成本是因為代碼重構、架構重構，甚至底層開發(fā)語言更換引起的，最壞的情況就是數(shù)據(jù)丟失，所有努力付之一炬。這類成本支出大多數(shù)在一開始就可以避免，先打好基礎，往后可以省很多精力，少操很多心。

對于不同的初期投資成本，技術路線的選擇是不同的。這里假設網(wǎng)站剛剛只是一個構想，計劃第一年服務器硬件帶寬投入5萬左右。對于這個資金額度，有很多種方案可選擇，例如租用虛擬主機、租用單獨服務器，或者流行的私有云，或者托管服務器。前兩種選擇，網(wǎng)站發(fā)展到一定規(guī)模時需遷移，那時再重做規(guī)劃顯然影響更大。服務器托管因為配置自主、能完全掌握控制權，所以有一定規(guī)模的網(wǎng)站基本都是這種模式。采用自己托管服務器的網(wǎng)站，一開始要注意以下幾點——

一、開發(fā)語言

一般來說，技術人員（程序員）都是根據(jù)自己技術背景選擇自己最熟悉的語言，不過不可能永遠是一個人寫程序，所以在語言的選擇上還要是要費些心思。首先明確一點，無論用什么語言，最終代碼質(zhì)量是看管理，因此我們從前期開發(fā)成本分析?，F(xiàn)在國內(nèi)流行的適用于網(wǎng)站的語言，大概有java、php、.net、python、ruby這五大陣營。python和ruby因為在國內(nèi)流行的比較晚，現(xiàn)在人員還是相對難招一些。.net平臺的人相對多，但是到后期需要解決性能問題時，對人員技能的要求比較高。剩余的java、php用人可以說是最多的。java和php無法從語言層面做比較，但對于初期，應用幾乎都是靠前端支撐的網(wǎng)站來說，php入門簡單、編寫快速，優(yōu)勢相對大一點。至于后端例如行為分析、銀行接口、異步消息處理等，等真正需要時，就要根據(jù)不同業(yè)務需求來選擇不同語言了。

二、代碼版本管理

稍微有點規(guī)模的網(wǎng)站就需要使用代碼版本管理了。代碼版本管理兩點最大的好處，一是方便協(xié)同工作，二是有歷史記錄可查詢比較。代碼版本管理軟件有很多，vss/cvs/svn/hg等，目前國內(nèi)都比較流行，其中svn的普及度還是很高的。

假設選了svn，那么有幾點考慮。一是采用什么樹結構。初期可能只有一條主干，往后就需要建立分支，例如一條開發(fā)分支，一條上線分支，再往后，可能要每個小組一個分支。建議一開始人少時選擇兩條分支，開發(fā)和線上，每個功能本地測試無誤后提交到開發(fā)分支，最后統(tǒng)一測試，可以上線時合并到上線分支。如果每人都建自己的分支，合并時會浪費很大精力，對于幾乎每天都要修改幾次的WEB應用來說，所費時間太多。

向服務器部署代碼，可以手工部署也可以自動部署。手工部署相對簡單，一般可直接在服務器上svn update，或者找個新目錄svn checkout，再把web root給ln -s過去。應用越復雜，部署越復雜，沒有什么統(tǒng)一標準，只是別再用ftp上傳那種形式，一是上傳時文件引用不一致錯誤率增加，二是很容易出現(xiàn)開發(fā)人員的版本跟線上版本不一致，導致本來想改個錯字結果變成回滾。如果有多臺服務器還是建議自動部署，更換代碼的機器從當前服務池中臨時撤出，更新完畢后再重新加入。

三、服務器硬件

在各個機房里，靠一臺服務器孤獨支撐的網(wǎng)站數(shù)不清，但如果資金稍微充足，建議至少三臺的標準配置，分別用作web處理、數(shù)據(jù)庫、備份。web服務器至少要8G內(nèi)存，雙sata raid1，如果經(jīng)濟稍微寬松，或靜態(tài)文件或圖片多，則15k sas raid10。數(shù)據(jù)庫至少16G內(nèi)存，15k sas raid 10。備份服務器最好跟數(shù)據(jù)庫服務器同等配置。硬件可以上整套品牌，也可以兼容機，也可以半品牌半組裝，取決于經(jīng)濟能力。當然，這是典型的搭配，有些類型應用的性能瓶頸首先出現(xiàn)在web上，那種情況就要單獨分析了。

web服務器可以既跑程序又當內(nèi)存緩存，數(shù)據(jù)庫服務器則只跑主數(shù)據(jù)庫（假如是MySQL的話），備份服務器所承擔就相對多一些，web配置、緩存配置、數(shù)據(jù)庫配置都要跟前兩臺一致，這樣WEB和數(shù)據(jù)庫任意一臺出問題，很容易就可以將備份服務器切換過去臨時頂替，直到解決完問題。要注意，硬件是隨時可能壞掉的，特別是硬盤，所以寧可WEB服務器跟數(shù)據(jù)庫服務器放在一起，也一定不能省掉備份，備份一定要異機，并且有異步，電力故障、誤操作都可能導致一臺機器上的所有數(shù)據(jù)丟失。很多的開源備份方案可選擇，最簡單的就是rsync，寫crontab里，定時同步。備份和切換，建議多做測試，選最安全最適合業(yè)務的，并且盡可能異地備份。

四、機房

三種機房盡量不要選：聯(lián)通訪問特別慢的電信機房、電信訪問特別慢的聯(lián)通機房、電信聯(lián)通訪問特別慢的移動或鐵通機房。機房要盡可能多的實地參觀，多測試，找個網(wǎng)絡質(zhì)量好，管理嚴格的機房。機房可以說是非常重要，直接關系到網(wǎng)站訪問速度，網(wǎng)站訪問速度直接關系到用戶體驗，訪問速度很慢的網(wǎng)站，很難獲得用戶青睞。

五、架構

在大方向上，被熟知的架構是web負載均衡+數(shù)據(jù)庫主從+緩存+分布式存儲+隊列。在一開始，按照可擴展的原則設計和編程就可以。只是要多考慮緩存失效時的雪崩效應、主從同步的數(shù)據(jù)一致性和時間差、隊列的穩(wěn)定性和失敗后的重試策略、文件存儲的效率和備份方式等等意外情況。緩存失效、數(shù)據(jù)庫復制中斷、隊列寫入錯誤、電源損壞，在實際運維中經(jīng)常發(fā)生，如果不注意這些，出現(xiàn)問題時恢復期可能會超出預期很長時間。

六、服務器軟件

操作系統(tǒng)Linux很流行。在沒有專業(yè)運維人員的情況下，應傾向于擇使用的人多、社區(qū)活躍、配置方便、升級方便的發(fā)行版，例如RH系列、debian、ubuntu server等，硬件和操作系統(tǒng)要一起選擇，看是否有適合的驅(qū)動，如果確定用某種商業(yè)軟件或解決方案，也要提前知曉其對哪種操作系統(tǒng)支持最佳。web服務器方面，apache、nginx、lighttpd三大系列中，apache占有量還是最大，但是想把性能調(diào)教好還是需要很專業(yè)的，nginx和lighttpd在不需要太多調(diào)整的情況下可以達到一個比較不錯的性能。無論選擇什么軟件，除非改過這些軟件或你的程序真的不兼容新版本，否則盡量版本越新越好，版本新，意味著新特性增多、BUG減少、性能增加。一個典型的php網(wǎng)站，基本上大多數(shù)人都沒改過任何服務器軟件源代碼，絕大多數(shù)情況是能平穩(wěn)的升級到新版本的。類似于jdk5到 jdk6，python2到python3這類變動比較大的升級還是比較少見的。看看ChangeLog，看看升級說明，結合自己情況評估測試一下，越早升級越好，升級的越晚，所花費的成本越高。對于軟件包，盡量使用發(fā)行版內(nèi)置的包管理工具，沒有特殊要求時不建議自己編譯，那樣對將來運維不利。

七、數(shù)據(jù)庫

幾乎所有操作最后都要落到數(shù)據(jù)庫身上，它又最難擴展（存儲也挺難）。數(shù)據(jù)庫常見的擴展方法有復制、分片，設計時要考慮到每種應用的數(shù)據(jù)如何復制、分片，當然這種考慮一般會推遲到技術設計時期。在初期進行數(shù)據(jù)庫結構設計時，要根據(jù)不同的業(yè)務類型和增長量預期來考慮是否要分庫、分區(qū)，并且盡量不要使用聯(lián)合查詢、不使用自增ID以方便分片。復制延時問題、主從數(shù)據(jù)庫數(shù)據(jù)一致性問題，可以自己寫或者用已有的運維工具進行檢測。

用存儲過程是比較難擴展的，這種情形多發(fā)生于傳統(tǒng)C/S，特別是OA系統(tǒng)轉(zhuǎn)換過來的開發(fā)人員。低成本網(wǎng)站不是一兩臺小型機跑一個數(shù)據(jù)庫處理所有業(yè)務的模式，是機海作戰(zhàn)。方便水平擴展比那點預分析時間和網(wǎng)絡傳輸流量要重要的多的多。

另外，現(xiàn)在流行一種概念叫NoSQL，可以理解為非傳統(tǒng)關系型數(shù)據(jù)庫。實際應用中，網(wǎng)站有著越來越多的密集寫操作、上億的簡單關系數(shù)據(jù)讀取、熱備等，這都不是傳統(tǒng)關系數(shù)據(jù)庫所擅長的，于是就產(chǎn)生了很多非關系型數(shù)據(jù)庫，比如Redis/TC&TT/MongoDB/Memcachedb等，在測試中，這些幾乎都達到了每秒至少一萬次的寫操作，內(nèi)存型的甚至5萬以上。在設計時，可根據(jù)業(yè)務特點和性能要求來選擇是否使用這類數(shù)據(jù)庫。例如MongoDB，幾句配置就可以組建一個復制+自動分片+failover的環(huán)境，文檔化的存儲也簡化了傳統(tǒng)設計庫結構再開發(fā)的模式。但是當你決定采用一項技術時，一定要真正了解其優(yōu)劣，例如可能你所選擇的技術并不能支持你所需要的事務和數(shù)據(jù)一致性要求。

八、文件存儲

存儲的分布幾乎跟數(shù)據(jù)庫擴展一樣困難，不過只有百萬的PV的情況下，磁盤IO方面一般不會成大問題，一兩臺采用SATA做條帶RAID的機器可以應付，反而是自己做異步備份比較復雜，因為小文件多。如果只有一臺機器做存儲，可以做簡單的優(yōu)化，例如放最小縮略圖的分區(qū)和放中等縮略圖的分區(qū)，根據(jù)平均大小調(diào)整一下塊大小。存儲要規(guī)劃好目錄結構，否則文件增多后維護起來復雜，也不利于擴展。同時還要考慮將來擴容，例如采用LVM，或者把文件根據(jù)不同規(guī)則散列到不同機器。磁盤IO繁重的情況下更容易出現(xiàn)故障，所以要做好備份，若發(fā)現(xiàn)有盤壞掉，要馬上行動更換，很多人的硬盤都是壞了一塊之后，接二連三的壞下去。

為了將來圖片走cdn做準備，一開始最好就將圖片的域名分開，且不用主域名。因為很多網(wǎng)站都將cookie設置到了.domain.ltd，如果圖片也在這個域名下，很可能因為cookie而造成緩存失效，并且占多余流量，還可能因為瀏覽器并發(fā)線程限制造成訪問緩慢。

九、程序

一定硬件條件下，應用能承載多少訪問量，很大一部分也取決于程序如何寫。程序?qū)懙牟缓?，可能一萬的訪問都承載不了，寫的好，可能一兩臺機器就能承擔幾百萬PV。越是復雜、數(shù)據(jù)實時性要求越高的應用，優(yōu)化起來越難，但對普通網(wǎng)站有一個統(tǒng)一的思路，就是盡量向前端優(yōu)化、減少數(shù)據(jù)庫操作、減少磁盤IO。向前端優(yōu)化指的是，在不影響功能和體驗的情況下，能在瀏覽器執(zhí)行的不要在服務端執(zhí)行，能在緩存服務器上直接返回的不要到應用服務器，程序能直接取得的結果不要到外部取得，本機內(nèi)能取得的數(shù)據(jù)不要到遠程取，內(nèi)存能取到的不要到磁盤取，緩存中有的不要去數(shù)據(jù)庫查詢。減少數(shù)據(jù)庫操作指減少更新次數(shù)、緩存結果減少查詢次數(shù)、將數(shù)據(jù)庫執(zhí)行的操作盡可能的讓你的程序完成（例如join查詢），減少磁盤IO指盡量不使用文件系統(tǒng)作為緩存、減少讀寫文件次數(shù)等。程序優(yōu)化永遠要優(yōu)化慢的部分，換語法是無法“優(yōu)化”的。

然而編程時不應該把重點放在優(yōu)化上，應該關注擴展性。當今的WEB應用，需求變化非常之快，適應多種需求的架構是不存在的，我們的擴展性就要把要點放在跟底層交互的架構上，例如持久化數(shù)據(jù)的存取規(guī)則、緩存的存取規(guī)則等，還有一些共用服務，例如用戶信息等。先把不變的部分做完善，剩下的部分就很容易將精力放在業(yè)務邏輯上面了。

關于作者

劉志一，從1999年做個人網(wǎng)站開始一直專注于互聯(lián)網(wǎng)，目前就職于一家垂直行業(yè)C2C網(wǎng)站，做產(chǎn)品和開發(fā)方面工作。