試談百萬級訪問網站前期的技術準備

1、對互聯(lián)網有了解的人都有自己的方法，有人就把方法付諸實現(xiàn)，做個網站然后開始運營。事實上從純網站技術上來講，因為開源模式的進展，現(xiàn)在建一個小網站 差不多專門簡單也專門廉價。當訪問量到達一定數量級的時候成本就開始飆升了，問題也開始顯現(xiàn)了。因為帶寬的增加、硬件的擴展、人員的擴張所帶來的成本提高是顯而 易見的，而還有相當大的一部分成本是因為代碼重構、架構重構，甚至底層開發(fā)語言更換引起的，最慘的確實是數據丟失，辛辛苦苦好幾年，一夜回到創(chuàng)業(yè)前。減少成本確實是增加利潤。專門多情況，我們在一開始就能夠幸免，先打好基礎，往后能夠省專門多精力，少操專門多心。假設你是一個參與創(chuàng)業(yè)的技術人員，當前一窮二白，什么都要自己

2、做，自己出鈔票，初期幾十萬的資金，做一個應用不是特不復雜的網站，那么就要注意以下幾點：一、開發(fā)語言一般來講，技術人員（程序員）創(chuàng)業(yè)差不多上依照自己技術背景選擇自己最熟悉的語言，只是考慮到不可能永久是您一個人寫程序，這點還得認真想想。不管用什么語言，最終代碼質量是看治理，因此我們依舊從純語言層面來講實際一點?，F(xiàn)在流行的 HYPERLINK /zh_CN/ t _blank java、 HYPERLINK t _blank php、 HYPERLINK /net/ t _blank .net、 HYPERLINK / t _blank python、 HYPERLINK /en/ t _blank

3、 ruby都 有自己的優(yōu)劣，python和ruby，現(xiàn)在人員依舊相對難招一些，性能優(yōu)化也會費些力氣，.net平臺買不起windows server。java、php用的依舊最多。關于初期，應用幾乎差不多上靠前端支撐的網站來講，php的優(yōu)勢稍大一些，入門簡單、設計模式簡單、寫起來快、 性能足夠等，只是不注重設計模式也是它的劣勢，容易變得松散，隱藏bug稍多、難以維護。java的優(yōu)勢在于整套治理流程差不多有專門多成熟工具來輔助，強類 型也能幸免一些弱智BUG，大多數JAVA程序員比較注重設計模式，不管實不實際，代碼格式看起來依舊不錯的。這也是個劣勢，初學者可能太注重模式而專門難 解決實際需求。前端

4、不只是html、css這類。整個負責跟用戶交互的部分差不多上前端，包括處理程序。這類程序依舊建議用php，要緊緣故確實是開發(fā)迅速、從業(yè)人員廣泛。至于后端例如行為分析、銀行接口、異步消息處理等，隨便用什么程序，那個只能是依照不同業(yè)務需求來選擇不同語言了。二、代碼版本治理假如開發(fā)人員之間的網絡速度差不多，就 HYPERLINK / t _blank SVN；比較分散例如跨國，就 HYPERLINK / o Mercurial SCM(hg) t _blank hg。大多數人依舊svn的.假設選了svn，那么有幾點考慮。一是采納什么樹結構。初期可能只有一條主干，往后就需要建立分支，例如一條開發(fā)分支，

5、一條上線分支，再往后，可能 要每個小組一個分支。建議一開始人少時選擇兩條分支，開發(fā)和線上，每個功能本地測試無誤后提交到開發(fā)分支，最后統(tǒng)一測試，能夠上線時合并到上線分支。假如 喜愛把svn當做移動硬盤用，寫一點就commit一次也無所謂，確實是合并的時候頭大一些，這些人能夠自己建個分支甚至建立個本地代碼倉庫，隨便往自己的 分支提交，測試完畢后再提交到開發(fā)分支上。部署，能夠手工部署也能夠自動部署。手工部署相對簡單，一般是直接在服務器上svn update，或者找個新目錄svn checkout，再把web root給ln -s過去。應用越復雜，部署越復雜，沒有什么統(tǒng)一標準，只要不再用ftp上傳那種

6、形式就好，一是上傳時文件引用不一致錯誤率增加，二是專門容易出現(xiàn)開發(fā)人員 的版本跟線上版本不一致，導致本來想改個錯字結果變成回滾的杯具。假如有多臺服務器依舊建議自動部署，更換代碼的機器從當前服務池中臨時撤出，更新完畢后 再重新加入。不管項目多小，養(yǎng)成使用版本治理的好適應，最起碼還能夠當做你的備份，我的 HYPERLINK http:/zhiyi.us http:/zhiyi.us 盡管確實是一個wordpress，可依舊svn了，只改動一兩句css那也是勞動成果。三、服務器硬件不艷羨大客戶和有鈔票人，看看機房散戶區(qū)，一臺服務器孤獨的支撐的網站數不清。假如資金略微充足，建議至少三臺的標準配置，分不

