試談百萬(wàn)級(jí)訪問(wèn)網(wǎng)站前期的技術(shù)準(zhǔn)備

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

2、做，自己出鈔票，初期幾十萬(wàn)的資金，做一個(gè)應(yīng)用不是特不復(fù)雜的網(wǎng)站，那么就要注意以下幾點(diǎn)：一、開(kāi)發(fā)語(yǔ)言一般來(lái)講，技術(shù)人員（程序員）創(chuàng)業(yè)差不多上依照自己技術(shù)背景選擇自己最熟悉的語(yǔ)言，只是考慮到不可能永久是您一個(gè)人寫(xiě)程序，這點(diǎn)還得認(rèn)真想想。不管用什么語(yǔ)言，最終代碼質(zhì)量是看治理，因此我們依舊從純語(yǔ)言層面來(lái)講實(shí)際一點(diǎn)?，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)在人員依舊相對(duì)難招一些，性能優(yōu)化也會(huì)費(fèi)些力氣，.net平臺(tái)買不起windows server。java、php用的依舊最多。關(guān)于初期，應(yīng)用幾乎差不多上靠前端支撐的網(wǎng)站來(lái)講，php的優(yōu)勢(shì)稍大一些，入門簡(jiǎn)單、設(shè)計(jì)模式簡(jiǎn)單、寫(xiě)起來(lái)快、 性能足夠等，只是不注重設(shè)計(jì)模式也是它的劣勢(shì)，容易變得松散，隱藏bug稍多、難以維護(hù)。java的優(yōu)勢(shì)在于整套治理流程差不多有專門多成熟工具來(lái)輔助，強(qiáng)類 型也能幸免一些弱智BUG，大多數(shù)JAVA程序員比較注重設(shè)計(jì)模式，不管實(shí)不實(shí)際，代碼格式看起來(lái)依舊不錯(cuò)的。這也是個(gè)劣勢(shì)，初學(xué)者可能太注重模式而專門難 解決實(shí)際需求。前端

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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