建站
咨詢
售后
建站咨詢
開始設計代碼結構之前，先回顧一下之前準備過的事情：我們有負載均衡的WEB服務器，有主從DB服務器并可能分片，有緩存，有可擴展的存儲。在組織代碼的各個方面，跟這些準備息息相關，我一二三的列出來分別說，并且每一條都以“前面講到”這個經(jīng)典句式開頭，為了方便對照。
10年積累的成都網(wǎng)站設計、網(wǎng)站建設經(jīng)驗，可以快速應對客戶對網(wǎng)站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡服務。我雖然不認識你，你也不認識我。但先網(wǎng)站設計后付款的網(wǎng)站建設流程，更有黑龍江免費網(wǎng)站建設讓你可以放心的選擇與我們合作。
向您推薦：詳述***訪問網(wǎng)站前期的技術準備(上篇)
別著急看經(jīng)典句式，我思維跳躍了，插一段。實際開發(fā)中，我們總會在性能和代碼優(yōu)雅性上作折中。對于當今的計算機和語言解釋器，多幾層少幾層對象調用、聲明變量為Map還是HashMap這種問題是***才需要考慮的問題，永遠要考慮系統(tǒng)最慢的部分，從最慢的部分解決。例如看看你用的ORM是不是做了很多你用不到的事情，是不是有重復的數(shù)據(jù)調用。我們做的是web應用開發(fā)，不是底層框架API，代碼易讀易懂是保證質量很重要的一方面，你的程序是為了什么而設計，有不同的方法……算了，這個話題另起一篇文章來說，扯遠了，想交流可關注我的微博 http://t.sina.com.cn/liuzhiyi，咱繼續(xù)……
前面講到，WEB服務器是要做負載均衡的，圖片服務器是要分開的。對于這點，代碼在處理客戶端狀態(tài)時，不要把狀態(tài)放到單機上，舉例，不要用文件session，嗯，常識。如果有可能，***在一開始就做好用戶單點認證的統(tǒng)一接口，包括跨域如何判斷狀態(tài)、靜態(tài)頁面如何判斷狀態(tài)，需要登錄時的跳轉和返回參數(shù)定義，底層給好接口，應用層直接就用（可參考GAE的user服務）。登錄方面的設計要考慮移動設備的特性，比如電腦可以用浮動層窗口，但NOKIA自帶的瀏覽器或UCWEB就無法處理這種表現(xiàn)形式，程序一定既能處理AJAX請求又能直接通過URL來處理請求。圖片服務器分開，資源文件***也布局到圖片服務器，也就是WEB服務器只服務動態(tài)程序。雖然開發(fā)測試時稍微復雜（因為需要絕對URI才能訪問），但將來頁面前端優(yōu)化上會輕松許多，并且你的WEB服務器IO優(yōu)化也輕松許多。程序引用資源文件時，要有一個統(tǒng)一的處理方法，在方法內部可以自動完成很多事情，例如將css/js根據(jù)組合，拼成一個文件，或者自動在生成的URI后面加上QUERYSTRING，如果將來前端用了緩存服務，那生成QUERYSTRING是最簡單的刷新服務端緩存和客戶端緩存的辦法。
前面講到，數(shù)據(jù)庫會有復制，可能會多主多從，可能會分片。我們程序在處理數(shù)據(jù)的過程中，***能抽象出來單獨放做一層。拿現(xiàn)在流行的MVC模式來說，就是在M層下方再放一個數(shù)據(jù)層，這個數(shù)據(jù)層不是通常所說的JDBC/PDO/ActiveRecord等，而是你自己的存取數(shù)據(jù)層，僅對外暴露方法，隱藏數(shù)據(jù)存取細節(jié)。這個數(shù)據(jù)層內部不要怕寫的難看，但一定要提供所有的數(shù)據(jù)存儲功能，其他任何層次不要看到跟數(shù)據(jù)庫打交道的字眼。之所以這樣做，是因為在單關系數(shù)據(jù)庫的情況下，可能會SELECT…JOIN…或直接INSERT…INTO…，可你可能會將一些表放到key-value數(shù)據(jù)庫里存儲，或者分片，這么做之后原來的語句和方式要全部改變，如果過于分散，則移植時會耗費很大精力，或得到一個很大的Model。在數(shù)據(jù)層面的設計上，盡量避免JOIN查詢，我們可以多做冗余，多做緩存，每種數(shù)據(jù)盡量只需要一次查詢，然后在你的程序里面進行組合。對于比較復雜的數(shù)據(jù)組合，在實時性要求不高的情況下，可采用異步處理，用戶訪問時只取處理后的結果。在對于主鍵的處理上，避免使用自增ID，可以用一定規(guī)則生成的唯一值當做主鍵，這種主鍵是最簡單的分片分布策略。即使用自增ID，也***用一個自增ID發(fā)生器，否則從數(shù)據(jù)庫不小心被寫了一下，那主鍵很容易沖突。
前面講到，咱數(shù)據(jù)庫前面還有某些緩存擋著。別把mysql的query cache當緩存，應用稍復雜的時候QUERY CACHE反而會成為累贅。緩存跟數(shù)據(jù)庫和業(yè)務結合的很緊密，正因為跟業(yè)務關系緊密，所以這點沒有放之四海而皆準的方法。但我們還是有一些規(guī)則可參照。規(guī)則一：越接近前端，緩存的顆粒度越大。例如在WEB最前端緩存整個頁面，再往后一層緩存部分頁面區(qū)域，再往后緩存區(qū)域內的單條記錄。因為越靠近后端，我們的可操作性越靈活，并且變化最多的前端代碼也比較方便編寫。在實踐中，因為產(chǎn)品需求變化速度非?？欤芷谠絹碓蕉?，有時很難將Controller和Model分的那么清楚，Controller層面處理部分緩存必不可免，但要保證如果出現(xiàn)這種情況，Controller所操作的緩存一定不要影響其他數(shù)據(jù)需求方，也就是要保證這個緩存數(shù)據(jù)只有這一個Controller在用。規(guī)則二：沒有緩存時程序不能出錯。在不考慮緩存失效引發(fā)的雪崩效應時，你的程序要有緩存跟沒緩存一個樣，不能像新浪微博一樣，緩存一失效，粉絲微博全空，整個應用都亂套了。在緩存必不可少的情況下，給用戶出錯信息都比給一個讓人誤解的信息強。規(guī)則三，緩存更新要保證原子性或稱作線程安全，特別是采用被動緩存的方式時，很可能兩個用戶訪問時導致同一個緩存被更新，通常情況這不是大問題，可緩存失效后重建時很可能是引發(fā)連鎖反應的原因之一。規(guī)則四：緩存也是有成本的。不只是技術成本，還有人工時間成本。如果一個功能使用緩存和不使用，在可預見的訪問量情況下區(qū)別微小，但使用緩存會使復雜度增加，那就不用，我們可以加個TODO標注，在下次迭代的時候加上緩存處理。
前面講到，文件存儲是獨立的，那么所有的文件操作就都是遠程調用?？梢栽谖募掌魃咸峁┮粋€很簡單的RESTful接口，也可以提供xmlrpc或json serveice，WEB服務器端所生成和處理的文件，全部通過接口通知文件服務器去處理，WEB服務器本身不要提供任何文件存儲。你會發(fā)現(xiàn)很多大網(wǎng)站的上傳圖片跟保存文章是分兩步完成的，就是基于這個原因。
以上幾條“前面講到”，其實無數(shù)人都講過，我也只是結合前幾篇文章用自己的話重復了一遍，真正分析起來精髓很簡單——除了良好的功能邏輯分層，我們還要為數(shù)據(jù)庫存儲、緩存、隊列、文件服務等程序外層資源調用單獨設計接口，你可以把你的程序想象成是運行在 Amazon EC2 上并用他的所有web service服務，你的數(shù)據(jù)庫就是它的SimpleDB，你的隊列就是他的SQS，你的存儲就是他的S3，唯一不同是amazon的接口是遠程調用，你的是內部調用。
將支撐服務接口化，意味著將MySQL更換到PostgreSQL不需要更改業(yè)務處理程序，移植團隊甚至不需要跟業(yè)務開發(fā)團隊過多溝通；意味著業(yè)務開發(fā)團隊是對接口編程而不是對數(shù)據(jù)庫編程；意味著不會因為某個業(yè)務開發(fā)人員的失誤而拖垮性能。
對程序掃盲不感興趣的直接看這里——
產(chǎn)品設計完了，程序框架搭完了，可能有矛盾在這個節(jié)骨眼兒產(chǎn)生了。不斷有產(chǎn)品設計抱怨說他的創(chuàng)意沒實現(xiàn)到預期效果，有程序員抱怨說產(chǎn)品設計不切實際。這種抱怨多緣于產(chǎn)品人員不懂技術，技術人員不理解產(chǎn)品。從廣義上來講，產(chǎn)品包含市場策略、營銷手段、功能設計，產(chǎn)品和技術在爭論時往往把焦點放在功能上，而實際重點是，實現(xiàn)這個功能所消耗的成本跟能這個功能帶來的利益能否換算，能否取其輕重。若可以，爭議解決。若不能，則拋硬幣看運氣。因為一個功能的加強而引發(fā)指標井噴，或因項目拖延而導致貽誤戰(zhàn)機的例子比比皆是。激進的決策者注重利益，保守的決策者注重損失，聰明的決策者會考慮這個問題是否真的那么嚴重。
關系到未來的事情誰都說不準，要不怎么說創(chuàng)業(yè)一半靠運氣呢。不過總有能說的準的事情，那就得靠數(shù)據(jù)說話。
沒有100%也有99.9%的網(wǎng)站安裝了訪問統(tǒng)計代碼，連我的 http://zhiyi.us 也不例外，新聞聯(lián)播也總說科學決策科學發(fā)展的。有了統(tǒng)計，能確定的事情就很多了。例如，可以根據(jù)來源-目標轉化率來分析哪類渠道的人均獲取成本低，根據(jù)來源-內容訪問猜測用戶跳出率原因，根據(jù)用戶點擊行為判斷鏈接位置是否合理等。將數(shù)據(jù)以不同方式組合起來，找到內在聯(lián)系，分析內因外因，制定對應策略，減少拍腦門決策?？繑?shù)據(jù)支撐運營是個非常專業(yè)的事情，雖然不懂深奧的數(shù)學模型不會復雜的公式計算，漸漸學會因為A所以B，因為A和B所以C還是相對簡單的
網(wǎng)站名稱：詳述百萬級訪問網(wǎng)站前期的技術準備(下篇)
鏈接地址：http://www.5511xx.com/article/ccdjess.html
