技術乾貨 | 網易雲信本地服務端叢集錄製探索與實踐

語言: CN / TW / HK

時間 2021-12-14 08:54:59 網易智企技術+

主題: Java

導讀：本文主要介紹了網易雲信本地服務端叢集錄製的整體系統架構。系統性地解決了使用本地服務端錄製時併發錄製場景及可用性的問題，幫助客戶快速實現安全可靠的本地服務端錄製。

文｜古德

網易雲信服務端開發工程師

背景

基於網易雲信 linux 錄製 sdk，可以通過以 sdk 拉流的方式在開發者的 linux 伺服器上實現本地錄製的功能；可以實現錄製的定製化開發，錄製檔案儲存在本地具有更高的安全性。本地服務端錄製在金融業或對於資料安全有很高要求的場景下非常重要，同時具有更高的靈活性（比如自定義水印），這也是本地服務端錄製的一個重要優勢。

在實際客戶接入的場景下，客戶方的開發者大多是 Java 開發，對接 linux 錄製 sdk，需要封裝 jni 橋接包，還需要考慮錄製的負載均衡，錄製服務的可靠性等問題，接入成本很高。為了在降低接入成本的同時又能實現可擴充套件的高可用本地服務端錄製服務，搭建一套本地服務端錄製的分散式集群系統顯得格外重要。

下面我們介紹一下本地服務端錄製分散式叢集的特性。

系統特性

錄製叢集動態擴縮容；
多備份錄製實現錄製高可用；
註冊中心高可用；
多種負載均衡策略，CPU 負載，併發數，輪詢，隨機；
CPU使用率超閾值警告；
錄製過程中錄製健康狀態實時監控及警告；
可擴充套件的物件儲存方式；
提供跨平臺的 REST API 方式呼叫實現本地服務端錄製；
提供原生無侵入式的 JAVA API sdk jar 包，方便使用 Java 開發的客戶快速接入。

為了實現上面的特性，整個系統的架構是什麼樣的呢？下面來介紹一下。

整體架構

架構上整體分為三層

介面層

業務方服務端可以直接使用雲信的 Java sdk 控制錄製的開始、佈局的更新以及錄製結束。

服務層

提供標準的 rest api 的介面供介面層呼叫，同時介面受到祕鑰加密鑑權的安全保護。

為了讓叢集內的機器協調執行錄製任務，服務層在入口處有一個排程層，負責計算叢集內的各個節點的錄製併發數。結合節點機器的配置權重，在開始錄製時實時計算錄製任務應該分配到哪臺節點最合適。在開始錄製後，更新錄製佈局及結束錄製時，也是在排程層根據錄製編號將請求自動路由到正確的錄製節點上。在追求高可用性的背景下，可以選擇使用多臺錄製機器同時執行一個房間的錄製任務。

註冊中心，叢集中的每一個錄製節點都將自己註冊到註冊中心上。 每一個錄製節點都和錄製中心保持心跳請求。 當錄製節點下線後，排程層會自動發現更新後的註冊列表。通過註冊中心可以實現不停機擴容，只要啟動新的錄製節點註冊到註冊中心後，叢集感知到新的錄製節點就會按照指定的負載均衡策略將錄製請求路由到新的錄製機器節點上了。

註冊中心被設計成一個高可用的註冊中心，只要超過半數的註冊中心線上就可以保證服務正常。
註冊中心具備主節點選舉機制，從而方便實現由主節點來執行的叢集內單機定時任務。
同時各個錄製點在上報心跳的時候，會將該節點的機器負載，錄製併發數等資訊一併傳送到註冊中心，供排程層針對採集的資料進行合理的排程路由。

錄製執行器負責呼叫雲信本地服務端錄製 sdk 動態連結庫，實現拉流錄製核心控制。每一個房間的錄製會被分配一個單獨的程序來執行。錄製執行器管理器通過 socket 與錄製執行器通訊，控制開始結束錄製和更新佈局等操作，同時也通過 socket 探測錄製執行器的健康狀況，當發現無法探測到錄製執行器時即時告警。

說到告警，自然少不了對叢集的監控。全面的監控可以保證對服務整體執行狀態做到了如指掌，更能夠提前發現問題即時應對，甚至做到自動容災。因為錄製對 CPU 資源的消耗非常大，所以對叢集 CPU 使用率的監控是必不可少的。

服務斷路保護器， 是指在服務 CPU 或錄製併發數超過設定的閾值以上之後，服務叢集將拒絕新的開始錄製的請求，已達到保護錄製叢集穩定性的目的。

配置管理模組 用來儲存叢集的系統配置，以及業務配置。更新配置後，整個叢集會自動感知到配置更新。

物件儲存模組 負責儲存錄製檔案。在錄製完成後，可以將機器上的錄製檔案根據配置自由上傳到期望的儲存服務中，比如傳統的 ftp 伺服器、網易的 NOS 服務、阿里的 OSS 服務等物件儲存服務。

定時任務， 這裡分有兩種定時任務，一種是全叢集中同一時間只能有一個機器在執行的任務（這裡叫它 Leader Job，由叢集中的主節點負責執行），另外一種是叢集內所有的機器都要執行的任務（這裡叫它 Distribute Job）。

Leader Job，典型的一個任務是掃描整個叢集中所有正在錄製的記錄，對他們進行健康探測，發現錄製異常時，完成錄製異常掃尾操作，如殺掉錄製程序，更新錄製記錄狀態等。還會發出告警通知。
Distribute Job，其中一個重要的任務是要定時清理掉磁碟上過期的錄製檔案及對應的日誌檔案，回收磁碟空間。

資料層

大家可以看到上圖中黃色區域內的部分就是我們的本地服務端叢集服務。外圍的應用伺服器對整個錄製過程透明，不需要關心錄製內部複雜的實現邏輯。當錄製結束後，應用伺服器就會收到錄製檔案的抄送請求。

針對上面的拓撲圖，大家對整體請求的時序可能還不太清楚，那麼下面再帶大家瞭解一下服務的時序流程。

時序流程

時序流程步驟

錄製節點啟動後，會將自己註冊到註冊中心，收到註冊請求的註冊中心節點再將註冊請求廣播同步給註冊叢集中的其他註冊節點。
外圍的應用伺服器啟動後，通過初始化 Java sdk 定時拉取註冊中心中的錄製節點列表資訊。
外圍的應用伺服器發起開始錄製後，根據要錄製的備份數量和叢集機器的負載均衡策略選擇到由哪幾臺機器承擔錄製任務。這樣雖然佔用了更多的資源，卻可以提高錄製服務的可用性，只要其中一臺錄製機器服務正常即可。另外也可以通過配置選擇當監聽到錄製服務異常時，開啟一個新的錄製程序進行錄製，這樣在對成本敏感的條件下，可以儘可能保證服務的可用性。
外圍的應用伺服器發起更新佈局操作後，系統根據錄製編號將請求路由給正確的錄製節點進行控制。
叢集中的主節點定時任務負責檢查叢集內所有錄製節點中正在進行中的錄製的健康狀態。當發現有錄製失敗的情況下，會抄送給外圍的應用伺服器。
如果叢集中的錄製節點的 CPU 超過設定的閾值時也會發送告警抄送給外圍的應用伺服器。