作者：徐嘉偉，騰訊web前端開發(fā) 高級(jí)工程師

商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系騰訊WeTest獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。

WeTest 導(dǎo)讀

一項(xiàng)指標(biāo)的變好，總少不了相應(yīng)優(yōu)化策略的實(shí)施。優(yōu)化并不是簡單的一蹴而就，而是個(gè)不斷迭代與推翻的過程。更深層的優(yōu)化方案，往往是在某種思維策略之下，對(duì)問題場(chǎng)景和基本策略優(yōu)缺的深刻理解后做出的當(dāng)下最優(yōu)的權(quán)衡結(jié)果。本文筆者從前端高并發(fā)優(yōu)化這一具體點(diǎn)出發(fā)，逐步向大家闡述筆者在優(yōu)化的“術(shù)”之上思維層面的一些思考。希望能給各位帶來共鳴和感悟。

背景： 
之所以會(huì)以前端高并發(fā)這一主題入手，一來是本人曾負(fù)責(zé)過一些超高并發(fā)量的業(yè)務(wù)（手Q紅包），在這方面算是有些經(jīng)驗(yàn)。二來是相對(duì)于業(yè)務(wù)功能優(yōu)化這類光前端層面的邏輯就涉及產(chǎn)品、設(shè)計(jì)等多方人員合作討論而完成的優(yōu)化（即邏輯本身并非純出自前端人員的腦子），前端高并發(fā)這種前端層面邏輯純由前端人員全把控的優(yōu)化，或許作為前端的我，能得出來的思考觀點(diǎn)會(huì)更深刻和更通用一些。

一、普遍的優(yōu)化思路

說到優(yōu)化，大家在收到“優(yōu)化指標(biāo)”任務(wù)的時(shí)候。通常會(huì)做兩件事情——分析“優(yōu)化指標(biāo)”對(duì)應(yīng)的痛點(diǎn)、尋找解決痛點(diǎn)的技術(shù)方案并施行。那這樣是否就足夠了呢？我的答案是否定的。在我的認(rèn)知里這只是第一層的優(yōu)化，雖然在結(jié)果上往往我們使用更優(yōu)的技術(shù)后確實(shí)可以達(dá)到更好的優(yōu)化效果，但卻又不那么完美，優(yōu)化效果還可以做得更好。那究竟缺了什么呢？下面，我會(huì)逐步闡述我的優(yōu)化思路。首先，普遍的優(yōu)化思路是基礎(chǔ)，我們先來看看在普遍的優(yōu)化思路下，基本的前端高并發(fā)策略是怎么樣的？

二、分析本質(zhì)痛點(diǎn)

高并發(fā)場(chǎng)景，與普通場(chǎng)景的核心區(qū)別是并行的訪問量激增。因此，前端高并發(fā)策略本質(zhì)要解決的是由訪問量激增帶來的問題。那訪問量激增帶來的是什么問題呢？

我們先來看一張H5正常的訪問流圖：

正常情況下，從用戶端到后臺(tái)的數(shù)據(jù)流動(dòng)是很均衡的，用戶的訪問量在后臺(tái)可承受的范圍內(nèi)。

而在高并發(fā)場(chǎng)景下，若不進(jìn)行任何的高并發(fā)策略應(yīng)對(duì)，原訪問流圖會(huì)變成這樣（前端到后臺(tái)紅色部分的請(qǐng)求會(huì)被后臺(tái)拒掉甚至可能會(huì)擊垮后臺(tái)）：

圖中可以很明顯地看出高并發(fā)的痛點(diǎn)：數(shù)據(jù)流動(dòng)過程兩端失衡了。解決這一痛點(diǎn)，需要把兩端重新回到數(shù)據(jù)流動(dòng)的平衡狀態(tài)。可以從兩方面著手，一方面是后臺(tái)層面盡可能地提供更大的承載能力（如增加機(jī)器等）；另一方面則是在前端層面盡可能地加強(qiáng)其作為用戶與后臺(tái)之間的“門”的精簡過濾能力。

加強(qiáng)前端“門”的精簡過濾能力后，我們期望看到的訪問流圖是這樣的：

雖然用戶并發(fā)量很大，但在前端高并發(fā)策略下，兩端失衡這一痛點(diǎn)得到了解決。那這些高并發(fā)策略都有哪些呢？我們來一個(gè)個(gè)地尋找。

