愛奇藝直播 - 春晚直播業務API架構

小結：

一、服務熔斷策略   

在網關服務中常常會對後端不一樣api接口作服務聚合，好比A服務 -> B服務 -> C服務 ，若是C服務出現問題，那麼在調用C服務以前須要作熔斷。而在設計熔斷器的時候主要實現瞭如下三個狀態：

狀態	具體策略
Closed	熔斷器關閉狀態，若是服務調用失敗，則使失敗次數加1，失敗次數到了必定閾值或者必定比例，則啓動熔斷機制。
Open	熔斷器打開狀態，在該狀態下會對出錯的服務請求當即返回錯誤響應，同時設計了一個時鐘選項，默認的時鐘達到了必定時間（這個時間通常設置成平均故障處理時間，也就是MTTR），到了這個時間，進入半熔斷狀態。
Half-Open	容許定量的服務請求，若是調用在必定比例上都成功了則認爲已恢復，關閉熔斷器(重置失敗次數)，不然打開熔斷器。

二、提升單機併發承載能力

一級緩存local cache+二級分佈式緩存Redis

解決數據一致性的問題：

利用Redis Pub/Sub(發佈/訂閱)的特性以及設計合理的Redis key 來避免以上問題。
每一個業務機上有個後臺線程訂閱redis消息，若是計算中心更新Redis成功會publish消息，後臺線程收到Redis的消息會更新當前本地緩存，保證每次更新數據時用戶看到的數據都是相同的。

 

https://mp.weixin.qq.com/s/qts9huG0V91AfhRN4cts0Q

乾貨|愛奇藝直播 - 春晚直播業務API架構

原創： 愛奇藝直播團隊 愛奇藝技術產品團隊 3月15日

 

導讀

家人團聚共賞春晚，已經成爲國人歡度春節必不可少的慶祝方式。現在，愛奇藝春晚直播，成爲千千萬萬家庭同享這份歡樂的新途徑。根據以往的統計數據，春晚期間愛奇藝的訪問量是平時的數倍甚至是數十倍，不亞於12306春節搶票的「盛況」，這也給系統帶來了史無前例的訪問壓力。咱們在2019年直播中加入了個性化節目和互動元素，接口複雜度更高，團隊重點任務則是保障直播間信息、直播互動等後端直播內容流暢響應。除了春晚直播，像明星演唱會、綜藝節目等大型直播也是咱們重點服務對象。簡而言之咱們團隊提供的是大型直播業務API服務，咱們簡稱「QLive」。

大型直播每每帶來的就是大流量和高併發，而咱們的「QLive」也經受住了屢次業務洪峯的洗禮和考驗，下面是咱們團隊經歷過的一些大型直播。

 

 

  在春晚這種高併發的場景下，對「QLive」伸縮擴容和高可用具備較高的要求。而在互聯網分佈式架構設計中，爲了提升系統併發能力主要有兩種方法論：

方法/實施策略/優勢/缺點

垂直擴展/提高單機併發處理能力/節省機器採購成本/單機性能有極限

水平拓展/增長對應業務機或者存儲的服務器數量/機器資源足夠的話能線性提高併發能力/有必定的機器採購成本

 

咱們綜合考慮了這兩種方法，設計了多級緩存策略提高接口響應速度同時也提升了單機承載併發的上限，在應用層部署了雙機房從而線性增長了整個服務的併發承載能力。通過線上壓測，「QLive」目前承載40萬+的qps。

接下來具體看下「QLive」的總體架構，總體上分紅三層：

1. 接入層(業務中臺)： 

主要扮演的角色是負載均衡、降級、業務封裝、避免複雜性擴散，並且考慮到接入層位置的特殊性(物理上最接近用戶)，咱們部署了外網多機房，主要有如下兩個明顯的做用：

·  讓不一樣運營商的用戶以最短路徑接入系統。

·  避免因爲部分主幹網絡故障致使的單點故障。

2.應用層(雙機房架構)：

實現了機房隔離、服務隔離、熱點隔離等策略，提升了集羣可用性和水平擴展的靈活性。

3.基礎服務層：

運維平臺

·  監控報警：經過分鐘級報警感知、多維度監控圖表作到業務提早預警和故障快速定位。

·  CMDB：資源管理、依賴管理、流程規範。

·  發佈系統：管理代碼上線、審計、回滾等功能。

數據中心

·  計算中心：基於Quartz的分佈式任務調度系統，異步處理數據量大或者耗時長的業務。

·  Trace鏈路日誌：Agent無侵入式部署、快速定位代碼性能問題、可追溯的性能數據。

·  數據中心：前端PingBack、收集外網用戶故障造成閉環、實時生成數據報表。

接入層—業務中臺

