對于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協議棧。