轉載請註明出處：https://blog.csdn.net/impingo
項目官網：https://pingos.io
項目地址：https://github.com/im-pingo/pingos
誤區？究竟什麼是信令，什麼是事件
雖然本人做流媒體研發有些年頭了，但是以往所用的流媒體協議都是rtmp、hls、http-flv、http-fmp4等等比較“單純”的流媒體協議。在接觸WebRTC協議的初期，甚至看到網上一些架構方案的時候都習慣把信令和媒體混在一起，不管是邏輯上或是物理部署上。就像下圖：
在這張圖上offer、answer等等這類用來傳輸媒體參數的消息和“流通知”、“用戶上線通知”、“呼叫通知”等等消息並列都由所謂的“信令服務器”分發，並且在協議的設計上也是同一類型的消息（最初我也是這麼做的）。
與此同時“信令服務器”還要負責維護進出房間的邏輯，負責選擇後臺媒體服務器（類似選點），如果考慮跨節點回源的情況，問題會更復雜。
但是我個人認爲這種將所有業務都砸在信令服務器的思路是極其錯誤的。
思考一：怎樣劃分消息類別
列舉幾個常見的消息
| 媒體信令（signal） | 事件消息（event） |
|---|---|
| offer/answer | 新用戶加入/退出 |
| candidate/ready | 新流發佈/取消 |
| pause/stop | 退出房間 |
第一種消息類型是媒體信令消息（我們姑且叫它們 signal），這種消息傳遞的是與媒體參數有關的內容，在webrtc裏如offer/answer/candidate/ready等等，它們是WebRTC協議的一部分，就如同rtmp協議中的handshake/connection/play等，再如rtsp協議中的setup、play等信令一樣是與媒體流不可拆分的整體。
第二種消息類型是事件消息（我們姑且叫它們 event），這種消息傳遞的是與媒體無關的內容，如“上下線”、“流發佈成功”、“流移除”等等，這些消息並不是webrtc建連所必須的，而是客戶端之間發佈和訂閱的消息，它們和webrtc毫無關係。
那麼爲什麼還是在很多新人的方案或者認知裏總是把它們放在一起？我覺得是因爲rtmp、hls等協議有比較完善的標準，它們的握手、控制等信令都是和媒體傳輸嚴格綁定的。另外它們都是單TCP鏈接，信令和媒體在連接上是無法分開的。而webrtc則不同，控制信令部分沒有標準，就連信令連接都是和媒體連接獨立的，這就造成了一種錯覺，“既然webrtc signal是長連接，event也是長連接，那麼他們應該就是同樣的東西，放在一起實現有何不可？”這樣的思想容易讓人把signal和event放在一起實現，從而導致信令服務器的角色定位混亂。其實webrtc這樣的協議並不特殊，完全可以把它看做一個另類的rtsp協議，同樣是信令和媒體數據分開傳輸，爲什麼大家不會把rtsp的信令和上下線業務混在一起？原因就像上面說到的，因爲rtsp協議完善並且有成熟的庫可調用，在rtsp庫的調用者看來它和rtmp一樣不能拆分。然而到了webrtc協議，大家的思路就開始發散了，signal和event完全混在了一起。
綜上這兩種消息應該要嚴格區分的，不管是邏輯上的耦合還是代碼上的耦合亦或是物理上服務實例的部署耦合都是原罪。
說得更極端一點：這兩種消息最好連監聽同一個端口這種事情都不要做，因爲它們真的天上地下，毫無關係。（這裏並不是完全反對使用同一個端口，只是爲了表達一下它們毫無關係的程度。）
思考二：怎樣理解信令服務器
信令是媒體服務器必不可少的一部分，但它不是IM服務器，它沒有分發消息的責任，應該與IM服務器嚴格區分。
上文圖中的信令服務器至少具有：WebRTC信令能力、IM能力（event轉發/文字消息轉發）、服務器調度能力。
但是我們已經對消息進行了分類，既然職責不同，爲何還要在一起？我認爲應該將信令服務器的能力拆分，原來所認爲的信令服務器應該對應拆分爲：信令服務器、IM服務器、調度服務器三種。
由於不管是從WebRTC協議上看還是業務控制上看信令服務都是媒體服務器的一部分，不可獨立。我建議讓信令服務器和媒體服務器綁定，就像rtsp服務器一樣，信令和媒體組合爲一個整體。這時候就沒有獨立的信令服務器了，因爲它已經被包含在了媒體服務器的實例中。
從現在開始“信令服務器”就消失了，它已經成爲WebRTC媒體服務器不可拆分的一部分。下文中提到“媒體服務器”是已經集成了“信令服務器”的。
拆分後的結構是什麼樣子的？
此時的流程爲：
- IM系統負責即時消息和事件轉發。
- 客戶端需要推拉流時由IM系統向調度服務集羣請求流媒體服務器地址。
- 客戶端向媒體服務器建立信令連接和推拉流操作。
- 媒體服務器將流狀態通知給調度系統，由調度服務判斷是否需要轉碼或存儲，如果需要轉碼或者存儲則通知轉碼或錄製服務拉取媒體流。
- 媒體服務器之間的回源地址由調度服務器提供，媒體服務器向調度服務器請求回源地址進行回源。
從上圖可以看出此時的“調度服務”、“媒體服務”、“IM服務”已經極大地解耦，各自的系統可以相對獨立地開發維護或升級。
下面聊聊設計原則
- 媒體服務：媒體服務器集成媒體信令功能，客戶端推拉流功能，服務器間推拉流功能，流狀態通知功能。此時的媒體服務已經成爲了一個與業務完全脫離的角色，它僅僅是受調度服務擺佈的提供流轉發功能的木偶而已。
- IM服務：負責同步同一個房間內的所有人的信息、狀態、事件等等，IM服務器已經與媒體服務完全脫離，它僅僅需要關心同一個房間內的客戶端消息是否能夠在房間內廣播，當客戶端需要推拉流的時候IM服務器從調度服務那裏獲取一下媒體服務器的地址，然後返回給客戶端就好，剩下的事就與IM服務器無關了。
- 調度服務：負責記錄流發佈的信息，並且提供服務器調度查詢，是否轉碼等相關業務的判斷和觸發功能。
QQ交流羣：697773082
QQ交流羣：697773082