聊一聊當下發(fā)生的事情吧。疫情期間大家都在享受延長假期的福利，吐槽在家辦公的不爽，而我們則從過年開始就一直在戰(zhàn)斗，到現(xiàn)在還沒有好好休息過。

先說背景，我目前在騰訊IMWeb團隊，負責在線教育騰訊課堂的前端研發(fā)。

都說疫情期間在線教育是風口，我想說，打的贏扛得住也許是機遇，打不贏完全是炮灰。

1.先說流量

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

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

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

1.1 前端考驗一——主域

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

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

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

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

1.2 前端考驗二——音視頻直播

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

圖片

課堂前端團隊針對于音視頻領域做了非常多的優(yōu)化，在疫情期間，音視頻作為核心模塊被重點關注，快速上線了快直播，簡化WebRTC信令，分攤更大的流量，HLS降級WebRTC，混流開關等等。

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

1.3 前端考驗三——SAS數(shù)據(jù)管理配置平臺

圖片

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

圖片

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

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

1.4 前端考驗四——IMPush

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

圖片

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

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

1.5 前端考驗五——監(jiān)控、日志與灰度

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

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

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

圖片

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

圖片

灰度方案其實相對是比較難做的，最簡單的是按照機器灰度，但這種方案在實際環(huán)境中基本上是不可用的，對于一個需求來說，如果同時修改了老頁面和新頁面，會導致用戶前后訪問不一，甚至出現(xiàn)404情況。更好的方式是按照登錄態(tài)灰度，這時候我們需要統(tǒng)一接入層，Nginx、TSW都是可以的選擇，在白名單內(nèi)用戶進行灰度。

圖片

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

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

1.6 前端考驗六——后臺保護

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

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

圖片

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

2. 再說需求

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

騰訊課堂之前的toB部分針對的是開課機構、個人老師，現(xiàn)在是學校教務、學校老師、學校領導、教育局領導，老板們直接重點關注，可想而知產(chǎn)品的壓力有多大。

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

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

圖片

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

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

2.1 快速開發(fā)需求——Nohost方案

圖片

Nohost方案對于測試環(huán)境多需求并行開發(fā)做了很好的支持，不僅支持前端分發(fā)，還利用docker打通了后臺環(huán)境。

開發(fā)很便捷使用分支部署，產(chǎn)品可以在家切不同的需求環(huán)境體驗，測試也可在家訪問不同環(huán)境進行測試。

圖片

2.2 快速開發(fā)需求——Tolstoy方案

圖片

Tolstoy打通了后臺的PB、CGI，讓后臺定義的協(xié)議能夠自動生成文檔、Mock、聲明文件、測試用例等等，尤其是TS的自動生成，為開發(fā)提供了很大的遍歷，讓我們的TS項目開發(fā)的更快更好。

2.3 穩(wěn)定上線需求——Thanos方案

圖片

Thanos方案是我核心主導的，它解決的是發(fā)布鏈路的問題，對于大公司而言，發(fā)布除了CI/CD之外，還有一些其他的額外流程保障，形成發(fā)布閉環(huán)。

圖片

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

圖片

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

圖片

2.4 個人技術能力

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

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

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

圖片

另一方面，文檔在這一刻發(fā)揮出應有的價值，一般團隊不怎么注重文檔建設，一來寫起來廢時間，二來對于晉升和成長沒什么幫助，看起來完全是利他性質(zhì)，但實際上是互利。這時團隊的價值觀和管理者就非常重要了，文檔的程度可以從側面反映出團隊的管理水平。

3. 總結

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

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

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