一、背景
專案介紹
勵步雙師課堂是以錄播視訊和線下中教老師結合的 AI 智慧化面授教學課程。課堂中有三個角色：
- 主播老師: 視訊哈佛外教老師，帶著小朋友進行英文知識點的教學。主要承載“教”的職能。
- 主教老師: 主要負責引導，陪伴，激勵小朋友，組織課堂紀律，關注小朋友上課的情況，和家長進行一對一溝通等等。主要承載“育”的職能。
- 學生: 上課小朋友，2-8 歲。
目前整體的教學組織架構是以深圳研發中心示範班+加盟校區的方式進行教學研發、培訓、常規授課。通常新功能會先預釋出到深圳示範班預授，穩定後才會釋出到其他加盟校區。這樣既能保證其他加盟校區穩定教學、又能快速迭代新功能。以下一個簡化的組織架構圖。
上文已經提到雙師課堂是以錄播的形式進行教學，必然需要課件視訊。其中課件視訊會經歷幾個流程：錄製、上傳、打點、稽核、教學使用。早期起步階段只有深圳研發中示範班授課，因此課件視訊儲存在本地機房，在同一內網下能正常使用。隨著產品逐漸打磨成形，必然要落地到加盟校區使用。可是一個迫切要解決的問題擺在我們面前：加盟校區如何獲取課件視訊？
要解決的幾個問題：
- 一個課件視訊的容量比較大: 1-2G, 一節課的課件視訊總和: 2-3G。研發中心的教研人員如何快速上傳課件視訊和預覽課件視訊，並且支援加盟校區主播端播放線上課件視訊
- 加盟校區外網環境不穩定的情況下，如何保證課件視訊流暢地播放.
- 如何在研發中心示範班和加盟校區間針對課件視訊做灰度釋出和A/B測試
在這樣背景下，蒲公英發布平臺在內部開始推進。總得來說大概經歷3個階段:
- 階段1: 課件視訊從 “研發中心本地機房” => “雲端OSS”
- 階段2: 課件視訊從 “研發中心本地機房” => “雲端OSS” => “校區機房”
- 階段3: 教學資源從 “研發中心本地機房” => “雲端OSS” => “釋出平臺(管理)” => “校區機房”
二、蒲公英總體架構圖
上方是蒲公英的總體架構圖。最上層是現階段支援的釋出資源型別：課件視訊/圖片、APP安裝包、頁面靜態資源、互動多媒體資源、docker映象、指令碼檔案、Nodejs擴充套件庫DLL等
下半部分是雲端和校區的系統:
- CMDB：管理校區資產資訊。蒲公英將釋出的資源和cmdb的資產資訊(校區城市、分校、教室、教學裝置、校區伺服器)關聯一起.
- 版本管理：記錄各終端使用的各類資源的當前版本號、歷史版本、版本升級依賴.
- 釋出平臺：後臺系統，負責資源的手動釋出、自動釋出、灰度釋出、回滾等釋出策略
- Mercedes Server: 負責接收上游釋出平臺的資源分發訊息、轉發訊息給相應校區節點的Agent服務
- Beetle: 負責上傳資源/下載資源
- Talgate：負責Mercedes Server和所有校區節點Agent服務地註冊，會話連線管理，訊息通訊等
- Mercedes Agent: 負責接收Server的分發訊息、排程Beetle從雲端OSS下載資源、同校區兩臺伺服器的資源同步
- Cadillac: 負責接受校區教室主播端訪問內網資源請求、校區教學服務的api gateway.
三、起源
痛點：課件視訊檔案很大，教研老師上傳視訊時間長、上傳過程出現網路波動或者關閉頁面需重新上傳。課件打點稽核通過後，如何快速提供給示範班使用。
解法：
- 課件系統是一個提供給教研老師製作課件、管理課件的後臺系統。它是一個BS架構的WEB系統，上傳檔案的方式是通過http直傳，上傳過程中一旦有中斷，只能重新上傳， 這樣大大降低教研老師工作效率。經過調研決定採用tus協議實現斷點續傳上傳大檔案。tus協議是一種基於HTTP/1.1和HTTP/2機制用於檔案斷點續傳。這裡畫了一個大致上傳流程圖，詳細內容請檢視tus官方文件(https://tus.io/)。
- 教研老師上傳課件後，還需經過稽核員預覽、稽核通過後才能交付使用。因此考慮可以先上傳到研發中心的資源伺服器，因為是在同一個內網環境，不需要經過外網，這樣加快了上傳速度。待課件經稽核員稽核通過後，再經由資源伺服器上傳到雲端OSS。
- 課件視訊上傳問題已經解決了。但加盟校區的主播端播放視訊的優化方案還未到位，考慮到示範班和加盟校區想盡早使用，前線業務不能耽擱的情況下。我們評估了走外網播放視訊方案的可行性：校區教學網路外接兩條電信線路上網，一條為30M專線網路，一條為200M撥號光纖。互為備份，避免單線故障。我們在研發中心模擬校區的實際網路頻寬，使用10臺PC 通過有線網路卡，同時播放視訊，通過監控防火牆出口流量峰值、檢視cacti 流量實時狀況，並實際在PC 體驗視訊播放的流暢度
測試結果：流量下行峰值為173.8M，平均值為50M。 流量上行峰值為5M. PC播放視訊的實際體驗效果不錯，流暢度良好.
就這樣這套方案平穩地幫我們過濾到下一個階段。
下面給出早期版本的簡化架構圖:
相應的簡化流程：課件 => 斷點續傳 => 線上預覽播放 => 稽核通過，觸發上傳任務 => 非同步上傳到oss => 主播端播放課件視訊
落地效果：基本滿足早期業務需求
四、資源分發
痛點：各校區當地外網環境無法100%保證全天候穩定，主播端線上播放課件視訊出現卡頓、載入中現象。極端情況下影響正常授課。
解法：課件資源如果在授課前已經儲存在校區的伺服器、開始授課時主播端只需要從內網拉取資源，這樣就不依賴於外網環境。源著這個思路開始構思一個異地多校的資源分發系統。
Q：資源分發系統的雲端Server和分校節點Agent如何端到端的實時通訊?
A：複用雙師教學系統的長連線閘道器服務Talgate，各個節點(server, agent)需要先往閘道器中心Talgate註冊，建立長連線資料通道。
Q：如何保證長連線通訊雙方訊息不丟失?
A：ACK+ 超時重傳 + 去重
- Server推送訊息時，攜帶一個標識 SID，推送出訊息後會將當前訊息新增到“待 ACK 訊息列表”。Agent成功接收訊息後，會給Server回一個業務層的 ACK 包，包中攜帶有本條接收訊息的 SID。Server接收後，會從“待 ACK 訊息列表”記錄中刪除此條訊息。【ACK】
- 如果Agent接收不到訊息，Server的“待 ACK 訊息列表”會維護一個超時計時器，一定時間內如果沒有收到Agent的 ACK 包，會從“待 ACK 訊息列表”中重新取出那條訊息進行重推。【超時重傳】
- 如果Agent接收到訊息了，but ACK包丟了，導致Server重傳訊息，可能會讓Agent收到重複的訊息，這時Agent需要根據SID來進行業務層的去重。 【去重】
Q：Server或者Agent當機可能導致重傳失效。下一次重新連線上，Agent之前有若干條訊息丟失，怎麼辦?
A：Server需要進行完整性檢查，利用“時間戳比對”機制，發現Agent“有訊息丟失”的情況，可以重新同步丟失的資料。
- Server給接收方Agent推送 task1，順便帶上一個最新的時間戳 timestamp1，接收方 Agent 收到 task1 後，更新本地最新訊息的時間戳為 timestamp1。
- Server推送第二條訊息 task2，帶上一個當前最新的時間戳 timestamp2，task2 在推送過程中由於某種原因接收方 Agent 和 Server連線斷開，導致 task2 沒有成功送達到接收方 Agent。
- Agent 重新連上Server，攜帶本地最新的時間戳 timestamp1，Server將Agent 暫存的訊息中時間戳大於 timestamp1 的所有訊息返回給Agent，其中就包括之前沒有成功的 task2。
- Agent 收到 task2 後，更新本地最新訊息的時間戳為 timestamp2。通過時間戳機制，Agent 可以成功地讓丟失的 task2 進行補償傳送。
Q: 校區Agent收到任務後，開始從雲端OSS下載資源，如何避免重複下載，下載資源失敗怎麼辦?
A：Beetle是上傳/下載服務元件，部署在校區，負責接收Agent的下載指令，執行實際的從雲端下載資原始檔的工作。
- Beetle先從本地檔案列表檢查檔案是否已經下載或者下載中，若已經下載則返回成功，若正在下載中則返回下載中，否則執行下一步。
- Beetle計算待下載檔案大小 檢查是否大於 可用容量(磁碟剩餘容量-下載中檔案大小)，若大於的情況，現在方案是返回失敗。後續迭代方案是給資原始檔按等級、檔案大小做加權值，優先下載權值高的檔案。
- Beetle對於大檔案的下載，按斷點續傳下載檔案，若出現網路不穩定下載失敗，根據配置檔案的重試次數，執行重試機制。若重試後無效，返回失敗。
- Agent收到下載失敗結果，更新分發任務狀態為“下載失敗”，通知Server任務失敗。並觸發告警到質量監控平臺。
Q: 如果校區儲存資源的一臺伺服器出現故障，如何保證資源正常載入？
A：每個校區部署兩臺伺服器，使用LVS做主機冗餘，避免一臺機器當機，出現單點故障。
- Mercedes Server根據校區節在閘道器注冊的先後順序選舉Master，先給校區Master 伺服器A傳送分發任務，伺服器A完成資源分發後，需同步資源給Slave伺服器B。
- 使用類Rsync+Sesync的機制實現伺服器檔案雙向同步，雙方比對檔案列表，若發現缺失則同步資源。
- 如果伺服器A出現故障無法使用，伺服器B被選舉為Master，接管資源分發任務，待故障機器A恢復後，伺服器B檢查是否有新資源要同步給伺服器A， 有則同步資源。
Q: 如果資源沒有及時分發到校區節點，如何保證主播端正常載入資源？
A：每個校區的閘道器服務Cadillac提供查詢課件資原始檔URL，Cadillac會檢查資原始檔是否釋出，如果釋出則返回內網URL地址，若未釋出則返回外網URL地址。
另外避免一些誤操作導致已經發布的資源丟失的情況，而無法提前發現，建立了一套預警機制：Cadillac每晚11點會查詢往後7天所有校區課表的課件資源URL列表，通過http head方法批量檢查資源是否存在於內網，若不存在則觸發告警、流轉到質量監控報警平臺。
Q: 如果校區兩臺伺服器都出現硬體故障或者長時間斷電的情況下，如何保證主播端正常載入課件資源？
A：主播端當主動探測到校區內網伺服器無法工作後，自動切換到外網訪問雲端服務，載入外網課件資源。
下面給出相應的簡化架構圖：
相應的簡化流程：課件 => 斷點續傳 => 線上預覽播放 => 稽核通過，觸發上傳任務 => 非同步上傳到oss => Mercedes Server建立課件分發任務 => 選取指定校區的Master伺服器、給它傳送任務 => Mercedes Agent接收到任務、記錄任務、給Beetle傳送下載任務、Beetle接到任務、記錄下載任務、下載課件 => 校區伺服器雙向同步資源 => 內網不可用時切換到外網.
落地效果：課件資源不依賴外網環境，主播端正常播放課件視訊，提高教學系統的可用性。
五、多型別資源分發、版本管理
痛點：現有課件分發策略粒度比較粗，僅支援自動分發到所有校區。 一旦課件內容有問題，必將影響所有校區的正常教學。
解法：搭建統一發布平臺，打通上游業務系統、CI/CD系統和下游資源分發系統。管理資源版本號、釋出記錄、制定按城市、校區、版本三個維度的釋出策略。監控釋出流程，出現失敗的任務觸發告警。
Q: 蒲公英發布平臺除了支援課件視訊釋出外，也支援包括互動多媒體資源、安裝包、Nodejs擴充套件庫DLL、頁面靜態資源、指令碼檔案、Docker映象等多種型別資源的釋出。不同型別資源是否有共性，能不能抽象成通用的一種資源，實現統一管理？
A：多種型別資源都有一些必要的屬性：型別、釋出源、版本號、檔名稱、檔案大小、檔案存放OSS地址、MD5值、建立時間等，由此可以抽象成：“資源”、“釋出任務”、“釋出策略”、”釋出任務歷史“ 四個實體物件組成蒲公英的基礎單元。
Q：其他型別資源的分發方式是否跟課件資源一樣：由蒲公英主動推送分發任務給校區節點，再由校區Agent執行下載資源操作？
A：對於主播端、主教端、電子班牌、手錶這類安裝包，需要客戶端執行下載安裝操作。顯然無法保證客戶端24小時線上，蒲公英有釋出任務時，很大概率是客戶端不線上或者正在授課使用中，無法實時升級。因此被動接受釋出任務的方式不適用於客戶端升級。所以蒲公英需要提供介面給客戶端檢查是否有新版本更新，由客戶端定期檢查和執行升級。另外考慮到所有客戶端都是執行在校區內，為了減少外網環境的依賴，大檔案的安裝包先分發到校區伺服器，再由校區閘道器Cadillac提供版本更新介面，提高客戶端升級成功率。
相應的簡化流程：課件 => 斷點續傳 => 線上預覽播放 => 稽核通過，觸發上傳任務 => 非同步上傳到oss => 建立課件分發任務 => 蒲公英發布 => 選取指定校區的Master伺服器、給它傳送任務 => Mercedes Agent接收到任務、記錄任務、給Beetle傳送下載任務、Beetle接到任務、記錄下載任務、下載課件 => 校區伺服器同步資源 => 內網不可用、切換外網.
落地效果：蒲公英統一發布平臺上線1個月左右來共釋出250+個課件、1000+個互動多媒體資源、20+次客戶端版本（主播端、主教端、手錶）升級。
六、未來規劃
持續優化各服務元件，優化系統使用互動體驗，優化使用者角色許可權 ，解藕業務側邏輯，解藕部署環境的依賴，引入多租戶的組織結構，開放能力給集團其他夥伴使用。
七、經驗總結
從技術架構角度來說，勵步雙師教學系統是一個異地多校的分散式架構，它複雜度來源主要包括：高可用，可擴充套件性。這裡主要介紹了分散式資源分發（蒲公英）平臺的架構演進過程，基於業務發展階段，分別引入資源分發、資源雙備、版本管理，灰度釋出等功能。
招聘資訊
好未來技術團隊正在熱招前端、演算法、後臺開發等各個方向高階開發工程師崗位，大家可點選本公眾號“技術招聘”欄目瞭解詳情，歡迎感興趣的夥伴加入我們！
也許你還想看
