中國應用性能管理行業盛宴——2016中國應用性能管理大會(簡稱APMCon 2016)於8月18日至19日在北京新雲南皇冠假日酒店隆重召開。APMCon由聽雲、極客邦和InfoQ聯合主辦的作為國內APM領域最具影響力的技術大會，首次舉辦的APMCon以“驅動應用架構優化與創新”為主題，致力於推動APM在國內的成長與發展。
七牛雲首席佈道師何李石於基於雲架構的性能優化專場發表了題為《七牛直播雲性能優化實踐》的演講，現場解讀了七牛直播雲服務在各個環節性能監控和優化的實踐，包括服務端實時流網絡性能優化，客戶端編碼解碼效率和首開時間優化等內容。
以下為演講實錄：
大家下午好!我是來自七牛的何李石，今天跟大家分享一下直播相關的內容。我們七牛一開始是做存儲的，後來基於存儲我們做了分發，因為我們要讓客戶的文件能夠快速的上傳和下載。2014年年底我們接了一些監控攝像頭的服務，我們發現直播是未來一個比較常用的場景，然後我們就做了直播雲。從2014年年底到今年6月份，我們接到很多直播的客戶，經過這些驗證，在6月30號我們正式發佈了直播雲。因為今天是APM大會，我主要跟大家分享一下我們在性能方面是怎麼去做優化的。實際上直播對我們來說是一個完整的解決方案，所以優化應該是包括整個環節，包括推流端、網絡以及播放端。
我們先來看一下業務模型是什麼樣？最下面有一個推流端，中間是我們的實時流網絡，可以理解成CDN，但他的網絡架構和CDN不太一樣，最右邊是播放端，大家如果經常看直播接觸最多的是右邊這塊。中間是我們的實時流網絡，這些代表節點，這個線路代表一個流的流向，有調度服務節點，這樣子的基本業務模型構成了直播解決方案。我們做的事情包括所有這些，包括推流端推出去，到網絡的分發以及播放端。今天我分享的是性能相關的東西，性能實際上涉及到整個鏈路，包括推流端的性能、網絡性能、播放端的性能都會涉及到。
我們再來看一下它的內核，對於我們的客戶來說，我們提供的三個端的SDK都有，推流端SDK、實時流網絡SDK還有播放端，播放端就是跟解碼和播放相關的SDK。
這裡我們簡單講一下七牛相關的業務，一開始我們有一個存儲系統，為了加速用戶的分發以及上傳下載我們做了內容分發網絡，這是存儲和CDN相關的東西，後面我們做了通用的計算平臺，以及基於對象存儲上面做了數據處理平臺，以及現在做的大數據平臺。因為會有很多的圖片或音視頻，在這個基礎上做了一些深度學習，相當於對大數據進行處理的平臺。然後我們看直播，直播實際上是一個解決方案，它包含推流端SDK、播放端SDK以及直播雲，會對直播流進行處理，因為我們知道直播就是一個分發通道，對上面的內容進行處理，這些處理包括錄製回放、轉碼的處理還有內容識別。內容識別我們最常見的就是加速，加速是網絡的主要功能。然後基於這個可能還需要做一些運營相關的東西，比如說計費之類的。
對於我們的客戶或者直播的App開發者來說使用方式是這樣的，一般會有一個自己的App Server，這三塊SDK，推流端SDK、雲的SDK還有播放端的SDK這是我們剛才介紹的內容。App裡面除了Server端和DB之外，還可能需要實現跟業務相關的東西，比如說彈幕、道具、點贊等等，這些目前都是我們來實現的。
簡單介紹完七牛的直播業務模型之後，我們再來看一下我們目前做一個直播的產品遇到的挑戰以及關鍵指標有哪些。
對於終端用戶或者我們的開發者來說，他有幾個關鍵性的指標。首開時間，我們希望比如說你用映客的話就是一點就能開，最好控制在1秒以內。然後是累計延遲，比如我在這邊講的時候，有人在那邊看，他整個延遲時間不能超過3秒，最好是在1秒以內。昨天有人分享做1秒以內的延時，這也是可以做到的，今天還看到做到500毫秒以內的延遲，我待會兒會講為什麼我們不是這麼做的。另外就是低卡頓率，你要讓客戶非常流暢地觀看你的視頻，既使是碼率和分辨率不是太多。還有就是高可用，我們目前都是用豎狀CDN做到的，你的節點可以做到冗餘，我們這邊的網絡會不太一樣，一會會介紹。然後就是低成本，對於我們一個新的公司或者創業公司來說要自己做直播的話，他的成本實際上是非常重要的，我們不可能一下子就建一個非常大的CDN網絡去做這方面的事情，但是我們可以用一種更加低成本的方式去做到同樣高可靠、高可用以及性能、速度也能達到足夠好。
再來看一下我們的挑戰是什麼？一個是實時傳輸，我們知道所謂的直播實時性非常重要，主要體現在傳輸協議和網絡方面。另外就是他有海量的終端用戶，比如說上次運動員可能映客會說有2000萬用戶，瞬間來了非常多的用戶，就會造成一種驚群效應，什麼意思呢？就是說你這個節點裡瞬間來了非常非常多的用戶，可能導致你整個節點的所有用戶都擁堵了。還有一個是實時轉存，我們知道北京這邊有一個監管要求，要求把實時直播內容能夠存儲下來，保存一定的時間，這是需要有海量存儲支持的。然後是多屏多終端適配，這就更加明顯，比如我們每個人手機都不太一樣，或者電腦，對一個雲平臺來說他的要求就是能實時轉碼，在編碼和解碼方面做到比較好的兼容性。
我們先來看一下推流端，輸出之前需要經過採集、處理、編碼的過程。這裡面有一系列的Buffer，這些Buffer都是為了做好每個環節的控制。比如說採樣的控制，我們有一個視頻或者音頻的採樣率需要控制，如果採樣率太高的話可以採到比較清晰的音視頻，但是他的內容太多了，或者他對於硬件的要求很高。在採樣完成之後到處理環節，處理環節就是我們經常說的一些濾鏡、美顏、水印，我們一般會用GPU做處理。再到編碼環節，編碼在推出之前有一個Buffer控制編碼的效率，比如我在收到網絡反饋之前可能需要降碼、推流，降碼就是通過網絡的帶寬或者說網絡的質量反饋回來之後，可以實時調整編碼的碼率。還有一個是推流，昨天聽雲的人分享了一個客戶端的劫持，劫持在中國是非常嚴重的，即使沒有劫持，我們也可能對這個解析沒法控制，所以我們需要在智能網絡方面做一些特殊的調度，配合服務端去做。還有熱網情況下怎麼去優化它的推流的效率，我可能先丟失一些幀做推流。
除了這些編碼相關環節的優化之外，我們可能還有一個非常重要的模塊，就是QoS，質量的實時上報模塊。我們做到的是結合自己的模塊和第三方的，比如聽雲的質量調優和報警模塊做這個事情。我們給客戶會有一個SDK，他用SDK做的話我們就可以在這裡面做很多的事情，比如可以對他的節點進行實時監控，他的推流失敗次數以及卡頓次數，通過他推流的情況再結合調度，實時調整他的推流網絡。
還有一個非常重要的數據就是離線數據。我們光看實時數據只能對當前某個用戶的推流做調優，但對於整個網絡的呢？因為CDS或者我們的推流實時網絡是不斷演化的過程，我們需要通過一些彙總的數據來看，看它總體的卡頓次數、卡頓時長、卡頓率以及它平均推流時長，比如說一個主播平均推了多長時間才推出的，還有他整體的可用性。除了QoS模塊還有一個報障模塊，是說你可以查到你卡頓的原因，從App一直到SDK，因為他的App裡面肯定有我們的SDK，再到服務端，再整理出一個分析報告。
到這兒為止這些工作基本上把推流端相關的優化做的差不多了，這裡面只是比較宏觀的東西，細節還有很多，比如說編碼方面就非常多，都是非常專業領域的東西。
我們再看服務端，還是看剛才的網絡，先解釋一下這個網絡是怎麼樣的。這裡面表示一個收流節點可以通過一系列的線路轉發到另外一個節點，這裡面所有的節點都是對等的。這個圖表示一個流，實際上可以從這個節點到這個節點，只不過看哪個節點離用戶最近，這跟傳統的CDN節點還是不太一樣，這個節點可以進行收流、分流、轉發，或者我們後面講到的對流進行處理。先來看一下假設這是個收流節點，這裡面的這兩個都是用來做優化的，是離用戶最近的，這個流過來以後可以通過線路C直接到這裡面。這裡面是假設這個節點是壞掉的，這條線路就不能到了，它可以直接繞過去，雖然說延時會大一點。第二條線路也是這樣的，就是一個網狀的結構。這樣子就能做到整個網絡是去中心化的網絡，比如我們現在很多的海外用戶，有些做跨境電商購物的，我們要上海外節點就非常方便，他可以直接在日本或者新加坡上一個節點就可以了，可以通過CDN拉流到國內播。
然後是無狀態化，這是非常重要的。這裡面的節點只負責一些無狀態的事情，比如你收流過來之後我對你的流進行分發，如果這個節點壞了，我就再找一條線路，它不需要維持它的狀態，之所以不需要是因為實際上它是有一個多活的調度中心做這個事情，比如說它的線路哪條最優，哪個節點壞了可以實時上報到調度中心。
第三點是智能調度，智能傳輸就是它能夠在全局找一個當前最優的路徑，比如我們可以做一個5秒一次的探活以及數據的連接性，這裡面也有講到，通過我們自己的監控中心去做節點的探活以及連通性。還有一點非常重要的，就是一路流過來之後，比如說我在第一個節點到下一個節點，每經過一個節點都會統計增率FPS，看看當前的增率不是有下降了，一般碼率不會變化太大，但是增率可能會變大。這樣子實時的增率對能整個鏈路的質量進行監控，比如北京連接的客戶，說他卡了，我們知道他連的是哪一個邊緣節點，能知道這個流是從哪來，就能比較好的快速定位問題。彙總的數據也是這樣的，能通過彙總數據看到當前選的點是不是有效，因為在CDN的行業裡面選物理節點非常重要，我們可以通過一些異常的數據來儘快調整這些選點。
網絡講完之後，服務端還有一個重要的內容就是傳輸協議。我們看下目前常用的幾個傳輸協議有RTMP，能控制在1到3秒以內;然後是HLS能控制在10秒，可能會超過10秒，但是我們現在做到的大概是6到7秒以內，HLS是基於HTTP的協議;然後HTTP-FLV也是基於HTTP的協議，能做到基本上1到3秒內。
如果我們要求實時性，一般會選擇RTMP或者HTTP-FLV，能滿足互動性比較高的場景。但如果做得比較好的話，它們需要有播放性的支持，很難做成通用的，如果要做的話要對播放進行定製。HLS是比較通用的，因為他是基於HTTP協議，數據流的分發都是基於傳統的CDN，它是一個文件的切片，切成很小的片，再不斷的去更新他所有的文件，這樣子就對已有的CDN兼容性非常好，直接可以用已有的CDN的網絡，但是它是單向廣播的，互動性比較低，延時也相對比較大。
其實除了這些協議之外還可以定製協議，比如我們的RTMP是基於TCP的，可能會帶來一定的延遲，比如可以基於UDB來做，我們可以做到非常低的延遲，比如500毫秒。但是為什麼我們沒有這麼做？對於我們雲服務提供商來說，我覺得一個是我們自己去定製的話，協議是不夠健壯的。TCB或者UDB都是經過幾十年的時間經驗，我們再去定製，如果萬一以後有什麼問題我們可能需要不斷地填坑。另外，現在所有的無論是我們自己建的節點，或者是用第三方節點做分發都是基於HTTP協議。當你的用戶量不大的時候你可以自己定製協議，比如說場景不超過100人的教室直播的話你可以自己定製。但是如果你的用戶非常多，我們再去用一個自己定製的協議，這是非常危險的事情。所以這也是為什麼Facebook這種公司，他們可能在嘗試定製的協議，但是目前他們還是在用RTMB，雖然是很老的協議，但是兼容性非常好。無論是基於定製還是基於P2P做傳輸，實際上都是可行的，但是我們作為一個要對所有客戶負責的公司，可能不太適合現在去做定製。
在服務端還有另外一個重要的環節就是轉碼，這個圖裡面每個節點是對等的，你的數據過來之後在這裡面分發到下一個節點過程中，每個節點都可以進行轉碼。這張圖中我給了兩個轉碼節點，第一個轉碼節點是在收流的時候，第二個是在靠近用戶端的轉碼。
為什麼存在這兩種情況呢？對於RTMP來說，一個RTMP一般來說原始碼率不會小於末端碼率的，我一般不太可能把一個500K碼率的視頻轉成1M的視頻，所以如果是RTMP傳輸的話我可能只需要在收流節點轉好，之後在內部的轉發環節就可以降低他的轉發帶寬。如果是基於HLS播放的就可以在邊緣節點裡面去做，為什麼呢？因為如果是在這裡面轉好之後，他裡面傳輸的都是基於HTTP來傳輸效率就降低了，所以我靠近用戶端再轉就可以了，需要的時候再轉，這是我們做的一個優化。
為什麼我們能夠做到每個節點都可以進行轉碼呢？我剛才說到它是一個無狀態的節點，比如說轉碼它只是對文件進行處理的過程，不需要自己維持這些狀態，轉完之後把這個流分發到下一個節點就可以了。實際上現在有一些比較新的技術可以做到這些的，比如說基於Docker容器的虛擬化，我這裡面已經存入了轉碼的程序，你過來我直接在這裡面啟動就可以，也就是說這個節點裡面本身部了一個虛擬化的計算平臺，我直接可以秒級啟動這個程序，如果這裡資源不夠我可以把轉碼程序調度到另外一個節點，調度也是非常方便的。
對於存儲來說我們知道一個流需要對它進行存下來，可能會回看。在社交直播當中存下來的很少，但是為了監管需求也有需要保存下來的。但是在某些場景，比如教育直播，可能需要把一些精品講師的內容存下來回看，那就需要有一個實時轉碼或者存儲的需求，對存儲來說我們可以在靠近存儲的機房去轉，對於其他的我們可以根據需要來轉。這裡面從網絡、轉碼以及前面介紹的傳輸協議，基本上覆蓋了服務端的一些優化。
最後就是播放端，它是離用戶最近的，就是最後一公里。首先就是首開，用戶點進去之後能多快給到數據，首開延遲一般都會在服務端做一個緩存，數據到達客戶端能直接解碼，這個目前做到的是基於Flash的播放器，能做到0.5秒。如果消除累計延遲的話會有一個做播放控制的緩存，這個緩存對於首開延遲來說肯定越小越好，但是因為用戶的網絡可能不太一定，比如我在這裡面有Wi-Fi，出去之後就要用3G或4G了，特別是在網絡切換的時候差距比較大，就會有網絡抖動，我們為了消除這個網絡抖動帶來的影響，會在播放端做一些Buffer，這些Buffer會影響他的首開時間，很大的優化就是如何平衡這兩個Buffer的大小。還有一個就是丟幀，關鍵幀肯定不能丟，因為包含了視頻的全量信息，B幀是可以丟的，我們的一個優化是儘量在這個過程當中使用B幀，B幀雖然說壓縮效率是最高的，但是因為它其實是向後參考的，解碼的時候它不僅要參考前面那個幀，並且要參考後面過來的幀，也就是說這個數據過來到能正常播放可能需要等好幾幀才能播，所以會帶來比較大的延遲，除非是那種網絡非常好或者說解碼性能非常好的情況下，要不然其實不推薦用，直接可以把B幀去掉。然後另外一個優化就是自適應碼率，在自動播放的時候，比如優酷這種網站會自動幫你降碼率，可以做到自適應。
重點看一下基於HTTP的測試性碼率是怎麼做的。首先播放端發一個請求到服務端get一份數據，我們在服務端有兩種碼率的數據A和B，分別代表它的碼率是不一樣，我們會先把它切好存在服務端，然後根據你的客戶端的網絡來取，你要請求什麼樣的數據，然後再把它分發給你。
我們看一下，首先播放端向服務端發請求，然後服務端會把這個A碼率的數據通過HTTP傳到客戶端。這是一個非常簡單的模型，要做到這個樣子，其實服務端做的事情比較少，服務端把它切成多個碼率的視頻文件存下來就可以了。但是，在客戶端還需要做很多事情，我們來看一下客戶端需要做哪些事情？
首先它有一個帶寬預估模塊，就是當前用戶的帶寬多大，他能承受多大碼率的視頻拉取，然後通過這個預估結果去選擇相應的碼率，下一個片斷的碼率是多大，因為他經常能實時的調整當前用戶播放的碼率。選擇碼率之後再有下載調度模塊做調度，基於這個就能通過HTTP接口去服務端拉數據了，把數據拉給播放端去播放，然後可以根據它當前的播放效果再把數據反饋回去，比如說我拉一個片斷，拉過去花多少時間是可以計算的，然後再預估下一次能不能再拉這麼大的，或者說能不能拉更大的，這就是播放端自適應的原理，但是這個是基於HTTP的，其實RTMP也是類似的。有三大模塊去控制它的片段的拉取，另外一個就是通過實時的反饋去實時調整碼率，但前提是你服務端需要有存這麼多的數據，怎麼做到的？就是我剛才說的實時轉碼。
在播放端除了播放相關的模塊之外，還有跟推流端類似的QoS模塊，負責對播放過程中的性能進行監控，當然這個也可以基於第三方做，比如說聽雲的監控調優和報警。首先看有哪些東西呢？就是首開時間，我們能做到0.5秒，它是一個平均值，有些可能是0.1秒，有些可能超過1秒，這是有可能的。然後我們需要對這個進行篩選，再統計出來。然後播放的失敗次數，到底是進行推流失敗了導致不能播，還是因為用戶本身的網絡失敗了，用戶沒網的話這些數據不能上報回來。還有卡頓次數，播放過程中卡了多長時間，卡的次數多少，除了這個實時數據之外還有離線數據，看彙總的報告來綜合評估整個推流和播放的次數，其實主要是網絡的效果是怎麼樣的以及我們用戶的網絡分佈大致是怎麼樣的。
除了QoS模塊還有個報送模塊，這個是可選的，用戶在播報過程，我們可以把數據上報回來進行分析，無論是優化SDK還是網絡都是可以的。
閱讀更多 比特網 的文章
