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

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

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

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

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

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

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

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

4）我門已經(jīng)把媒體服務(wù)管理和添加的成本降到非常低的水平；

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