開(kāi)始設(shè)計(jì)代碼結(jié)構(gòu)之前，先回顧一下之前準(zhǔn)備過(guò)的事情：我們有負(fù)載均衡的WEB服務(wù)器，有主從DB服務(wù)器并可能分片，有緩存，有可擴(kuò)展的存儲(chǔ)。在組織代碼的各個(gè)方面，跟這些準(zhǔn)備息息相關(guān)，我一二三的列出來(lái)分別說(shuō)，并且每一條都以“前面講到”這個(gè)經(jīng)典句式開(kāi)頭，為了方便對(duì)照。

51CTO向您推薦：詳述***訪問(wèn)網(wǎng)站前期的技術(shù)準(zhǔn)備(上篇)

別著急看經(jīng)典句式，我思維跳躍了，插一段。實(shí)際開(kāi)發(fā)中，我們總會(huì)在性能和代碼優(yōu)雅性上作折中。對(duì)于當(dāng)今的計(jì)算機(jī)和語(yǔ)言解釋器，多幾層少幾層對(duì)象調(diào)用、聲明變量為Map還是HashMap這種問(wèn)題是***才需要考慮的問(wèn)題，永遠(yuǎn)要考慮系統(tǒng)最慢的部分，從最慢的部分解決。例如看看你用的ORM是不是做了很多你用不到的事情，是不是有重復(fù)的數(shù)據(jù)調(diào)用。我們做的是web應(yīng)用開(kāi)發(fā)，不是底層框架API，代碼易讀易懂是保證質(zhì)量很重要的一方面，你的程序是為了什么而設(shè)計(jì)，有不同的方法……算了，這個(gè)話題另起一篇文章來(lái)說(shuō)，扯遠(yuǎn)了，想交流可關(guān)注我的微博 http://t.sina.com.cn/liuzhiyi，咱繼續(xù)……

前面講到，WEB服務(wù)器是要做負(fù)載均衡的，圖片服務(wù)器是要分開(kāi)的。對(duì)于這點(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)用層直接就用（可參考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ù)器，也就是WEB服務(wù)器只服務(wù)動(dòng)態(tài)程序。雖然開(kāi)發(fā)測(cè)試時(shí)稍微復(fù)雜（因?yàn)樾枰^對(duì)URI才能訪問(wèn)），但將來(lái)頁(yè)面前端優(yōu)化上會(huì)輕松許多，并且你的WEB服務(wù)器IO優(yōu)化也輕松許多。程序引用資源文件時(shí)，要有一個(gè)統(tǒng)一的處理方法，在方法內(nèi)部可以自動(dòng)完成很多事情，例如將css/js根據(jù)組合，拼成一個(gè)文件，或者自動(dòng)在生成的URI后面加上QUERYSTRING，如果將來(lái)前端用了緩存服務(wù)，那生成QUERYSTRING是最簡(jiǎn)單的刷新服務(wù)端緩存和客戶端緩存的辦法。

前面講到，數(shù)據(jù)庫(kù)會(huì)有復(fù)制，可能會(huì)多主多從，可能會(huì)分片。我們程序在處理數(shù)據(jù)的過(guò)程中，***能抽象出來(lái)單獨(dú)放做一層。拿現(xiàn)在流行的MVC模式來(lái)說(shuō)，就是在M層下方再放一個(gè)數(shù)據(jù)層，這個(gè)數(shù)據(jù)層不是通常所說(shuō)的JDBC/PDO/ActiveRecord等，而是你自己的存取數(shù)據(jù)層，僅對(duì)外暴露方法，隱藏?cái)?shù)據(jù)存取細(xì)節(jié)。這個(gè)數(shù)據(jù)層內(nèi)部不要怕寫的難看，但一定要提供所有的數(shù)據(jù)存儲(chǔ)功能，其他任何層次不要看到跟數(shù)據(jù)庫(kù)打交道的字眼。之所以這樣做，是因?yàn)樵趩侮P(guān)系數(shù)據(jù)庫(kù)的情況下，可能會(huì)SELECT…JOIN…或直接INSERT…INTO…，可你可能會(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)行組合。對(duì)于比較復(fù)雜的數(shù)據(jù)組合，在實(shí)時(shí)性要求不高的情況下，可采用異步處理，用戶訪問(wèn)時(shí)只取處理后的結(jié)果。在對(duì)于主鍵的處理上，避免使用自增ID，可以用一定規(guī)則生成的唯一值當(dāng)做主鍵，這種主鍵是最簡(jiǎn)單的分片分布策略。即使用自增ID，也***用一個(gè)自增ID發(fā)生器，否則從數(shù)據(jù)庫(kù)不小心被寫了一下，那主鍵很容易沖突。

