試談百萬級訪問網(wǎng)站前期的技術(shù)準備-閱讀頁
2025-07-29 02:12本頁面
【正文】 從DB服務(wù)器并可能分片，有緩存，有可擴展的存儲。別著急看經(jīng)典句式，我思維跳躍了，插一段。對于當今的計算機和語言解釋器，多 幾層少幾層對象調(diào) 用、聲明變量為Map還是HashMap這種問題是最后才需要考慮的問題，永遠要考慮系統(tǒng)最慢的部分，從最慢的部分解決。我們做的是web應用開發(fā)，不是底層框架API，代碼易讀易懂是保證質(zhì)量很重要的一方面，你的程序是為了什 么而設(shè)計，有不同的方法……算了，這個話題另起一篇文章來說，扯遠了，想交流可關(guān)注我的微博 ，咱繼續(xù)……前面講到，WEB 服務(wù)器是要做負載均衡的，圖片服務(wù)器是要分開的。 如果有可能，最好在一開始就做好用戶單點認證的統(tǒng)一接口，包括跨域如何判斷狀態(tài)、靜態(tài)頁面如何判斷狀態(tài)，需要登錄時的跳轉(zhuǎn)和返回參數(shù)定義，底層給好接口， 應用層直接就用（可參考GAE的 user服務(wù)）。圖片服務(wù)器分開，資源文件最好也布局到圖片服務(wù)器，也就是WEB服務(wù)器只服務(wù)動態(tài)程序。程序引用資源文件時，要有一個 統(tǒng)一的處理方法，在方法內(nèi)部可以自動完成很多事情，例如將css/js根據(jù)組合，拼成一個文件，或者自動在生成的URI后面加上QUERYSTRING， 如果將來前端用了緩存服務(wù)，那生成QUERYSTRING是最簡單的刷新服務(wù)端緩存和客戶端緩存的辦法。我們程序在處理數(shù)據(jù)的過程中，最好能抽象出來單獨放做一層。這 個數(shù)據(jù)層內(nèi)部不要怕寫的難看，但一定要提供所有的數(shù)據(jù)存儲功能，其他任何層次不要看到跟數(shù)據(jù)庫打交道的字眼。在數(shù)據(jù)層面的設(shè)計上，盡量避免JOIN查詢，我們可以多做 冗余，多做緩存，每種數(shù)據(jù)盡量只需要一次查詢，然后在你的程序里面進行組合。在對于主鍵的處理上，避免使用自增ID，可以用一定規(guī)則生成的唯一值當做主鍵，這種主鍵是最簡單的分片分布策略。前面講到，咱數(shù)據(jù)庫前面還有某些緩存擋著。緩存跟數(shù)據(jù)庫和業(yè)務(wù)結(jié)合的很緊密，正因為跟業(yè)務(wù)關(guān)系緊密，所以這點沒有放之四海而皆準的方法。規(guī) 則一：越接近前端，緩存的顆粒度越大。因為越靠近后端，我們 的可操作性越靈活，并且變化最多的前端代碼也比較方便編寫。規(guī)則二：沒有緩存時程序不能出錯。在緩存必不可少的情況下，給用戶出錯信息都比給一個讓人誤 解的信息強。規(guī)則四：緩存也是有成本的。如果一個功能使用緩存和不使用， 在可預見的訪問量情況下區(qū)別微小，但使用緩存會使復雜度增加，那就不用，我們可以加個TODO標注，在下次迭代的時候加上緩存處理。可以在文件服務(wù)器上提供一個很簡單的RESTful接口，也可以提供xmlrpc 或json serveice，WEB服務(wù)器端所生成和處理的文件，全部通過接口通知文件服務(wù)器去處理，WEB服務(wù)器本身不要提供任何文件存儲。以上幾條“前面講到”，其實無數(shù)人都講過，我也只是結(jié)合前幾篇文章用自己的話重復了一遍，真正分析起來精髓很簡單——除了良好的功能邏輯分層，我們 還要為數(shù)據(jù)庫存儲、緩存、隊列、文件服務(wù)等程序外層資源調(diào)用單獨設(shè)計接口，你可以把你的程序想象成是運行在 Amazon EC2 上并用他的所有web service服務(wù)，你的數(shù)據(jù)庫就是它的SimpleDB，你的隊列就是他的SQS，你的存儲就是他的S3，唯一不同是amazon的接口是遠程調(diào)用，你的是內(nèi)部調(diào)用。對程序掃盲不感興趣的直接看這里——產(chǎn)品設(shè)計完了，程序框架搭完了，可能有矛盾在這個節(jié)骨眼兒產(chǎn)生了。這種抱怨多緣于產(chǎn)品人員不懂技術(shù)，技術(shù)人員不理解產(chǎn)品。若可以，爭議解決。因為一個功能的 加強而引發(fā)指標井噴，或因項目拖延而導致貽誤戰(zhàn)機的例子比比皆是。關(guān)系到未來的事情誰都說不準，要不怎么說創(chuàng)業(yè)一半靠運氣呢。沒有100%%的網(wǎng)站安裝了訪問統(tǒng)計代碼，連我的 也不例外，新聞聯(lián)播也總說科學決策科學發(fā)展的。例如，可以根據(jù)來源目標轉(zhuǎn)化率來分析哪類渠道的人均獲取成本低，根據(jù)來 源內(nèi)容訪問猜測用戶跳出率原因，根據(jù)用戶點擊行為判斷鏈接位置是否合理等?？繑?shù)據(jù)支撐運營是個非常專業(yè)的事情，雖然不懂深奧的數(shù)學模型不會復雜的公式計算，漸漸學會因為A所以B，因為A和B所以C還是相對簡
外語相關(guān)推薦
鄂ICP備17016276號-1