【融雲分析】去中心化的RTC通訊服務平臺

編者按：去中心化的RTC網絡無需關心其它媒體服務狀態，可快速增長地域媒體服務節點部署，與信令服務無耦合。本文來自融雲聯合創始人，CTO楊攀在LiveVideoStackCon 2019上海的演講內容，由LiveVideoStack整理而成。

你們好，我叫楊攀，從開始工做至今有17年了，一直在從事電信、通訊、社交以及開放平臺領域相關的工做。大約在2004年左右，MSN剛開始進入中國並落地，當時咱們的團隊在上海將一些MSN的美國業務在本地作了電信運營商的落地。後續，我也參與到了整個飛信團隊的建設之中，目前融雲的研發團隊就是以前中國移動飛信的核心研發團隊，整個團隊從研發到產品再到運營在一塊兒工做了大約12年之久。

1、背景介紹

融雲作的是通訊雲服務，能夠說是基於IP的虛擬通訊運營商，咱們但願將來全部在Internet上的IP流量，包括消息、語音片斷、視頻片斷、紅包、表情、音頻通話和視頻通話等等，全部的這些通訊都能承載在咱們本身建設的全球通訊網上，而這一樣也是咱們的使命。所以，目前咱們在全球大規模地鋪設了本身的網絡，包括在北京、新加坡和北美建設的三個大數據中心，在全球有數百個接入節點和數千個加速節點。

本次要與你們分享的主要內容就是在架構尺度上的部分技術經驗與積累。

2、分佈式無級聯的RTC架構

首先，爲你們介紹分佈式無級聯的RTC架構。對於RTC的架構，在WebRTC中的定義是一個Peer到Peer的通訊。其中並無直接給出一個明確的標準來告訴你如何去作信令服務、媒體服務等。那麼，一個最簡單的分佈式媒體服務是什麼樣的呢？

通常的基本模式是，A用戶和B用戶首先經過一個信令服務，信令服務爲A和B分別分配媒體服務，而後幫助它們之間創建一個聯繫。對於這種簡單分佈式但並不支持級聯的RTC架構，它的優勢是每個媒體服務自己都不須要和其它的媒體服務創建鏈接，而且不會進行網絡優化。可是，它最大的問題就是當咱們給A客戶端分配一個媒體服務後，B客戶端也是須要鏈接同一媒體服務的。假如咱們先給A客戶端就近分配一個媒體服務，此時A客戶端和媒體服務之間鏈接的質量是很是好的，可是若是A客戶端和B客戶端不在同一地區，B客戶端也許距離這個媒體服務很是遠，中間的網絡就可能會很是不穩定，此時A客戶端和B客戶端經過這個媒體服務創建的通訊就是存在問題的。所以，這種模式只適用小規模範圍的通訊，如城域或者是公司內部的私網。

下面，將介紹有級聯的RTC架構是如何實現的。

3、分佈式有級聯的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網絡的思考。

4、融雲對分佈式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全球網絡。

5、融雲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）全部場景都所有實現組件化，由於它們的底層就是用積木搭建出來。

6、將來計劃

最後，咱們的架構設計將來計劃是能夠將Media Server作成Dockerfile，放到網站上供你們下載。咱們還能夠支持混合雲模式，實現RTC Media Server的衆包。衆包指的就是用戶能夠找尋合適的網絡，經過本身的硬件部署一個Dockerfile、架設一個本身寫的Media Server，還能夠成爲融雲全球加速通訊網的節點中的一員。第二種模式就是用戶租用融雲的全球通訊網，但能夠實現私有的信令部署。再有一種模式就是用戶能夠按照模型自建媒體服務，而後自建私有的信令部署。

融雲IM商用版年中大促火爆進行中

從 7 月 1 日——8 月 31 日，融雲年中大促正在火熱進行中，IM 商用版預存最低享 7 折，更多詳情能夠點擊登陸融雲官網活動頁面查看。