作為前端，工作中處理過什么復(fù)雜的需求？

從春節(jié)假期到現(xiàn)在，我們遭遇了前所未有的流量峰值，雖然具體數(shù)字不方便透露，但是可以預(yù)想得到，那么多所學(xué)校在期間強制網(wǎng)絡(luò)上課，學(xué)生加老師的數(shù)量是多么龐大。

如果說雙十一是所有具有消費能力和沖動的人群沖擊，那么這一次則是所有學(xué)生和老師的強制訪問，訪問者沒有選擇權(quán)，這是最可怕的一點。比雙十一更可怕的是，我們沒有時間準(zhǔn)備，雙十一也許可以提前幾個月甚至半年開始謀劃，這次的流量則完全是毫無預(yù)兆的突發(fā)性事件，要求我們在短時間內(nèi)必須做出快速的決策響應(yīng)。

截止現(xiàn)在，流量高峰已經(jīng)沖擊三波了，每一次都是幾倍的增長，流量逐漸平穩(wěn)，也讓我能夠偷閑刷一刷知乎。。

對于前端而言，最大的影響莫過于主域，一旦我們的主域扛不住，html都打不開了，整個全玩完。

在我們團(tuán)隊，主域的Nginx主要是由前端負(fù)責(zé)管理，在騰訊的運維體系下，STGW在下一層統(tǒng)統(tǒng)是交由業(yè)務(wù)來維護(hù)，運維同學(xué)完全不了解業(yè)務(wù)是如何發(fā)布和控制的。從某種程度來說，我們才是真正的DevOps，夸張一點說，運維同學(xué)與我們打交道也許僅限于機(jī)器申領(lǐng)與容量。

除了承載核心HTML入口，主域還承接了CDN的降級策略，防止某處運營商等問題直接導(dǎo)致CDN無響應(yīng)，之前的教訓(xùn)讓我們做了這層容災(zāi)。所以主域的穩(wěn)定性至關(guān)重要。

所幸這里僅僅是靜態(tài)渲染，抗住高并發(fā)不是太難的事情，不過Nginx對于前端的能力提出了更高的要求，對于Nginx的改動，有著嚴(yán)格的流程把控，務(wù)必做好充分的驗證。

音視頻鏈路對于課堂而言是重中之重，老師和學(xué)生的核心目的就是通過直播來上課，一旦音視頻掛了，騰訊課堂所有其他功能形同雞肋，這是前端第二項影響巨大的考驗。

課堂前端團(tuán)隊針對于音視頻領(lǐng)域做了非常多的優(yōu)化，在疫情期間，音視頻作為核心模塊被重點關(guān)注，快速上線了快直播，簡化WebRTC信令，分?jǐn)偢蟮牧髁?/strong>，HLS降級WebRTC，混流開關(guān)等等。

由于我不主要負(fù)責(zé)音視頻開發(fā)，音視頻所做的工作遠(yuǎn)遠(yuǎn)大于這里提到的，我們組負(fù)責(zé)音視頻的小姐姐已經(jīng)不知道通宵了多少回，十分辛苦~

這個平臺承接了所有的運營、類目、產(chǎn)品配置，對接CKV與CDB平臺做數(shù)據(jù)存儲，對接云COS做文件存儲，通過JSON Schema配置出數(shù)據(jù)服務(wù)，同步ZK節(jié)點供后臺查詢。

目前成百上千張表都在這個平臺上，一旦掛了，后果不可預(yù)料。這個平臺整體運用了GraphQL技術(shù)作為訪問查詢，屬于前端團(tuán)隊的第二大考驗。

得益于SAS平臺最初設(shè)計的簡潔性，監(jiān)控非常的充足，擴(kuò)容也較為容易，非常輕松地挺過流量高峰。

IMPush是前端團(tuán)隊自研的消息通道，承接了所有socket消息轉(zhuǎn)發(fā)。這個系統(tǒng)承接了聊天區(qū)所有的消息服務(wù)，與后臺保持全雙工長連接通道，利用Redis進(jìn)行數(shù)據(jù)緩存，整體agent與center都會受到比較大的壓力挑戰(zhàn)。

這個服務(wù)如果掛了，所有的聊天區(qū)、彈幕都將面臨癱瘓，影響也是非常大的。

同樣的手段，借助于現(xiàn)有的負(fù)載均衡L5體系和資源，需要抗住巨大的并發(fā)量。

我習(xí)慣將監(jiān)控、日志和灰度稱為前端三板斧，是衡量一個前端團(tuán)隊是否專業(yè)的重要指標(biāo)。很多前端并不注重這點，最多只有一個腳本報錯的監(jiān)控，最基本的測速返回碼等監(jiān)控都沒有。

單論腳本報錯監(jiān)控，我們其實已經(jīng)準(zhǔn)備三套方案，BadJS+Sentry+FullLink，在超高的訪問量下，可以預(yù)計所有的平臺基本上都會掛，而腳本監(jiān)控對于前端來說是非常重要的，三套系統(tǒng)的降級方案保證了我們在外網(wǎng)出問題的時候第一時間定位到問題所在，快速響應(yīng)bug。

日志上報是前端最容易忽略的，當(dāng)用戶量多了你就會發(fā)現(xiàn)，很多問題是沒有腳本報錯的，如果只依賴于報錯監(jiān)控，很多外網(wǎng)問題兩眼一抹黑，無從下手了。作為專業(yè)的前端，我們需要全鏈路的日志定位。

前端團(tuán)隊在這里借用開源的ELK方案，與后臺全鏈路系統(tǒng)打通，在基礎(chǔ)上通過DC通道上報落地，Agent代理不同監(jiān)控系統(tǒng)，做成了上報中臺方案，在Kibana系統(tǒng)上統(tǒng)一查詢和定制報表。

