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