更新時間：2025-09-15 08:36:53
網站建設
554從現在純網站技術來看，因為開源模式的發展，現在搭建一個小網站非常容易，成本也很低，所以很多人把自己的創業方向定位在了互聯網應用上。這些人大多不是很懂技術，或者不是很精通，而且網站開發和維護的知識很零散，學習成本太高，所以這篇文章結合了這些知識點。訪問量幾千的小網站，一天訪問量一兩百萬的小網站，中間可能會出現什么問題，一開始如何做足夠的工作，盡可能避免這些問題。
由于您的努力，您網站的訪問量逐漸增加。在增加的過程中，問題也可能開始出現。因為帶寬增加、硬件擴容、人員膨脹帶來的成本增加是顯而易見的，而且有相當一部分成本是由代碼重構、架構重構，甚至是底層開發語言的更換造成的。最壞的情況是數據丟失，所有的努力都是徒勞的。這種成本支出，大部分在一開始是可以避免的，先打好基礎，以后可以省心省力。
對于不同的初始投資成本，技術路線的選擇是不同的。這里假設網站只是一個想法，第一年計劃在服務器硬件帶寬上投入5萬左右。對于這筆錢，有很多選擇，比如租用虛擬主機，租用單獨的服務器，或者現在流行的私有云，或者托管服務器。對于前兩種方案，當網站發展到一定規模后，需要進行遷移，然后重新規劃，顯然影響會更大。由于服務器托管是自行配置和完全可控的，具有一定規模的網站基本都是這種模式。對于使用自己托管服務器的網站，開頭要注意以下幾點——
一、開發語言
一般來說，技術人員（程序員）會根據自己的技術背景來選擇自己最熟悉的語言，但是靠自己寫程序是不可能永遠的，所以在語言的選擇上還是要花點心思的。首先明確一點，不管用什么語言，最終的代碼質量還是要靠管理，所以我們從前期的開發成本來分析。目前國內流行的適用于網站的語言大致分為五個陣營：java、php、net、python、ruby。因為python和ruby在國內流行的比較晚，所以招人還是比較困難的。net平臺的人比較多，但是后期需要解決性能問題的時候，對人員技能的要求比較高。剩下的java和php雇主可以說是最多的了。 Java和php從語言層面無法比較，但是對于起步階段，應用幾乎都是前端網站支持的，php上手容易，編寫速度快，有比較大的優勢。至于后端如行為分析、銀行接口、異步消息處理等，真正需要的時候，需要根據不同的業務需求選擇不同的語言。
二、代碼版本管理
稍大的網站需要使用代碼版本管理。代碼版本管理最大的好處有兩個，一是方便協同工作，二是有歷史記錄可以查詢比較。代碼版本管理軟件有很多，比如vss/cvs/svn/hg等，目前國內比較流行，svn的普及度還是很高的。
假設選擇了svn，則有幾個注意事項。一是使用什么樹結構。前期可能只有一個trunk，后期需要建立分支，比如開發分支，live分支，再后來，可能每個團隊都有一個分支。建議一開始人少的時候選擇兩個分支，development和online。各功能本地測試無誤后提交給開發分支。最后統一測試上線的時候可以合并到線上分支。如果每個人都建立自己的分支，合并的時候會浪費很多精力。對于一天修改幾次的WEB應用來說，會花費太多的時間。
手動或自動將代碼部署到服務器。手動部署相對簡單。一般可以在服務器上直接svn update，或者找一個新的目錄svn checkout，然后把web根目錄給ln -s。應用程序越復雜，部署就越復雜。沒有統一的標準。只是不要使用ftp上傳。首先，上傳時文件引用不一致錯誤率增加。第二，開發者的版本很容易和線上版本不一致，導致我本來想改個錯別字變成回滾。如果有多臺服務器，還是建議自動部署。換碼機暫時退出當前服務池，更新完成后重新加入。
三、服務器硬件
在每個機房里，光是一臺服務器就支持了無數個網站，但是如果資金稍微充足一點，建議至少三個標準配置，分別用于網頁處理、數據庫、備份。 web服務器至少需要8G內存，double sata raid1，如果經濟稍微寬松一點，或者靜態文件或者圖片比較多，那就15k sas raid10。數據庫至少要有16G內存和15k sas raid 10。備份服務器最好和數據庫服務器配置在同一級別。硬件可以是品牌整機，也可以是兼容機，也可以是半品牌半組裝，看經濟能力。當然，這是一個典型的組合。某些類型應用的性能瓶頸最先出現在Web端，需要單獨分析。
Web服務器可以運行程序并充當內存緩存，而數據庫服務器只運行主數據庫（如果是MySQL），備份服務器承擔的更多。 Web配置、緩存配置、數據庫配置必須和前面兩者保持一致，所以如果WEB和數據庫哪一個出現問題，很容易切換備份服務器臨時替代，直到問題解決。需要注意的是，硬件隨時都有可能壞掉，尤其是硬盤，所以最好把WEB服務器和數據庫服務器放在一起，備份一定不能省略。備份必須是不同的和異步的，可能會出現斷電和誤操作。導致機器上的所有數據丟失。有許多開源備份解決方案可供選擇。最簡單的就是rsync，用crontab寫的，定時同步。對于備份和切換，建議多做測試，選擇最安全最適合業務的，盡量異地備份。
四、機房
盡量不要選擇三種機房：聯通訪問特別慢的聯通機房、電信訪問特別慢的聯通機房、電信機房
聯通訪問特別慢的移動或鐵通機房。機房要盡可能多的實地參觀，多測試，找個網絡質量好，管理嚴格的機房。機房可以說是非常重要，直接關系到網站訪問速度，網站訪問速度直接關系到用戶體驗，訪問速度很慢的網站，很難獲得用戶青睞。五、架構
在大方向上，被熟知的架構是web負載均衡+數據庫主從+緩存+分布式存儲+隊列。在一開始，按照可擴展的原則設計和編程就可以。只是要多考慮緩存失效時的雪崩效應、主從同步的數據一致性和時間差、隊列的穩定性和失敗后的重試策略、文件存儲的效率和備份方式等等意外情況。緩存失效、數據庫復制中斷、隊列寫入錯誤、電源損壞，在實際運維中經常發生，如果不注意這些，出現問題時恢復期可能會超出預期很長時間。
六、服務器軟件
操作系統Linux很流行。在沒有專業運維人員的情況下，應傾向于擇使用的人多、社區活躍、配置方便、升級方便的發行版，例如RH系列、debian、ubuntu server等，硬件和操作系統要一起選擇，看是否有適合的驅動，如果確定用某種商業軟件或解決方案，也要提前知曉其對哪種操作系統支持最佳。web服務器方面，apache、nginx、lighttpd三大系列中，apache占有量還是最大，但是想把性能調教好還是需要很專業的，nginx和lighttpd在不需要太多調整的情況下可以達到一個比較不錯的性能。無論選擇什么軟件，除非改過這些軟件或你的程序真的不兼容新版本，否則盡量版本越新越好，版本新，意味著新特性增多、BUG減少、性能增加。一個典型的php網站，基本上大多數人都沒改過任何服務器軟件源代碼，絕大多數情況是能平穩的升級到新版本的。類似于jdk5到 jdk6，python2到python3這類變動比較大的升級還是比較少見的。看看ChangeLog，看看升級說明，結合自己情況評估測試一下，越早升級越好，升級的越晚，所花費的成本越高。對于軟件包，盡量使用發行版內置的包管理工具，沒有特殊要求時不建議自己編譯，那樣對將來運維不利。
七、數據庫
幾乎所有操作最后都要落到數據庫身上，它又最難擴展（存儲也挺難）。數據庫常見的擴展方法有復制、分片，設計時要考慮到每種應用的數據如何復制、分片，當然這種考慮一般會推遲到技術設計時期。在初期進行數據庫結構設計時，要根據不同的業務類型和增長量預期來考慮是否要分庫、分區，并且盡量不要使用聯合查詢、不使用自增ID以方便分片。復制延時問題、主從數據庫數據一致性問題，可以自己寫或者用已有的運維工具進行檢測。
用存儲過程是比較難擴展的，這種情形多發生于傳統C/S，特別是OA系統轉換過來的開發人員。低成本網站不是一兩臺小型機跑一個數據庫處理所有業務的模式，是機海作戰。方便水平擴展比那點預分析時間和網絡傳輸流量要重要的多的多。
另外，現在流行一種概念叫NoSQL，可以理解為非傳統關系型數據庫。實際應用中，網站有著越來越多的密集寫操作、上億的簡單關系數據讀取、熱備等，這都不是傳統關系數據庫所擅長的，于是就產生了很多非關系型數據庫，比如Redis/TC&TT/MongoDB/Memcachedb等，在測試中，這些幾乎都達到了每秒至少一萬次的寫操作，內存型的甚至5萬以上。在設計時，可根據業務特點和性能要求來選擇是否使用這類數據庫。例如MongoDB，幾句配置就可以組建一個復制+自動分片+failover的環境，文檔化的存儲也簡化了傳統設計庫結構再開發的模式。但是當你決定采用一項技術時，一定要真正了解其優劣，例如可能你所選擇的技術并不能支持你所需要的事務和數據一致性要求。
八、文件存儲
存儲的分布幾乎跟數據庫擴展一樣困難，不過只有百萬的PV的情況下，磁盤IO方面一般不會成大問題，一兩臺采用SATA做條帶RAID的機器可以應付，反而是自己做異步備份比較復雜，因為小文件多。如果只有一臺機器做存儲，可以做簡單的優化，例如放最小縮略圖的分區和放中等縮略圖的分區，根據平均大小調整一下塊大小。存儲要規劃好目錄結構，否則文件增多后維護起來復雜，也不利于擴展。同時還要考慮將來擴容，例如采用LVM，或者把文件根據不同規則散列到不同機器。磁盤IO繁重的情況下更容易出現故障，所以要做好備份，若發現有盤壞掉，要馬上行動更換，很多人的硬盤都是壞了一塊之后，接二連三的壞下去。
為了將來圖片走cdn做準備，一開始最好就將圖片的域名分開，且不用主域名。因為很多網站都將cookie設置到了.domain.ltd，如果圖片也在這個域名下，很可能因為cookie而造成緩存失效，并且占多余流量，還可能因為瀏覽器并發線程限制造成訪問緩慢。
九、程序
一定硬件條件下，應用能承載多少訪問量，很大一部分也取決于程序如何寫。程序寫的不好，可能一萬的訪問都承載不了，寫的好，可能一兩臺機器就能承擔幾百萬PV。越是復雜、數據實時性要求越高的應用，優化起來越難，但對普通網站有一個統一的思路，就是盡量向前端優化、減少數據庫操作、減少磁盤IO。向前端優化指的是，在不影響功能和體驗的情況下，能在瀏覽器執行的不要在服務端執行，能在緩存服務器上直接返回的不要到應用服務器，程序能直接取得的結果不要到外部取得，本機內能取得的數據不要到遠程取，內存能取到的不要到磁盤取，緩存中有的不要去數據庫查詢。減少數據庫操作指減少更新次數、緩存結果減少查詢次數、將數據庫執行的操作盡可能的讓你的程序完成（例如join查詢），減少磁盤IO指盡量不使用文件系統作為緩存、減少讀寫文件次數等。程序優化永遠要優化慢的部分，換語法是無法“優化”的。
然而編程時不應該把重點放在優化上，應該關注擴展性。當今的WEB應用，需求變化非常之快，適應多種需求的架構是不存在的，我們的擴展性就要把要點放在跟底層交互的架構上，例如持久化數據的存取規則、緩存的存取規則等，還有一些共用服務，例如用戶信息等。先把不變的部分做完善，剩下的部分就很容易將精力放在業務邏輯上面了。
關于作者
劉志一，從1999年做個人網站開始一直專注于互聯網，目前就職于一家垂直行業C2C網站，做產品和開發方面工作。
我們專注高端建站，小程序開發、軟件系統定制開發、BUG修復、物聯網開發、各類API接口對接開發等。十余年開發經驗，每一個項目承諾做到滿意為止，多一次對比，一定讓您多一份收獲！
