建站
咨詢
售后
建站咨詢
新聞中心
相信每一位開發(fā)同學(xué)多多少少都想?yún)⑴c或負(fù)責(zé)一個高用戶、高訪問、高并發(fā)的系統(tǒng)吧。一來可以增加自己實際的項目經(jīng)驗，有應(yīng)對高并發(fā)場景的解決方案，二來是有個高并發(fā)的項目經(jīng)驗無疑是自己簡歷的一個大大的加分項。
從策劃到設(shè)計制作，每一步都追求做到細(xì)膩，制作可持續(xù)發(fā)展的企業(yè)網(wǎng)站。為客戶提供做網(wǎng)站、成都網(wǎng)站設(shè)計、網(wǎng)站策劃、網(wǎng)頁設(shè)計、國際域名空間、虛擬主機、網(wǎng)絡(luò)營銷、VI設(shè)計、 網(wǎng)站改版、漏洞修補等服務(wù)。為客戶提供更好的一站式互聯(lián)網(wǎng)解決方案,以客戶的口碑塑造優(yōu)易品牌,攜手廣大客戶,共同發(fā)展進(jìn)步。
但是奈何很多人都沒有機會可以參與這樣的項目，本文從以下幾點介紹一下設(shè)計一個高流量高并發(fā)的系統(tǒng)需要經(jīng)歷哪些步驟以及考慮哪些因素(文章中的不足之處還請大佬們多多指點)。
高流量高并發(fā)系統(tǒng)關(guān)注點
1、設(shè)計原則
1.1、系統(tǒng)設(shè)計原則
在設(shè)計一個系統(tǒng)之前，我們先要有一個統(tǒng)一且清晰的認(rèn)知：不要想著一下就能設(shè)計出完美的系統(tǒng)，好的系統(tǒng)是迭代出來的。不要復(fù)雜化，要先解決核心問題。但是要有先行的規(guī)劃，對現(xiàn)有的問題有方案，對未來系統(tǒng)有預(yù)案。
在設(shè)計高并發(fā)的系統(tǒng)時要遵循以下幾個原則：
無狀態(tài)原則
什么是無狀態(tài)?服務(wù)器不保存狀態(tài)，對單次請求的處理不依賴別的請求就是無狀態(tài)，主要是為了在應(yīng)對高并發(fā)時方便水平擴展。
拆分原則
在我們的系統(tǒng)體積過于龐大或者承載不了大量的請求時，就要考慮拆分系統(tǒng)，將復(fù)雜問題簡單化或?qū)⒘髁糠稚⒉煌酉到y(tǒng)分擔(dān)壓力?？梢园凑找韵聨讉€維度進(jìn)行拆分：
- 系統(tǒng)維度： 比如電商系統(tǒng)，我們可以拆分成商品、支付、優(yōu)惠券多個子系統(tǒng)。
- 功能維度： 將系統(tǒng)按功能再次拆分。
- 讀寫維度： 按照讀寫比例將服務(wù)拆分成讀服務(wù)和寫服務(wù)。
- 模塊維度： 將系統(tǒng)按照基礎(chǔ)架構(gòu)、消息隊列、分庫分表 、組件等模塊進(jìn)行拆分維護(hù)。
服務(wù)化原則
當(dāng)我們的系統(tǒng)被拆分的足夠大時，一旦發(fā)生故障靠人工來處理是非常耗時耗力。這個時候就可以通過注冊發(fā)現(xiàn)、限流、熔斷、降級等方案讓每個服務(wù)可以自己處理問題來幫助我們減少排障成本。
1.2、業(yè)務(wù)設(shè)計原則
在進(jìn)行業(yè)務(wù)設(shè)計時要遵循一些最基本的原則比如：
防重原則
在某些場景下要防止用戶重復(fù)操作，例如：用戶注冊、用戶下單、用戶支付等。我們需要在客戶端和服務(wù)端有一些方案避免這種問題。
模塊復(fù)用原則
在業(yè)務(wù)中每個功能多多少少是有聯(lián)系的，在設(shè)計的時候模塊盡量要獨立，其他模塊直接調(diào)用即可，調(diào)用減少代碼的冗余。
可追溯原則
在程序的運行中避免不了業(yè)務(wù)問題以及故障的發(fā)生，但是我們可以通過日志的方式快速定位問題，做到有據(jù)可查。
反饋原則
系統(tǒng)對用戶的響應(yīng)應(yīng)該是具體、詳細(xì)的，舉一個很簡單的例子，用戶登錄失敗后應(yīng)該反饋給用戶的是“用戶名錯誤”或者“密碼錯誤”，而不是“登錄失敗”。
備份原則
做好代碼備份、數(shù)據(jù)備份以及人員備份。
2、客戶端優(yōu)化
在高并發(fā)高流量的系統(tǒng)客戶端的優(yōu)化是必不可少的，如果沒有做好客戶端的優(yōu)化影響用戶體驗是一方面，有時候甚至是致命的。
這里分享下我之前慘痛的教訓(xùn)：之前參與過一個秒殺的業(yè)務(wù)，就是因為前端的沒有做優(yōu)化，大量用戶在刷新頁面時服務(wù)器的帶寬被打爆，頁面加載不出來，影響了系統(tǒng)的發(fā)展，這是非常致命的。主要原因還是沒有經(jīng)驗，以為后端做好高并發(fā)抵抗就可以。
客戶端優(yōu)化主要集中以下幾點：
資源下載
- 減少不必要傳輸：例如減少cookie使用，因為cookie 隨著請求發(fā)送而發(fā)送從而增加數(shù)據(jù)量。
- 減少數(shù)據(jù)量輸出：例如刪除JS無效注釋，一來可以減少體積，二來可以提高代碼安全?；蛘呖梢詫⑽募嚎s后傳輸。
- 減少請求 ：將資源數(shù)目多、體積小、頻繁創(chuàng)建http請求的文件合并，比如JS合并、矢量圖 SVG。
- 轉(zhuǎn)移第三方：將請求轉(zhuǎn)移至第三方，例如oss。
資源緩存
常見的資源緩存就是圖片、樣式和腳本。有些場景可以利用客戶端的緩存幫助服務(wù)端分擔(dān)壓力，比如網(wǎng)約車中的預(yù)估價格，客戶端可以緩存計算規(guī)則并緩存，減少向服務(wù)端的請求。
資源解析
我們知道頁面中資源解析的順序是從上到下，如果上面有改變下面也需要變動，所以我們要縮小回流、重繪的范圍，比如虛擬dom。除此之外我們還可以利用懶加載和預(yù)加載進(jìn)行優(yōu)化：
- 懶加載： 先加載基礎(chǔ)的，再根據(jù)用戶的操作進(jìn)行局部加載。將原來一次性要加載的拆分成多次加載，減少下載數(shù)量和耗時。比如：樹節(jié)點、折疊面板、二級菜單等。
- 預(yù)加載： 當(dāng)前頁面對下個頁面的解析、拉取資源。下面代碼作為參考