想了解一個異地多校平臺的架構演進過程嗎？讓我來告訴你！

時間 2020-08-30

原文原文鏈接

1、背景前端

項目介紹算法

勵步雙師課堂是以錄播視頻和線下中教老師結合的 AI 智能化面授教學課程。課堂中有三個角色：docker

主播老師: 視頻哈佛外教老師，帶着小朋友進行英文知識點的教學。主要承載「教」的職能。
主教老師: 主要負責引導，陪伴，激勵小朋友，組織課堂紀律，關注小朋友上課的狀況，和家長進行一對一溝通等等。主要承載「育」的職能。
學生: 上課小朋友，2-8 歲。

目前總體的教學組織架構是以深圳研發中心示範班+加盟校區的方式進行教學研發、培訓、常規授課。一般新功能會先預發佈到深圳示範班預授，穩定後纔會發佈到其餘加盟校區。這樣既能保證其餘加盟校區穩定教學、又能快速迭代新功能。如下一個簡化的組織架構圖。api

上文已經提到雙師課堂是以錄播的形式進行教學，必然須要課件視頻。其中課件視頻會經歷幾個流程：錄製、上傳、打點、審覈、教學使用。早期起步階段只有深圳研發中示範班授課，所以課件視頻存儲在本地機房，在同一內網下能正常使用。隨着產品逐漸打磨成形，必然要落地到加盟校區使用。但是一個迫切要解決的問題擺在咱們面前：加盟校區如何獲取課件視頻？服務器

要解決的幾個問題：網絡

一個課件視頻的容量比較大: 1-2G, 一節課的課件視頻總和: 2-3G。研發中心的教研人員如何快速上傳課件視頻和預覽課件視頻，而且支持加盟校區主播端播放線上課件視頻
加盟校區外網環境不穩定的狀況下，如何保證課件視頻流暢地播放.
如何在研發中心示範班和加盟校區間針對課件視頻作灰度發佈和A/B測試

在這樣背景下，蒲公英發布平臺在內部開始推動。總得來講大概經歷3個階段:架構

階段1: 課件視頻從「研發中心本地機房」 => 「雲端OSS」
階段2: 課件視頻從「研發中心本地機房」 => 「雲端OSS」 => 「校區機房」
階段3: 教學資源從「研發中心本地機房」 => 「雲端OSS」 => 「發佈平臺(管理)」 => 「校區機房」

2、蒲公英整體架構圖框架

上方是蒲公英的整體架構圖。最上層是現階段支持的發佈資源類型：課件視頻/圖片、APP安裝包、頁面靜態資源、互動多媒體資源、docker鏡像、腳本文件、Nodejs擴展庫DLL等異步

下半部分是雲端和校區的系統:分佈式

CMDB：管理校區資產信息。蒲公英將發佈的資源和cmdb的資產信息(校區城市、分校、教室、教學設備、校區服務器)關聯一塊兒.
版本管理：記錄各終端使用的各種資源的當前版本號、歷史版本、版本升級依賴.
發佈平臺：後臺系統，負責資源的手動發佈、自動發佈、灰度發佈、回滾等發佈策略
Mercedes Server: 負責接收上游發佈平臺的資源分發消息、轉發消息給相應校區節點的Agent服務
Beetle: 負責上傳資源/下載資源
Talgate：負責Mercedes Server和全部校區節點Agent服務地註冊，會話鏈接管理，消息通訊等
Mercedes Agent: 負責接收Server的分發消息、調度Beetle從雲端OSS下載資源、同校區兩臺服務器的資源同步
Cadillac: 負責接受校區教室主播端訪問內網資源請求、校區教學服務的api gateway.

3、起源

痛點：課件視頻文件很大，教研老師上傳視頻時間長、上傳過程出現網絡波動或者關閉頁面需從新上傳。課件打點審覈經過後，如何快速提供給示範班使用。

解法：

課件系統是一個提供給教研老師製做課件、管理課件的後臺系統。它是一個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 => 主播端播放課件視頻

落地效果：基本知足早期業務需求

4、資源分發

痛點：各校區當地外網環境沒法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接到任務、記錄下載任務、下載課件 => 校區服務器雙向同步資源 => 內網不可用時切換到外網.

落地效果：課件資源不依賴外網環境，主播端正常播放課件視頻，提升教學系統的可用性。

5、多類型資源分發、版本管理

痛點：現有課件分發策略粒度比較粗，僅支持自動分發到全部校區。一旦課件內容有問題，必將影響全部校區的正常教學。

解法：搭建統一發布平臺，打通上游業務系統、CI/CD系統和下游資源分發系統。管理資源版本號、發佈記錄、制定按城市、校區、版本三個維度的發佈策略。監控發佈流程，出現失敗的任務觸發告警。

Q: 蒲公英發布平臺除了支持課件視頻發佈外，也支持包括互動多媒體資源、安裝包、Nodejs擴展庫DLL、頁面靜態資源、腳本文件、Docker鏡像等多種類型資源的發佈。不一樣類型資源是否有共性，能不能抽象成通用的一種資源，實現統一管理？

A：多種類型資源都有一些必要的屬性：類型、發佈源、版本號、文件名稱、文件大小、文件存放OSS地址、MD5值、建立時間等，由此能夠抽象成：「資源」、「發佈任務」、「發佈策略」、」發佈任務歷史「四個實體對象組成蒲公英的基礎單元。

Q：其餘類型資源的分發方式是否跟課件資源同樣：由蒲公英主動推送分發任務給校區節點，再由校區Agent執行下載資源操做？

A：對於主播端、主教端、電子班牌、手錶這類安裝包，須要客戶端執行下載安裝操做。顯然沒法保證客戶端24小時在線，蒲公英有發佈任務時，很大機率是客戶端不在線或者正在授課使用中，沒法實時升級。所以被動接受發佈任務的方式不適用於客戶端升級。因此蒲公英須要提供接口給客戶端檢查是否有新版本更新，由客戶端按期檢查和執行升級。另外考慮到全部客戶端都是運行在校區內，爲了減小外網環境的依賴，大文件的安裝包先分發到校區服務器，再由校區網關Cadillac提供版本更新接口，提升客戶端升級成功率。

相應的簡化流程：課件 => 斷點續傳 => 在線預覽播放 => 審覈經過，觸發上傳任務 => 異步上傳到oss => 建立課件分發任務 => 蒲公英發布 => 選取指定校區的Master服務器、給它發送任務 => Mercedes Agent接收到任務、記錄任務、給Beetle發送下載任務、Beetle接到任務、記錄下載任務、下載課件 => 校區服務器同步資源 => 內網不可用、切換外網.

落地效果：蒲公英統一發布平臺上線1個月左右來共發佈250+個課件、1000+個互動多媒體資源、20+次客戶端版本（主播端、主教端、手錶）升級。