三、尋找可行技術(shù)方案

前端“門”的角色要加強(qiáng)的是兩方面的能力，一個(gè)是精簡，另一個(gè)是過濾。

精簡

首先，我們先看精簡的技術(shù)方案。如果把后臺(tái)的承載能力比作成一個(gè)“圓”，那前端和后臺(tái)之間的通道就相當(dāng)于一個(gè)以此圓為出口寬度的水管，其中的水可以理解為H5中的請(qǐng)求。而這樣的圓在H5中，實(shí)際有兩個(gè)，一個(gè)是最大并發(fā)數(shù)、一個(gè)是最大流量。對(duì)應(yīng)的則是我們并行請(qǐng)求中的請(qǐng)求數(shù)和請(qǐng)求大小，精簡這兩者，即可在“圓”的面積固定的情況下，提供更多的“水”進(jìn)出。

所以，在精簡的技術(shù)方案上，需要能針對(duì)并行請(qǐng)求中的請(qǐng)求數(shù)和請(qǐng)求大小進(jìn)行精簡。

1、請(qǐng)求數(shù)精簡

當(dāng)請(qǐng)求數(shù)從邏輯層面已無法再精簡時(shí)（如去掉一些無用請(qǐng)求），這時(shí)我們往往會(huì)將焦點(diǎn)聚焦到純技術(shù)方案上。

H5請(qǐng)求數(shù)精簡的方案，目前大致方案如下，核心為：合并。

圖中列出的是H5中常用的資源類型（還有別的如視頻、音頻，不一一列舉）。可以看出，就圖中列出的目前的技術(shù)，對(duì)于請(qǐng)求數(shù)的減少，可以說要多極致可有多極致。極端情況下，一個(gè)業(yè)務(wù)只有一個(gè)請(qǐng)求也是可以做到的。

2、請(qǐng)求大小精簡

同樣的，當(dāng)請(qǐng)求大小從邏輯層面已無法再精簡時(shí)（如去掉一些無用函數(shù)、代碼），這時(shí)我們往往會(huì)將焦點(diǎn)聚焦到純技術(shù)方案上。H5請(qǐng)求大小精簡的方案，目前大致方案如下，核心為：壓縮

可以看到，就目前的技術(shù)，對(duì)于請(qǐng)求大小的精簡，每種資源都可以進(jìn)一步的壓縮精簡。

過濾

上面說的是前端“門”精簡能力的技術(shù)方案，那下面我們?cè)賮砜聪虑岸恕伴T”過濾能力的技術(shù)方案。還是剛剛水管的比喻，前端的過濾，可以理解為在前端“門”上加了一層可反彈特定水的網(wǎng)，用于把無須進(jìn)入的水反彈掉（不知道這個(gè)比喻于水而言是否恰當(dāng)，總之要表達(dá)的就是類似這么個(gè)道理）。能把“水”反彈的方式有很多種，一種是被動(dòng)式的，即只允許特定量的水通過，超了的部分就進(jìn)不來了，這策略一般用于后臺(tái)，叫“過載保護(hù)”；另一種則是主動(dòng)式的，通過對(duì)數(shù)據(jù)時(shí)效性的犧牲把數(shù)據(jù)往更前的一端進(jìn)行儲(chǔ)存。在前端層面，一般叫“本地緩存”，當(dāng)請(qǐng)求時(shí)發(fā)現(xiàn)前端有緩存的內(nèi)容，就不用再去訪問服務(wù)器了。

所以，在過濾的技術(shù)方案上，前端可以通過緩存來完成。

1、緩存過濾請(qǐng)求

H5請(qǐng)求過濾的方案，目前大致方案如下，核心為：緩存。

通過具體的前端緩存技術(shù)，可將原本需要通過到達(dá)后臺(tái)的請(qǐng)求直接從前端緩存處獲取而達(dá)到“過濾”的效果。

四、普遍優(yōu)化思路下的基本策略

