網(wǎng)上有很多關(guān)于雙流區(qū)個(gè)人如何申請(qǐng)pos機(jī),流媒體服務(wù)器如何實(shí)現(xiàn)負(fù)載均衡的知識(shí)，也有很多人為大家解答關(guān)于雙流區(qū)個(gè)人如何申請(qǐng)pos機(jī)的問題，今天pos機(jī)之家(m.afbey.com)為大家整理了關(guān)于這方面的知識(shí)，讓我們一起來看下吧!
本文目錄一覽：
1、雙流區(qū)個(gè)人如何申請(qǐng)pos機(jī)
雙流區(qū)個(gè)人如何申請(qǐng)pos機(jī)
作者：Winlin、Azusachino、Benjamin
編輯：Alex
▲掃描圖中二維碼或點(diǎn)擊閱讀原文▲
了解音視頻技術(shù)大會(huì)更多信息
當(dāng)我們的業(yè)務(wù)超過單臺(tái)流媒體服務(wù)器的承受能力，就會(huì)遇到負(fù)載均衡問題，一般我們會(huì)在集群中提供這種能力，但實(shí)際上集群并非是唯一的實(shí)現(xiàn)方式。有時(shí)候負(fù)載均衡還會(huì)和服務(wù)發(fā)現(xiàn)等時(shí)髦詞匯聯(lián)系起來，而云服務(wù)的LoadBalancer無疑不可回避，因此，這個(gè)問題其實(shí)相當(dāng)復(fù)雜，以至于大家會(huì)在多個(gè)場合詢問這個(gè)問題，我打算系統(tǒng)地闡述這個(gè)問題。
如果你已經(jīng)知道了以下問題的所有答案，并且深刻了解背后的原因，那么你可以不用看這篇文章了：
? SRS是否需要Nginx、F5或HAProxy做流代理？不需要，完全不需要，這樣是完全誤解了流媒體的負(fù)載均衡。而HTTPS我們卻建議這么做，同時(shí)為了減少對(duì)外服務(wù)的IP又建議用云LoadBalancer。? 如何發(fā)現(xiàn)SRS邊緣節(jié)點(diǎn)？如何發(fā)現(xiàn)源站節(jié)點(diǎn)？對(duì)于邊緣，通常DNS和HTTP-DNS都可以；而源站是不應(yīng)該直接暴露給客戶端直接連接的。? WebRTC在服務(wù)發(fā)現(xiàn)上有什么區(qū)別？由于CPU性能損耗更大，負(fù)載均衡的閾值更低；在單PeerConnectIOn時(shí)流會(huì)動(dòng)態(tài)變化，導(dǎo)致更難負(fù)載均衡；移動(dòng)端UDP的切網(wǎng)和IP漂移，會(huì)引入更多問題。? DNS和HTTP-DNS哪個(gè)更合適作為流媒體服務(wù)器的服務(wù)發(fā)現(xiàn)機(jī)制？肯定是HTTP-DNS，因?yàn)榱髅襟w服務(wù)器的負(fù)載變化，比Web服務(wù)器的變化更大，考慮新增1K的客戶端對(duì)于兩種不同服務(wù)器的負(fù)載影響。? 負(fù)載均衡是否只需要考慮如何降低系統(tǒng)負(fù)載？首要目標(biāo)是考慮降低系統(tǒng)負(fù)載，或者防止系統(tǒng)過載導(dǎo)致質(zhì)量問題甚至崩潰；同時(shí)在同等負(fù)載時(shí)，也需要考慮就近服務(wù)和成本因素。? 負(fù)載均衡是否只能靠增加一層服務(wù)器？一般大型的CDN分發(fā)系統(tǒng)，明顯是分層的，無論是靜態(tài)的樹設(shè)計(jì)，還是動(dòng)態(tài)的MESH設(shè)計(jì)，在流的傳輸上都是靠分層增加負(fù)載能力；同時(shí)，還能通過端口重用（REUSEPORT）方式，用多進(jìn)程方式增加節(jié)點(diǎn)的負(fù)載而不會(huì)增加層。? 負(fù)載均衡是否只能使用集群方式實(shí)現(xiàn)？集群是基本的增加系統(tǒng)容量的方式，除此之外，也可以通過業(yè)務(wù)分離配合Vhost實(shí)現(xiàn)系統(tǒng)隔離，或者通過一致性hash來分流業(yè)務(wù)和用戶。好吧，讓我們?cè)敿?xì)聊聊負(fù)載和負(fù)載均衡。
What is Load？在解決系統(tǒng)均衡問題時(shí)，首先我們看看什么是負(fù)載？對(duì)于服務(wù)器來說，負(fù)載就是因?yàn)橛锌蛻舳说脑L問，而導(dǎo)致的資源消耗上升。當(dāng)資源消耗出現(xiàn)嚴(yán)重不均衡，可能會(huì)導(dǎo)致服務(wù)不可用，比如CPU跑滿了，所有客戶端都會(huì)變得不正常。
對(duì)于流媒體服務(wù)器而言，就是流媒體客戶端導(dǎo)致的服務(wù)器資源消耗。一般我們會(huì)從服務(wù)器資源消耗角度度量系統(tǒng)負(fù)載：
? CPU：服務(wù)器消耗的CPU，一般我們稱CPU消耗較多的為計(jì)算密集型場景，而把網(wǎng)絡(luò)帶寬消耗較多的稱為IO密集型場景。直播場景一般屬于IO密集型場景，CPU一般不會(huì)首先成為瓶頸；而在RTC中卻不是，RTC是IO和計(jì)算都很密集，這是非常大的差異。? 網(wǎng)絡(luò)帶寬：傳輸流媒體時(shí)需要消耗網(wǎng)絡(luò)帶寬，也就是上文介紹的IO密集型場景。流媒體肯定是IO密集型場景，所以帶寬一定是重要的瓶頸。而有些場景比如RTC同時(shí)還是計(jì)算密集場景。? 磁盤：如果不需要錄制和支持HLS，那么磁盤就不是重要的瓶頸，如果一定開啟錄制和HLS，那么磁盤將變得非常關(guān)鍵，因?yàn)榇疟P是最慢的。當(dāng)然由于現(xiàn)在內(nèi)存較多，所以一般我們采用掛內(nèi)存盤的方式避免這個(gè)問題。? 內(nèi)存： 相對(duì)而言，內(nèi)存是流媒體服務(wù)器中消耗較少的資源，盡管做了不少Cache，但是內(nèi)存一般還是不會(huì)首先達(dá)到瓶頸。所以一般內(nèi)存也會(huì)在流媒體服務(wù)器中大量用作Cache，來交換其他的資源負(fù)載，比如SRS在直播CPU優(yōu)化時(shí)，用writev緩存和發(fā)送大量數(shù)據(jù)，就是用高內(nèi)存換得CPU降低的策略。當(dāng)負(fù)載過高，會(huì)有什么問題？負(fù)載過高會(huì)導(dǎo)致系統(tǒng)直接出現(xiàn)問題，比如延遲增大，卡頓，甚至不可用。而這些負(fù)載的過載，一般都會(huì)有連鎖反應(yīng)。比如：
? CPU： CPU過高會(huì)引起連鎖反應(yīng)，這時(shí)候意味著系統(tǒng)無法支持這么多客戶端，那么會(huì)導(dǎo)致隊(duì)列堆積，從而引起內(nèi)存大量消耗；同時(shí)網(wǎng)絡(luò)吞吐也跟不上，因?yàn)榭蛻舳藷o法收到自己需要的數(shù)據(jù)，出現(xiàn)延遲增大和卡頓；這些問題反而引起CPU更高，直到系統(tǒng)崩潰。? 網(wǎng)絡(luò)帶寬： 若超過系統(tǒng)的限定帶寬，比如網(wǎng)卡的限制，或者系統(tǒng)隊(duì)列的限制，那么會(huì)導(dǎo)致所有用戶都拿不到自己需要的數(shù)據(jù)，出現(xiàn)卡頓現(xiàn)象。另外也會(huì)引起隊(duì)列增大，而處理堆積隊(duì)列，一般需要消耗CPU，所以也會(huì)導(dǎo)致CPU上升。? 磁盤： 若超過磁盤負(fù)載，可能會(huì)導(dǎo)致寫入操作掛起。而在同步寫入的服務(wù)器，會(huì)導(dǎo)致流無法正常傳輸，日志堆積。在異步寫入的服務(wù)器，會(huì)導(dǎo)致異步隊(duì)列堆積。注意目前SRS是同步寫入，正在進(jìn)行多線程異步寫入。? 內(nèi)存： 超過內(nèi)存會(huì)OOM，直接干掉服務(wù)器進(jìn)程。一般內(nèi)存主要是泄露導(dǎo)致的緩慢上漲，特別是在流很多時(shí)，SRS為了簡化問題，沒有清理和刪除流，所以若流極其多，那么內(nèi)存的持續(xù)上漲是需要關(guān)注的。由此可見，系統(tǒng)的負(fù)載，首先需要被準(zhǔn)確度量，也就是關(guān)注的是過載或超載（Overload）情況，這個(gè)問題也需要詳細(xì)說明。
What is Overload？超過系統(tǒng)負(fù)載就是超載或過載（Overload），這看起來是個(gè)簡單的問題，但實(shí)際上卻并不簡單，比如：
? CPU是否超過100%就是過載？不對(duì)，因?yàn)橐话惴?wù)器會(huì)有多個(gè)CPU，也就是8個(gè)CPU的服務(wù)器，實(shí)際上能達(dá)到800%。? 那CPU是否不超過總CPU使用率，比如8CPU的服務(wù)器不超過800%就不會(huì)過載？不對(duì)，因?yàn)榱髅襟w服務(wù)器不一定能用多核，比如SRS就是單核，也就是它最多跑100%。? 那是否SRS不超過100%使用率，就不會(huì)過載？不對(duì)，因?yàn)槠渌倪M(jìn)程可能也在消耗，不能只看SRS的CPU消耗。因此，對(duì)于CPU來說，知道流媒體服務(wù)器能消耗多少CPU，獲取流媒體服務(wù)器的CPU消耗，才能準(zhǔn)確定義過載：
? 系統(tǒng)總CPU，超過80%認(rèn)為過載，比如8CPU的服務(wù)器，總CPU超過640%就認(rèn)為過載，一般系統(tǒng)的load值也升很高，代表系統(tǒng)很繁忙。? SRS每個(gè)進(jìn)程的CPU，超過80%認(rèn)為過載，比如8CPU的服務(wù)器總CPU只有120%，但SRS的進(jìn)程占用80%，其他占用40%，那么此時(shí)也是過載。網(wǎng)絡(luò)帶寬，一般是根據(jù)以下幾個(gè)指標(biāo)判斷是否過載，流媒體一般和流的碼率Kbps或Mpbs有關(guān)，代表這個(gè)流每秒是多少數(shù)據(jù)傳輸：
? 是否超過服務(wù)器出口帶寬，比如云服務(wù)器公網(wǎng)出口是10Mbps，那么如果平均碼率是1Mbps的直播流，超過10個(gè)客戶端就過載了。如果100個(gè)客戶端都來推拉流，那么每個(gè)客戶端只能傳輸100Kbps的數(shù)據(jù)，當(dāng)然會(huì)造成嚴(yán)重卡頓。? 是否超過內(nèi)核的隊(duì)列，在UDP中，一般系統(tǒng)默認(rèn)的隊(duì)列大小只有256KB，而流媒體中的包數(shù)目和字節(jié)，在流較多時(shí)遠(yuǎn)遠(yuǎn)超過了隊(duì)列長度，會(huì)導(dǎo)致沒有超過服務(wù)器帶寬但是出現(xiàn)丟包情況，具體參考《SRS性能(CPU)、內(nèi)存優(yōu)化工具用法》（https://www.jianshu.com/p/6d4a89359352）這部分內(nèi)容。? 是否超過客戶端的網(wǎng)絡(luò)限制，有時(shí)候某些客戶端的網(wǎng)絡(luò)很差，出現(xiàn)客戶端的網(wǎng)絡(luò)過載。特別是直播推流時(shí)，需要重點(diǎn)關(guān)注主播上行的網(wǎng)絡(luò)，沒經(jīng)驗(yàn)的主播會(huì)出現(xiàn)弱網(wǎng)等，導(dǎo)致所有人卡頓。磁盤，主要涉及的是流的錄制、日志切割以及慢磁盤導(dǎo)致的STW問題：
? 若需要錄制的流較多，磁盤作為最慢的設(shè)備，會(huì)明顯成為瓶頸。一般在系統(tǒng)設(shè)計(jì)時(shí)，就需要避免這種情況，比如64GB內(nèi)存的服務(wù)器，可以分32GB的內(nèi)存盤，給流媒體服務(wù)器寫臨時(shí)文件?；蛘呤褂幂^小的內(nèi)存盤，用外部的程序比如node.js，開啟多線程后，將文件拷貝到存儲(chǔ)或發(fā)送到云存儲(chǔ)，可以參考srs-cloud（https://github.com/ossrs/srs-cloud）的最佳實(shí)踐。? 服務(wù)器的日志，在一些異常情況下，可能會(huì)造成大量寫入，另外如果持續(xù)累計(jì)不切割和清理，會(huì)導(dǎo)致日志文件越來越大，最終寫滿磁盤。SRS支持logrotate，另外docker一般也可以配置logrotate，通常會(huì)將日志做提取后（日志少可以直接采集原始日志），傳輸?shù)皆频娜罩痉?wù)做分析，本地只需要存儲(chǔ)短時(shí)間比如15天日志。? STW問題，寫磁盤是阻塞操作，特別是掛載的網(wǎng)絡(luò)磁盤（比如NAS），掛載到本地文件系統(tǒng)，而服務(wù)器在調(diào)用write寫入數(shù)據(jù)時(shí)，實(shí)際上可能有非常多的網(wǎng)絡(luò)操作，那么這種其實(shí)會(huì)更消耗時(shí)間。SRS目前應(yīng)該完全避免掛載網(wǎng)絡(luò)磁盤，因?yàn)槊看巫枞紩?huì)導(dǎo)致整個(gè)服務(wù)器STW（世界暫停）不能處理其他請(qǐng)求。內(nèi)存主要是涉及泄露和緩存問題，主要的策略是監(jiān)控系統(tǒng)整體的內(nèi)存，相對(duì)比較簡單。
Special for Media Server除了一般的資源消耗，在流媒體服務(wù)器中，還有一些額外因素會(huì)影響到負(fù)載或者負(fù)載均衡，包括：
? 長連接：直播和WebRTC的流都是長時(shí)間，最長的直播可能超過2天，而會(huì)議開幾個(gè)小時(shí)也不是難事。因此，流媒體服務(wù)器的負(fù)載是具有長連接特性，這會(huì)對(duì)負(fù)載均衡造成很大的困擾，比如輪詢調(diào)度策略可能不是最有效的。? 有狀態(tài)：流媒體服務(wù)器和客戶端的交互比較多，中間保存了一些狀態(tài)，這導(dǎo)致負(fù)載均衡服務(wù)器無法直接在服務(wù)出現(xiàn)問題時(shí)，把請(qǐng)求直接給一臺(tái)新的服務(wù)器處理，甚至都不是一個(gè)請(qǐng)求，這個(gè)問題在WebRTC中尤其明顯，DTLS和SRTP加密的這些狀態(tài)，使得不能隨意切換服務(wù)器。? 相關(guān)性：兩個(gè)Web請(qǐng)求之間是沒有關(guān)聯(lián)的，一條失敗并不會(huì)影響另外一條。而在直播中，推流能影響所有的播放；在WebRTC中，只要有一個(gè)人拉流失敗或傳輸質(zhì)量太差，盡管其他流都表現(xiàn)良好，但這個(gè)會(huì)議可能還是開不下去。這些問題當(dāng)然不完全是負(fù)載和負(fù)載均衡問題，比如WebRTC支持的SVC和Simulcast功能，目的就是為了解決某些弱客戶端的問題。有些問題是可以通過客戶端的失敗重試解決，比如高負(fù)載時(shí)的連接遷移，服務(wù)器可以強(qiáng)制關(guān)閉，客戶端重試遷移到下一個(gè)服務(wù)器。
還有一種傾向，就是避免流媒體服務(wù)，而是用HLS/DASH/CMAF等切片，這就變成了一個(gè)Web服務(wù)器，上面所有的問題就突然沒有了。但是，切片協(xié)議實(shí)際上只能做到3秒，或者比較常見的5秒以上的延遲場景，而在1到3秒的直播延遲，或者500ms到1秒的低延遲直播，以及200ms到500ms的RTC通話，以及100ms之內(nèi)的控制類場景，永遠(yuǎn)都不能指望切片服務(wù)器，這些場景只能使用流媒體服務(wù)器實(shí)現(xiàn)，不管里面?zhèn)鬏數(shù)氖荰CP的流，還是UDP的包。
我們?cè)谙到y(tǒng)設(shè)計(jì)時(shí)，需要考慮這些問題，例如WebRTC應(yīng)該盡量避免流和房間耦合，也就是一個(gè)房間的流一定需要分布到多個(gè)服務(wù)器上，而不是限制在一臺(tái)服務(wù)器。這些業(yè)務(wù)上的限制越多，對(duì)于負(fù)載均衡越不利。
SRS Overload現(xiàn)在特別說明SRS的負(fù)載和過載情況：
? SRS的進(jìn)程：若CPU超過100%，則過載。SRS是單線程設(shè)計(jì)，無法使用多個(gè)CPU的能力（這個(gè)后面我會(huì)詳細(xì)展開講講）。? 網(wǎng)絡(luò)帶寬：一般是最快達(dá)到過載的資源，比如直播中達(dá)到1Gbps吞吐帶寬時(shí)可能CPU還很空閑，RTC由于同時(shí)是計(jì)算密集型，稍微有些差異。? 磁盤：除了非常少的路數(shù)的流的錄制，一般需要規(guī)避磁盤問題，掛載內(nèi)存盤，或者降低每個(gè)SRS處理的流的路數(shù)。參考srs-cloud(https://github.com/ossrs/srs-cloud)的最佳實(shí)踐。? 內(nèi)存：一般是使用較少的資源，在流路數(shù)特別特別多，比如監(jiān)控場景不斷推流和斷開的場景，需要持續(xù)關(guān)注SRS的內(nèi)存上漲。這個(gè)問題可以通過Gracefully Quit(https://github.com/ossrs/srs/issues/413#issuecomment-917771521)規(guī)避。特別說明一下SRS單線程的問題，這其實(shí)是個(gè)選擇，沒有免費(fèi)的性能優(yōu)化，多線程當(dāng)然能提升處理能力，同時(shí)是以犧牲系統(tǒng)的復(fù)雜度為代價(jià)，同時(shí)也很難評(píng)估系統(tǒng)的過載，比如8核的多線程的流媒體服務(wù)器CPU多少算是過載？640%？不對(duì)，因?yàn)榭赡苊總€(gè)線程是不均勻的，要實(shí)現(xiàn)線程均勻就要做線程的負(fù)載調(diào)度，這又是更復(fù)雜的問題。
目前SRS的單線程，能適應(yīng)絕大多數(shù)場景。對(duì)于直播來說，Edge可以使用多進(jìn)程REUSEPORT方式，偵聽在同樣端口，實(shí)現(xiàn)消耗多核；RTC可以通過一定數(shù)量的端口；或者在云原生場景，使用docker跑SRS，可以起多個(gè)K8s的Pod，這些都是可選的更容易的方案。
Note: 除非是對(duì)成本非常敏感的云服務(wù)，那么肯定可以自己定制，可以付出這個(gè)復(fù)雜性的代價(jià)了。據(jù)我所知，幾個(gè)知名的云廠商，基于SRS實(shí)現(xiàn)了多線程版本。我們正在一起把多線程能力開源出來，在可以接受的復(fù)雜度范圍提升系統(tǒng)負(fù)載能力，詳細(xì)請(qǐng)參考https://github.com/ossrs/srs/issues/2188。
我們了解了流媒體服務(wù)器的這些負(fù)載，接下來該考慮如何分擔(dān)這些負(fù)載了。
Round Robin：Simple and RobustRound Robin是非常簡單的負(fù)載均衡策略：每次客戶端請(qǐng)求服務(wù)時(shí)，調(diào)度器從服務(wù)器列表中找到下一個(gè)服務(wù)器給客戶端，非常簡單：
server = servers[pos++ % servers.length()]
如果每個(gè)請(qǐng)求是比較均衡的，比如Web請(qǐng)求一般很短時(shí)間就完成了，那么這種策略是比較有效的。這樣新增和刪除服務(wù)器，上線和下線，升級(jí)和隔離，都非常好操作。
流媒體長連接的特點(diǎn)導(dǎo)致輪詢的策略并不好用，因?yàn)橛行┱?qǐng)求可能會(huì)比較久，有些比較短，這樣會(huì)造成負(fù)載不均衡。當(dāng)然，如果就只有少量的請(qǐng)求，這個(gè)策略依然非常好用。
SRS的Edge邊緣集群中，在尋找上游Edge服務(wù)器時(shí)，使用的也是簡單的Round Robin方式，這是假設(shè)流的路數(shù)和服務(wù)時(shí)間比較均衡，在開源中是比較合適的策略。本質(zhì)上，這就是上游Edge服務(wù)器的負(fù)載均衡策略，相當(dāng)于是解決了總是回源到一臺(tái)服務(wù)器的過載問題。如下圖所示：
源站集群中，第一次推流時(shí)，Edge也會(huì)選擇一臺(tái)Origin服務(wù)器，使用的也是Round Robin策略。這本質(zhì)上就是Origin服務(wù)器的負(fù)載均衡策略，解決的是Origin服務(wù)器過載問題。如下圖所示：
在實(shí)際業(yè)務(wù)中，一般并不會(huì)使用純粹的Round Robin，而是有個(gè)調(diào)度服務(wù)，會(huì)收集這些服務(wù)器的數(shù)據(jù)，評(píng)估負(fù)載，給出負(fù)載比較低或者質(zhì)量高的服務(wù)器。如下圖所示：
如何解決Edge的負(fù)載均衡問題呢？依靠的是Frontend Load Balance策略，也就是前端接入側(cè)的系統(tǒng)，我們下面講常用的方式。
Frontend Load Balancer: DNS or HTTP DNS我們?cè)赗ound Robin中重點(diǎn)介紹了服務(wù)內(nèi)部的負(fù)載均衡，而直接對(duì)客戶端提供服務(wù)的服務(wù)器，一般叫做Frontend Load Balancer，情況會(huì)有點(diǎn)不太一樣：
? 若整個(gè)流媒體服務(wù)節(jié)點(diǎn)較少，而且是中心化部署，那么也可以用Round Robin的方式。在DNS中設(shè)置多個(gè)解析IP，或者HTTP DNS返回時(shí)隨機(jī)選擇節(jié)點(diǎn)，或者選擇相對(duì)較輕的負(fù)載的機(jī)器，也是可行的方案。? 在較多節(jié)點(diǎn)，特別是分布式部署的節(jié)點(diǎn)中，是不可能選擇Round Robin的方案，因?yàn)槌素?fù)載之外，還需要考慮用戶的地理位置，一般來說會(huì)選擇分配“就近”的節(jié)點(diǎn)。同樣DNS和HTTP DNS也能做到這點(diǎn)，一般是根據(jù)用戶的出口IP，從IP庫中獲取地理位置信息。其實(shí)DNS和HTTP DNS在調(diào)度能力上沒有區(qū)別，甚至很多DNS和HTTP DNS系統(tǒng)的決策系統(tǒng)都是同一個(gè)，因?yàn)樗鼈円鉀Q的問題是一樣的：如何根據(jù)用戶的IP，或者其他的信息（比如RTT或探測的數(shù)據(jù)），分配比較合適的節(jié)點(diǎn)（一般是就近，但也要考慮成本）。
DNS是互聯(lián)網(wǎng)的基礎(chǔ)，可以認(rèn)為它就是一個(gè)名字翻譯器，比如我們?cè)赑ING SRS的服務(wù)器時(shí)，會(huì)將ossrs.net解析成IP地址182.92.233.108，這里完全沒有負(fù)載均衡的能力，因?yàn)榫鸵慌_(tái)服務(wù)器而已，DNS在這里只是名字解析：
ping ossrs.netPING ossrs.net (182.92.233.108): 56 data bytes64 bytes from 182.92.233.108: icmp_seq=0 TTL=64 time=24.350 ms
而DNS在流媒體負(fù)載均衡時(shí)的作用，其實(shí)是會(huì)根據(jù)客戶端的IP，返回不同服務(wù)器的IP，而DNS系統(tǒng)本身也是分布式的，在播放器的/etc/hosts文件中就可以記錄DNS的信息，如果沒有就會(huì)在LocalDNS（一般在系統(tǒng)中配置或自動(dòng)獲?。┎樵冞@個(gè)名字的IP。
這意味著DNS能抗住非常大的并發(fā)，因?yàn)椴⒉皇且慌_(tái)中心化的DNS服務(wù)器在提供解析服務(wù)，而是分布式的系統(tǒng)。這就是為何新建解析時(shí)會(huì)有個(gè)TTL（過期時(shí)間），修改解析記錄后，在這個(gè)時(shí)間之后才會(huì)生效。而實(shí)際上，這完全取決于各個(gè)DNS服務(wù)器自己的策略，而且還有DNS劫持和篡改等操作，所以有時(shí)候也會(huì)造成負(fù)載不均衡。
因此HTTP DNS就出來了，可以認(rèn)為DNS是互聯(lián)網(wǎng)的運(yùn)營商提供的網(wǎng)絡(luò)基礎(chǔ)服務(wù)，而HTTP DNS則可以由流媒體平臺(tái)也就是各位自己來實(shí)現(xiàn)，就是一個(gè)名字服務(wù)，也可以調(diào)用一個(gè)HTTP API來解析，比如：
curl http://your-http-dns-service/resolve?domain=ossrs.net{["182.92.233.108"]}
由于這個(gè)服務(wù)是自己提供的，可以自己決定什么時(shí)候更新該名字代表的含義，當(dāng)然可以做到更精確的負(fù)載，也可以用HTTPS防止篡改和劫持。
Note: HTTP-DNS的這個(gè)your-http-dns-service接入域名，則可以用一組IP，或者用DNS域名，因?yàn)樗挥猩贁?shù)節(jié)點(diǎn)，所以它的負(fù)載相對(duì)比較好均衡。
Load Balance by VhostSRS支持Vhost，一般是CDN平臺(tái)用來隔離多個(gè)客戶，每個(gè)客戶可以有自己的domain域名，比如：
vhost customer.a {}vhost customer.b {}
如果用戶推流到同一個(gè)IP的服務(wù)器，但是用不同的Vhost，它們也是不同的流，播放時(shí)地址不同也是不同的流，例如：
? rtmp://ip/live/livestream?vhost=customer.a
? rtmp://ip/live/livestream?vhost=customer.b
Note：當(dāng)然，可以直接用DNS系統(tǒng)，將IP映射到不同的域名，這樣就可以直接在URL中用域名代替IP了。
其實(shí)Vhost還可以用作多源站的負(fù)載均衡，因?yàn)樵贓dge中，可以將不同的客戶分流到不同的源站，這樣可以不用源站集群也可以擴(kuò)展源站的能力：
vhost customer.a { cluster { mode remote; origin server.a; }}vhost customer.b { cluster { mode remote; origin server.a; }}
那么不同的Vhost實(shí)際上共享了Edge節(jié)點(diǎn)，但是Upstream和Origin可以是隔離的。當(dāng)然也可以配合Origin Cluster來做，這時(shí)候就是多個(gè)源站中心，和Consistent Hash要實(shí)現(xiàn)的目標(biāo)有點(diǎn)像了。
Consistent Hash在Vhost隔離用戶的場景下，會(huì)導(dǎo)致配置文件比較復(fù)雜，還有一種更簡單的策略，也可以實(shí)現(xiàn)類似的能力，那就是一致性Hash（Consistent Hash）。
比如，可以根據(jù)用戶請(qǐng)求的Stream的URL做Hash，決定回源到哪個(gè)Upstream或Origin，這樣就一樣可以實(shí)現(xiàn)同樣的隔離和降低負(fù)載。
實(shí)際應(yīng)用中，已經(jīng)有這種方案在線上提供服務(wù)，所以方案上肯定是可行的。當(dāng)然，SRS沒有實(shí)現(xiàn)這個(gè)能力，需要自己碼代碼實(shí)現(xiàn)。
其實(shí)Vhost或者Consistent Hash，也可以配合Redirect來完成更復(fù)雜的負(fù)載均衡。
HTTP 302: Redirect302是重定向（Redirect），實(shí)際上也可以用作負(fù)載均衡，比如通過調(diào)度訪問到服務(wù)器，但是服務(wù)器發(fā)現(xiàn)自己的負(fù)載過高，那么就給定向到另外一臺(tái)服務(wù)器，如下圖所示：
Note: 除了HTTP 302，實(shí)際上RTMP也支持302，SRS的源站集群就是使用這個(gè)方式實(shí)現(xiàn)的。當(dāng)然這里302主要用于流的服務(wù)發(fā)現(xiàn)，而不是用于負(fù)載均衡。
既然RTMP也支持302，那么在服務(wù)內(nèi)部，完全可以使用302來實(shí)現(xiàn)負(fù)載的再均衡。若某個(gè)Upstream的負(fù)載過高，就將流調(diào)度到其他的節(jié)點(diǎn)，并且可以做多次302跳轉(zhuǎn)。
一般在Frontend Server中，只有HTTP流才支持302，比如HTTP-FLV或者HLS。而RTMP是需要客戶端支持302，這個(gè)一般支持得很少，所以不能使用。
另外，基于UDP的流媒體協(xié)議，也有支持302的，比如RTMFP，一個(gè)Adobe設(shè)計(jì)的Flash的P2P的協(xié)議，也支持302。當(dāng)然目前用得很少了。
WebRTC目前沒有302的機(jī)制，一般是依靠Frontend Server的代理，實(shí)現(xiàn)后續(xù)服務(wù)器的負(fù)載均衡。而QUIC作為未來HTTP3的標(biāo)準(zhǔn)，肯定是會(huì)支持302這種基本能力的。而WebRTC逐漸也會(huì)支持WebTransport（基于QUIC），因此這個(gè)能力在未來也會(huì)具備。
SRS: Edge ClusterSRS Edge本質(zhì)上就是Frontend Server，它可以解決以下問題：
? 直播的播放能力擴(kuò)展問題，比如支持10萬人觀看，可以水平擴(kuò)展Edge Server。? 解決就近服務(wù)的問題，和CDN起到的作用是一樣的，一般會(huì)選擇和用戶所在的城市部署。? Edge使用Round Robin方式連接到Upstream Edge，實(shí)現(xiàn)Upstream的負(fù)載均衡。? Edge本身的負(fù)載均衡，是依靠調(diào)度系統(tǒng)，比如DNS或HTTP-DNS。如下圖所示：
特別說明：
? Edge是直播流的邊緣集群，支持RTMP和HTTP-FLV協(xié)議。? Edge不支持切片比如HLS或DASH，切片協(xié)議使用Nginx或ATS分發(fā)。? 不支持WebRTC，WebRTC有自己的集群機(jī)制。由于Edge本身就是Frontend Server，因此一般不需要為了增加系統(tǒng)容量，再在前面掛Nginx或LB，因?yàn)镋dge本身就是為了解決容量問題，而且只有Edge能解決合并回源的問題。
Note：合并回源，指的是同一個(gè)流只會(huì)回源一次，比如有1000個(gè)播放器連接到了Edge，Edge只會(huì)從Upstream獲取一路流，而不會(huì)獲取1000路流，這和透明Proxy是不同的。
當(dāng)然，有時(shí)候還是需要前面掛Nginx或LB，比如：
1. 為了支持HTTPS-FLV或HTTPS-API，Nginx支持得更好，而且HTTP/2也支持。2. 減少對(duì)外的IP，比如多個(gè)服務(wù)器對(duì)外使用一個(gè)IP，這時(shí)候就需要有一臺(tái)專門的LB代理到后端多臺(tái)Edge。3. 在云上部署，只能通過LB提供服務(wù)，這是云產(chǎn)品的設(shè)計(jì)導(dǎo)致的，比如K8s的Service。除此之外，不應(yīng)該在Edge前面再掛其他的服務(wù)器，應(yīng)該直接由Edge提供服務(wù)。
SRS: Origin Cluster和Edge邊緣集群不同，SRS源站集群主要是為了解決源站擴(kuò)展能力：
? 如果有海量的流，比如1萬路流，那么單個(gè)源站是扛不住的，需要多個(gè)源站形成集群。? 解決源站的單點(diǎn)問題，比如多區(qū)域部署，出現(xiàn)問題時(shí)自動(dòng)切換到其他區(qū)域。? 切片協(xié)議的性能問題，由于寫入磁盤損耗性能較大，除了內(nèi)存盤，還可以用多個(gè)源站降低負(fù)載。SRS源站集群是不建議直接對(duì)外提供服務(wù)，而是依靠Edge對(duì)外服務(wù)，因?yàn)槭褂昧藘蓚€(gè)簡單的技術(shù)：
? 流發(fā)現(xiàn)：源站集群會(huì)訪問一個(gè)HTTP地址查詢流，默認(rèn)是配置為其他源站，也可以配置為一個(gè)專門的服務(wù)。? RTMP 302重定向，若發(fā)現(xiàn)流不在本源站，那么會(huì)定向到其他源站。Note: 其實(shí)Edge在回源前也可以先訪問流查詢服務(wù)，找到有流的源站后再發(fā)起連接。但是有可能流會(huì)切走，所以還是需要一個(gè)重新定位流的過程。
這個(gè)過程非常簡單，如下圖所示：
由于流始終只在一個(gè)源站上面，因此生成HLS切片時(shí)也會(huì)由一個(gè)源站生成，不需要做同步。一般使用共享存儲(chǔ)的方式，或者使用on_hls將切片發(fā)送到云存儲(chǔ)。
Note: 還有一種方式，使用雙流熱備，一般是兩個(gè)不同的流，在內(nèi)部實(shí)現(xiàn)備份。這種一般需要自己實(shí)現(xiàn)，而且對(duì)于HLS、SRT和WebRTC都很復(fù)雜，SRS沒有支持也不展開了。
從負(fù)載均衡角度看源站集群，實(shí)際上是調(diào)度器實(shí)現(xiàn)的負(fù)載均衡，比如Edge回源時(shí)若使用Round Robin，或者查詢專門的服務(wù)應(yīng)該往哪個(gè)源站推流，甚至當(dāng)源站的負(fù)載過高，可以主動(dòng)斷開流，讓流重推實(shí)現(xiàn)負(fù)載的重新均衡。
SRS: WebRTC CasecadeWebRTC的負(fù)載只在源站，而不存在邊緣的負(fù)載均衡，因?yàn)閃ebRTC的推流和觀看幾乎是對(duì)等的，而不是直播這種一對(duì)萬級(jí)別的不對(duì)等。換句話說，邊緣是為了解決海量觀看問題，而推流和觀看差不多時(shí)就不需要邊緣做負(fù)載均衡（直播可以用來做接入和跳轉(zhuǎn)）。
WebRTC由于沒有實(shí)現(xiàn)302跳轉(zhuǎn)，因此接入都沒有必要邊緣做負(fù)載均衡了。比如在一個(gè)Load Balance，也就是一個(gè)VIP后面有10臺(tái)SRS源站，返回給客戶端的都是同一個(gè)VIP，那么客戶端最終會(huì)落到哪個(gè)SRS源站呢？完全就是看Load Balance的策略，這時(shí)候并不能像直播一樣加一個(gè)邊緣實(shí)現(xiàn)RTMP 302的跳轉(zhuǎn)。
因此，WebRTC的負(fù)載均衡，就完全不是Edge能解決的，它本來就是依靠源站集群。一般在RTC中，這種叫做Casecade（級(jí)聯(lián)），也就是它們是平等關(guān)系，只是一級(jí)一級(jí)的路由一樣地連接起來，增加負(fù)載能力。如下圖所示：
這里和OriginCluster有本質(zhì)的不同，因?yàn)镺riginCluster之間并沒有媒體傳輸，而是使用RTMP 302讓Edge跳轉(zhuǎn)到指定的源站，因?yàn)樵凑镜呢?fù)載是可控的，它最多只有有限個(gè)Edge來回源取流。
而OriginCluster不適合WebRTC，因?yàn)榭蛻舳诵枰苯舆B接到源站，這時(shí)候源站的負(fù)載是不可控的。比如在100人的會(huì)議中，每個(gè)流會(huì)有100個(gè)人訂閱，這時(shí)候需要將每個(gè)用戶分散到不同的源站上，和每個(gè)源站建立連接，實(shí)現(xiàn)推流和獲取其他人的流。
Note: 這個(gè)例子很罕見，一般100人互動(dòng)的會(huì)議，會(huì)使用MCU模式，由服務(wù)器合并成一路流，或者選擇性的轉(zhuǎn)發(fā)幾路流，服務(wù)器內(nèi)部的邏輯是非常復(fù)雜的。
實(shí)際上考慮WebRTC的常用場景，就是一對(duì)一通話，基本上占了80%左右的比例。那么這時(shí)候每個(gè)人都推一路流，播放一路流，是屬于典型的流非常多的情況，那么用戶可以完全連接到一個(gè)就近的Origin，而一般用戶的地理位置并不相同，比如在不同的地區(qū)或國家，那么源站之間級(jí)聯(lián)，可以實(shí)現(xiàn)提高通話質(zhì)量的效果。
在源站級(jí)聯(lián)的結(jié)構(gòu)下，用戶接入使用DNS或HTTP DNS協(xié)議訪問HTTPS API，而在SDP中返回源站的IP，因此這就是一次負(fù)載均衡的機(jī)會(huì)，可以返回離用戶比較接近而且負(fù)載較低的源站。
此外，多個(gè)源站如何級(jí)聯(lián)，若大家地區(qū)差不多，可以調(diào)度到一臺(tái)源站避免級(jí)聯(lián)，這可以節(jié)約內(nèi)部的傳輸帶寬（在大量的同地區(qū)一對(duì)一通話時(shí)很值得優(yōu)化），同時(shí)也增加了負(fù)載的不可調(diào)度性，特別是它們會(huì)演變成一個(gè)多人會(huì)議。
因此，在會(huì)議中，區(qū)分一對(duì)一的會(huì)議，和多人會(huì)議，或者限制會(huì)議人數(shù)，對(duì)于負(fù)載均衡實(shí)際上是非常有幫助的。如果能提前知道這是一對(duì)一會(huì)議，那么就更容易調(diào)度和負(fù)載均衡。很可惜的是，產(chǎn)品經(jīng)理一般對(duì)這個(gè)不感興趣。
Remark: 特別說明，SRS的級(jí)聯(lián)功能還沒有實(shí)現(xiàn)，只是實(shí)現(xiàn)了原型，還沒有提交到開源倉庫。
TURN, ICE, QUIC, etc特別補(bǔ)充一下WebRTC相關(guān)的協(xié)議，比如TURN、ICE和QUIC等。
ICE其實(shí)不算一個(gè)傳輸協(xié)議，它更像是標(biāo)識(shí)協(xié)議，一般指Binding Request和Response，會(huì)在里面帶有IP和優(yōu)先級(jí)信息，來標(biāo)識(shí)地址和信道的信息，用于多條信道的選擇，比如4G和WiFi都很好時(shí)優(yōu)先選誰。還會(huì)用作會(huì)話的心跳，客戶端會(huì)一直發(fā)送這個(gè)消息。
因此ICE對(duì)于負(fù)載均衡沒有作用，但是它可以用來標(biāo)識(shí)會(huì)話，和QUIC的ConnectionID作用類似，因此在經(jīng)過Load Balance時(shí)可以起到識(shí)別會(huì)話的作用，特別是客戶端的網(wǎng)絡(luò)切換時(shí)。
而TURN協(xié)議其實(shí)是對(duì)Cloud Native非常不友好的協(xié)議，因?yàn)樗切枰峙湟幌盗械亩丝?，用端口來區(qū)分用戶，這種是在私有網(wǎng)絡(luò)中的做法，假設(shè)端口無限，而公有云上端口往往是受限的，比如需要經(jīng)過Load Balance這個(gè)系統(tǒng)時(shí)，端口就是有限的。
Note: 當(dāng)然TURN也可以復(fù)用一個(gè)端口，而不真正分配端口，這限制了不能使用TURN直接通信而是經(jīng)過SFU，所以對(duì)于SRS也沒有問題。
TURN的真正用處是降級(jí)到TCP協(xié)議，因?yàn)橛行┢髽I(yè)的防火墻不支持UDP，所以只能使用TCP，而客戶端需要使用TURN的TCP功能。當(dāng)然了，也可以直接使用TCP的host，比如mediasoup就已經(jīng)支持了，而SRS還沒有支持。
QUIC比較友好的是它的0RTT連接，也就是客戶端會(huì)緩存SSL的類似ticket的東西，可以跳過握手。對(duì)于負(fù)載均衡，QUIC更有效的是它有ConnectionID，那么經(jīng)過LoadBalance時(shí)，盡管客戶端改變了地址和網(wǎng)絡(luò)，Load Balance還是能知道后端哪個(gè)服務(wù)來處理它，當(dāng)然這其實(shí)讓服務(wù)器的負(fù)載更難以轉(zhuǎn)移了。
其實(shí)WebRTC這么復(fù)雜的一套協(xié)議和系統(tǒng)，講起來都是亂糟糟的，很糟心。由于100ms級(jí)別的延遲是硬指標(biāo)，所以必須使用UDP和一套復(fù)雜的擁塞控制協(xié)議，再加上安全和加密也是基本能力，也有人宣稱Cloud Native的RTC才是未來，引入了端口復(fù)用和負(fù)載均衡，以及長連接和重啟升級(jí)等問題，還有那改得天翻地覆的結(jié)構(gòu)，以及來攪局的HTTP3和QUIC……
或許對(duì)于WebRTC的負(fù)載均衡，有一句話是最適用的：世上無難事，只要肯放棄。
SRS: Prometheus Exporter所有負(fù)載均衡的前提，就是能知道負(fù)載，這依賴數(shù)據(jù)采集和計(jì)算。Prometheus(https://prometheus.io)就是做這個(gè)用的，它會(huì)不斷采集各種數(shù)據(jù)，按照它的一套規(guī)則，也可以計(jì)算這些數(shù)據(jù)，它本質(zhì)上就是一個(gè)時(shí)序數(shù)據(jù)庫。
系統(tǒng)負(fù)載，本質(zhì)上就是一系列的時(shí)序數(shù)據(jù)，會(huì)隨著時(shí)間變化。
比如，Prometheus有個(gè)node_exporter (https://github.com/prometheus/node_exporter)，它提供了主機(jī)節(jié)點(diǎn)的相關(guān)時(shí)序信息，比如CPU、磁盤、網(wǎng)絡(luò)、內(nèi)存等，這些信息就可以作為計(jì)算服務(wù)負(fù)載的依據(jù)。
每個(gè)應(yīng)用服務(wù)，也會(huì)有對(duì)應(yīng)的exporter，比如redis_exporter (https://github.com/oliver006/redis_exporter)采集Redis的負(fù)載數(shù)據(jù)，nginx-exporter(https://github.com/nginxinc/nginx-prometheus-exporter)采集Nginx的負(fù)載數(shù)據(jù)。
目前SRS還沒有實(shí)現(xiàn)自己的exporter，未來一定會(huì)實(shí)現(xiàn)，詳細(xì)請(qǐng)參考https://github.com/ossrs/srs/issues/2899。
以上就是關(guān)于雙流區(qū)個(gè)人如何申請(qǐng)pos機(jī),流媒體服務(wù)器如何實(shí)現(xiàn)負(fù)載均衡的知識(shí)，后面我們會(huì)繼續(xù)為大家整理關(guān)于雙流區(qū)個(gè)人如何申請(qǐng)pos機(jī)的知識(shí)，希望能夠幫助到大家！