前面講到，咱數(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)的單條記錄。因?yàn)樵娇拷蠖耍覀兊目刹僮餍栽届`活，并且變化最多的前端代碼也比較方便編寫。在實(shí)踐中，因?yàn)楫a(chǎn)品需求變化速度非常快，迭代周期越來(lái)越短，有時(shí)很難將Controller和Model分的那么清楚，Controller層面處理部分緩存必不可免，但要保證如果出現(xiàn)這種情況，Controller所操作的緩存一定不要影響其他數(shù)據(jù)需求方，也就是要保證這個(gè)緩存數(shù)據(jù)只有這一個(gè)Controller在用。規(guī)則二：沒(méi)有緩存時(shí)程序不能出錯(cuò)。在不考慮緩存失效引發(fā)的雪崩效應(yīng)時(shí)，你的程序要有緩存跟沒(méi)緩存一個(gè)樣，不能像新浪微博一樣，緩存一失效，粉絲微博全空，整個(gè)應(yīng)用都亂套了。在緩存必不可少的情況下，給用戶出錯(cuò)信息都比給一個(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ā)現(xiàn)很多大網(wǎng)站的上傳圖片跟保存文章是分兩步完成的，就是基于這個(gè)原因。

以上幾條“前面講到”，其實(shí)無(wú)數(shù)人都講過(guò)，我也只是結(jié)合前幾篇文章用自己的話重復(fù)了一遍，真正分析起來(lái)精髓很簡(jiǎn)單——除了良好的功能邏輯分層，我們還要為數(shù)據(jù)庫(kù)存儲(chǔ)、緩存、隊(duì)列、文件服務(wù)等程序外層資源調(diào)用單獨(dú)設(shè)計(jì)接口，你可以把你的程序想象成是運(yùn)行在 Amazon EC2 上并用他的所有web service服務(wù)，你的數(shù)據(jù)庫(kù)就是它的SimpleDB，你的隊(duì)列就是他的SQS，你的存儲(chǔ)就是他的S3，唯一不同是amazon的接口是遠(yuǎn)程調(diào)用，你的是內(nèi)部調(diào)用。

將支撐服務(wù)接口化，意味著將MySQL更換到PostgreSQL不需要更改業(yè)務(wù)處理程序，移植團(tuán)隊(duì)甚至不需要跟業(yè)務(wù)開(kāi)發(fā)團(tuán)隊(duì)過(guò)多溝通；意味著業(yè)務(wù)開(kāi)發(fā)團(tuán)隊(duì)是對(duì)接口編程而不是對(duì)數(shù)據(jù)庫(kù)編程；意味著不會(huì)因?yàn)槟硞€(gè)業(yè)務(wù)開(kāi)發(fā)人員的失誤而拖垮性能。

對(duì)程序掃盲不感興趣的直接看這里——

產(chǎn)品設(shè)計(jì)完了，程序框架搭完了，可能有矛盾在這個(gè)節(jié)骨眼兒產(chǎn)生了。不斷有產(chǎn)品設(shè)計(jì)抱怨說(shuō)他的創(chuàng)意沒(méi)實(shí)現(xiàn)到預(yù)期效果，有程序員抱怨說(shuō)產(chǎn)品設(shè)計(jì)不切實(shí)際。這種抱怨多緣于產(chǎn)品人員不懂技術(shù)，技術(shù)人員不理解產(chǎn)品。從廣義上來(lái)講，產(chǎn)品包含市場(chǎng)策略、營(yíng)銷手段、功能設(shè)計(jì)，產(chǎn)品和技術(shù)在爭(zhēng)論時(shí)往往把焦點(diǎn)放在功能上，而實(shí)際重點(diǎn)是，實(shí)現(xiàn)這個(gè)功能所消耗的成本跟能這個(gè)功能帶來(lái)的利益能否換算，能否取其輕重。若可以，爭(zhēng)議解決。若不能，則拋硬幣看運(yùn)氣。因?yàn)橐粋€(gè)功能的加強(qiáng)而引發(fā)指標(biāo)井噴，或因項(xiàng)目拖延而導(dǎo)致貽誤戰(zhàn)機(jī)的例子比比皆是。激進(jìn)的決策者注重利益，保守的決策者注重?fù)p失，聰明的決策者會(huì)考慮這個(gè)問(wèn)題是否真的那么嚴(yán)重。

關(guān)系到未來(lái)的事情誰(shuí)都說(shuō)不準(zhǔn)，要不怎么說(shuō)創(chuàng)業(yè)一半靠運(yùn)氣呢。不過(guò)總有能說(shuō)的準(zhǔn)的事情，那就得靠數(shù)據(jù)說(shuō)話。

沒(méi)有100%也有99.9%的網(wǎng)站安裝了訪問(wèn)統(tǒng)計(jì)代碼，連我的 http://zhiyi.us 也不例外，新聞聯(lián)播也總說(shuō)科學(xué)決策科學(xué)發(fā)展的。有了統(tǒng)計(jì)，能確定的事情就很多了。例如，可以根據(jù)來(lái)源-目標(biāo)轉(zhuǎn)化率來(lái)分析哪類渠道的人均獲取成本低，根據(jù)來(lái)源-內(nèi)容訪問(wèn)猜測(cè)用戶跳出率原因，根據(jù)用戶點(diǎn)擊行為判斷鏈接位置是否合理等。將數(shù)據(jù)以不同方式組合起來(lái)，找到內(nèi)在聯(lián)系，分析內(nèi)因外因，制定對(duì)應(yīng)策略，減少拍腦門決策。靠數(shù)據(jù)支撐運(yùn)營(yíng)是個(gè)非常專業(yè)的事情，雖然不懂深?yuàn)W的數(shù)學(xué)模型不會(huì)復(fù)雜的公式計(jì)算，漸漸學(xué)會(huì)因?yàn)锳所以B，因?yàn)锳和B所以C還是相對(duì)簡(jiǎn)單的

原文鏈接：http://zhiyi.us/internet/thinking-twice-before-building-your-site-final.html

【編輯推薦】

1. 大型B2C網(wǎng)站高性能可伸縮架構(gòu)技術(shù)探秘
2. 世界***的PHP站點(diǎn) Facebook后臺(tái)技術(shù)探秘
3. 視頻專題：大型網(wǎng)站架構(gòu)技術(shù)專家談
4. 大型網(wǎng)站架構(gòu)演變和知識(shí)體系
5. 高并發(fā)高負(fù)載的大型網(wǎng)站系統(tǒng)架構(gòu)