完成上述兩步——分析本質(zhì)痛點(diǎn)、尋找可行技術(shù)方案，接下來大家普遍的做法是選擇其中的合適方案，然后用到我們的項(xiàng)目中。對(duì)于合并，我們會(huì)把同類型的文件統(tǒng)一做下合并；對(duì)于壓縮，我們會(huì)把沒壓縮的代碼都統(tǒng)一做下壓縮；對(duì)于緩存，我們統(tǒng)一啟用較長的http cache、使用localstorage緩存、使用離線包。整體策略下來，雖然在一定程度上會(huì)有效果，但是我認(rèn)為這往往又是不夠的。要做到更徹底的優(yōu)化，就需要對(duì)優(yōu)化方案和優(yōu)化場(chǎng)景本身做更深入的思考和策略調(diào)整。而這，往往是需要靠相應(yīng)的思維模式驅(qū)動(dòng)的。下面我來分別說說我總結(jié)出來的一些適用于更深層優(yōu)化的思維，其中會(huì)著重談?wù)劜町惢季S。

差異化思維

差異化思維，講求的是在深入理解技術(shù)與場(chǎng)景后，對(duì)技術(shù)與場(chǎng)景進(jìn)行差異化分解，以達(dá)到每個(gè)差異場(chǎng)景的進(jìn)一步技術(shù)最優(yōu)。

從前兩步中——分析本質(zhì)痛點(diǎn)、尋找可行技術(shù)方案，我們了解到高并發(fā)應(yīng)對(duì)在前端技術(shù)層面可以從合并、壓縮、緩存三方面著手。一個(gè)很淺顯的道理是，這些策略做得越徹底，前端層面能擋掉的并發(fā)量就越多。但事實(shí)上，往往我們卻又并不能這么做，而只能選取其中一種比較折中的方案。

比如，考慮到對(duì)頁面訪問耗時(shí)的影響，我們并不會(huì)把整個(gè)H5項(xiàng)目資源合并成為一個(gè)請(qǐng)求。原因在于，從本質(zhì)上來說，每項(xiàng)純技術(shù)策略，有其優(yōu)點(diǎn)的同時(shí)，就必然會(huì)帶來或多或少的缺點(diǎn)，正所謂萬物有利必有弊。而當(dāng)這個(gè)弊端成為了影響項(xiàng)目核心能力（如體驗(yàn)方面能力中的頁面訪問耗時(shí)）的時(shí)候，即使是能更好地提高并發(fā)能力的方案，在利弊權(quán)衡之后往往最終也并不會(huì)采用。這就是我前面說的只選擇折中的優(yōu)化方案時(shí)優(yōu)化不夠徹底的原因。

在利弊權(quán)衡之下，往往我們會(huì)選擇一個(gè)折中方案（如下圖那樣中選擇的策略3）：

而更徹底的優(yōu)化應(yīng)該是，了解每個(gè)方案所導(dǎo)致的弊端影響，由弊端影響對(duì)項(xiàng)目場(chǎng)景進(jìn)行差異化分析，按各場(chǎng)景對(duì)弊端影響面的容忍程度，實(shí)行策略方案的差異化。對(duì)于能接受弊端影響的場(chǎng)景，使用最優(yōu)方案；而對(duì)于不太能接受弊端影響的場(chǎng)景，使用較優(yōu)方案；依次類推到使用折中方案。從而做到差異化的精細(xì)優(yōu)化。優(yōu)化后的總體策略方案會(huì)變成類似下圖的形式，原有項(xiàng)目只是單純的使用折中策略3，而差異化處理后，會(huì)抽離出部分項(xiàng)目模塊使用更優(yōu)的策略1和策略2。

下面，我會(huì)使用這種思維，對(duì)上面兩步得出的前端高并發(fā)中的三種策略——合并、壓縮、緩存進(jìn)行進(jìn)一步的差異化優(yōu)化。

差異化的合并策略

代碼合并，合并到一定程度其弊端就會(huì)逐步放大顯露。

弊端有：單個(gè)請(qǐng)求過大，造成對(duì)頁面首屏渲染耗時(shí)的影響；動(dòng)靜請(qǐng)求合并后（cgi＋html），緩存時(shí)效性的要求會(huì)大大地提高（緩存時(shí)效性取決于各合并資源中要求最高者，木桶原理）。

根據(jù)每個(gè)弊端的影響，下面針對(duì)具體場(chǎng)景進(jìn)行差異化分析。

1、“資源首屏體驗(yàn)相關(guān)度”差異化分解

