作者 | 麼敬國（新東方教育科技集團雲教室直播平臺技術負責人），灝正（ 阿里雲 Serverless 架構師）
新東方教育科技集團定位於以學生全面成長為核心，以科技為驅動力的綜合性教育集團。新東方線上教育業務的雲教室系統支援了影片直播、轉碼、點播等新東方所有線上教育場景。隨著業務量的增大，由於直播轉錄及影片轉碼任務處理平臺具有明顯的波峰波谷特性，自建機房較低的資源利用率成為了業務的核心痛點。為了提升計算資源利用率，進一步實現降本提效目標，在幾次嘗試之後，新東方踏上了 Serverless 實踐之路。以下內容是由新東方教育科技集團雲教室直播平臺技術負責人 麼敬國 在雲棲大會的分享。
如何應對難以預測的業務量？
新東方除了自己的線上教育業務使用雲教室平臺以外，還透過美刻雲直播對外開放了新東方的直播能力。雲教室直播平臺主要支援四種業務模式:
- 雲教室：線上直播互動課，講究互動性。
- 雲點播：錄播課。
- 雲直播：大型直播，以主播為主。
- 智慧教室：軟硬體結合的方案，提供類似於雙師的教育模式。
直播+錄播是新東方主推的課程交付模式。直播課程互動性強，可以實現良好的課堂互動，激發學生的學習興趣；教師可以基於學生的課堂反饋或互動直接與學生進行互評，便於教師及時對教學環境作出微調，從而讓教學過程更有針對性；透過互動和課堂答疑，可以讓教學過程和效果更有保障，直播課程比較適合低幼年齡段的學生。
而面對高中及高中以上年齡段的學生，錄播課更為合適，錄播課特點為學習時間靈活，學生可以自主對學習內容進行檢索，進行有選擇性的學習，一般適用於高中和高中以上年齡段學生。錄播課的優點在於可以對授課內容不斷進行打磨、編輯，製作精品課程，需求量逐步加大。
最初團隊採用地錄製技術方案為客戶端錄屏，將老師的直播進行錄製，方便學生反覆觀看，但這樣的方式出錯率高， CPU 佔用率也較高，無法對錄製 UI 佈局進行靈活定製，只能是看到什麼錄什麼，這樣的方式僅能滿足低幼年齡段的課程需求。
今年，新東方開始對接大學生線上教育業務，對錄播課程的質量提出了更高的要求。團隊開始考慮採用服務端錄製的方式解決問題。服務端錄製的兩個核心點在於直播錄製和影片標準化生產。我們的業務模式決定了我們很難準確預測業務量，因此，新東方關鍵的技術任務是實現計算彈性。
三種選擇，函式計算脫穎而出
要解決服務端錄製的問題，擺在團隊面前的有三個可選的技術路線：
- 直接使用 ECS 自建，該方案的優勢是靈活性比較高，但問題在於計算沒有彈性，雖然雲廠商提供了彈性分配 ECS 資源 API ，但是自己實現整個計算彈性需要巨大的開發量，同時後續運維比較複雜，資源成本高，難以做到標準化。
- 雲錄屏 SaaS 方案，這個方案的優勢是具備標準化的服務，研發投入比較少，運維工作也較少，但是問題在於靈活性差，資源成本極高，難以進行進一步的效能最佳化。我們希望尋找一家成熟的 SaaS 廠商提供地服務以快速支援業務，但是經過試用，這些平臺的成熟度和技術指標等均無法滿足我們的需求。
- 採用阿里雲函式計算 FC，我們發現阿里雲的函式計算產品可以完美滿足計算的彈性需求，只需要關注具體需求在平臺上做開發即可，研發投入小同時免運維，開發過程自主可控，靈活性高，可按需使用極大降低了使用成本，實現標準化相對容易。不過函式計算是一個比較新的技術，團隊需要一段時間來熟悉。
經過反覆比對，新東方團隊選擇使用使用函式計算來解決服務端錄製問題。
新東方的 Serverless 實踐
錄播轉碼，函式計算小試牛刀
我們首先在錄播轉碼場景下進行了嘗試。錄播轉碼的核心訴求是對直播流進行實時轉碼，儲存為標準的影片格式，方便後續加工使用。
在這個場景中，我們第一次感受到了函式計算 FC 帶來的彈性優勢。在老師進入房間發起轉碼請求後，可快速啟動函式例項進行轉碼。在上課結束後，結束轉碼任務，將臨時音影片結果上傳至雲端儲存後即可立即釋放函式例項，不會存在任何計算資源的浪費。有了在錄播轉碼專案中應用函式計算的經驗以後，我們對函式計算方案有了更大的信心。
初露鋒芒，函式計算直播合流轉碼方案
之後，我們啟動了雲端錄製專案。使用 Chrome 瀏覽器加入直播房間，對瀏覽器介面進行截圖錄製，該方案的關鍵在於彈性提供瀏覽器例項。
因此，我們利用阿里雲函式計算啟動 Linux 容器，在 Linux 容器執行 Chrome 瀏覽器實現彈性提供瀏覽器例項。整個的錄製流程是這樣的：老師進入教室以後，開始進行音影片推流以及白板操作。同時，錄製平臺發起錄製請求，啟動函式處理，開始接收教室的音影片流和白板操作，並在瀏覽器展現整個教室的畫面，同時做截圖。課程結束後，平臺發起結束錄製請求，函式計算平臺會優雅地終止例項。終止之前，例項會將臨時結果上傳至雲端儲存，隨後函式例項被銷燬，不存在任何資源浪費。
開箱即用的可觀測能力
我們認為，可觀測能力對於函式計算平臺至關重要。首先，業務高峰期需要啟動大量函式例項，因此，必須要完整的 metrics、log 和 trace 才能有效對海量例項進行監控。其次，因為函式計算例項按需建立，完成任務之後被銷燬，平臺必須儲存完整的日誌，以便發現問題後開發人員進行排錯。
我們曾在開發錄製服務的過程中面臨的問題是：啟動函式例項以後，Chrome瀏覽器要訪問直播服務，此時網路出現問題，導致錄製失敗。後續我們使用阿里雲 SLS 日誌平臺檢視日誌，發現 Chrome 瀏覽器核心對網路處理過於敏感。找出問題後，對症下藥，加入了重試機制，問題得以解決。
超出預期，函式計算帶來更多驚喜
在使用函式計算技術之前，我們期望它能透過百毫秒拉起上萬個例項，定時預熱徹底解決冷啟動困難，幫助我們承載直播轉碼和錄屏業務業務洪峰。有效應對大規模突發線上流量，按量付費，提高資源利用率，減少 20% 資源成本開支，極大程度降低運維成本，讓我們可以只專注業務創新。在實際使用的過程中，我們發現函式計算不但能夠中我們完美滿足我們的需求，還帶來了驚喜：讓我們的開發人員只需掌握幾個新概念、使用幾個 API ，即可輕鬆使用平臺。函式計算方案執行一段時間以來，雲資源費用得到較大降低。另外，函式計算允許根據自己的業務場景製作模板，並且可供其他業務方使用，也為我們帶來意外收穫。
點選閱讀原文，檢視新東方完整影片講說！