對于Media Server，我們可以將其理解為在一臺物理硬件的服務器上面部署了一套服務。但事實上，對于大規(guī)模的云廠商來講，一般是在某一個地方建立一個數(shù)據(jù)中心，在里面會投入很多的機器來運轉。一個媒體服務中心的架構設計往往非常簡單，對于左邊的HTTP請求要做Load Balance，然后把它分布在其他各種平臺的Media Server上，并且在中間還加了一個反向代理。

在數(shù)據(jù)中心里雖然有很多的媒體服務，但如果我們不做任何策略的話，就可能會出現(xiàn)以下情況：當三個人在一個房間聊天時，可能會被分配到了兩臺Media Server上，即在數(shù)據(jù)中心內還需要Media Server之間的通信，這樣是十分影響性能和質量的。那么，我們該如何解決這個問題呢？

如前所述，調用接口時要傳Token、Room ID/Channel ID、SDP。因此，我們可以通過算法將Room ID相同的用戶歸并到同一臺Media Server上，只要這個房間內的訂閱人數(shù)沒有超過該Media Server的物理上限，則可以保證該房間里用戶全在一個Media Server上進行通信，此時的性能是非常好的。除了上述情況外，還有另外一個問題，例如當前進行會議的房間的人數(shù)特別多，而且用戶數(shù)超過了Media Server所能承載的業(yè)務量。對于這種情況，我們就需要進行打散，也就是將用戶分散在不同的Media Server上。

接下來，總結一下我們在媒體服務方面除了上述內容之外還做了哪些事情。在進行HTTP接口調用時，HTTP接口支持QUIC，可減少交互握手的次數(shù)來優(yōu)化性能。另外，我們還做了媒體服務的端口收斂以及盡可能的去實現(xiàn)單中心間媒體服務的0調用。

接下來，針對前面提出的問題來總結一下結果：

1）我們按照新設計的架構模型實現(xiàn)了信令服務和媒體服務的解耦，當上線一個新的媒體服務時，無需在信令服務里添加任何注冊配置，唯一要做的就是在Smart DNS里為這個媒體服務增加一條記錄；

2）信令和媒體服務之間不存在任何調用關系，所以也就不存在任何數(shù)據(jù)和狀態(tài)的同步；

3）媒體中心間也不需要狀態(tài)同步；

4）我門已經把媒體服務管理和添加的成本降到非常低的水平；

5）直接復用融云的通訊通道，在融云RTC的SDK里面已經內涵了一個精簡版的IM協(xié)議棧。