對(duì)于合并后單文件過大，其影響的是頁面首屏渲染耗時(shí)。那我們可以從影響點(diǎn)出發(fā)，對(duì)頁面網(wǎng)絡(luò)資源請(qǐng)求按首屏體驗(yàn)相關(guān)性（影響點(diǎn)）進(jìn)行差異化拆分，從而最大程度地減少合并對(duì)體驗(yàn)的影響。最簡單的我們可以把資源分成兩部分——高相關(guān)性資源（首屏）和低相關(guān)性資源（非首屏）。每部分資源單獨(dú)策略處理，盡可能地做到極致的合并，提高并發(fā)能力。當(dāng)再次遇到合并后文件太大而影響渲染耗時(shí)時(shí)，則在本級(jí)中再進(jìn)一步分級(jí)，以此類推。如對(duì)于css、首屏渲染相關(guān)的js和圖片資源，可作為高相關(guān)性資源，把圖片base64進(jìn)css，然后再全部內(nèi)聯(lián)進(jìn)html頁面，與頁面合并。對(duì)于非首屏相關(guān)的js和圖片資源，作為低相關(guān)性資源單獨(dú)合并。這樣即可在不影響頁面首屏渲染耗時(shí)體驗(yàn)的同時(shí)，又保證了最大程度的減少并發(fā)請(qǐng)求數(shù)。

2、"資源時(shí)效依賴度"差異化分解

對(duì)于動(dòng)靜請(qǐng)求合并（cgi＋html），其影響的是緩存時(shí)效性，導(dǎo)致緩存時(shí)效性要求變高。那我們也可以從影響點(diǎn)出發(fā)，對(duì)頁面請(qǐng)求按時(shí)效依賴度（影響點(diǎn)）進(jìn)行差異化拆分。最簡單的我們可以把頁面分成兩類——高時(shí)效性要求頁面（入口不可控，本來就不做緩存）和低時(shí)效性要求頁面（入口完全可控，可通過修改頁面離線包等方式做更新，可緩存）。對(duì)于高時(shí)效性要求的頁面，動(dòng)靜請(qǐng)求合并后不會(huì)對(duì)該類頁面有影響，此類頁面可將cgi和html進(jìn)行合并。而對(duì)于低時(shí)效性要求的頁面，這類頁面是可以緩存的（如使用離線包），則不進(jìn)行cgi和html合并。

針對(duì)具體場(chǎng)景，差異化地采用相應(yīng)最優(yōu)的合并策略，優(yōu)化效果將會(huì)再進(jìn)一步地提升。

差異化的壓縮策略

同樣的，代碼壓縮，也有其弊端。弊端有：壓縮程度越高，代碼可讀性越差，不便于線上問題的定位；雖有更優(yōu)的壓縮算法，但算法本身又存在自身的局限性。

1、“資源可讀依賴度”差異化分解

對(duì)于代碼可讀性的影響，市面上其實(shí)已有代碼層面的解決方案，如項(xiàng)目支持debug模式切換（此解決思路就是一種差異化思維，按使用場(chǎng)景差異化分成代碼可讀性要求高場(chǎng)景和代碼可讀性要求低場(chǎng)景，如線上的代碼屬于代碼可讀性要求低的，采用極端壓縮版的代碼；開發(fā)debug模式下的代碼屬于代碼可讀性要求高的，采用非壓縮版的代碼，兩種模式可參數(shù)化切換）、sourcemap等。

2、“資源平臺(tái)支持程度”差異化分解

對(duì)于各壓縮算法的局限性（或者說各壓縮算法下的產(chǎn)物的局限性，如圖片資源有多種格式，而每種格式又有其局限性），其影響的是其所不支持（局限外）的那部分平臺(tái)，會(huì)導(dǎo)致那部分平臺(tái)無法使用。那我們從影響點(diǎn)出發(fā)，可以對(duì)該網(wǎng)絡(luò)資源按平臺(tái)支持程度（影響點(diǎn)）進(jìn)行差異化拆分。我們可以按壓縮算法的壓縮效果進(jìn)行方案的排序，從高到低地對(duì)方案的平臺(tái)支持程度進(jìn)行差異化判斷篩選，支持則使用當(dāng)前算法類型（格式），不支持則判斷使用下一種算法類型（格式）。