7、用作web處理、數據 庫、備份。web服務器至少要8G內存，雙sata raid1，假如經濟略微寬松，或靜態(tài)文件或圖片多，則15k sas raid1+0。數據庫至少16G內存，15k sas raid 1+0。備份服務器最好跟數據庫服務器同等配置。硬件能夠自己買品牌的底板，也確實是機箱配主板和硬盤盒，CPU內存硬盤都自己配，也能夠上整套品牌，也可 以兼容機。三臺機器，市場行情6、7萬也就配齊了。web服務器能夠既跑程序又當內存緩存，數據庫服務器則只跑主數據庫（假如是 HYPERLINK /products/standard/ o MySQL Standard Edition t _blank

8、 MySQL的話），備份服務器干的活就相對多一些，web配置、緩存配置、數據庫配置都要跟前兩臺一致，如此WEB和數據庫任意一臺出問題，把備份服務器換個ip就切換上去了。備份策略，能夠 HYPERLINK / o DRBD t _blank drbd，能夠 HYPERLINK .au/rsync/ o rsync t _blank rsync，或者其他的專門多專門多的開源備份方案可選擇。rsync最簡單，放cron里自己跑就行。備份和切換，建議多做測試，選最安全最適合業(yè)務的，同時盡可能異地備份。四、機房三種機房盡量不要選：聯(lián)通訪問特不慢的電信機房、電信訪問特不慢的聯(lián)通機房、電信聯(lián)通訪問特不慢的移

9、動或鐵通機房。那網通機房呢？親，網通聯(lián)通N久 往常合并改叫聯(lián)通了。多多查找，實地參觀，多多測試，多方打探，北京、上海、廣州等各個主節(jié)點都市，依舊有專門多優(yōu)質機房的，找個網絡質量好，治理嚴格的機 房，特不是治理要嚴格，千萬不網站無法訪問了，打個電話過去才明白不人維護時把你網線碰掉了，這比DOS都頭疼。自己扯了幾根光纖就稱為機房的，看您抗風 險程度和心理素養(yǎng)了。機房能夠講是特不重要，直接關系到網站訪問速度，網站訪問速度直接關系到用戶體驗，我能夠翻墻看風景，但買個網游vpn才能打開你這 個還不如何知名的網站就有難度了。或許您網站的ajax專門出色，但是document如何也不ready，一些代碼永久

10、絕緣于用戶。五、架構初期架構一般比較簡單，web負載均衡+數據庫主從+緩存+分布式存儲+隊列。大方向上也確實就這幾樣東西，細節(jié)上也許多文章都重復過了，按照今后 會有N多WEB，N多主從關系，N多緩存，N多xxx設計就行，差不多方案差不多上現(xiàn)成的，只是您比其他人厲害之處就在于設計上考慮到緩存失效時的雪崩效應、主 從同步的數據一致性和時刻差、隊列的穩(wěn)定性和失敗后的重試策略、文件存儲的效率和備份方式等等意外情況。緩存總有一天會失效，數據庫復制總有一天會斷掉， 隊列總有一天會寫不到里面去，電源總有一天會燒壞。依照墨菲定律，假如不考慮這些，網站早晚會成為茶幾。六、服務器軟件Linux、 HYPERLIN

11、K / o nginx t _blank nginx、php、mysql，幾乎是標配，我們除了看名字，還得選版本。Linux發(fā)行版眾多，只要沒專門要求，就選個用的人最多的，社區(qū)最活躍的，配置最方便的，軟件包最全最新的，例如 HYPERLINK / o Debian t _blank debian、 HYPERLINK o Ubuntu t _blank ubuntu。 至于RHEL之類的嘛，你用只能在RHEL上才能運行的軟件么？剩下的nginx、php、mysql、activemq、其他的等等，除非你改過這些軟 件或你的程序確實不兼容新版本，否則盡量版本越新越好，版本新，意味著新特性增多、BU

