編者按：作為互聯(lián)網(wǎng)通信云服務商，除了滿足最基本的音視頻數(shù)據(jù)實時傳輸需求外，還會需要提供很多個性化的云端服務。本文來自融云的聯(lián)合創(chuàng)始人兼 CTO 楊攀在 LiveVideoStackCon2019 北京站上的精彩分享，結合融云去中心化的媒體服務架構，解析如何構建靈活的、可擴展的音視頻通訊云服務。
大家好，我是融云的聯(lián)合創(chuàng)始人兼 CTO 楊攀，本次我分享的主題是融云在公有云媒體服務設計的理念和思路。
我是從2002年參加工作，至今已經(jīng)十七年，其中有十五年的時間都是在做關于 IM 的工作。2004年時我加入了 MSN，作為 MSN 進中國第一個落地的本地化服務，我在其中擔任項目負責人的工作。2008年到2014年間我都在從事與飛信相關的工作，經(jīng)歷了飛信從一個非常小的業(yè)務成長為數(shù)億級規(guī)模的水平。2014年后隨著云服務的興起，我與團隊創(chuàng)立了融云，將即時通訊與云服務結合提供給開發(fā)者，讓開發(fā)者可以通過調(diào)用 SDK 使用 IM 服務。
本次演講將分為設計概述、媒體服務、能力服務、服務集群和服務網(wǎng)絡五個部分展開。
1. 設計理念
融云是一家互聯(lián)網(wǎng)通信云服務商，眾所周知，要想做基本的音視頻服務，首先你需要具備信令服務、能力服務和媒體服務這三種能力，這些能力都基于 WebRTC 技術，但 WebRTC 本身的定義是 P2P 的通訊，它本身并沒有服務部分，在服務部分有很多開源的實現(xiàn)解決方案。其次 WebRTC 也沒有定義信令服務的部分，很多廠家都是通過自己開發(fā)或采用第三方信令的方式來解決這個問題。信令其實就是一個長鏈接的通信通道，它與 IM 即時通訊其實是一樣的，融云也有案例說明客戶可以采用融云的公有云即時通訊解決方案來滿足信令服務的需求。隨著基礎通信能力達到要求之后，又不斷引入新的需求，比如對音視頻內(nèi)容的審核、更大規(guī)模的使用WebRTC技術替代直播平臺的解決方案，這也就引入了類服務這樣新的功能。融云即時通訊業(yè)務的設計理念是各司其職、避免依賴，核心服務專注通信，能力服務專注業(yè)務，只要做到這一點，系統(tǒng)就可以實現(xiàn)部署簡單和運維方便，降低管理的成本。另外融云作為全球互聯(lián)網(wǎng)通信云服務提供商，在設計之初就不可避免要考慮全球互聯(lián)的問題，全球互聯(lián)的架構與私有架構的不同需要充分照顧到。
2. 媒體服務
2.1 媒體服務基礎能力
首先從三大能力中的媒體服務能力談起，融云團隊一般都稱之為"三無服務"，"三無"是指一個媒體服務對其他的服務沒有依賴，其他的服務對這個媒體服務自身也沒有依賴，并且每個服務沒有任何中心化的配置。根據(jù)工作中的經(jīng)驗，無論是在公有云、私有云還是混合云環(huán)境中，會面臨要部署的環(huán)境和客戶端的環(huán)境都非常復雜的情況，比如用戶會在防火墻后或者服務器本身就在防火墻里面，遇到這些情況，融云采用端口收斂的方式進行通信的策略控制，這都是需要在設計之初就做到的事情。
另外融云還實現(xiàn)了兩個實時通信場景，第一個場景是絕大多基礎音視頻廠商都能做到的二人 P2P 會話，第二個場景是多人視頻會議，在這個場景中人數(shù)一般會在十人以上。隨著業(yè)務的發(fā)展，大家都能感覺到一個技術趨勢：用 WebRTC 的方式做直播，傳統(tǒng)的直播是將客戶端的流在服務端處理之后推給 CDN，最后由 CDN 進行分發(fā)，這樣做的好處是利用 CDN 的基礎架構可以實現(xiàn)大規(guī)模用戶在一個房間收看直播，這是 CDN 技術特點所帶來的優(yōu)勢，但同時 CDN 也存在著一些問題，比如首屏開屏的速度過慢，當然目前針對這個問題也有著各式各樣的解決方案。有些客戶在這基礎上就會提出能否使用 WebRTC 來實現(xiàn)直播場景，業(yè)內(nèi)也稱這種方案為低延遲直播，由于延遲比較低，在直播中的互動也會更加友好。
2.2 信令服務與媒體服務
關于信令服務和媒體服務的關系，絕大多數(shù)的廠商信令服務和媒體服務都是在一起的，融云的設計理念強調(diào)要解耦，使得部署和維護都更簡單，因此信令服務和媒體服務之間也需要解耦和無依賴，信令服務與媒體服務之間原本存在的狀態(tài)同步也要解開，而且融云本身就有特別健壯的信令服務，因此可以復用融云的 IM 通道，融云本身在這方面的投入也相當大。
上圖是信令服務與媒體服務的簡單架構，每一個媒體服務都與信令服務相關，相關性的目的是讓彼此清楚各自的狀態(tài)，這個設計模式的特點是客戶端與信令服務通信，通信結束之后可以與媒體服務通信，而媒體服務之間的對接不受影響。
2.3 實時通信發(fā)布/訂閱過程解析
上圖是為了實現(xiàn)解耦引入的實時通信發(fā)布/訂閱的模型，當 Client A 要與 Client B 進行會話時，第一步是進行發(fā)布，首先用 Client 調(diào)用 IM Server，提交加入房間/通話申請，調(diào)用信令服務的目的是拿 Token 返回，Token 中包括之后整個訂閱/發(fā)布功能所需要的關鍵數(shù)據(jù)，拿到這些 Token 之后去調(diào)用相關媒體服務的地址，傳統(tǒng)的設計通常是找信令服務，在分析 IP 地址庫之后指到媒體服務，由于我們需要做到解耦，因此在 Token 調(diào)用媒體服務后會給出一個返回值，返回值是 IP 地址和 Domain。返回 Client 之后就可以拿到 IP 的信息，連到媒體服務開始與 Client B 通信，通信的過程完全是依靠長鏈接的信令服務通道來進行的，Client A 將它得到的 Domain 信息發(fā)送給 Client B，此時發(fā)送階段工作結束。發(fā)送階段結束之后由 Client B 來執(zhí)行訂閱工作，Client B 會找到離它比較近的信令服務，調(diào)用媒體服務接口連到 Client A 連接的媒體服務，這就是完整的發(fā)布/訂閱模式。
2.4 媒體服務對客戶端接口設計
對于媒體服務對客戶端接口的設計，只需要提供發(fā)布/取消發(fā)布流、SFU 訂閱/取消訂閱和 MCU 訂閱/取消訂閱的接口，就可以完成解耦過程，整個通信的過程也可以建立起來。
3. 能力服務
3.1 能力服務分類
本身正常的一對一、多對多通信完全可以通過媒體服務就可以實現(xiàn)，融云最初上線的版本也是基于媒體服務去實現(xiàn)通信需求。后續(xù)客戶和業(yè)務產(chǎn)生了新的需求，比如在 AB 通訊時需要錄像、對音視頻的審核以及 WebRTC 實現(xiàn)低延遲直播等，融云將這些需求統(tǒng)稱為能力服務。
3.2 能力服務設計原則
能力服務一樣也有設計原則，首先，需要與媒體服務或信令服務解耦、無依賴;第二，無中央配置，無需通過配置來控制能力服務的功能和邏輯，而是通過接口和調(diào)用關系來控制;第三，結構簡單，能夠?qū)崿F(xiàn)低成本運維;第四，能力服務可利用現(xiàn)有的網(wǎng)絡能力。
3.3 媒體服務對接能力服務過程
通過上圖來解釋媒體服務對接能力服務過程中的邏輯，與發(fā)布/訂閱模塊相同，都是用 Client 調(diào)用 IM Server，調(diào)用信令服務拿 Token 返回，Token 可以直接生成一個 Hash 值，可以將 Token 理解為一個字符串，將想要的數(shù)據(jù)通過加密算法封到 Token字符串里，比如"host@clusterld"，"config"，Token 返回 Client 之后還是尋找媒體服務，在連接另外一個媒體服務做通信時接入能力服務，由發(fā)起方提供能力服務的內(nèi)容。
3.4 媒體服務對能力服務接口設計
媒體服務對能力服務接口設計分為申請推流/接受推流申請和推出推流/接受推流推出兩種。
4. 服務集群
4.1 服務集群設計原則
關于服務集群的設計理念，首先還是貫穿始終的結構簡單、易于維護，其次是可低成本構建集群以及可快速的擴縮容。
4.2 媒體服務集群框架
整個媒體服務集群的架構如上圖所示，其中每臺媒體服務器應該有自己獨立向外暴露的 IP 地址，用于進行 RTC 相關的通訊。媒體服務現(xiàn)在有兩個角色，一個是用于 RTC 相關的通訊，另外每個媒體服務器現(xiàn)在有自己 HTTP 的接口，用負載均衡和反向代理來控制這些 HTTP 接口的調(diào)用，通過反向代理實現(xiàn)規(guī)則調(diào)度。
4.3 服務集群實現(xiàn)
媒體服務集群還實現(xiàn)了實時通信單中心間媒體服務零調(diào)用，直播模式單中心理論上支持無限擴容以及通過代理層的控制實現(xiàn)無業(yè)務中斷的更新。
4.4 MCU 能力服務集群
MCU 能力服務集群與媒體服務集群邏輯相同。
4.5 集群概況
在沒有能力服務的情況下，上半部分就是融云標準的數(shù)據(jù)中心模型，引入能力服務后，需要復用媒體服務集群現(xiàn)有的基礎設施，所有的能力服務就會與媒體服務部署在一起，但實際上由于架構實現(xiàn)解耦，比較靈活，并不需要物理上部署在一起。
5. 服務網(wǎng)絡
5.1 全球網(wǎng)絡設計原則
融云在做 IM 的時候?qū)τ谌蚓W(wǎng)絡設計有非常豐富的經(jīng)驗，通過多年來在全球覆蓋地區(qū) IM 網(wǎng)絡和基礎數(shù)據(jù)的收集，基本可以了解全球各個地區(qū)的實時網(wǎng)絡變化情況。在這過程中團隊總結出任何物理的優(yōu)化都不是特別穩(wěn)定，因此全球網(wǎng)絡的設計理念就包括客戶端就近接入，多鏈路選擇，數(shù)據(jù)中心間同源音視頻只有一路級聯(lián)，利用IaaS能力進行中心間級聯(lián)鏈路的優(yōu)化。
5.2 跨國級聯(lián)示意圖
跨國級聯(lián)示意
5.3 全球網(wǎng)絡的工作
另外，融云在全球網(wǎng)絡中還做了一些工作，比如 DoH 剛在2018年9月變成RFC 的標準，主要解決 DNS 中間人劫持問題，根據(jù)融云這么多年業(yè)務開發(fā)經(jīng)驗來看，很多連接問題最終發(fā)現(xiàn)都是由 DNS 劫持導致的。另外在引入 SmartDNS 時會遇到 LocalDNS 緩存不準的問題，這些都會導致最終分配的就近地址不是真正的就近地址。融云目前的工作模式是將三者結合起來使用，在引入 SmartDNS 技術的同時引入 BGP Anycast 運營商技術來解決最近地址問題，通過這三層技術最大化來保證找到用戶的最近地址。另外可以在某些特殊情況下采用公網(wǎng)鏈路來做數(shù)據(jù)中心之間的級聯(lián)通信，絕大多數(shù)廠商礙于成本的考慮也采取了這樣的方法，但公網(wǎng)存在某些特殊情況不穩(wěn)定的問題，因此需要有一些備用鏈路，甚至在一些特殊的國家地區(qū)做物理鏈路優(yōu)化，融云 IM 在全球的基礎網(wǎng)絡設施投入很大成本，也收獲了很可觀的成績。
6. 未來工作計劃
關于融云目前正在開展的工作計劃，隨著業(yè)務的不斷增加，按照現(xiàn)有的架構其實可以引入更多基于場景的能力服務，只要遵循架構模型就可以不斷地引入新的模型。另外在融云的架構模式下天生支持混合云模式，由于各個服務間都是解耦的，任何私有環(huán)境下的服務都可以直接利用已經(jīng)存在的公有媒體服務架構之上，對于公有媒體服務來說，只要遵循相同的發(fā)布/訂閱模型就可以直接使用。
關于融云
融云，安全、可靠的全球互聯(lián)網(wǎng)通信云服務商，向開發(fā)者和企業(yè)提供即時通訊和實時音視頻通信云服務。iResearch 艾瑞權威數(shù)據(jù)報告顯示，融云即時通訊云市場份額連續(xù)多年穩(wěn)居首位。
11月30日，融云將在上海舉辦2019全球互聯(lián)網(wǎng)通信云大會(WICC 2019)，這是全球范圍內(nèi)首個圍繞互聯(lián)網(wǎng)通信云技術開展研討的行業(yè)技術會議。目前，大會免費報名通道限時開啟中，開發(fā)者們可通過大會官網(wǎng)(wicc.rongcloud.cn)申請限時免費門票，參與WICC 2019大會期間含主會場與技術分論壇所有場次的內(nèi)容分享。
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