但針對CDN，我們無法架設(shè)統(tǒng)一的Node服務(wù)來接入，這時需要考慮離線方案，制作離線包以及PWA管理平臺，利用離線版本進(jìn)行登錄態(tài)灰度，可與Node服務(wù)保持一致。

有了這三點的保障，我們才可以做到心中有底，數(shù)據(jù)支撐指導(dǎo)我們的行動，來抗住高并發(fā)流量。

在這場戰(zhàn)役面前，前端不能自己獨善其身，不僅僅要做好自己的分內(nèi)事，更要幫助后臺團(tuán)隊共渡難關(guān)。

首先，在核心場景下，按需屏蔽不重要的接口，幫助后臺減輕壓力，可根據(jù)后臺的負(fù)載情況動態(tài)調(diào)整。

其次，前端自己要保持柔性，除了核心CGI外，其他接口無論是超時還是返錯，都不要影響頁面核心功能的正常運行，這對前端的代碼提出了很高的要求，所幸平時團(tuán)隊CR習(xí)慣養(yǎng)成良好，對接口的異常處理也做的比較完善，只是模擬接口測試驗證花費了一些時間。

你以為上面就是全部了？Too Naive！上面的幾點只是擠出時間去做一些調(diào)整，重頭戲還在于極度緊張的業(yè)務(wù)需求。

騰訊課堂之前的toB部分針對的是開課機(jī)構(gòu)、個人老師，現(xiàn)在是學(xué)校教務(wù)、學(xué)校老師、學(xué)校領(lǐng)導(dǎo)、教育局領(lǐng)導(dǎo)，老板們直接重點關(guān)注，可想而知產(chǎn)品的壓力有多大。

我們在兩天內(nèi)就推出了騰訊課堂極速版（https://ke.qq.com/s），支持老師10s開課，隨時隨地開課，目前已經(jīng)迭代到了第4版。

眾所周知，對于一個系統(tǒng)而言，由簡入繁易，由繁入簡難。騰訊課堂有著一套復(fù)雜的B側(cè)管理體系，極速版要將這一切推翻，讓老師極速開課，學(xué)生極速上課，這是多么困難的一件事情。課堂在這么短時間內(nèi)拿下極速版的版本發(fā)布，體現(xiàn)了極強的開發(fā)戰(zhàn)斗力。

在此期間，開發(fā)承接的工作量大約在平時的五倍左右，不僅僅需要通宵達(dá)旦，更需要快速響應(yīng)，課堂前端每日均發(fā)布版本達(dá)到10次以上，如何在高頻次的發(fā)布中不影響質(zhì)量也是巨大的考驗。

要保持高強度的戰(zhàn)斗力，對于團(tuán)隊的基礎(chǔ)效率工具建設(shè)提出了很高的要求。

如果沒有一個系統(tǒng)承載流程，這些雜亂無章的步驟可能成為發(fā)布事故的罪魁禍?zhǔn)住?/span>

另一方面，分支模型也是關(guān)鍵因素，采取分支發(fā)布的策略帶來的好處很多，但缺點也有，其中很重要的是分支準(zhǔn)入問題，以及發(fā)布覆蓋問題，這兩個普遍性問題在Thanos方案得到保障。

在高需求量，deadline又非常緊的情況下，對每個人的技術(shù)能力要求很高。騰訊課堂的前端復(fù)雜度還有很重要的一點體現(xiàn)在端上，老師端、學(xué)生端、機(jī)構(gòu)端、APP端、PC端、小程序端、微信公眾號、QQ公眾號、題庫、直播間等等等等……，這些端和項目可謂是眼花繚亂，數(shù)不過來。

很多項目歷史悠久，包含了眾多技術(shù)棧，從古老的FIS、QQ客戶端內(nèi)嵌、jQuery，到React、TypeScript、RN、音視頻等等，切換一個項目，如同換了家公司，需要重新適應(yīng)技術(shù)棧。

在人力不足的情況下，每個人都要去應(yīng)對自己不熟悉的領(lǐng)域，可能你還沒搞清楚什么是HLS就被拉去做音視頻，或者完全沒接觸過fis的情況下去熟悉整個項目的構(gòu)建打包流程，這對于個人快速上手能力和編程速度質(zhì)量都提出很高的要求。

最后，回歸正題，前端的復(fù)雜度也許很多，比如之前我參與的CPU負(fù)載過高問題排查，用盡手段定位一個月之后發(fā)現(xiàn)是一條正則語句引發(fā)的，這種性質(zhì)的復(fù)雜屬于特定場景下的復(fù)雜度。而我今天提到的“復(fù)雜度”則比較普適，所有團(tuán)隊都存在面臨這種場景的可能性，而對于每個團(tuán)隊而言，我認(rèn)為沒有一個團(tuán)隊會覺得應(yīng)對起來很簡單。更多需要的是公司資源調(diào)度+團(tuán)隊技術(shù)積累+個人能力的配合。

成長最高效的方式，不是一個人單槍匹馬孤軍奮斗，而是和大家并肩作戰(zhàn)享受狂歡。

真正復(fù)雜的需求，個人的力量是有限的，如何協(xié)調(diào)整個團(tuán)隊的力量更為艱難。當(dāng)團(tuán)隊在技術(shù)視野、技術(shù)方向上有前瞻性，沉淀性，個人不僅僅是埋頭寫業(yè)務(wù)時，是團(tuán)隊在推著個人成長，在高手云集的團(tuán)隊中保持核心競爭力，才是個人成長最合適的方向。

來源：騰訊IMWeb團(tuán)隊