12、G減少、性能增加?？傆行┑缆犕局v的人跟你講老的版本穩(wěn)定。所謂穩(wěn) 定，是相關于專門業(yè)務來講的，而就一個php寫的網站，大多數人都沒改過任何服務器軟件源代碼，絕大多數情況是能平穩(wěn)的升級到新版本的。類似于jdk5到 jdk6，python2到python3這類變動比較大的升級依舊比較少見的。看看ChangeLog，看看升級講明，結合自己情況評估一下，越早升級 越好，不人家都用php6寫程序了這邊還php4的逛游呢。優(yōu)秀的開源程序升級依舊專門負責任的，看好文檔，不怕。以上這六點預備完畢，現(xiàn)在我們有了運行環(huán)境，有了差不多架構骨架，有了備份和切換方案，應該開始著手設計開發(fā)方面的情況了。開發(fā)方面的情況許多，

13、下一篇會先講一些重點。七、數據庫幾乎所有操作最后都要落到數據庫身上，它又最難擴展（存儲也挺難）。關于mysql，什么樣的表用myisam，什么樣的表用innodb，在開發(fā) 之前要確定。復制策略、分片策略，也要確定。表引擎方面，一般，更新不多、不需要事務的表能夠用myisam，需要行鎖定、事務支持的，用innodb。 myisam的鎖表不一定是性能低下的根源，innodb也不一定全是行鎖，具體細節(jié)要多看相關的文檔，熟悉了引擎特性才能用的更好?，F(xiàn)代WEB應用越來 越復雜了，我們設計表結構時常常設計專門多冗余，盡管不符合傳統(tǒng)范式，但為了速度考慮依舊值得的，要求高的情況下甚至要杜絕聯(lián)合查詢。編程時得多

14、注意數據一 致性。復制策略方面，多主多從結構也最好一開始就設計好，代碼直接按照多主多從來編寫，用一些小技巧來幸免復制延時問題，同時還要解決多數據庫數據是否一致，能夠自己寫或者找現(xiàn)成的運維工具。分片策略?？倳心敲磶讉€表數據量超大，這時分片必不可免。分片有專門多策略，從簡單的分區(qū)到依照熱度自動調整，依照具體業(yè)務選擇一個適合自己的。幸免自增ID作為主鍵，不利于分片。用存儲過程是比較難擴展的，這種情形多發(fā)生于傳統(tǒng)C/S，特不是OA系統(tǒng)轉換過來的開發(fā)人員。低成本網站不是一兩臺小型機跑一個數據庫處理所有業(yè)務的模式，是機海作戰(zhàn)。方便水平擴展比那點預分析時刻和網絡傳輸流量要重要的多的多。NoSQL。這只是一

15、個概念。實際應用中，網站有著越來越多的密集寫操作、上億的簡單關系數據讀取、熱備等，這都不是傳統(tǒng)關系數據庫所擅長的，因此 就產生了專門多非關系型數據庫，比如Redis/TC&TT/MongoDB/Memcachedb等，在測試中，這些幾乎都達到了每秒至少一萬次 的寫操作，內存型的甚至5萬以上。例如MongoDB，幾句配置就能夠組建一個復制+自動分片+failover的環(huán)境，文檔化的存儲也簡化了傳統(tǒng)設計庫 結構再開發(fā)的模式。專門多業(yè)務是能夠用這類數據庫來替代mysql的。八、緩存。數據庫專門脆弱，一定要有緩存在前面擋著，事實上我們優(yōu)化速度，幾乎確實是優(yōu)化緩存，能用緩存的地點，就不要再跑到后端數據庫

16、那折騰。緩存有持久化緩存、 內存緩存，生成靜態(tài)頁面是最容易理解的持久化緩存了，還有專門多比如varnish的分塊緩存、前面提到的memcachedb等，內存緩 存，memcached首當其沖。緩存更新可用被動更新和主動更新。被動更新的好處是設計簡單，緩存空了就自動去數據庫取數據再把緩存填上，但容易引發(fā)雪 崩效應，一旦緩存大面積失效，數據庫的壓力直線上升專門可能掛掉。主動緩存可幸免這點然而可能引發(fā)程序取不到數據的問題。這兩者之間如何配合，程序設計要多 動腦筋。九、隊列。用戶一個操作專門可能引發(fā)一系列資源和功能的調動，這些調動假如同時發(fā)生，壓力無法操縱，用戶體驗也不行，能夠把如此一些操作放入隊列，

