分布式無級聯的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的使命。