一、前言
首先分享出原文鏈接
http://www.infoq.com/cn/news/2017/09/streaming-Pipeline-kuaishou。自己平時並未用過快手，但是通過“宇宙中心”——五道口 快手巨大的LOGO以及 老家小伙伴的聊天內容來看，快手還是相當火爆的。雖然，直播這個技術看起來很簡單，但是能夠同時支撐百萬人的實時直播就需要很強的技術功力了。
二、博文整理
- 挑戰：通常情況下主播都是用手機，網速無法保證，如何保證觀眾觀看的流暢度
解決方案：實時監測主播手機網絡狀態，根據網絡狀態動態調整視頻碼率。因為視頻的錄制、編輯（美顏、水印等）、編碼壓縮等操作都是在主播手機上發生的，因此直播視頻的碼率還需要根據主播的手機配置（CPU，攝像頭像素等）調整，在保證直播流暢的前提下盡量的提升畫質。另一方面，就需要購買足夠的帶寬、CDN等資源了。
- 挑戰：主播和觀眾互動的時候，如果解決跨線路、CDN的數據不同步的問題（秒殺順序問題）
解決方案：主播的直播內容會推送到一個CDN源，然后這個CDN源將編碼后的視頻流分發到各個CDN廠商的服務器上，觀眾通過連接CDN廠商的服務器來獲取直播內容；在分發視頻源的過程中，需要保證各個CDN得到的視頻與直播信號的延時以及各個CDN之間傳輸的延時在一個可接受的范圍內（需要與每個CDN廠商協調），這樣才能保證不同地區的用戶同步（相差不大）看到直播。最好的方法是：自建CDN；
- 鏈路運行監控
解決方案：在直播端，統計主播手機的各個參數信息，直播過程中將手機CPU、內存、視頻幀率等信息上傳到監控中心；視頻向CDN源站推送的過程中，監測連接質量以及網絡延時。用戶播放端，統計DNS解析、網絡延時（從發送請求到收到應答包）、緩沖區大小（緩沖區越大，一次請求傳輸的數據越多，播放效果越流暢）。
從手機端統計到的監控數據會發送到監控中心的服務器，數據處理流程是：kafka作為可靠的消息隊列負責接收上報的統計數據，kafka中的數據可以被消費兩次，一次是用於實時處理展示（通過Flink從kafka消費數據並進行清洗，然后寫入到Elastic Search集群，利用Kibana實時展示Elastic Search中存儲的信息，存儲量小導致只能保存最近一段時間的數據），另一種是非實時的（Hadoop集群消費Kafka中的數據並進行對應的處理，將處理后的數據寫入Hive數據庫，實時性差但是存儲量大）主要用於存儲歷史數據供后期復盤分析使用。
- 監控數據分析、使用
解決方案：利用Elastic Search或者Hive中存儲的數據可以從兩個維度來進行分析展示：1、用戶體驗質量（QoE）：直播在線人數、直播跳出率等，通過分析這些數據以及相關的直播內容，可以推斷出這些指標的變化是直播內容（無聊、違規等）導致的還是技術原因導致的。利用這些監控指標，可以及時的處理一些違規直播內容或者找出產品存在的某些缺陷。2、服務質量（QoS）：純技術參數（如視頻幀率變化、直播延遲等問題），很多時候可以結合QoE來精確定位一些問題。
- 上線流程
解決方案：添加新模塊、bug修復等操作完成后，需要通過灰度驗證、AB測試的方式進行上線，上線前需要測試回滾流程以保證在灰度的過程中出現BUG可以很快的回滾到之前可用版本。（PS：阿里內部灰度步驟是：5% 10% %30 %50 %100，每個步驟之間通常會間隔4個小時左右，用以確認灰度效果）
- 開播跳幀優化
解決方案：通常情況下CDN直播服務器都會緩存一小部分內容（延時），一遍用戶在任何時候打開都可以立即獲取到內容。每個客戶端從CDN拉取的數據都會存到接收緩沖區，這個緩沖區只能接收一定長度的數據，而CDN服務器為了使直播盡量流暢，每次都會向用戶多發數據，如果超出緩沖區的長度，數據就會被丟棄，如果下次請求接收被丟棄的數據，直播延時就會進一步增大（觀眾無法參與互動），如果拉取新數據就會出現跳幀等情況，效果非常差。制定統一的發送數據長度與app上的接收緩沖區匹配，協調每個CDN廠商配合修改。另外還可以在客戶端播放時，通過提高播放幀數來加速播放，解決與直播相差加大的問題。
- DNS解析耗時過長
解決方案：通常情況下，用戶訪問一個互聯網資源DNS解析都是必須的，但是由於標准的DNS解析服務器沒有負載、延時監測，會造成后端DNS負載不均衡的情況，間接影響到了直播流暢度。采用app內置內部的DNS（改進后的）地址，來加快DNS解析速度，解決負載不均衡問題。
三、個人總結
整個分享的文章中，個人感覺最受益的是：
- 全鏈路監控以及監控數據可視化，這對於一個龐大的分布式系統來講是相當重要的。
- 大數據的運用，分析用戶的觀看行為可以對直播內容以及資源配置進行有針對性地優化，增加用戶粘性的同時降低資產成本。在這個互聯網時代，每個人都需要了解一些大數據的東西。
- 這一點是我自己想的，運用機器學習等現代方法對海量數據進行挖掘，找出一些有用的信息。
- 上線的整個過程需要認真學習，這都是經驗之談。
- 要么有錢（自建CDN），要么有人（運用技術解決CDN、DNS等問題）
上學的時候，寫過一個簡單的聊天工具，無界面、無認證的方式，當時覺得想要做出一款聊天軟件只需要加上界面以及登錄認證就可以了。工作后，接觸的東西多了，才發現同樣的一件事，並發100和並發100w有着天壤之別。任何一個小事被放大100w倍之后，都是很大的一件事。寫程序時，必須提前做好設計，考慮多種情況，然后嚴格測試、灰度上線、故障回滾。這些東西都是需要很深的技術、工程積累的。