17、由另幾個模塊 去異步執(zhí)行，例如發(fā)送郵件，發(fā)送手機短信。開源隊列服務器專門多，性能要求不高用數據庫當做隊列也能夠，只要保證程序讀寫隊列的接口不變，底層隊列服務可隨 時更換就能夠，類似Zend Framework里的Zend_Queue類，java.util.Queue接口等。十、文件存儲。除了結構化數據，我們經常要存放其他的數據，像圖片之類的。這類數據數量繁多、訪問量大。典型的確實是圖片，從用戶頭像到用戶上傳的照片，還要生成不 同的縮略圖尺寸。存儲的分布幾乎跟數據庫擴展一樣困難。不使用專業(yè)存儲的情況下，差不多差不多上靠自己的NAS。這就涉及到結構。拿圖片存儲舉例，圖片是特不容 易產生熱點的，有些

18、圖片上傳后就不再有人看，有些可能每天被訪問數十萬次，而且大量小文件的異步備份也專門耗費時刻。為了今后圖片走cdn做預備，一開始最好就將圖片的域名分開，且不用主域名。專門多網站都將cookie設置到了.domain.ltd，假如圖片也在那個域名下，專門可能因為cookie而造成緩存失效，同時占多余流量，還可能因為掃瞄器并發(fā)線程限制造成訪問緩慢。假如用一般的文件系統(tǒng)存儲圖片，有一個簡單的方法。計算文件的hash值，比如md5，以結果第一位作為第一級目錄，如此第一級有16個目錄。從0 到F，能夠把那個字母作為域名，0.到（客戶端dns壓力會增大），還能夠擴展到最多16個NAS集群 上。第二級可用年月

19、例如，201011，第三級用日，第四級可選，依照上傳量，比如am/pm，甚至小時。最終的目錄結構可能會是 e/201008/25/am/e43ae391c839d82801920cf.jpg。rsync備份時能夠用腳本只同步某年某日某時的文件，幸免計 算大量文件帶來的開銷。因此最好是能用專門的分布式文件系統(tǒng)或更專業(yè)點的存儲解決方案。下面，我們要談談代碼了。這一系列的最后一篇寫給一般編程人員，假如不感興趣可直接看本文最后幾段。開始設計代碼結構之前，先回憶一下之前預備過的情況：我們有負載均衡的 WEB服務器，有主從DB服務器并可能分片，有緩存，有可擴展的存儲。在組織代碼的各個方面，跟這些預備息息相

20、關，我一二三的列出來分不講，同時每一條都 以“前面講到”那個經典句式開頭，為了方便對比。不著急看經典句式，我思維跳躍了，插一段。實際開發(fā)中，我們總會在性能和代碼優(yōu)雅性上作折中。關于當今的計算機和語言解釋器，多 幾層少幾層對象調 用、聲明變量為Map依舊HashMap這種問題是最后才需要考慮的問題，永久要考慮系統(tǒng)最慢的部分，從最慢的部分解決。例如看看你用的ORM是不是做了 專門多你用不到的情況，是不是有重復的數據調用。我們做的是web應用開發(fā)，不是底層框架API，代碼易讀易明白是保證質量專門重要的一方面，你的程序是為了什 么而設計，有不同的方法罷了，那個話題另起一篇文章來講，扯遠了，想交流可關注

21、我的微博 HYPERLINK /liuzhiyi /liuzhiyi，咱接著 HYPERLINK http:/zhiyi.us/internet/thinking-twice-before-building-your-site-one.html 前面講到，WEB 服務器是要做負載均衡的，圖片服務器是要分開的。關于這點，代碼在處理客戶端狀態(tài)時，不要把狀態(tài)放到單機上，舉例，不要用文件session，嗯，常識。 假如有可能，最好在一開始就做好用戶單點認證的統(tǒng)一接口，包括跨域如何推斷狀態(tài)、靜態(tài)頁面如何推斷狀態(tài)，需要登錄時的跳轉和返回參數定義，底層給好接口， 應用層直接就用（可參考 HYPERLINK

22、/intl/zh-CN/appengine/ GAE的 user服務）。登錄方面的設計要考慮移動設備的特性，比如電腦能夠用浮動層窗口，但NOKIA自帶的掃瞄器或UCWEB就無法處理這種表現(xiàn)形式，程序一 定既能處理AJAX請求又能直接通過URL來處理請求。圖片服務器分開，資源文件最好也布局到圖片服務器，也確實是WEB服務器只服務動態(tài)程序。盡管開發(fā)測 試時略微復雜（因為需要絕對URI才能訪問），但今后頁面前端優(yōu)化上會輕松許多，同時你的WEB服務器IO優(yōu)化也輕松許多。程序引用資源文件時，要有一個 統(tǒng)一的處理方法，在方法內部能夠自動完成專門多情況，例如將css/js依照組合，拼成一個文件，或者自動在生

