*來源于微信公眾號：行走的伯樂（ID：gh_4a819e0635dd），作者楊文海

此次疫情持續(xù)時間長，范圍廣。為了不影響廣大中小學(xué)生的學(xué)習(xí)，教育部門提出了停課不停學(xué)的口號。廣大教育信息化企業(yè)、互聯(lián)網(wǎng)公司也紛紛響應(yīng)，以支持學(xué)校線上教學(xué)為實際行動，為抗擊疫情出一份力。春節(jié)后，各家公司工程師均動員起來，在家遠(yuǎn)程辦公，紛紛對現(xiàn)有系統(tǒng)進(jìn)行優(yōu)化，該擴容的擴容，該調(diào)整的調(diào)整，以應(yīng)對2月10日開學(xué)第一堂的到來。

2月10日早晨，全國上下的在線學(xué)習(xí)活動，均成為了各家公司的車禍現(xiàn)場。學(xué)生們過五關(guān)斬六將也沒能很好的完成上午的學(xué)習(xí)任務(wù)。學(xué)生們遇到的問題從登錄，進(jìn)入直播間到直播信號延遲卡頓。

9點之后，各家的系統(tǒng)均陸續(xù)出現(xiàn)崩潰，各公司也紛紛祭出重啟大法并尋找甩鍋方案（比如甩給電信運營商）。各家公司的系統(tǒng)均在崩潰的邊緣緊張度過了一上午。教育機構(gòu)在遇到這種萬（yu）萬（liao）沒（zhi）想（zhong）到的問題后，將學(xué)習(xí)形式切換為點播方案，這才令各路公司的工程師們長出了一口氣。

那么，都2020年了，國內(nèi)的互聯(lián)網(wǎng)企業(yè)早已經(jīng)歷了618，雙11，春節(jié)紅包等高并發(fā)場景的歷練，為何還紛紛撞車呢？我們先分析下當(dāng)前教育機構(gòu)采用的在線學(xué)習(xí)的幾種產(chǎn)品架構(gòu)形態(tài)。不同的產(chǎn)品架構(gòu)形態(tài)在這次事件的問題根源是各不相同的。

學(xué)校自建平臺

這類平臺一般采用校內(nèi)學(xué)習(xí)平臺加云直播服務(wù)的架構(gòu)方案。校內(nèi)部署的平臺要考慮部署成本和研發(fā)成本，絕大多數(shù)都采用單應(yīng)用服務(wù)器+單數(shù)據(jù)庫的架構(gòu)方案。比較有實力的學(xué)校還會升級為7層負(fù)載服務(wù)，多應(yīng)用服務(wù)，redis緩存，數(shù)據(jù)庫主從這種相對健壯的系統(tǒng)。

學(xué)校自建平臺有好處也有弊端。好處是自己相對可控，因為用戶就是自己學(xué)校的學(xué)生和教師，可以根據(jù)年級進(jìn)行錯峰上課，避免大流量的沖擊。一般只要學(xué)校的系統(tǒng)能經(jīng)歷過選課等服務(wù)的實際使用，再通過錯峰學(xué)習(xí)，基本可以扛過這次事件。弊端就是如果前期沒有經(jīng)過實際的大規(guī)模應(yīng)用，學(xué)校平臺建設(shè)完成后只是少量的應(yīng)用，沒有經(jīng)歷過全校范圍的實際應(yīng)用，那么在這次在線學(xué)習(xí)過程中，只能是硬挺，多半都度過不了學(xué)生登錄的環(huán)節(jié)。

這類系統(tǒng)架構(gòu)在本次事件中最大的問題就是水平擴容能力幾乎為0。受限于學(xué)校的物理環(huán)境，不是短時間能馬上擴容的。也就只有非常有實力的學(xué)校，才會儲備一些冗余的計算資源，在此次關(guān)鍵時刻發(fā)揮其作用。

區(qū)縣級教育云平臺

區(qū)縣級平臺一般都部署在區(qū)縣教育機構(gòu)的自建數(shù)據(jù)中心內(nèi)，16年后期也有在政務(wù)云上申請私有云進(jìn)行部署的。此類在線學(xué)習(xí)平臺的架構(gòu)方案一般都是我們耳熟能詳?shù)牡湫突ヂ?lián)網(wǎng)架構(gòu)。