接入層主要有兩部分組成：網關服務、業務中臺。爲了防止系統過載，在接入網關服務中加入了熔斷降級的策略，保證在極端狀況下部分核心服務是可用的。

       首先咱們須要明確熔斷和降級這兩種概念：服務熔斷通常是某個下游服務故障引發的；服務降級是總體服務壓力過大須要保護核心業務採起的一些降級策略。

服務熔斷：     

在網關服務中常常會對後端不一樣api接口作服務聚合，好比A服務 -> B服務 -> C服務 ，若是C服務出現問題，那麼在調用C服務以前須要作熔斷。而在設計熔斷器的時候主要實現瞭如下三個狀態：

狀態

具體策略

Closed

熔斷器關閉狀態，若是服務調用失敗，則使失敗次數加1，失敗次數到了必定閾值或者必定比例，則啓動熔斷機制。

Open

熔斷器打開狀態，在該狀態下會對出錯的服務請求當即返回錯誤響應，同時設計了一個時鐘選項，默認的時鐘達到了必定時間（這個時間通常設置成平均故障處理時間，也就是MTTR），到了這個時間，進入半熔斷狀態。

Half-Open

容許定量的服務請求，若是調用在必定比例上都成功了則認爲已恢復，關閉熔斷器(重置失敗次數)，不然打開熔斷器。

 

 

服務降級：

咱們主要使用了自動開關降級、人工開關降級這兩種策略。 

·  自動開關降級：根據系統負載、總體超時率、失敗次數等指標選擇對次要功能(好比視頻播放次數)作降級，降級後的處理方案有返回默認值、兜底數據、緩存等方案。

·  人工開關降級：經過監控報警發現線上一些服務存在問題，這個時候須要暫時將有問題的服務摘掉，好比某個緩存節點異常讀取不到數據 ；若是發現某些寫的服務調用量太大，若是不是強實時性，同步寫的方式能夠改爲異步緩解存儲壓力。

應用層—雙機房架構

       雙機房的主要技術挑戰是機房間的延時、數據同步的問題。

       1.機房延時問題：A城市的兩個核心機房延時大概在1ms內，可是A城市到B城市則可能有近30ms的延時，若是應用依賴的服務都跨機房訪問那麼性能會慘不忍睹。

       2.數據同步問題：若是MySQL、Redis等數據存儲須要作不一樣機房的數據同步，若是有幾十毫秒的延時，整個數據同步是很是大的挑戰。

3.解決方案：

·  同城機房部署，機房延時能夠忽略不計。

·  機房隔離，服務和服務之間，服務和資源之間使用智能DNS鏈接，儘可能保證服務不跨機房調用。

應用層—多級緩存

爲了提升單機併發承載能力，咱們設計了多級緩存架構，最終線上服務端核心接口平均響應耗時在10ms內。

·  主要技術挑戰：不一樣緩存之間數據一致性問題。

·  緩存中間件：一級緩存local cache+二級分佈式緩存Redis。

·  解決數據一致性的問題：利用Redis Pub/Sub(發佈/訂閱)的特性以及設計合理的Redis key 來避免以上問題。每一個業務機上有個後臺線程訂閱redis消息，若是計算中心更新Redis成功會publish消息，後臺線程收到Redis的消息會更新當前本地緩存，保證每次更新數據時用戶看到的數據都是相同的。

·  代理層緩存：用戶訪問量不少時候是沒法預期的，機器數量不變的狀況下，如何性能最大化是咱們常常思考的問題。上圖能夠看出主要併發壓力來自業務WebServer，直播節目有個特性，直播節目信息、流地址不會發生變化，一般只有在開播狀態變動和直播結束時間延後會更改直播信息。在實際實踐過程當中發現，能夠將核心節目接口功能上移到Nginx層，只有在配置中心加入緩存頭的節目纔會進行動態文件的緩存，保證緩存量控制極少的量，這樣能夠利用Nginx緩存文件優點，結合自身業務系統的特色，讓靜態緩存的靈活性和效率都能獲得保障。

 

基礎服務層—監控大屏

監控大屏主要分數據採集和圖表展現，數據採集流程以下：

·  flume Agent收集採集Nginx的訪問日誌。

·  多個Agent數據匯聚到同一個Agent。

·  Kafka做爲消息通道將數據存儲到Hive。

·  經過大數據平臺(babel)將不一樣緯度的數據彙總到業務mysql數據庫中。

·  監控大屏最終展現彙總數據。

展望

以上是愛奇藝直播團隊在大型直播場景下應對大流量高併發的一些思考，整個系統也通過了屢次大型直播的考驗，始終保持在低故障率，可用性作到了99.9999%。除了應對高流量，如何下降訪問鏈路、加快業務方對接、直播組件化也是目前探索的方向。