23、成的URI后面加上QUERYSTRING， 假現(xiàn)在后前端用了緩存服務，那生成QUERYSTRING是最簡單的刷新服務端緩存和客戶端緩存的方法。 HYPERLINK http:/zhiyi.us/internet/thinking-twice-before-building-your-site-two.html 前面講到， 數據庫會有復制，可能會多主多從，可能會分片。我們程序在處理數據的過程中，最好能抽象出來單獨放做一層。拿現(xiàn)在流行的MVC模式來講，確實是在M層下方再 放一個數據層，那個數據層不是通常所講的JDBC/PDO/ActiveRecord等，而是你自己的存取數據層，僅對外暴露方法，隱藏

24、數據存取細節(jié)。這 個數據層內部不要怕寫的難看，但一定要提供所有的數據存儲功能，其他任何層次不要看到跟數據庫打交道的字眼。之因此如此做，是因為在單關系數據庫的情況 下，可能會SELECTJOIN或直接INSERTINTO，可你可能會將一些表放到key-value數據庫里存儲，或者分片，這么做之后原來 的語句和方式要全部改變，假如過于分散，則移植時會耗費專門大精力，或得到一個專門大的Model。在數據層面的設計上，盡量幸免JOIN查詢，我們能夠多做 冗余，多做緩存，每種數據盡量只需要一次查詢，然后在你的程序里面進行組合。關于比較復雜的數據組合，在實時性要求不高的情況下，可采納異步處理，用戶訪 問時

25、只取處理后的結果。在關于主鍵的處理上，幸免使用自增ID，能夠用一定規(guī)則生成的唯一值當做主鍵，這種主鍵是最簡單的分片分布策略。即使用自增ID， 也最好用一個自增ID發(fā)生器，否則從數據庫不小心被寫了一下，那主鍵專門容易沖突。前面講到，咱數據庫前面還有某些緩存擋著。不把mysql的query cache當緩存，應用稍復雜的時候QUERY CACHE反而會成為累贅。緩存跟數據庫和業(yè)務結合的專門緊密，正因為跟業(yè)務關系緊密，因此這點沒有放之四海而皆準的方法。但我們依舊有一些規(guī)則可參照。規(guī) 則一：越接近前端，緩存的顆粒度越大。例如在WEB最前端緩存整個頁面，再往后一層緩存部分頁面區(qū)域，再往后緩存區(qū)域內的單條

26、記錄。因為越靠近后端，我們 的可操作性越靈活，同時變化最多的前端代碼也比較方便編寫。在實踐中，因為產品需求變化速度特不快，迭代周期越來越短，有時專門難將Controller和 Model分的那么清晰，Controller層面處理部分緩存必不可免，但要保證假如出現(xiàn)這種情況，Controller所操作的緩存一定不要阻礙其他 數據需求方，也確實是要保證那個緩存數據只有這一個Controller在用。規(guī)則二：沒有緩存時程序不能出錯。在不考慮緩存失效引發(fā)的雪崩效應時，你的程 序要有緩存跟沒緩存一個樣，不能像新浪微博一樣，緩存一失效，粉絲微博全空，整個應用都亂套了。在緩存必不可少的情況下，給用戶出錯信息都

27、比給一個讓人誤 解的信息強。規(guī)則三，緩存更新要保證原子性或稱作線程安全，特不是采納被動緩存的方式時，專門可能兩個用戶訪問時導致同一個緩存被更新，通常情況這不是大問 題，可緩存失效后重建時專門可能是引發(fā)連鎖反應的緣故之一。規(guī)則四：緩存也是有成本的。不只是技術成本，還有人工時刻成本。假如一個功能使用緩存和不使用， 在可預見的訪問量情況下區(qū)不微小，但使用緩存會使復雜度增加，那就不用，我們能夠加個TODO標注，在下次迭代的時候加上緩存處理。前面講到，文件存儲是獨立的，那么所有的文件操作就差不多上遠程調用。能夠在文件服務器上提供一個專門簡單的RESTful接口，也能夠提供xmlrpc 或json serveice，WEB服務器端所生成和處理的文件，全部通過接口通知文件服務器去處理，WEB服務器本身不要提供任何文件存儲。你會發(fā)覺專門多大網站的 上傳圖片跟保存文章是分兩步完成的，確實是基于那個緣故。以上幾條“前面講到”，事實上許多人都講過，我也只是結合前幾篇文章用自己的話重復了一遍，真正分析起來精髓專門簡單除了良好的功能邏輯分層，我們 還要為數據庫存儲、緩存、隊列、文件服務等程序外層資源調用單獨設計接口，你能夠把你的程序想象成是運行在 Amazon EC2