硬負(fù)載均衡->軟負(fù)載->API網(wǎng)關(guān)->微服務(wù)->分布式緩存->數(shù)據(jù)庫讀寫分離

按理這套架構(gòu)應(yīng)該沒有問題，擴容也相對容易，但是現(xiàn)實情況確是很殘酷的。原因我們會在后面重點討論。

教育信息化公司的在線學(xué)習(xí)云平臺

此類平臺的典型運營公司如希沃等，學(xué)校購買其在線學(xué)習(xí)服務(wù)。這類平臺的架構(gòu)也是非常典型的互聯(lián)網(wǎng)架構(gòu)方案。

該架構(gòu)方案除了：接入層負(fù)載->7層負(fù)載->API網(wǎng)關(guān)->微服務(wù)->分布式緩存-分布式數(shù)據(jù)庫外，還會增加配置管理、日志收集、報警監(jiān)控，數(shù)據(jù)查詢異構(gòu)等。

粗略一看，這套架構(gòu)跟阿里京東等電商公司的是基本類似的，就算支撐不了像雙11這樣的QPS，經(jīng)過擴容后也應(yīng)該能撐過這次在線學(xué)習(xí)吧，畢竟全國的學(xué)生不是都在一個云平臺里學(xué)習(xí)的。這個原因我們也會在后面重點討論。

互聯(lián)網(wǎng)公司的學(xué)習(xí)平臺

此次在線學(xué)習(xí)，阿里和騰訊作為互聯(lián)網(wǎng)界的擔(dān)當(dāng)，也承擔(dān)起了為社會提供在線學(xué)習(xí)服務(wù)的責(zé)任。這兩家公司的學(xué)習(xí)平臺，均是基于中臺進(jìn)行搭建的。其架構(gòu)有各自公司的獨特背景，因此不在本文的討論范圍之內(nèi)。

但在線上教學(xué)過程中，大部分直播課程都出現(xiàn)延遲卡頓現(xiàn)象。究其原因，主要是地主家也沒有余糧了。當(dāng)前是遠(yuǎn)程辦公的高使用時期，釘釘微信是各個公司遠(yuǎn)程辦公的主要工具，阿里騰訊的直播帶寬受限于接入運營商，也無法短時間擴容數(shù)倍。

下面我們回歸主題，重點討論下區(qū)縣云平臺及教育信息化公司的在線學(xué)習(xí)平臺的問題原因。

幸福的人生是相同的，不幸福的人生各有各的不同。我主要是從架構(gòu)宏觀角度去推測此次問題的產(chǎn)生原因。

問題一：盲目擴容

從春節(jié)到現(xiàn)在，在朋友圈中可以不斷看到教育信息化公司的朋友們在發(fā)本公司的研發(fā)人員加班擴容的內(nèi)容。

擴容方案不外乎對以下幾個環(huán)節(jié)進(jìn)行擴容：

1.    接入層擴容。對接入帶寬進(jìn)行擴容，增加帶寬，滿足更多的請求所帶來的數(shù)據(jù)量激增。

2.    網(wǎng)關(guān)及應(yīng)用層擴容。由于幾乎都是微服務(wù)架構(gòu)，應(yīng)用層可以說是最方便的擴容點。通過對應(yīng)用層擴容，系統(tǒng)可以同時響應(yīng)更多的請求。

3.    資源層擴容。資源層包括redis緩存、數(shù)據(jù)庫，hbase，ES等各類數(shù)據(jù)存儲資源。本層的擴容有兩個途徑。一個是增加計算資源，例如增加數(shù)據(jù)庫的MySQL核數(shù)，另外一個是增加分片數(shù)量。

擴容是面對激增請求的必要手段，但是如果面對增加一個數(shù)量級左右的請求時，就不能是簡單的進(jìn)行如上擴容就可以解決了。

接入層對一般教育信息化公司相對容易一些，畢竟總帶寬不高，從幾G增加到幾十G對于現(xiàn)在的IDC運營商來講，也不是太難的事情。

應(yīng)用層擴容，也相對容易，現(xiàn)在的互聯(lián)網(wǎng)基礎(chǔ)中間件已經(jīng)足夠完善，擴容個幾倍也是可以掌控的。