例如對(duì)于圖片資源，圖片的格式豐富多樣，多樣的格式實(shí)際來源于每種格式使用的壓縮算法的不同，都有其擅長的領(lǐng)域。這時(shí)，我們不能只用一種最普遍適用的格式，而應(yīng)該利用上面的差異化思路來加載圖片。按照各圖片格式的壓縮程度，對(duì)于支持tpg（公司內(nèi)叫sharpp）的平臺(tái)請(qǐng)求tpg格式圖片，不支持tpg的則再去判斷是否支持webp；支持webp的平臺(tái)則請(qǐng)求webp格式的圖片，若不支持webp則再往下判斷。而針對(duì)圖片格式的擅長領(lǐng)域，對(duì)于色彩豐富的圖片采用jpg格式、色彩較簡單或需要透明通道的采用png格式，按最適合的進(jìn)行圖片格式差異化選取。甚至對(duì)于圖片的尺寸（尺寸與壓縮無關(guān)，但目的都是為了減少請(qǐng)求大小，故用于類比），我們也可以采用這個(gè)差異化思路，如根據(jù)當(dāng)前客戶端的分辨率，返回最適大小的圖片給客戶端，從而做到高分辨率客戶端請(qǐng)求返回高分辨率圖片，低分辨率客戶端請(qǐng)求返回低分辨率圖片。

針對(duì)具體場(chǎng)景，差異化地采用相應(yīng)最優(yōu)的壓縮策略，優(yōu)化效果也將會(huì)再進(jìn)一步地提升。

差異化的緩存策略

與上面的類似，緩存策略同樣也有相應(yīng)的弊端。弊端有：緩存時(shí)間越長，數(shù)據(jù)的準(zhǔn)確性就越差，會(huì)存在緩存數(shù)據(jù)雖有效但已與最新數(shù)據(jù)有較大差異的問題。

1、“資源時(shí)效依賴度”差異化分解

針對(duì)資源有效性受緩存時(shí)間長短的影響，我們可以對(duì)資源進(jìn)行時(shí)效性分級(jí)。可大致分成更新可控資源和更新不可控資源。此處的可不可控指的是資源更新后頁面能否實(shí)時(shí)感知到更新。對(duì)于前端開發(fā)人員部署的js、css、圖片等資源，均可作為更新可控資源，設(shè)置極長緩存，因?yàn)檫@類資源更新的同時(shí)可以將版本信息實(shí)時(shí)同步給前端頁面（如拉取的文件改名了、改時(shí)間戳了等）。而對(duì)于無法實(shí)時(shí)同步版本信息給前端頁面的資源，可作為更新不可控資源。對(duì)于這部分資源，我們可以再根據(jù)業(yè)務(wù)對(duì)各資源的時(shí)效性要求程度進(jìn)行差異化分級(jí)。

以手Q中的H5項(xiàng)目中用到的QQ頭像資源為例，此場(chǎng)景下頭像是一個(gè)對(duì)項(xiàng)目更新不可控的資源。用戶通過使用手Q或PC QQ修改自身頭像后，各H5項(xiàng)目對(duì)于這個(gè)修改是無感知的，H5并不會(huì)實(shí)時(shí)地收到更新通知（除非雙方在接口層面上做同步通知）。此時(shí)，如果頭像緩存時(shí)間設(shè)置較長，就會(huì)出現(xiàn)用戶更新了頭像，但在H5項(xiàng)目中看到的頭像還是舊的的情況。但如果不緩存，在高并發(fā)場(chǎng)景下勢(shì)必對(duì)頭像服務(wù)器造成極大的并發(fā)壓力。這時(shí)，就需要對(duì)這一更新不可控資源做進(jìn)一步差異化分解。

對(duì)于手Q中社交性較強(qiáng)的H5項(xiàng)目（如手Q紅包、手Q AA收款等），其中雖然有很多頭像，但是各頭像對(duì)時(shí)效性的要求還是有差異的。最簡單的我們可以把頭像分成兩類，高時(shí)效性頭像和低時(shí)效性頭像。稍作分析后，其實(shí)可以發(fā)現(xiàn)，對(duì)于使用者而言，用戶自身（主人態(tài)）的頭像變更是最敏感的，如果用戶在手Q或PC QQ上修改完自己的頭像后，進(jìn)入該H5后發(fā)現(xiàn)自己的頭像沒有變是不太能容忍的。此時(shí)，用戶自身的頭像可作為高時(shí)效性頭像。而對(duì)于其他用戶（客人態(tài)）的頭像的時(shí)效性，變沒變，使用者其實(shí)倒不會(huì)太過在意，所以對(duì)于非用戶自身的頭像可作為低時(shí)效性頭像。最后在策略上，對(duì)于高時(shí)效性頭像，緩存一個(gè)較短時(shí)間；對(duì)于低時(shí)效性頭像，則緩存一個(gè)相對(duì)較長時(shí)間。（實(shí)現(xiàn)起來也很容易，可將差異化邏輯放在前端判斷然后加時(shí)間戳決定緩存時(shí)間即可。）

