徐立：今天跟大家講的主題是PLIL的直播云服務實踐。我跟別人有什么不一樣，我覺得有幾點，比較認真，我真的很認真。第二個，是有一個有產品的程序員，喜歡解決面對實際的問題，用具體的手段，解決一個非常具體的問題。今天這個主題分享是關于一群小伙伴們，經歷的實際問題。解決問題過程當中，形成一個新產品，這樣一個小故事。我們?yōu)槭裁磿鲞@樣一件事情，我們公司最早是做云基礎的，但是在大部分大家接觸的設施當中，用的協(xié)議，90%都是協(xié)議。我們遇到過比較特殊的，實際上就是我不想僅僅是通過上傳下載的方式，進行輸入和輸出，我希望更快的方式來產生輸入輸出，所以我們做了這樣一個事情。直播的特性，其實是面向成熟來講，增加了標準輸入和標準輸出。
直播的定義，它是指多媒體等數(shù)據(jù)，是以實時消息形式呈現(xiàn)給終端用戶的技術。常見我寫是這樣，廣告模型，有一個直播方，經過服務器，經過處理之后傳遞給終端，想看就是屏幕的分辨，或者是碼率。具體的協(xié)議層面來講，它其實比較混搭，輸入這一層，推到媒體器上之后，可以轉一些格式輸出。還有HGL、HGS這些更豐富的協(xié)議呈現(xiàn)給觀眾，這是一個非常簡單的模型。非常簡單的模型，有非常難的技術挑戰(zhàn)。本身來講，TMP是實時消息協(xié)議，就是一個長鏈接，它收到的每個數(shù)據(jù)包，轉發(fā)每個數(shù)據(jù)包，在整個網絡層次，它的好處，它的顏色非常低，我們比如說現(xiàn)在非常多，我現(xiàn)在在講，場外的觀眾是可以實時看到，這個基本上來講，就是走向一個趨勢。還有一種HLS，蘋果提出來一個技術，蘋果很認真，認真到你如果在蘋果手機上播放視頻，視頻文件超過多大，不允許你通過視頻方式進行點播，必須切片，就是下載的方式去進行點播。所以總得來講，可以用來做這種直播，但是顏色會更高一些。
這是一個更具體的對比，主要是跟平臺相關的，RTMP的技術，在PC端在移動端需要做一些移值，所以平臺上做移值。新舊的技術形態(tài)，直播的玩法比較高程度比較高，實施起來也比較困難。先讓自己用一套服務或者是服務器，這樣一個設施，其次還要購買這些商業(yè)的軟件，再組成一個集群。同時還要去搞定網絡的事情。這個其實本身來講，技術的方案角度來講，并沒有什么優(yōu)點，但是經濟上會覺得更加可控。實際上來講，這個是不言而喻。它的缺點也很明顯，我們現(xiàn)在互聯(lián)網的時代下，你的系統(tǒng)的附載，內網的很容易成為一個瓶頸，這是一個問題。另外一個問題，在移動端，你想有一些非常豐富的跟媒體的一些功能，但是如果就是說你用現(xiàn)有的路徑來搭，自定義一些工藤的定義。技術玩法用我們現(xiàn)在已經做好的成熟技術，對開發(fā)者來講，你只要用介入就可以方便，功能非常多，開發(fā)上面非?？?，用戶體驗非常好，從經濟層面角度來講，唯一缺點，是有新的嘗試，這個來講也不算什么。
這個是我們業(yè)務交互的邏輯。中間是我們服務的主體，上面AppServer，比如說一家互聯(lián)網公司要做，可能有服務器也可能有終端。如果要用一個手機去做一個直播怎么做，服務器會先跟我們產生一個交互，之后拿到一個授權，分發(fā)給它的代授權。它的主播直接到我們這一邊了。觀眾如果要看的時候，觀眾也是通過信息流，業(yè)務服務器，拿一個地址，拿到這個地址之后，這個播放頁直接在我們這邊產生直播的輸出，不同的碼率，等一些相關的參數(shù)。
其實對我們來講，就通了，但是從使用方角度來講，它要做的事情要輕松，輕松的一個層面，它只需要一個代碼就賦予了直播的功能。對它還來講是一個純透明的，多快好省，其次它跟我們的存儲，它可以回放、點播，轉成其他的格式提供下載。這個也是存儲?；谖覀冞@個存儲，優(yōu)勢來講，有一些技術上的紅利。比如像我們剛才講的存檔，云端錄制、轉碼、轉存、下載，還有視頻的提示轉碼，現(xiàn)在是播頻，手機有不同的屏，經過不同的分辨率的情況下，需要轉一下分辨率轉一下格式。還有一個，像食品抽幀，截圖，還有一些跟七?，F(xiàn)有API組合復用，這是什么意思，你可以把上一個輸出和下一個輸入連接起來，這是一個哲學。我們系統(tǒng)哲學，非常了解這一塊，在這一點上，我們現(xiàn)有的和新的產品也是可以組合起來復用，還有我們昨天發(fā)布了，發(fā)現(xiàn)功能，很有限的情況下做一些處理，是一個擴展，功能性自定義的擴展。它的想像空間非常大，在業(yè)務需求的滿意情況下，只你想不到，沒有你做不到的事。
這是它比較卡通的一張圖，解釋它有哪些模塊，有轉碼的還有存儲，有加速的，有打刀的。
具體我們現(xiàn)在做這個服務，它已經解決哪些問題，或者說它已經開始解決一些場景化的問題。首先來講，這個其實是非常普遍的，電臺直播，可能大家日常生活中會聽到很多，包括在手機上聽到很多你在用音頻，包括像一些網絡電臺，這是最直接的網絡直播。還有教學直播，這個問題也是可以覆蓋，到用戶端。還有這種新鮮的，監(jiān)控直播，有代表的，你可以在你手機上去看你家里，或者哪里的攝像頭，可以看到那邊實施的狀態(tài)。還有一種現(xiàn)場直播，像我們今天這個活動，這個現(xiàn)場就是一個直播，這也是英文的場景。還有游戲直播，這個也是現(xiàn)在互聯(lián)網領域里面，互動娛樂里面最火的一個就是游戲直播，手游的游戲直播。還有我們剛才提到的手機直播，大家的社交方向是這樣，所有有很多移動互聯(lián)網公司，從一片做的圖片，社交，后來轉視頻的社交，發(fā)現(xiàn)沒有太好的玩法之后，誕生一種新的玩法，就是手機直播的方式，隨時隨地拍直播，這里面我們提供了一個相應的手機直播，可以方便開發(fā)者很快用這樣一個功能。還有一種場景，可穿戴設備，相機，里面可以裝我們的直播的CDK，可以打通。
它的產品是怎樣的？我們自己是開發(fā)者，我們是做在那邊開發(fā)這個服務，某種程度上是非常懂開發(fā)者的需求，產品形象是這樣，服務器服務的意思。如果你要用真的就是代碼進來，整個環(huán)節(jié)就打通了，并且在播控管理這塊更加透明和開放。具體從技術的角度而言，直播數(shù)據(jù)是什么性質的數(shù)據(jù)，有什么不同和相同的地方？比如像直播的網絡4跟成熟的網絡還不太一樣，成熟網絡本身來講不是傳數(shù)據(jù)只是分發(fā)數(shù)據(jù)，數(shù)據(jù)本身，這個是有點不一樣的地方。最典型的一個代表，延遲Delay。比如無線在做直播，場外要過多少分鐘才能看到，所以延遲這塊的要求非常高，延遲穩(wěn)定的網絡情況下，發(fā)送和接收的時間差，中間轉發(fā)環(huán)節(jié)越多，延遲越大，這是網絡層面的。
這個延遲可具體計算，這是一個簡單的表，是關于延遲的對比，我覺得還是非常敏感，大家覺得世界最敏感的生物可能是你們，但比你們最敏感是程序員。當你的系統(tǒng)實現(xiàn)的時候，你會需要用毫秒去度量一個東西，毫秒的概念一秒是一千毫秒，大家看到這個屏幕，你的差是40毫秒，根據(jù)愛因斯坦的定論，這實際從基礎物理上限定了網絡分子在進行這個過程中最高速率，比較可觀非?？?，每秒有30萬公里，這僅僅只是在真空中的傳輸速度。我們現(xiàn)在網絡實際上有物理這一層，或者介質，通過了這個介質之后有一定的折射力，比如像光纖，每秒可以傳20萬公里，這個算下來，從紐約到北美或者到倫敦或者整個地球跑一圈，它的延遲還是非常低，最多一次傳遞200毫秒，往返一次在400毫秒一秒之內就完成。
信息科技帶來不一樣的地方，有非常大的價值。
我們剛才講的是物理延遲，一般很難區(qū)分你幾秒延遲會怎么樣。你的手機你將會延遲300毫米，如果有請求，刷一個圖片，刷你的朋友圈，這個時候明顯會感覺到你的圖片在上傳，這個時候跟這個延遲有非常大的關系。為什么？我們今天所有應用都是構建在這一層，它的普及在90%甚至95%以上，我們剛才講的直播，其實也是GET，它的好處在不可靠的傳輸面上實現(xiàn)了一種可靠的傳輸?shù)姆绞?，它典型就是這樣，每一次傳的過程中，要經過這個過程，數(shù)據(jù)報往返過程，都會把往返延遲加進去。實際上大家可以很容易發(fā)現(xiàn)，如果短鏈接請求的話，復用長鏈接，這樣的話可以提高。
還有一個關鍵難點，是在抖動，就是網絡突然抖了一下，這個時候從角度來講，數(shù)據(jù)包是會重傳，這實際上也會延遲。它會可控，非常精細這是一件非常困難的事。在傳輸速度這塊，因為跟主播方跟觀眾是一個雙邊，有一個播放那端，另一邊如果網絡卡了，全局播放卡里，會受到全局的影響，卡了只是一個局部的影響。這里面你想作到高品質的數(shù)字，這實際上也是非常難。剛才講直播整個網絡都是在傳數(shù)據(jù)，而且看上去的方式，就是每個數(shù)據(jù)包的經過，經過的延遲會多大性能上的損耗。
這個是我們嘗試之后，把我們架構進行改版。最早是這樣的架構，前面有后面有一堆進行處理。這種方式有什么問題？其實也有問題，問題在于它專發(fā)郵件過多的時候，每一個都是要經過，在這種情況下如果你在進行轉發(fā)，意味著你的開銷存在增長。這樣會帶來，內部本身的延遲，實際上來講還有一個不好的地方。后來我們最近一個架構的改版，其實把前端這些把內部的轉換邏輯去掉了。它盡量如果過了一幕，就不在內幕有一個補充，產生一些大的性能上的開銷，這樣來講它的好處變得更加快了，在性能上更加優(yōu)異。
第二個很快網絡相關，最早的模型終端在我們這，再通過邊緣網絡分發(fā)，回到我們的集群。后來我們又進行了一個改版，推到我們這，邊緣上進行廣播。這樣來講，整個頁面少有一些非常麻煩的環(huán)節(jié)。還有一個，終端是多種多樣，對輸出格式也是多追多樣多樣化的需求，有一種方式，是在更新，做轉協(xié)議，再傳遞到邊緣。這樣的話，你在中心轉多種格式之后，再轉到邊緣網絡帶寬也是非常擁擠的。這種情況下，你直接在節(jié)點之間直接通過實施協(xié)議，到節(jié)點之后在這個過程中處理，再產生輸出。這樣來講，沒有那么用度，在邊緣進行一個輸出的話，轉發(fā)樞紐的話，對用戶更好。
另外一個經驗值得分享是在多核時代，這個延續(xù)就是屬于現(xiàn)在的傳統(tǒng)。有這套服務器，這兩個對比這個多，就只有兩點，過去這種C語言按照內存編程的，內存會有大量的操作，包括安全鎖這些東西，尤其是這些編程的時候非常復雜，但是在這里面，包括內存這塊已經做得非常好。但是它在整個語言層面上由于田園的支撐，這樣來講的話，在你編寫比較復雜的業(yè)務邏輯的時候，可以起到一個非常好的幫助你去理解業(yè)務的編程。
所以就是說，PLIL這個東西，延續(xù)了我們的傳統(tǒng)，我們最早是發(fā)布1.0的時候，就做了一個大規(guī)模的存儲，它的可靠性是16個9，現(xiàn)在是11個9，我們在做另外一個產品的時候，都是這樣，如果要做一個高的，也基本上是用G語言實現(xiàn)，做這個產品我們也是用Go語言實現(xiàn)企業(yè)級的直播云服務。這也是我們覺得比較有挑戰(zhàn)的地方，因為我們在做這件事情當中，我們用了大量的文檔，就是數(shù)據(jù)結構的定義，到邏輯的描述全部都參照了一遍，那些穩(wěn)當都是幾十頁、上百頁，按照那個標準進行一個實現(xiàn)，這里面的挑戰(zhàn)非常大的。在整個社區(qū)找不到這個媒體跟媒體處理，你都找不到。我們去做這些哥倫布編碼的時候，有時候還要直接去看英文，這里面遇到的挑戰(zhàn)非常大。
另外一個，我們剛才講，我們是程序員，我們做這件事情也非常特別，我們的工作方式也特別，我們不在一塊，分布在全國各地，是一種協(xié)同的方式，我們講P2P多殼的方式，但是遵照P2P在網絡概念里面是一種節(jié)奏，每個節(jié)點在P2P這個網絡有這個網絡的情況下，可以發(fā)揮它自己更大的作用。如果這個網絡一旦丟失，個體其實不復存在，對應到團隊管理當中，每個人在職級上就像平級的。但是有了存在，個人的價值可以更大，可以被放大，但是如果這個團隊丟失，個體的價值也會非常微弱。
所以說，我們在做這樣一個事情的時候，我們也進行了一些新的嘗試，在工作方式的嘗試，這個嘗試現(xiàn)在運行下來，到這個產品現(xiàn)在，已經做出來，成功的一次嘗試。我們目前也在交替一些東西，這個有我們工程主頁，大家有興趣可以看一下，覺得我們這件事情有意義，也可以加入我們這樣一個團隊。謝謝大家！