資源層出問題了。前面幾層把請求都接收過來了，都在期盼資源層的服務(wù)也能抗過去，但是資源層不僅是增加計算核心，還有連接數(shù)瓶頸，IO瓶頸等一系列問題。有人說，第二種對資源層的分片增加可以緩解上面的問題呀。是的，但這是一廂情愿的。在系統(tǒng)設(shè)計時，如果沒有經(jīng)過很好的分片策略分析，熱點數(shù)據(jù)側(cè)傾到一個或幾個分片上，還是會出現(xiàn)上述的資源層瓶頸問題。

一旦資源層的服務(wù)響應(yīng)時間過長，會造成應(yīng)用層對外的請求響應(yīng)失敗，重試請求會繼續(xù)涌入，當(dāng)數(shù)個應(yīng)用服務(wù)因過量請求阻塞后，外部請求會落入其余應(yīng)用服務(wù)上，于是乎，風(fēng)卷殘云一般引起雪崩效應(yīng)，所有服務(wù)就都掛了。

擴容，不僅是計算資源的堆積。擴容完畢后，一定要有完備的全流程壓測體系支持，否則擴容就會變成增加我們必勝的口號而已。

問題二：限流降級流于形式

沒有哪個互聯(lián)網(wǎng)公司的研發(fā)人員會承認(rèn)自己不會做限流和降級。但是，這個事情往往都流于形式了。

限流降級本身是兩個不同的技術(shù)點，但是限流就是有損服務(wù)，有損服務(wù)又必須有良好的降級方案去應(yīng)對。

限流從接入層到資源層都需要面對。每一層都需要根據(jù)計算資源的配置情況和前期壓測情況通過仔細(xì)斟酌來設(shè)定限流方案，而不是僅僅看本層服務(wù)的計算資源數(shù)量，一拍腦袋的就設(shè)置了一個值。這種值過于保守會形成瓶頸點，稍微大一點，又容易在極高流量的情況下被摸死。

降級更是需要在系統(tǒng)架構(gòu)設(shè)計之初就需要考慮。降級不僅僅是服務(wù)出現(xiàn)故障時的托底方案，更是要跟業(yè)務(wù)方一同商量的業(yè)務(wù)范疇的降級手段。比如說直播間必須在前24小時建好，課件資源不允許即時修改等。

如果要有良好的限流降級方案，此次云平臺服務(wù)商應(yīng)該不會如此不堪沖擊。

教育信息化公司要想解決上述問題，面臨的難點我認(rèn)為有如下：

1.    基礎(chǔ)平臺搭建困難

沒有過硬的基礎(chǔ)平臺體系，想獲得穩(wěn)定的產(chǎn)品基本是空中樓閣。穩(wěn)定的基礎(chǔ)平臺是需要時間積淀，不斷趟坑才能獲得的。不過好在有阿里云等各類云平臺服務(wù)商，他們提供相對完備的解決方案。建議還在IDC機房自建的中小公司盡快上云。

2.    專業(yè)的架構(gòu)師團隊

專業(yè)的架構(gòu)師團隊是核心，否則所有的架構(gòu)只淪落為皮毛，沒有跟公司的自身業(yè)務(wù)融合在一起。不過尖端的架構(gòu)師基本都被頭部互聯(lián)網(wǎng)公司爭搶，如何獲得這方面的人才是所有教育信息化公司需要考慮的事情。

3.    研發(fā)及運維成本

滿足高并發(fā)的架構(gòu)必然帶來極高的研發(fā)成本以及運營成本。公司如何平衡并發(fā)量以及研發(fā)成本直接的關(guān)系，就是教育信息化公司的決策者們自己要考慮的事情了。

這次停課不停學(xué)，不僅是教育信息化企業(yè)的試金石，也是在線教學(xué)平臺驗證其架構(gòu)師團隊的試金石。高并發(fā)不僅是架構(gòu)方案的模仿以及想當(dāng)然的擴容，它需要架構(gòu)與業(yè)務(wù)的深度結(jié)合、認(rèn)真的壓測準(zhǔn)備以及團隊的整體意識提升。

雙11等活動倒逼電商公司技術(shù)的技術(shù)提升，也希望這次停課不停學(xué)能幫助各企業(yè)直面架構(gòu)問題，并提升團隊技術(shù)能力。

本文轉(zhuǎn)載自微信公眾號“行走的伯樂”，作者楊文海。文章為作者獨立觀點，不代表芥末堆立場，轉(zhuǎn)載請聯(lián)系原作者。