可扩展的公有云媒体服务设计解析
生活随笔
收集整理的這篇文章主要介紹了
可扩展的公有云媒体服务设计解析
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
作為互聯網通信云服務商，除了滿足最基本的音視頻數據實時傳輸需求外，還會需要提供很多個性化的云端服務。本文來自融云的聯合創始人兼CTO 楊攀在 LiveVideoStackCon2019 北京站上的精彩分享，結合融云去中心化的媒體服務架構，解析如何構建靈活的、可擴展的音視頻通訊云服務。文 / 楊攀整理 / LiveVideoStack
大家好，我是融云的聯合創始人兼CTO 楊攀，本次我分享的主題是融云在公有云媒體服務設計的理念和思路。我是從2002年參加工作，至今已經十七年，其中有十五年的時間都是在做關于IM 的工作。2004年時我加入了 MSN，作為 MSN 進中國第一個落地的本地化服務，我在其中擔任項目負責人的工作。2008年到2014年間我都在從事與飛信相關的工作，經歷了飛信從一個非常小的業務成長為數億級規模的水平。2014年后隨著云服務的興起，我與團隊創立了融云，將即時通訊與云服務結合提供給開發者，讓開發者可以通過調用 SDK 使用 IM 服務。本次演講將分為設計概述、媒體服務、能力服務、服務集群和服務網絡五個部分展開。1. 設計理念融云是一家互聯網通信云服務商，眾所周知，要想做基本的音視頻服務，首先你需要具備信令服務、能力服務和媒體服務這三種能力，這些能力都基于WebRTC 技術，但 WebRTC 本身的定義是 Ｐ2Ｐ 的通訊，它本身并沒有服務部分，在服務部分有很多開源的實現解決方案。其次 WebRTC也沒有定義信令服務的部分，很多廠家都是通過自己開發或采用第三方信令的方式來解決這個問題。信令其實就是一個長鏈接的通信通道，它與 IM 即時通訊其實是一樣的，融云也有案例說明客戶可以采用融云的公有云即時通訊解決方案來滿足信令服務的需求。隨著基礎通信能力達到要求之后，又不斷引入新的需求，比如對音視頻內容的審核、更大規模的使用WebRTC技術替代直播平臺的解決方案，這也就引入了類服務這樣新的功能。融云即時通訊業務的設計理念是各司其職、避免依賴，核心服務專注通信，能力服務專注業務，只要做到這一點，系統就可以實現部署簡單和運維方便，降低管理的成本。另外融云作為全球互聯網通信云服務提供商，在設計之初就不可避免要考慮全球互聯的問題，全球互聯的架構與私有架構的不同需要充分照顧到。2. 媒體服務2.1 媒體服務基礎能力首先從三大能力中的媒體服務能力談起，融云團隊一般都稱之為“三無服務”，“三無”是指一個媒體服務對其他的服務沒有依賴，其他的服務對這個媒體服務自身也沒有依賴，并且每個服務沒有任何中心化的配置。根據工作中的經驗，無論是在公有云、私有云還是混合云環境中，會面臨要部署的環境和客戶端的環境都非常復雜的情況，比如用戶會在防火墻后或者服務器本身就在防火墻里面，遇到這些情況，融云采用端口收斂的方式進行通信的策略控制，這都是需要在設計之初就做到的事情。另外融云還實現了兩個實時通信場景，第一個場景是絕大多基礎音視頻廠商都能做到的二人Ｐ2Ｐ 會話，第二個場景是多人視頻會議，在這個場景中人數一般會在十人以上。隨著業務的發展，大家都能感覺到一個技術趨勢：用WebRTC 的方式做直播，傳統的直播是將客戶端的流在服務端處理之后推給 CDN，最后由CDN 進行分發，這樣做的好處是利用 CDN 的基礎架構可以實現大規模用戶在一個房間收看直播，這是CDN 技術特點所帶來的優勢，但同時 CDN 也存在著一些問題，比如首屏開屏的速度過慢，當然目前針對這個問題也有著各式各樣的解決方案。有些客戶在這基礎上就會提出能否使用WebRTC 來實現直播場景，業內也稱這種方案為低延遲直播，由于延遲比較低，在直播中的互動也會更加友好。2.2 信令服務與媒體服務關于信令服務和媒體服務的關系，絕大多數的廠商信令服務和媒體服務都是在一起的，融云的設計理念強調要解耦，使得部署和維護都更簡單，因此信令服務和媒體服務之間也需要解耦和無依賴，信令服務與媒體服務之間原本存在的狀態同步也要解開，而且融云本身就有特別健壯的信令服務，因此可以復用融云的IM 通道，融云本身在這方面的投入也相當大。上圖是信令服務與媒體服務的簡單架構，每一個媒體服務都與信令服務相關，相關性的目的是讓彼此清楚各自的狀態，這個設計模式的特點是客戶端與信令服務通信，通信結束之后可以與媒體服務通信，而媒體服務之間的對接不受影響。2.3 實時通信發布/訂閱過程解析上圖是為了實現解耦引入的實時通信發布/訂閱的模型，當 Client A 要與 Client B 進行會話時，第一步是進行發布，首先用 Client 調用IM Server，提交加入房間/通話申請，調用信令服務的目的是拿Token 返回，Token 中包括之后整個訂閱/發布功能所需要的關鍵數據，拿到這些 Token 之后去調用相關媒體服務的地址，傳統的設計通常是找信令服務，在分析IP 地址庫之后指到媒體服務，由于我們需要做到解耦，因此在 Token 調用媒體服務后會給出一個返回值，返回值是IP 地址和 Domain。返回 Client 之后就可以拿到 IP 的信息，連到媒體服務開始與 Client B 通信，通信的過程完全是依靠長鏈接的信令服務通道來進行的，Client A將它得到的 Domain 信息發送給 Client B，此時發送階段工作結束。發送階段結束之后由Client B 來執行訂閱工作，Client B 會找到離它比較近的信令服務，調用媒體服務接口連到Client A 連接的媒體服務，這就是完整的發布/訂閱模式。2.4 媒體服務對客戶端接口設計對于媒體服務對客戶端接口的設計，只需要提供發布/取消發布流、SFU 訂閱/取消訂閱和MCU 訂閱/取消訂閱的接口，就可以完成解耦過程，整個通信的過程也可以建立起來。3. 能力服務3.1 能力服務分類本身正常的一對一、多對多通信完全可以通過媒體服務就可以實現，融云最初上線的版本也是基于媒體服務去實現通信需求。后續客戶和業務產生了新的需求，比如在AB 通訊時需要錄像、對音視頻的審核以及 WebRTC 實現低延遲直播等，融云將這些需求統稱為能力服務。3.2 能力服務設計原則能力服務一樣也有設計原則，首先，需要與媒體服務或信令服務解耦、無依賴；第二，無中央配置，無需通過配置來控制能力服務的功能和邏輯，而是通過接口和調用關系來控制；第三，結構簡單，能夠實現低成本運維；第四，能力服務可利用現有的網絡能力。3.3 媒體服務對接能力服務過程通過上圖來解釋媒體服務對接能力服務過程中的邏輯，與發布/訂閱模塊相同，都是用 Client 調用 IM Server，調用信令服務拿 Token 返回，Token 可以直接生成一個 Hash 值，可以將 Token 理解為一個字符串，將想要的數據通過加密算法封到 Token字符串里，比如“host@clusterld”，“config”，Token 返回 Client 之后還是尋找媒體服務，在連接另外一個媒體服務做通信時接入能力服務，由發起方提供能力服務的內容。3.4 媒體服務對能力服務接口設計媒體服務對能力服務接口設計分為申請推流/接受推流申請和推出推流/接受推流推出兩種。4. 服務集群4.1 服務集群設計原則關于服務集群的設計理念，首先還是貫穿始終的結構簡單、易于維護，其次是可低成本構建集群以及可快速的擴縮容。4.2 媒體服務集群框架整個媒體服務集群的架構如上圖所示，其中每臺媒體服務器應該有自己獨立向外暴露的IP 地址，用于進行 RTC 相關的通訊。媒體服務現在有兩個角色，一個是用于RTC 相關的通訊，另外每個媒體服務器現在有自己 HTTＰ 的接口，用負載均衡和反向代理來控制這些HTTP 接口的調用，通過反向代理實現規則調度。4.3 服務集群實現媒體服務集群還實現了實時通信單中心間媒體服務零調用，直播模式單中心理論上支持無限擴容以及通過代理層的控制實現無業務中斷的更新。4.4 MCU 能力服務集群MCU能力服務集群與媒體服務集群邏輯相同
4.5 集群概況在沒有能力服務的情況下，上半部分就是融云標準的數據中心模型，引入能力服務后，需要復用媒體服務集群現有的基礎設施，所有的能力服務就會與媒體服務部署在一起，但實際上由于架構實現解耦，比較靈活，并不需要物理上部署在一起。5. 服務網絡5.1 全球網絡設計原則融云在做IM 的時候對于全球網絡設計有非常豐富的經驗，通過多年來在全球覆蓋地區 IM網絡和基礎數據的收集，基本可以了解全球各個地區的實時網絡變化情況。在這過程中團隊總結出任何物理的優化都不是特別穩定，因此全球網絡的設計理念就包括客戶端就近接入，多鏈路選擇，數據中心間同源音視頻只有一路級聯，利用IaaS能力進行中心間級聯鏈路的優化。5.2 跨國級聯示意圖跨國級聯示意5.3 全球網絡的工作另外，融云在全球網絡中還做了一些工作，比如DoH 剛在2018年9月變成RFC 的標準，主要解決 DNS 中間人劫持問題，根據融云這么多年業務開發經驗來看，很多連接問題最終發現都是由DNS 劫持導致的。另外在引入 SmartDNS 時會遇到 LocalDNS 緩存不準的問題，這些都會導致最終分配的就近地址不是真正的就近地址。融云目前的工作模式是將三者結合起來使用，在引入SmartDNS 技術的同時引入 BGP Anycast 運營商技術來解決最近地址問題，通過這三層技術最大化來保證找到用戶的最近地址。另外可以在某些特殊情況下采用公網鏈路來做數據中心之間的級聯通信，絕大多數廠商礙于成本的考慮也采取了這樣的方法，但公網存在某些特殊情況不穩定的問題，因此需要有一些備用鏈路，甚至在一些特殊的國家地區做物理鏈路優化，融云IM 在全球的基礎網絡設施投入很大成本，也收獲了很可觀的成績。6. 未來工作計劃關于融云目前正在開展的工作計劃，隨著業務的不斷增加，按照現有的架構其實可以引入更多基于場景的能力服務，只要遵循架構模型就可以不斷地引入新的模型。另外在融云的架構模式下天生支持混合云模式，由于各個服務間都是解耦的，任何私有環境下的服務都可以直接利用已經存在的公有媒體服務架構之上，對于公有媒體服務來說，只要遵循相同的發布/訂閱模型就可以直接使用。
大家好，我是融云的聯合創始人兼CTO 楊攀，本次我分享的主題是融云在公有云媒體服務設計的理念和思路。我是從2002年參加工作，至今已經十七年，其中有十五年的時間都是在做關于IM 的工作。2004年時我加入了 MSN，作為 MSN 進中國第一個落地的本地化服務，我在其中擔任項目負責人的工作。2008年到2014年間我都在從事與飛信相關的工作，經歷了飛信從一個非常小的業務成長為數億級規模的水平。2014年后隨著云服務的興起，我與團隊創立了融云，將即時通訊與云服務結合提供給開發者，讓開發者可以通過調用 SDK 使用 IM 服務。本次演講將分為設計概述、媒體服務、能力服務、服務集群和服務網絡五個部分展開。1. 設計理念融云是一家互聯網通信云服務商，眾所周知，要想做基本的音視頻服務，首先你需要具備信令服務、能力服務和媒體服務這三種能力，這些能力都基于WebRTC 技術，但 WebRTC 本身的定義是 Ｐ2Ｐ 的通訊，它本身并沒有服務部分，在服務部分有很多開源的實現解決方案。其次 WebRTC也沒有定義信令服務的部分，很多廠家都是通過自己開發或采用第三方信令的方式來解決這個問題。信令其實就是一個長鏈接的通信通道，它與 IM 即時通訊其實是一樣的，融云也有案例說明客戶可以采用融云的公有云即時通訊解決方案來滿足信令服務的需求。隨著基礎通信能力達到要求之后，又不斷引入新的需求，比如對音視頻內容的審核、更大規模的使用WebRTC技術替代直播平臺的解決方案，這也就引入了類服務這樣新的功能。融云即時通訊業務的設計理念是各司其職、避免依賴，核心服務專注通信，能力服務專注業務，只要做到這一點，系統就可以實現部署簡單和運維方便，降低管理的成本。另外融云作為全球互聯網通信云服務提供商，在設計之初就不可避免要考慮全球互聯的問題，全球互聯的架構與私有架構的不同需要充分照顧到。2. 媒體服務2.1 媒體服務基礎能力首先從三大能力中的媒體服務能力談起，融云團隊一般都稱之為“三無服務”，“三無”是指一個媒體服務對其他的服務沒有依賴，其他的服務對這個媒體服務自身也沒有依賴，并且每個服務沒有任何中心化的配置。根據工作中的經驗，無論是在公有云、私有云還是混合云環境中，會面臨要部署的環境和客戶端的環境都非常復雜的情況，比如用戶會在防火墻后或者服務器本身就在防火墻里面，遇到這些情況，融云采用端口收斂的方式進行通信的策略控制，這都是需要在設計之初就做到的事情。另外融云還實現了兩個實時通信場景，第一個場景是絕大多基礎音視頻廠商都能做到的二人Ｐ2Ｐ 會話，第二個場景是多人視頻會議，在這個場景中人數一般會在十人以上。隨著業務的發展，大家都能感覺到一個技術趨勢：用WebRTC 的方式做直播，傳統的直播是將客戶端的流在服務端處理之后推給 CDN，最后由CDN 進行分發，這樣做的好處是利用 CDN 的基礎架構可以實現大規模用戶在一個房間收看直播，這是CDN 技術特點所帶來的優勢，但同時 CDN 也存在著一些問題，比如首屏開屏的速度過慢，當然目前針對這個問題也有著各式各樣的解決方案。有些客戶在這基礎上就會提出能否使用WebRTC 來實現直播場景，業內也稱這種方案為低延遲直播，由于延遲比較低，在直播中的互動也會更加友好。2.2 信令服務與媒體服務關于信令服務和媒體服務的關系，絕大多數的廠商信令服務和媒體服務都是在一起的，融云的設計理念強調要解耦，使得部署和維護都更簡單，因此信令服務和媒體服務之間也需要解耦和無依賴，信令服務與媒體服務之間原本存在的狀態同步也要解開，而且融云本身就有特別健壯的信令服務，因此可以復用融云的IM 通道，融云本身在這方面的投入也相當大。上圖是信令服務與媒體服務的簡單架構，每一個媒體服務都與信令服務相關，相關性的目的是讓彼此清楚各自的狀態，這個設計模式的特點是客戶端與信令服務通信，通信結束之后可以與媒體服務通信，而媒體服務之間的對接不受影響。2.3 實時通信發布/訂閱過程解析上圖是為了實現解耦引入的實時通信發布/訂閱的模型，當 Client A 要與 Client B 進行會話時，第一步是進行發布，首先用 Client 調用IM Server，提交加入房間/通話申請，調用信令服務的目的是拿Token 返回，Token 中包括之后整個訂閱/發布功能所需要的關鍵數據，拿到這些 Token 之后去調用相關媒體服務的地址，傳統的設計通常是找信令服務，在分析IP 地址庫之后指到媒體服務，由于我們需要做到解耦，因此在 Token 調用媒體服務后會給出一個返回值，返回值是IP 地址和 Domain。返回 Client 之后就可以拿到 IP 的信息，連到媒體服務開始與 Client B 通信，通信的過程完全是依靠長鏈接的信令服務通道來進行的，Client A將它得到的 Domain 信息發送給 Client B，此時發送階段工作結束。發送階段結束之后由Client B 來執行訂閱工作，Client B 會找到離它比較近的信令服務，調用媒體服務接口連到Client A 連接的媒體服務，這就是完整的發布/訂閱模式。2.4 媒體服務對客戶端接口設計對于媒體服務對客戶端接口的設計，只需要提供發布/取消發布流、SFU 訂閱/取消訂閱和MCU 訂閱/取消訂閱的接口，就可以完成解耦過程，整個通信的過程也可以建立起來。3. 能力服務3.1 能力服務分類本身正常的一對一、多對多通信完全可以通過媒體服務就可以實現，融云最初上線的版本也是基于媒體服務去實現通信需求。后續客戶和業務產生了新的需求，比如在AB 通訊時需要錄像、對音視頻的審核以及 WebRTC 實現低延遲直播等，融云將這些需求統稱為能力服務。3.2 能力服務設計原則能力服務一樣也有設計原則，首先，需要與媒體服務或信令服務解耦、無依賴；第二，無中央配置，無需通過配置來控制能力服務的功能和邏輯，而是通過接口和調用關系來控制；第三，結構簡單，能夠實現低成本運維；第四，能力服務可利用現有的網絡能力。3.3 媒體服務對接能力服務過程通過上圖來解釋媒體服務對接能力服務過程中的邏輯，與發布/訂閱模塊相同，都是用 Client 調用 IM Server，調用信令服務拿 Token 返回，Token 可以直接生成一個 Hash 值，可以將 Token 理解為一個字符串，將想要的數據通過加密算法封到 Token字符串里，比如“host@clusterld”，“config”，Token 返回 Client 之后還是尋找媒體服務，在連接另外一個媒體服務做通信時接入能力服務，由發起方提供能力服務的內容。3.4 媒體服務對能力服務接口設計媒體服務對能力服務接口設計分為申請推流/接受推流申請和推出推流/接受推流推出兩種。4. 服務集群4.1 服務集群設計原則關于服務集群的設計理念，首先還是貫穿始終的結構簡單、易于維護，其次是可低成本構建集群以及可快速的擴縮容。4.2 媒體服務集群框架整個媒體服務集群的架構如上圖所示，其中每臺媒體服務器應該有自己獨立向外暴露的IP 地址，用于進行 RTC 相關的通訊。媒體服務現在有兩個角色，一個是用于RTC 相關的通訊，另外每個媒體服務器現在有自己 HTTＰ 的接口，用負載均衡和反向代理來控制這些HTTP 接口的調用，通過反向代理實現規則調度。4.3 服務集群實現媒體服務集群還實現了實時通信單中心間媒體服務零調用，直播模式單中心理論上支持無限擴容以及通過代理層的控制實現無業務中斷的更新。4.4 MCU 能力服務集群MCU能力服務集群與媒體服務集群邏輯相同
4.5 集群概況在沒有能力服務的情況下，上半部分就是融云標準的數據中心模型，引入能力服務后，需要復用媒體服務集群現有的基礎設施，所有的能力服務就會與媒體服務部署在一起，但實際上由于架構實現解耦，比較靈活，并不需要物理上部署在一起。5. 服務網絡5.1 全球網絡設計原則融云在做IM 的時候對于全球網絡設計有非常豐富的經驗，通過多年來在全球覆蓋地區 IM網絡和基礎數據的收集，基本可以了解全球各個地區的實時網絡變化情況。在這過程中團隊總結出任何物理的優化都不是特別穩定，因此全球網絡的設計理念就包括客戶端就近接入，多鏈路選擇，數據中心間同源音視頻只有一路級聯，利用IaaS能力進行中心間級聯鏈路的優化。5.2 跨國級聯示意圖跨國級聯示意5.3 全球網絡的工作另外，融云在全球網絡中還做了一些工作，比如DoH 剛在2018年9月變成RFC 的標準，主要解決 DNS 中間人劫持問題，根據融云這么多年業務開發經驗來看，很多連接問題最終發現都是由DNS 劫持導致的。另外在引入 SmartDNS 時會遇到 LocalDNS 緩存不準的問題，這些都會導致最終分配的就近地址不是真正的就近地址。融云目前的工作模式是將三者結合起來使用，在引入SmartDNS 技術的同時引入 BGP Anycast 運營商技術來解決最近地址問題，通過這三層技術最大化來保證找到用戶的最近地址。另外可以在某些特殊情況下采用公網鏈路來做數據中心之間的級聯通信，絕大多數廠商礙于成本的考慮也采取了這樣的方法，但公網存在某些特殊情況不穩定的問題，因此需要有一些備用鏈路，甚至在一些特殊的國家地區做物理鏈路優化，融云IM 在全球的基礎網絡設施投入很大成本，也收獲了很可觀的成績。6. 未來工作計劃關于融云目前正在開展的工作計劃，隨著業務的不斷增加，按照現有的架構其實可以引入更多基于場景的能力服務，只要遵循架構模型就可以不斷地引入新的模型。另外在融云的架構模式下天生支持混合云模式，由于各個服務間都是解耦的，任何私有環境下的服務都可以直接利用已經存在的公有媒體服務架構之上，對于公有媒體服務來說，只要遵循相同的發布/訂閱模型就可以直接使用。
LiveVideoStack?秋季招聘
LiveVideoStack正在招募編輯/記者/運營，與全球頂尖多媒體技術專家和LiveVideoStack年輕的伙伴一起，推動多媒體技術生態發展。同時，也歡迎你利用業余時間、遠程參與內容生產。了解崗位信息請在BOSS直聘上搜索“LiveVideoStack”，或通過微信“Tony_Bao_”與主編包研交流。
總結
以上是生活随笔為你收集整理的可扩展的公有云媒体服务设计解析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： LiveVideoStack线上分享第四
- 下一篇： 首届全球互联网通信云大会重磅来袭 融云邀