去中心化的 RTC 通信平台架构设计
?
去中心化的RTC網絡無需關心其它媒體服務狀態，可快速增加地域媒體服務節點部署，與信令服務無耦合。本文來自融云聯合創始人，CTO楊攀在LiveVideoStackCon 2019上海的演講內容，由LiveVideoStack整理而成。在8月23-24日的LiveVideoStackCon2019北京大會上，楊攀還將分享《可擴展的公有云媒體服務設計解析》。
文 / 楊攀
整理 / LiveVideoStack
大家好，我叫楊攀，從開始工作至今有17年了，一直在從事電信、通信、社交以及開放平臺領域相關的工作。大約在2004年左右，MSN剛開始進入中國并落地，當時我們的團隊在上海將一些MSN的美國業務在本地做了電信運營商的落地。后續，我也參與到了整個飛信團隊的建設之中，目前融云的研發團隊就是之前中國移動飛信的核心研發團隊，整個團隊從研發到產品再到運營在一起工作了大約12年之久。
一、背景介紹
?
融云做的是通信云服務，可以說是基于IP的虛擬通信運營商，我們希望未來所有在Internet上的IP流量，包括消息、語音片段、視頻片段、紅包、表情、音頻通話和視頻通話等等，所有的這些通信都能承載在我們自己建設的全球通信網上，而這同樣也是我們的使命。因此，目前我們在全球大規模地鋪設了自己的網絡，包括在北京、新加坡和北美建設的三個大數據中心，在全球有數百個接入節點和數千個加速節點。
本次要與大家分享的主要內容就是在架構尺度上的部分技術經驗與積累。
二、分布式無級聯的RTC架構
?
首先，為大家介紹分布式無級聯的RTC架構。對于RTC的架構，在WebRTC中的定義是一個Peer到Peer的通信。其中并沒有直接給出一個明確的標準來告訴你如何去做信令服務、媒體服務等。那么，一個最簡單的分布式媒體服務是什么樣的呢？
?
一般的基本模式是，A用戶和B用戶首先通過一個信令服務，信令服務為A和B分別分配媒體服務，然后幫助它們之間建立一個聯系。對于這種簡單分布式但并不支持級聯的RTC架構，它的優點是每一個媒體服務本身都不需要和其它的媒體服務建立連接，并且不會進行網絡優化。但是，它最大的問題就是當我們給A客戶端分配一個媒體服務后，B客戶端也是需要連接同一媒體服務的。假如我們先給A客戶端就近分配一個媒體服務，此時A客戶端和媒體服務之間連接的質量是非常好的，但是如果A客戶端和B客戶端不在同一地區，B客戶端也許距離這個媒體服務非常遠，中間的網絡就可能會非常不穩定，此時A客戶端和B客戶端通過這個媒體服務建立的通信就是存在問題的。因此，這種模式只適用小規模范圍的通信，如城域或者是公司內部的私網。
?
下面，將介紹有級聯的RTC架構是如何實現的。
?
三、分布式有級聯的RTC架構
?
有級聯的RTC架構則要求A客戶端和B客戶端分別找到不同的媒體服務來進行通信，媒體服務之間也要做級聯的通信，這樣就能解決上述無級聯RTC架構存在的問題。如上圖所示，我們可以先為左邊的Client找到一個對它來講質量最好的媒體服務，然后再為右邊的Client找到一個質量最好的媒體服務，兩個媒體服務之間還要再通過一些網絡優化的手段來保證它們的通信質量。上圖系統中的藍色部分叫做Signal Server，Client可以通過Signal Server和Media Server進行SDP交換。
分布式有級聯的RTC架構可以實現鏈路的優化，但同時我們也不難發現，Signal Server和Media Server之間存在的耦合問題。這是因為所有的Media Server都需要在Signal Server中進行注冊登記以進行管理，并且Signal Server還要和Media Server之間保持一個健康狀態的檢查，比如做一個TCP的長連接、做一個心跳包。此外，Signal Server不僅需要知道Media Server里有哪些用戶正在使用流媒體通信，還需要知道它的用戶狀態。一方面，對于緊的耦合，當部署一個新的媒體服務時，就會需要很復雜的工程實施，因為在很多地方均要Update配置。另一方面，如果在通話過程中發現媒體服務或者信令服務之間存在一些異常狀態，則會導致整個通話斷掉，因為他們兩個之間的耦合非常緊密。到目前為止，大家能夠在市面上看到的開源解決方案基本上都是按這個模式去設計的。在電信運營商領域，Signal Server最典型的就是用SIP協議來實現的，包括我們之前做飛信也是用的一個SIP的簡化協議SIPC。還有一種方案就是，可以搭一個XMPP的服務器，用它來實現Presence管理，所謂的Presence管理與SIP一樣，就是用一條IM通道來做Signal Server。
?
在這一部分，我們分析了分布式有級聯RTC架構的優點和缺點。接下來，我們一起來看看融云對分布式RTC網絡的思考。
?
四、融云對分布式RTC網絡的思考
?
如上所述，由于信令服務器和媒體服務是有耦合的，我們上線或下線任何一個媒體服務器均要在Signal Server里Update相關狀態和配置。因此，我們的第一個訴求就是要設計一種將信令服務和媒體服務解耦開來的架構；第二個訴求就是要使得我們的信令服務和媒體服務之間能不管對方的狀態如何，讓它們不需要狀態同步；第三個訴求就是讓每一個媒體中心都是獨立的；第四個訴求就是要降低新建與維護媒體中心的成本，因為通信云服務有數以千計或萬計的機器和節點要管理；最后一個訴求就是要全面復用融云即時通訊通道。
?
上圖是融云的分布式RTC網絡架構，我們將Signal Server換成了融云的IM基礎設施。簡單來說，IM是用來發消息的，它實際上就是把一段數據通過一個長連接的、永遠在線的通道從一端推送到另外一端，而且該服務要保證這條通道永遠是可用的，同時發的每一個信令、指令都不能丟失，并且要以最快的速度到達。總的來說，這就是Signal Server的使命。
接下來，我將為大家詳細講解融云的RTC建連過程。
?
如上圖所示包含有五個角色，分別是Client A、Client A對應的Media Server、IM Server、Client B對應的Media Server、Client B。Client A是通信的發起方，IM Server就是我們的Signal Server。在這個架構里面，我們引入Pub/Sub模型來實現解耦，下面將分兩部分講解。
?
Pub過程：Client A會利用Smart DNS直接找到自己對應的Media Server，然后調用該Media Server上開放的一個HTTP接口，調用該接口是為了傳遞傳Token、Room ID/Channel ID，以及交換SDP，這個在后面會詳細解釋。調用完之后，Media Server會返回該Media Server的IP地址和Client A在Media Server上注冊后所分配的Resource ID，Resource ID是Client A在Media Server上唯一的身份標識。Client A接收到Media Server返回的信息后就可以直接與Media Server建立RTC連接，接著就可以開始利用信令通道了。之后IM Server要將Client A呼叫Client B的指令Push給Client B，并且會將Media Server返回給Client A的信息直接Send給Client B。此時，Pub過程就完成了。
?
Sub過程：與前面相同，Client B也要通過Smart DNS找到一個相對來說質量最好的Media Server，然后調用其另外一個接口將剛才傳過來的信息告訴這個Media Server。當Client B對應的Media Server拿到了Client A對應的Media Server的信息后，由Resource ID就可以知道要將Client A和Client B之間建立連接，在內部建立關聯后返回一個ACK，說明已經調用成功。一旦Client A和Client B建立RTC連接成功后，Client A對應的Media Server和Client B對應的Media Server就建立起了級聯。
?
當RTC的通道連接建立成功后，去中心化完成，此時我們就完成了Media Server和Signal Server之間的解耦。
?
總結一下，融云的RTC建連過程采用了極簡的接口設計。如上述的時序圖，有幾次HTTP調用實際上全都是通過一個HTTP接口來實現的，而這一個HTTP接口通過傳遞不同的參數就非常簡單的實現了發布/取消發布流，SFU和MCU的訂閱/取消訂閱。
下面將詳細講解一下在前面提到的Media Server。
?
對于Media Server，我們可以將其理解為在一臺物理硬件的服務器上面部署了一套服務。但事實上，對于大規模的云廠商來講，一般是在某一個地方建立一個數據中心，在里面會投入很多的機器來運轉。一個媒體服務中心的架構設計往往非常簡單，對于左邊的HTTP請求要做Load Balance，然后把它分布在其他各種平臺的Media Server上，并且在中間還加了一個反向代理。在數據中心里雖然有很多的媒體服務，但如果我們不做任何策略的話，就可能會出現以下情況：當三個人在一個房間聊天時，可能會被分配到了兩臺Media Server上，即在數據中心內還需要Media Server之間的通信，這樣是十分影響性能和質量的。那么，我們該如何解決這個問題呢？如前所述，調用接口時要傳Token、Room ID/Channel ID、SDP。因此，我們可以通過算法將Room ID相同的用戶歸并到同一臺Media Server上，只要這個房間內的訂閱人數沒有超過該Media Server的物理上限，則可以保證該房間里用戶全在一個Media Server上進行通信，此時的性能是非常好的。除了上述情況外，還有另外一個問題，例如當前進行會議的房間的人數特別多，而且用戶數超過了Media Server所能承載的業務量。對于這種情況，我們就需要進行打散，也就是將用戶分散在不同的Media Server上。
?
接下來，總結一下我們在媒體服務方面除了上述內容之外還做了哪些事情。在進行HTTP接口調用時，HTTP接口支持QUIC，可減少交互握手的次數來優化性能。另外，我們還做了媒體服務的端口收斂以及盡可能的去實現單中心間媒體服務的0調用。
?
接下來，針對前面提出的問題來總結一下結果：1）我們按照新設計的架構模型實現了信令服務和媒體服務的解耦，當上線一個新的媒體服務時，無需在信令服務里添加任何注冊配置，唯一要做的就是在Smart DNS里為這個媒體服務增加一條記錄；2）信令和媒體服務之間不存在任何調用關系，所以也就不存在任何數據和狀態的同步；3）媒體中心間也不需要狀態同步；4）我門已經把媒體服務管理和添加的成本降到非常低的水平；5）直接復用融云的通訊通道，在融云RTC的SDK里面已經內涵了一個精簡版的IM協議棧。
下面將介紹一下融云的RTC全球網絡。
?
五、融云RTC全球網絡
?
融云是一家覆蓋全球的云通信服務商，目前已經建立了全球的通信網絡，遍布中國、東南亞、中東等地。只要客戶需要，我們的工程團隊就可以去當地建設數據中心，將整個的通信網絡基礎設施鋪到那里。目前，我們已經將全新建設一個Media Server的成本降到非常低的程度，以至于只僅添加一條DNS記錄就可以搞定，這也是我們整個后端的研發團隊引以自豪的地方。
?
那么，我們在全球網絡上做了哪些工作呢？首先，我們引入了一個新的概念HTTPDNS，融云每天有幾千萬的活躍用戶，因此連接訪問的次數可能會是特別大數量級的。根據我們手里掌握數據的分析結果來看，DNS是影響連通率指標的罪魁禍首，尤其在國內復雜的網絡環境下。因此，需要引入HTTPDNS來進一步提高通信質量。其次，媒體中心間的物理鏈路優化。級聯的一種簡單方式就是物理連接，現在幾乎所有的廠商都會花錢進行物理鏈路的優化。此外，對于跨廠商或者在網絡比較復雜地區可能要建設一些物理服務器，那我們就要解決邏輯鏈路的優化，在這里面通常是采用一些轉發的策略，其中的基礎邏輯就是收集數據、實時分析數據然后做出決策去實現調度。
接下來，再補充介紹一些其它的技術點。
1）RTC鑒權
?
在最初的實時通信模型架構中，根據Room ID/Channel ID直接加入即可訂閱它的流，并且可以看到它里面的內容，這就導致了存在安全的隱患。那么如何解決這個問題呢？解決方法就是在前面所講到的模型中調HTTP接口時要傳一個Token。具體來講，當兩個客戶端建立連接時，在同步調用Signal Server的過程中會傳一個Token回來，Token是信令服務調用后臺的密鑰服務所分發的一個令牌。當拿著這個令牌去連Client對應的Media Server時，Media Server會Check令牌隱含的信息是否與要建立連接Client的Room ID/Channel ID相匹配。如果不匹配，則沒有權限查看里面的內容。驗證是否匹配的基本邏輯是上圖中的Key Server和Media Server共享一套密鑰算法和密鑰，它們都是部署在數據中心里的，里面的協議也都是我們內部來實現的。此外，在這里還有一個算法來驗證Token是否有二次的I/O請求和調用，這是一個常見的大規模高并發系統架構設計的基礎原理，即盡量在某些場合巧妙的通過一些算法和驗證減少I/O的請求和調用。
2）融云IM加速網絡
?
接下來，為大家介紹一下融云IM的加速網絡。從上圖中可以看出，我們的加速網絡模型是一個混合云，包含國內私有部署、國外私有部署，目前已經實現了國內外的互通。需要跟大家介紹的是，國內和國外的網絡之間訪問的質量是受到影響的，因此對于國內外的互通還需要進行一些專門的優化。這些優化說白了就是砸錢來解決問題，因此我們在國內有自己的加速節點，在國外也有自己的加速節點，并且還可以在國內外實現私有部署，包括把信令服務私有部署在用戶那里。舉例說明，目前我們有一個客戶是一家國內頂尖的IT企業，它的員工大概有十幾萬人，遍布在全球的各個城市和大區，他們希望通過我們幫助建立企業內部十幾萬人之間的IM與RTC溝通。由于全球各個地區網絡情況復雜，他們自己的團隊無法保證網絡質量的問題，對于鏈路情況復雜和距離較遠的情況也無法解決。最終，他們采用的是融云的解決方案，通過在北京的數據中心私有部署了一套IM的基礎設施服務，然后租用了融云的全球加速網絡，采用的就是經典的混合云模式。
3）融云RTC SDK
?
融云RTC SDK就是我們將所有東西解耦之后所得到的另一個副產品。實際上，音視頻通信云服務領域已經發展多年，在這個領域有一個很有意思的現象就是很多廠商把能力和功能耦合在一起。這就會導致如果我想做一個場景，那么就需要添加大量新的接口，而在大量新加的代碼里隱含著一個業務的場景和邏輯。前面講過，我們將RTC建連過程轉變成了Pub/Sub模型，使得系統變得極其簡單，如同幾塊樂高積木一樣。因此，無論我們想要引入何種邏輯，比如兩人通話、多人會議、千人的會議、小班課、直播連麥等等。這些場景都可以通過簡單的幾個模塊直接搭建出來，而我們要做的就是在上層將這一段業務場景或邏輯封裝成一個SDK，目前已有的SDK包括Call Kit、Call Lib等等，其中Kit指的就是UI Competent。舉例說明，微信音視頻電話的場景，我們的SDK包含了這個場景的UI組件和通信組件，用戶想要實現這個場景直接引用SDK即可，不用再做任何二次開發的工作。類似地，會議會控、直播的UI組件和通信組件等等都會封裝成SDK。并且，我們會隨著用戶的需求通過這些積木實現不同的業務場景。?
?
接下來總結一下融云RTC SDK的特點：1）我們真正做到了SDK組件自底向上地單向依賴，并且SDK組件沒有任何交叉調用；2）架構中間的可替換的信令層Signal Server與Media Server沒有任何關系，這意味著用戶可以使用我們的Media Server，使用自己的Signal Server，這個架構完全實現了解耦；3）所有場景都全部實現組件化，因為它們的底層就是用積木搭建出來。
?
六、未來計劃
?
最后，我們的架構設計未來計劃是可以將Media Server做成Dockerfile，放到網站上供大家下載。我們還可以支持混合云模式，實現RTC Media Server的眾包。眾包指的就是用戶可以找尋合適的網絡，通過自己的硬件部署一個Dockerfile、架設一個自己寫的Media Server，還可以成為融云全球加速通信網的節點中的一員。第二種模式就是用戶租用融云的全球通信網，但可以實現私有的信令部署。再有一種模式就是用戶可以按照模型自建媒體服務，然后自建私有的信令部署。
?
LiveVideoStack? 招募
LiveVideoStack正在招募編輯/記者/運營，與全球頂尖多媒體技術專家和LiveVideoStack年輕的伙伴一起，推動多媒體技術生態發展。同時，也歡迎你利用業余時間、遠程參與內容生產。了解崗位信息請在BOSS直聘上搜索“LiveVideoStack”，或通過微信“Tony_Bao_”與主編包研交流。
LiveVideoStackCon 2019北京 音視頻技術大會 初版日程現已上線，掃描圖中二維碼或點擊【閱讀原文】了解大會最新日程。
總結
以上是生活随笔為你收集整理的去中心化的 RTC 通信平台架构设计的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【大会】QoE也能驱动业务创新
- 下一篇： 【大会】海量高清视频服务端架构设计的变与