針對(duì)具體場(chǎng)景，差異化地采用相應(yīng)最優(yōu)的緩存策略，優(yōu)化效果也將會(huì)再進(jìn)一步地提升。

五、更多“維”的優(yōu)化

在差異化思維的指導(dǎo)下，高并發(fā)優(yōu)化策略得到了更進(jìn)一步的完善。該思維的核心思想是針對(duì)方案的優(yōu)缺與實(shí)際場(chǎng)景進(jìn)行差異權(quán)衡。從通用性角度來看，這項(xiàng)思維也適用于工作上的很多事情，是一項(xiàng)通用化的思維，而并不僅僅局限于使用在解決前端高并發(fā)這個(gè)問題點(diǎn)上。同時(shí)，也并非所有的方案都只采用差異化思維就能完美地解決問題。差異化思維只是眾多思維中的一種，實(shí)際上，還有很多思維。一個(gè)優(yōu)秀的優(yōu)化方案往往是在多“維”的思考權(quán)衡下的最終產(chǎn)物。

邊界放大思維

比如，邊界放大思維，指的是我們?cè)谧鲆豁?xiàng)事情的時(shí)候，視野不應(yīng)只停留在自己所能完全把控的領(lǐng)域，而應(yīng)該把邊界放大，從更外圍的視野來思考這個(gè)問題的解決方案。

如前面說到的緩存策略，其實(shí)有一個(gè)當(dāng)前H5的緩存策略弊端需要通過使用邊界放大思維來優(yōu)化。這個(gè)弊端是：當(dāng)前瀏覽器緩存技術(shù)有其自身的局限性，緩存的有效性依賴于用戶的二次訪問程度。弊端的核心問題在于：緩存時(shí)機(jī)與用戶首次訪問相耦合。這使得在一些超高并發(fā)的H5活動(dòng)中（活動(dòng)類與業(yè)務(wù)類H5不同，活動(dòng)類H5大部分是第一次訪問的用戶），緩存帶來的效果并沒有想象中大。

這是在純前端技術(shù)層面無法解決的。但當(dāng)我們把思維邊界放大，擴(kuò)展考慮到承載H5的平臺(tái)時(shí)，這個(gè)弊端也許就能獲得解決。因?yàn)檫@個(gè)弊端核心要解決的是資源的緩存與頁面訪問解耦的問題，而承載平臺(tái)方（尤其終端）是有這個(gè)能力完成的。如在手Q中，這個(gè)解決方案叫“離線包”。離線包支持被動(dòng)緩存的同時(shí)，也支持主動(dòng)緩存?？蓪㈨撁鎯?nèi)容無須用戶主動(dòng)訪問而通過預(yù)下載或主動(dòng)push的方式緩存到用戶手Q客戶端上。首次訪問的用戶也可直接命中緩存。這樣即可大大提高緩存的有效性。春節(jié)期間，手Q各高并發(fā)H5無不使用這項(xiàng)技術(shù)來提高頁面的高并發(fā)能力。

邏輯全面性思維

再如，邏輯全面性思維，指的是我們?cè)谧鲆豁?xiàng)事情的時(shí)候，視野不能只停留于邏輯的局部，而應(yīng)該看到邏輯的全狀。如邏輯有正常狀態(tài)，也有異常狀態(tài)，我們不能只考慮正常狀態(tài)。邏輯有雙向也有單向，對(duì)于雙向的邏輯，我們不能只考慮其中的正向。

