本文由UCloud RTC首席架構師 王立飛的線上分享內容整理而成。詳細介紹了URTC萬人直播互動的架構設計與難點，在研發、業務應用和產品迭代過程中的架構演進與考量標準。
文 / 王立飛
整理 / LiveVideoStack
大家好，我是王立飛，目前在UCloud負責RTC的架構以及優化，本次分享的主題是URTC在萬人直播互動場景下的實踐與優化經驗，主要從萬人直播互動難點、URTC架構設計及實踐、URTC產品介紹這三個部分展開：
1. 萬人直播互動難點
萬人直播互動的難點有很多，其中大家經常遇到或普遍關注的主要有四個問題：大流量、讀寫擴散、高併發以及用戶分佈。
大流量：實時互動本身就是一種大流量的數據交互活動，而萬人直播則是在小規模直播互動形式的基礎上進行了萬級別的末端放大或中間鏈路的放大，因此其數據流量是非常龐大的，尤其是在拉流端。
讀寫擴散：RTC在控制層面（信令層），每個人的操作都可能會被放大至萬倍甚至十萬倍。在轉發面（數據包轉發），邊緣節點以及核心節點流量又將會被放大多少倍？
用戶分佈：用戶分佈是多人實時活動中比較常見的一個問題。用戶分佈於全國各地，面對不同的運營商、不同的網絡質量，就近接入該如何為每個用戶提供更優質的觀看體驗。
2. URTC架構設計及實踐
接下來我主要講一下針對上述難點，我們設計了一個怎樣的URTC架構，為什麼要這麼設計架構，URTC產品在線上運維過程中所遇到的問題以及如何解決這些問題。
2.1 URTC架構設計
URTC系統架構如圖所示，我相信大道至簡，架構應該明確清晰，每個子系統應該簡單高效，因為簡單的東西更容易穩定，更容易維護，同時更容易產生更大的性能飛躍。
第一個是RTC核心業務集群，承載的是RTC的信令控制以及RTC實時互動數據轉發的核心功能。
第二部分是轉碼錄製轉推，在RTC核心業務集群之上，完成的是整個RTC 實時畫面合成和轉碼的工作，CDN轉推以及雲端錄製保存。
第三部分是支撐業務，包括監控、計費、接入以及增值業務四個模塊。監控部分是針對線上服務運營情況的監測，方便我們與用戶定位問題並優化產品。接入服務主要負責用戶的就近接入以及負載均衡。
2.2 URTC設計準則
我們系統的設計原則：微服務、極簡設計、普通化。
微服務：這個是一個很普遍的設計原則，這裡不再贅述。
極簡設計：首先，URTC系統中所有的功能都進行了系統的拆分，單一的系統只實現單一的功能。其優點是更方便後臺研發人員熟悉整個系統，進行單一功能的優化。其次，系統可以做到單獨發佈、驗證，這對於整體灰度來說是非常好的體驗。
普通化：普通化對應的主要是減少硬件依賴、減少系統依賴，這也是大家經常會忽略的地方。例如許多開源系統軟件涉及功能繁多，像RTC的SFU服務、MCU、畫面合成以及錄製轉推可能都在一個系統中，這會帶來許多各種各樣的問題。我們可能需要一個64核 128G內存 1T硬盤 1G帶寬的機器配置，在系統擴容的時候這將會非常受限，沒辦法很快地找到系統的替代品是一件相當危險的事情，因此在系統設計之初我們要極力避免這種高度依賴資源的行為。
2.3 URTC的實踐
URTC的實踐是我們線上運維過程中的一些心得，主要分為四個部分，涵蓋了RTC整個交互鏈路，從調度、推流、分發到拉流業務功能的業務閉環。
2.3.1 URTC實時調度
實時調度最大的一個目標即實現負載均衡，將流量分散。其次是就近接入，為用戶選擇最優質的節點進行調度。而最容易被忽略的則是流量隔離以及分區保護兩點。流量隔離是指服務器或者用戶的業務可能會受到攻擊和流量暴增，此時我們需要對存在問題的區域進行流量隔離，以降低風險。分區保護是指可能存在部分用戶對分區有一定需求（如活動產生的流量暴增），此時可能造成系統的不穩定，就需要對這一特定區域進行隔離，單獨進行容量擴容，同時保證不會對其他用戶服務產生影響。
2.3.2 URTC推流接入
推流、分發和調度是RTC中通用的鏈路過程。在實時交互的過程中，推流是非常重要而又脆弱的一個環節。假設一個拉流點存在問題，它只會影響某個觀眾的觀感，而推流端影響的則是所有觀眾的體驗。因此在推流端一定要保證接入質量的穩定，以及鏈路容災的備份。
推流相對於拉流來說不會呈幾何倍數的放大，我們可以在推流端進行一些優化工作。推流端接入通過HTTP DNS進行分區後，分區會給我們的SDK分配三個接入地址，然後進行動態的Ping速。在此基礎上我們做了進一步的優化，針對大運營商，我們將最快歷史接入地址保存下來，以便於用戶快速接入、提升用戶體驗。
2.3.3 URTC源站保護
多路徑接入：推流的邊緣節點由多個接入點作為備份，如果一個點發生故障，推流端可以通過另外的節點繼續進行推流，中斷切換影響最多僅有秒級別。
多路徑傳輸：從邊緣點到路由節點，路由節點在每個區都會有節點，以防止其中一個路由節點崩潰，流量可以迅速遷移到另外的轉發節點，保證推流端不會發生長時間中斷。
適當冗餘：在推流端可以進行適當冗餘。冗餘的方式有很多，例如在用戶到邊緣節點可以採用FEC或者多發的策略進行數據的冗餘上傳，在邊緣節點到路由節點也可以進行適當的冗餘傳輸，以降低整個RTC的延時。
2.3.4 URTC分發優化
許多公司都有智能路由的路由轉發系統，我們的智能路由系統在國內設有華東、華北、華南等幾個路由節點進行各個區域路由轉發的操作，同時也可進行幾個節點間的災備。路由節點的鏈路依舊要進行適當的冗餘，鏈路一般會選擇最優路徑以及次優路徑作為傳輸路徑。延時、丟包是其中比較關鍵的衡量指標，跳數與成本兩項指標也會佔有一定權重，綜合計算得出一條最優路徑。所有的數據包經過路由轉發後都會通過最優路徑優先到達另外的邊緣。次優路徑則會作為災備或最優路徑變差情況下暫時性的鏈路傳輸，以便後續再次傳輸時篩選新的最優路徑進行傳輸。
UCloud的數據中心是有專線進行互聯的，在某些地點，例如跨洲際的中美之間的互通，我們都是通過專線來保證重要數據的傳輸。在國內也是專線和公網作為鏈路災備，同時幾個節點間的智能路由管理作為分發網絡。
2.3.5 URTC拉流
萬人直播系統中除了推流端是脆弱的優化點之外，拉流端也是優化最多的地方。其中常見的問題有以下幾種：
第一，用戶的網絡是不對等的，要解決不對等網絡下用戶的體驗。
第二，萬人直播互動中，端上的解碼性能可能會遇到瓶頸。在同時接收和解碼多路碼流時，由於移動端解碼能力有限，可能會導致用戶體驗驟降。
第三，萬人直播在末端流量會存在萬倍的放大，那麼如何優化流量的放大比？實際上我們無法在末端進行優化，大量的用戶使得每臺服務器都會承載一個放大比，我們能做的更多的是在路由節點與核心轉發之間通過幾倍的放大比使得末端達到完整的流量共享。
第四，在系統達到極限的情況下，應該通過柔性的降級使得用戶的實時交互正常進行。
- 用戶網絡不對等
用戶的位置、網絡運營商、網絡（4G/WIFI）千差萬別，而遠端推流來源相同。針對這種情況，在Web端常用的解決方式為多播，壓力主要集中在推流端上傳，需要編碼多路流上傳（常見的是一路高質量流和一路低質量流）。用戶端只需要根據自己的實際情況選擇相應質量流完成下發，以此達到不同用戶可以享受不同的用戶級別。在Native端更多采用的是分層的編碼。
- 解碼性能
在互聯網中用戶大都使用的是分辨率較低的場景，因此解碼性能的應用比較少。但在傳統領域例如教育、金融，對於清晰度的要求則會相對較高。假設在17人連麥的場景中，每個鏈路的帶寬按1M計算，每個人要拉取17路流，這就需要17M的下行網絡帶寬，並且每個用戶還需要解碼17路 720P的視頻。對於使用較穩定的有線網絡以及性能較好的PC設備的用戶來說沒有什麼問題。但對於4G網絡，低功耗移動端設備用戶來說 17路 720P無論是帶寬還是解碼性能都會成為瓶頸。此時多播無疑是更好的選擇，我們可以通過轉發低質量的碼率供移動端用戶享用，高質量的碼流供PC端、有線網絡用戶享用。
在產品中更好的優化方式：在有主持人的會議中，可以讓主持人動態選擇主講人的畫面為高質量畫面，其他人使用低質量畫面。或者在自由討論的模式下所有人都應用低質量畫面進行溝通，這樣對於交互的實時體驗會是均衡的結果。當然我們也可以選擇MCU，但是在互聯網規模級別的視頻會議和實時溝通中不太現實，硬件的成本會特別高。通過多播加SFU的場景策略優化，可以很好的達到MCU的效果，同時可以節省流量以及硬件成本。
- 流量優化
在萬人直播場景中流量在最末端會被放大萬倍，假設用戶分佈在不同的服務器中，如果說沒有路由節點使用的是傳統的橋接模式，源站會被路由節點瞬間上萬路的拉流，每一路假設有500K ，就已經被放大了1萬倍。而加入路由節點的好處是我們可以在路由節點之間進行流量的轉發。路由節點下面的所有碼流針對源站只需要拉一路流，在每臺服務器上用戶去共享這路流，核心路由的節點的流量不會被放大上萬倍，同時可以很好的保護源站的回源質量，保證下端算法的更好應用，為拉流端的最後一公里提供更好的視頻觀感。
其實服務器的架構有很多種。最常用的是用戶通過一臺服務器來服務一個會議，每個會議分佈在不同的服務器上，調度方式是主講人（管理員）定位整個會議室。如果會議的規模較大，服務器的配置要求高，替代品較少。服務器一旦崩潰，龐大的數據流量很難進行遷移。
第二種，應用相對較多的是橋接模式，邊緣節點之間進行橋接。假如我們的源站分佈於100臺服務器，源站會同時被100臺服務器拉流，放大比為100倍。假設在源站上存在100個主播同時推送，源站的下行壓力會非常大，而且每一路源站的回源質量會非常差，反而會破壞下行的觀看體驗。
第三種，源站推流到轉發中心，再由轉發中心通過合併回源進行邊緣的流量下發，在最邊緣承載更多的用戶量，同時轉發中心可以完成智能路由，故障轉移方案。
- 有損服務
我們將極端場景下的有損服務的提供分為幾個步驟。
首先是質量的降低，對於音頻和視頻，音頻的質量需要保障，可以通過逐步降低視頻的清晰度來保障最基本的體驗。如果視頻還是不能有相對較好的體驗，則會被關閉，提供下一降級的實時互動的音頻，以完成實時溝通的需求。
第二，在服務達到極限（可能崩潰）的情況下，我們可以通過旁路的CDN承載更多的流量，為用戶提供最基本的觀看體驗。
3. URTC產品介紹
核心功能主要是實時語音通話、實時視頻會議以及互動視頻直播。
上圖為URTC節點的分佈圖，節點分佈主要依賴於UCloud海量的數據節點，公有云的可用分區以及專線資源進行服務的搭建。
應用場景主要是在線教育，包括1對1互動課、1對17小班課、互動大班課和雙師課堂。
第二個應用場景是在智能設備領域，包括VR視頻眼鏡、車聯網自動駕駛、電梯可視對講、到訪登記系統以及無人機監控。
第三個是在傳統的互動娛樂場景，互動遊戲，遊戲解說以及比賽直播。
URTC平臺的兼容性目前已經覆蓋Web端、iOS端、Mac端、Android端、Windows端、ARM端的海思系列和其它ARM平臺以及Linux端。