其實(shí)，前面我說的所有前端高并發(fā)策略（包括前面畫的圖），都僅僅只考慮到了數(shù)據(jù)流的正向邏輯段，即數(shù)據(jù)從用戶端流向服務(wù)端的過程。而數(shù)據(jù)流的反向邏輯段其實(shí)是沒有考慮的（即數(shù)據(jù)從服務(wù)端回到用戶端的這一段邏輯情況）。而在高并發(fā)場(chǎng)景下，數(shù)據(jù)的反向邏輯段往往也會(huì)作為邏輯中非常關(guān)鍵的一環(huán)。沒考慮數(shù)據(jù)流反向邏輯段的高并發(fā)策略，優(yōu)化數(shù)據(jù)再好也只能說完成了一半。下面是數(shù)據(jù)流動(dòng)的全邏輯過程（紅色部分是數(shù)據(jù)流動(dòng)的反向邏輯段）：

在數(shù)據(jù)流的反向邏輯段中，前端在這層邏輯中的角色變成了數(shù)據(jù)接受方，而接受的數(shù)據(jù)可能存在多種狀態(tài)，前端需要對(duì)這些狀態(tài)都做好相應(yīng)的處理。在高并發(fā)下，若后臺(tái)過載了，那就會(huì)有部分?jǐn)?shù)據(jù)返回異常。此時(shí)，最簡單的我們可以分成兩種狀態(tài)——成功、失敗，成功狀態(tài)頁面正常展示，異常狀態(tài)則需要盡可能做到體驗(yàn)降級(jí)而非完全不可用。如靜態(tài)資源cdn請(qǐng)求失敗了，前端可以進(jìn)行這樣的一層異常邏輯處理：將當(dāng)前異常用戶的靜態(tài)資源域名臨時(shí)切換到備份域名（如頁面域名或備用域名），這樣可以將本來應(yīng)該白屏無法使用的體驗(yàn)降級(jí)到訪問速度較慢的體驗(yàn)，同時(shí)也給了錯(cuò)誤率超過閥值時(shí)的cdn機(jī)器擴(kuò)容提供調(diào)整時(shí)間。當(dāng)然，若再結(jié)合上面的差異化思想，我們還可以將當(dāng)前服務(wù)器的總體狀態(tài)進(jìn)行差異化分級(jí)（如當(dāng)前負(fù)載程度），通過配置返回等策略告知頁面當(dāng)前服務(wù)器并發(fā)情況的程度，前端針對(duì)這些狀態(tài)做差異化處理，逐步降級(jí)。如當(dāng)cgi并發(fā)超過一定限度時(shí)，前端可以考慮將一些非核心但訪問量較高的cgi的頁面入口逐步屏蔽掉，到最后僅保留核心的cgi入口，從而保障項(xiàng)目核心功能不受高并發(fā)影響。

五、結(jié)語

本文算是筆者從事4年前端工作以來的一些思考?；谇岸烁卟l(fā)策略這一優(yōu)化點(diǎn)，向各位逐步闡述筆者在其“術(shù)”方面和“思維”方面的一些思路。受限于自身的經(jīng)歷和視野，觀點(diǎn)也許有其局限性。希望文中提到的策略和思維，能給能作為讀者的你一些收獲。文章篇幅較長，文字較多，感謝耐心閱讀！

關(guān)于騰訊WeTest (wetest.qq.com)

騰訊WeTest是騰訊游戲官方推出的一站式游戲測(cè)試平臺(tái)，用十年騰訊游戲測(cè)試經(jīng)驗(yàn)幫助廣大開發(fā)者對(duì)游戲開發(fā)全生命周期進(jìn)行質(zhì)量保障。騰訊WeTest提供：適配兼容測(cè)試；云端真機(jī)調(diào)試；安全測(cè)試；耗電量測(cè)試；服務(wù)器性能測(cè)試；輿情監(jiān)控等服務(wù)。

http://www.cnblogs.com/wetest/p/7069005.html

延伸閱讀

• 要想為事業(yè)多添一把火，自己就得多添一捆材 2023-04-18
• 多敲代碼，不斷試錯(cuò) 2022-09-08
• 多積累才能有進(jìn)步——?jiǎng)?聰 2019-10-28
• 方法總比困難多——蘇*誠 2019-10-28
• 有志者事竟成 2019-08-02
• 做好了選擇，就要勇往直前 2019-07-11
• 吸取經(jīng)驗(yàn)，提高技能——王*鑫 2019-06-30
• 以提高用戶體驗(yàn)為中心——李*雅 2019-06-30
• 是項(xiàng)目的結(jié)束，也是我IT生涯的開始——李*昊 2019-06-30
• 萌寵之家 2019-06-28

要想為事業(yè)多添一把火，自己就得多添一捆材