新浪微博:大规模离线视频处理系统的架构设计
生活随笔
收集整理的這篇文章主要介紹了
新浪微博:大规模离线视频处理系统的架构设计
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
微博視頻平臺在4億月活用戶吃瓜嗨聊的高并發、大流量背景下,既要保證用戶微博生產和消費體驗,又要支持業務快速迭代,確保正確性、穩定性和高可用性。本次演將以微博視頻大規模視頻離線處理系統的架構設計為主題為大家帶來大規模分布式系統的架構設計,性能優化和高可用保障等一線實戰經驗。
文 / 霍東海整理 / LiveVideoStack大家好,我是來自新浪微博視頻平臺和微博平臺研發部的架構師霍東海,從2017年加入微博,目前在微博視頻平臺負責微博視頻離線處理系統架構等相關工作,包括大規模離線微服務系統的架構設計和服務保障體系的建設等。近期專注于視頻平臺技術體系的提升對用戶體驗提升的幫助,主導構建了微博SVE(Streaming Video Engine)系統,支持大并發場景下對視頻進行并行轉碼,大幅度提升轉碼效率。
1. 背景介紹微博本身有大并發、大流量的特性,有4億+的月活,同時微博也是一個開放平臺,支持多種第三方分享,每天都會有百萬視頻分享需進行處理。
微博視頻業務大概分兩種業余形態,一個如左圖所示,是豎版的短視頻分享,另一個是如右圖所示的稍微長一點的橫向播放的短視頻。微博視頻還有一些特殊的場景,例如在微博PC端點視頻按鈕會跳轉到酷燃網,它是一個5到15分鐘的短小綜藝類視頻分享的網站,如圖中,下面都是一些優酷,愛奇藝,騰訊等視頻網站分享到微博的視頻。我們微博視頻團隊面臨的業務場景是及其復雜的,我們要在復雜的場景下解決視頻處理的問題。如圖中,我們有微博視頻,酷燃視頻,付費視頻,微博故事,秒拍,以及通過開放平臺接入的視頻分享網站,微博在最上層會接入極其多的業務方。中間會引入業務調度中心,即業務調度層,對上層業務進行調度。另外是數據同步,所有的視頻呈現在微博都是博文的形式,始終是需要和我們自己的系統進行交互的。業務調度層的另外一個作用就是對視頻內容進行分析。往下一層是文件存儲,媒體庫層。文件存儲包括文件上傳,文件存儲方面等的問題。媒體庫是視頻對象的源信息,如視頻分辨率URL,視頻長寬,用戶ID,博文內容等信息存儲。最下層是轉碼服務。我們重點介紹的就是轉碼服務在微博場景下的思考。
2. 微博視頻轉碼服務架構與挑戰2.1 視頻處理系統傳統架構在講微博面臨的問題之前,先來了解一下視頻處理系統的傳統架構。例如,某一用戶在PC端或手機端有一個1080p,5Mbps的視頻需要上傳。在傳統的架構中,會先將文件傳到文件上傳服務,文件上傳服務將其傳到底層存儲。傳到存儲后,文件上傳服務會告知轉碼服務文件需進行轉碼。轉碼時轉碼服務通過調度器將轉碼任務傳到對應的轉碼集群中的轉碼服務器。真正轉碼的機器,從存儲中下載用戶上傳的源文件,轉換成特定格式后回存到存儲中。2.2 微博視頻轉碼服務 – 業務繁雜對微博視頻而言,我們有非常繁雜的業務,例如業務方會有不同的水印,一些用戶會對自己的視頻有特殊要求,另外系統要能滿足線上驗證優化轉碼算法的需求,再加上轉碼服務本身會提供抽幀等基礎服務,要使這些融合在一起快速方便的支持業務方的需求,我們面臨很大的挑戰。2.3 微博視頻轉碼服務 – 提速優化另外,在優化視頻基礎體驗的時候,我們會提出并行上傳來提高用戶上傳成功率,做類似斷點續傳的功能,我們還會做并行轉碼完成云廠商提出的分片轉碼。甚至我們做到了用戶邊轉邊存,使視頻在用戶手機端完成分片,一邊分片一邊上傳,上傳的同時后臺進行轉碼,上傳完成的同時,轉碼即可完成,最后合并視頻完成發送。這極大的提高了用戶上傳視頻到發布微博這一過程的體驗。
提速優化舉例第一個是順序上傳。現在順序上傳的過程一般是二進制切片,切片后依次上傳,整個系統延遲會比較長,做并行上傳時,例如兩個進程同時上傳,會比順序上傳提速一倍。在做并行轉碼時,相當于把視頻做成二進制分片上傳后,合并起來進行轉碼。轉碼時再將視頻切分成不同時長的片段進行分片轉碼,完成后合并視頻。這種方式下通過提高并行程度降低了延時。在邊傳邊轉方式下,客戶端上傳存儲后,馬上進行轉碼,客戶端操作與服務端服務并行,最后服務端會將源視頻、目標視頻分別合并。2.4 微博視頻處理系統面臨的挑戰我們面對業務繁雜,需進行基礎服務優化的雙重挑戰。另外,微博業務具有很強的實時性,這就要求我們每環節都得快速完成,包括我們實現代碼的時間,接入業務方上線的時間。我們必須實現一個低延時、高并發、高可用、高性能的視頻轉碼服務。視頻轉碼服務本身需要大量計算,需要大規模的集群支持這項服務。我們面臨的另外一個挑戰就是對大量集群的管理。由于我們使用了分片轉碼,邊傳邊轉的優化方式,一個視頻切成十片,轉碼量會變成十倍,這導致轉碼任務量陡增,同時也會產生一個更細粒度的調度。切片給我們帶來更加復雜的任務依賴關系,我們要管理切片、分片并行轉碼以及合并整個過程中的任務依賴。過程中步驟越多,失敗率越高,越要求系統有更高的健壯性降低失敗。我們今天主要講的就是如何實現一個低延時、高并發、高可用、高性能的系統,我將主要從以下幾個方面來說明。首先是高度靈活的配置生成系統,相當于將業務相關的東西從主系統中抽離放到配置系統中,使主系統專注于基礎性能優化和基礎服務。第二點要講的是基于DAG的邏輯組織框架即用工作流引擎去組織任務之間的依賴。最后會講一下高可用、高性能的任務調度器對系統的重要作用。3. 微博視頻轉碼服務架構設計3.1 木林森高度靈活的配置生成系統
對于靈活配置,我們取名為木林森。它是一個基于樹形結構的規則引擎,即我們的配置結果都是樹形結構,多棵樹即可組成森林,所以我們取名為木林森。木林森支持靈活的配置生成。微博有些業務場景下產品方只要求快速而不在意視頻輸出屬性,這時我們可以直接使現有輸出業務與輸入業務連接完成業務接入。用這種方式可以提升新業務接入效率。下面是一個簡單的示例。
如圖,例如我們有微博原生視頻接入業務,現在要接入的億幕視頻希望與原生視頻有相同的輸出。此時我們在輸出業務以下到轉碼輸出都不需要改變,我們只需要將節點連接,輸入的億幕視頻就與微博原生視頻有了相同的輸出。只需通過后臺點擊配置就可將視頻接入。右圖所示是微博視頻的輸出配置。
復雜場景下,原生視頻,秒拍視頻,VIP視頻的輸出業務配置如圖。不同用戶端視頻經過系統輸出的視頻是不同的。通過配置可完成復雜場景下的業務邏輯抽離。3.2 DAG基于DAG的邏輯組織框架
我們自己實現了一套工作流引擎框架來支撐我們的業務,首先介紹一下框架的思想。我們是基于Java開發的,這里用Java舉例。對于一般的上傳系統,代碼實現只有下載、轉碼、上傳的過程。在這一段代碼的基礎上,我們要實現分片轉碼,邊傳邊轉等復雜的邏輯流。最簡單的方法就是我們將一般上傳的代碼復制改動,這時我們的方式如右圖。上傳過程變為下載,切片,將切片結果上傳,下載切片,切片轉碼,上傳切片,然后使這個過程循環往復,這時可多臺機器并行工作,最后將切片合并。由于過程復雜,所有我們希望能用有向無環圖連接組織,將基礎服務固化,通過腳本將不同功能組織起來。這時我們無論下載文件轉碼上傳還是分片上傳,只需簡單連接即可,兩個下載之間的代碼是不需要改動的。我們將可固化的部分固化,將代碼拆成一個個可獨立執行的閉包,通過DAG管理包與包之間的關系,在DAG內部實現閉包的執行。這就是我們關于DAG框架的想法。這是我們轉碼服務的圖示。如圖中,Center部分就是中央調度的服務,Runner部分是執行轉碼任務的服務,videoTrans是DAG組織任務間關系的腳本。我們的腳本通過Groovy實現。框架名字叫做Olympiadane,是通過Groovy引擎執行連成的關系,其中的Group是可獨立調度的單位,即圖中白色的部分。任務先經過調度器,調度器根據情況分發到執行器,執行器內部根據前后依賴關系順序執行Task,在此例中就是下載,轉碼,上傳。另一臺機器也是一樣的。這樣就實現了執行流與業務之間的解耦,如果要接入其他的新服務的話,我們只需要再實現一個Task,將此Task的依賴關系放入腳本即可完成。另外通過腳本生成的就是圖中的Job。這是我們DAG架構。實現DAG框架后,可以通過腳本快速接入支持業務,由于腳本變動但Feature不是經常變動的,所以Feature可在腳本間共用,也可以獨立測試,這樣我們便可以完成可組裝的獨立組件。這些獨立組件具備可以獨立測試,易擴展,易部署,高性能的特性。這里描述的是DAG的過程。前面我們提到的分片轉碼,過程分是下載,切片,上傳分片結果幾步。例如有三個機器同時并行完成下載分片,轉碼,上傳結果的工作。當并行過程結束后,會有一個新的依賴關系,如圖中,下載所有分片,合并轉碼后的視頻,不同清晰度的文件都是在不同機器上并行工作的。這是對我們轉碼服務優化中,通過DAG組織的一次實踐。如圖中,灰色的部分變成了綠色,這表示這個過程是可以觀測的,這也是通過DAG方式實現的一個優勢。我們可以觀測任務執行到了哪一步,也可以更快的定位出現問題的地方。另外,由于我們進行了拆分,可以對獨立Feature進行DAG切面,例如我們可以統計它的耗時,這樣我們可以知道哪種類型的業務耗時較長,也有助于觀察系統的穩定性。在DAG的優化方面,我們通過字節碼編譯技術做到了腳本快速執行。另外我們引入了一些Protostuff技術快速完成資源存儲。3.3 調度器
高可用、高性能的任務調度器
我們通過木林森將業務系統抽離出來,通過DAG系統將實現時的依賴關系抽離,因此我們需要一個好的調度系統來支撐。由于我們進行了切片,因此調度任務達到了萬次每秒。我們也會需要更細粒度的調度任務,比起粗粒度的調度,對基礎組件性能要求更高。我們對調度器的另外一個設計目標就是調度占比要低于百分之五,這就意味著系統損耗更低。這對調度器有極高要求,我們要使百分之九十九的調度任務在10ms內分派到對應機器,并且我們希望它的調度是最優調度,即能準確把任務分派到空閑機器。在設計調度器時我們也做了一些思考。我們對中心化調度器和非中心化調度器做了對比。中心化調度器的調度準確度高,它將資源隊列信息放到中心化存儲中,對監控更親和。但是它的資源依賴較多,我們將隊列放到了資源中,因此資源訪問讀寫中會產生一定依賴,也會有一定性能損耗。對于去中心化調度器來說,它的擴展性更強,但是它存在調度不準確的問題。最終我們選擇了中心化調度方式。
上圖是調度器調度過程。左邊是調度器,右邊是執行器。調度器和執行器之間通過心跳注冊,心跳時間是可配置的。注冊完后會將機器信息放到機器隊列,中心資源中有一個任務優先級隊列,我們可以對不同任務映射不同優先級。另外一個是機器空閑優先級隊列,就是我們將機器空閑度映射為優先級。在派發時,我們會取到高優先級任務,取到空閑度優先級高的執行器,然后將任務派到指定機器,即可將任務放到執行隊列中。執行隊列的重要作用在后面會講到。執行結束后,會進行一次回調,從執行隊列中移除任務。我們通過三個隊列完成任務調度,由于存在資源依賴,所以我們對這些資源進行了哈希計算,不同機器可以使用不同資源,只要資源滿足就可分派任務。但是這里會有一個問題。心跳會匯報情況,但它會有一定延遲,如果Executor與資源中存儲的狀態產生差異,任務可能會被分派到一臺無法工作的機器。為解決此問題,我們設計了一個帶鎖的雙發調度。與之前介紹的相同,我們依然從隊列選擇機器。不同的是,我們會在空閑優先級隊列中取到最優的同時,取一個隨機機器去完成分派。分派后,執行器會再一次調用調度器確認由誰完成任務,再去執行。當最優任務不可執行時,另外一個機器可完成任務。這樣,我們就可以實現百分之九十九的任務在10毫秒內完成分派的目的。同樣的,帶鎖雙發調度也會有哈希計算的存在。同時,我們會使用WatchDog觀察執行隊列中的任務是否在規定時間完成,若沒有完成,我們會重新觸發調度器分派任務。這樣我們可以有效減慢失敗率提升。通過以上設計,我們的調度器可以實現毫秒級派發。對于微博業務來說,可能會出現緊急大流量出現,我們在設計時也考慮了水平伸縮方式,使它支持彈性擴縮容。通過WatchDog機制,我們可以實現宕機自動摘除。在實際應用中,我們每天都會有機器擴縮容,我們的做法是讓待擴容機器不接受任務,先完成已有任務,再做機器擴縮容工作。但這樣做還會有未完成的任務存在,通過WatchDog機制,我們可以確保這些任務重新分派完成。同時我們實現了4個9可用性。3.4 部署
在轉碼服務部署方面,我們在兩個IDC部署了完全相同的兩套資源,它們有獨立的域名,獨立的部署。這么做的好處是我們可以在兩個機房間隨意的切流量,任一機房出現問題,我們都可以切換,但是兩個機房的部署并不是一比一的冗余。我們常備的機房是一個大規模集群,另一個機房是一個小規模的,或許只有常備機房十分之一的量。兩個機房在使用時可以分開,例如我們轉一些不影響用戶發博的轉碼輸出時,可以使用小機房完成任務,這樣大機房出現“災難性”情況時,可以把流量切到小機房。當然小機房是不能滿足那么大流量的,但是調度器本身的隊列有堆積的特性,可以將堆積的任務慢慢執行。沒有大量機器冗余可以充分利用機器。4. 總結接下來,我將所有內容做一個總結。通過轉碼服務的優化提升,我們整體轉碼提速了5倍,集群利用率標準差下降了百分之五十。這里的標準差指由于分派任務不合理,分到不同清閑度的任務導致機器CPU利用率忽高忽低的情況。通過好的調度方式,對集群的利用率標準差有很大降低。另外,我們業務支撐的效率也成倍提升。我們通過各種方式進行解耦,將變化大的和變化小的分開放到不同位置。
在服務架構設計開發的過程中,我們使用了很多并行手段,包括機器并行、進程并行、線程的并行以及算法、CPU核的并行等,通過這些手段發揮機器最大的價值。今天我們設計的目的是一個低延時高可用的系統,我們用到的并行上傳,并行轉碼,極致上傳等手段都用了算法上分治、遞歸、貪心的思想。在高可用方面使用了高內聚低耦合的思想,用到了動靜分離、自動容錯、異地多活的手段。最后想和大家分享,我們在做系統架構、設計優化不知道該如何實現的時候,就可以無腦的把這些高內聚低耦合、空間換時間等常見的思想往系統上套,或許就可以得到想要的結果。優化架構并不是多么復雜深奧的東西,我們要去思考的是前人總結的這些手段在我們自己系統上的能否達到效果,如果得到了滿意的效果,那么這些思想就會轉化為我們自己的東西。
文 / 霍東海整理 / LiveVideoStack大家好,我是來自新浪微博視頻平臺和微博平臺研發部的架構師霍東海,從2017年加入微博,目前在微博視頻平臺負責微博視頻離線處理系統架構等相關工作,包括大規模離線微服務系統的架構設計和服務保障體系的建設等。近期專注于視頻平臺技術體系的提升對用戶體驗提升的幫助,主導構建了微博SVE(Streaming Video Engine)系統,支持大并發場景下對視頻進行并行轉碼,大幅度提升轉碼效率。
1. 背景介紹微博本身有大并發、大流量的特性,有4億+的月活,同時微博也是一個開放平臺,支持多種第三方分享,每天都會有百萬視頻分享需進行處理。
微博視頻業務大概分兩種業余形態,一個如左圖所示,是豎版的短視頻分享,另一個是如右圖所示的稍微長一點的橫向播放的短視頻。微博視頻還有一些特殊的場景,例如在微博PC端點視頻按鈕會跳轉到酷燃網,它是一個5到15分鐘的短小綜藝類視頻分享的網站,如圖中,下面都是一些優酷,愛奇藝,騰訊等視頻網站分享到微博的視頻。我們微博視頻團隊面臨的業務場景是及其復雜的,我們要在復雜的場景下解決視頻處理的問題。如圖中,我們有微博視頻,酷燃視頻,付費視頻,微博故事,秒拍,以及通過開放平臺接入的視頻分享網站,微博在最上層會接入極其多的業務方。中間會引入業務調度中心,即業務調度層,對上層業務進行調度。另外是數據同步,所有的視頻呈現在微博都是博文的形式,始終是需要和我們自己的系統進行交互的。業務調度層的另外一個作用就是對視頻內容進行分析。往下一層是文件存儲,媒體庫層。文件存儲包括文件上傳,文件存儲方面等的問題。媒體庫是視頻對象的源信息,如視頻分辨率URL,視頻長寬,用戶ID,博文內容等信息存儲。最下層是轉碼服務。我們重點介紹的就是轉碼服務在微博場景下的思考。
2. 微博視頻轉碼服務架構與挑戰2.1 視頻處理系統傳統架構在講微博面臨的問題之前,先來了解一下視頻處理系統的傳統架構。例如,某一用戶在PC端或手機端有一個1080p,5Mbps的視頻需要上傳。在傳統的架構中,會先將文件傳到文件上傳服務,文件上傳服務將其傳到底層存儲。傳到存儲后,文件上傳服務會告知轉碼服務文件需進行轉碼。轉碼時轉碼服務通過調度器將轉碼任務傳到對應的轉碼集群中的轉碼服務器。真正轉碼的機器,從存儲中下載用戶上傳的源文件,轉換成特定格式后回存到存儲中。2.2 微博視頻轉碼服務 – 業務繁雜對微博視頻而言,我們有非常繁雜的業務,例如業務方會有不同的水印,一些用戶會對自己的視頻有特殊要求,另外系統要能滿足線上驗證優化轉碼算法的需求,再加上轉碼服務本身會提供抽幀等基礎服務,要使這些融合在一起快速方便的支持業務方的需求,我們面臨很大的挑戰。2.3 微博視頻轉碼服務 – 提速優化另外,在優化視頻基礎體驗的時候,我們會提出并行上傳來提高用戶上傳成功率,做類似斷點續傳的功能,我們還會做并行轉碼完成云廠商提出的分片轉碼。甚至我們做到了用戶邊轉邊存,使視頻在用戶手機端完成分片,一邊分片一邊上傳,上傳的同時后臺進行轉碼,上傳完成的同時,轉碼即可完成,最后合并視頻完成發送。這極大的提高了用戶上傳視頻到發布微博這一過程的體驗。
提速優化舉例第一個是順序上傳。現在順序上傳的過程一般是二進制切片,切片后依次上傳,整個系統延遲會比較長,做并行上傳時,例如兩個進程同時上傳,會比順序上傳提速一倍。在做并行轉碼時,相當于把視頻做成二進制分片上傳后,合并起來進行轉碼。轉碼時再將視頻切分成不同時長的片段進行分片轉碼,完成后合并視頻。這種方式下通過提高并行程度降低了延時。在邊傳邊轉方式下,客戶端上傳存儲后,馬上進行轉碼,客戶端操作與服務端服務并行,最后服務端會將源視頻、目標視頻分別合并。2.4 微博視頻處理系統面臨的挑戰我們面對業務繁雜,需進行基礎服務優化的雙重挑戰。另外,微博業務具有很強的實時性,這就要求我們每環節都得快速完成,包括我們實現代碼的時間,接入業務方上線的時間。我們必須實現一個低延時、高并發、高可用、高性能的視頻轉碼服務。視頻轉碼服務本身需要大量計算,需要大規模的集群支持這項服務。我們面臨的另外一個挑戰就是對大量集群的管理。由于我們使用了分片轉碼,邊傳邊轉的優化方式,一個視頻切成十片,轉碼量會變成十倍,這導致轉碼任務量陡增,同時也會產生一個更細粒度的調度。切片給我們帶來更加復雜的任務依賴關系,我們要管理切片、分片并行轉碼以及合并整個過程中的任務依賴。過程中步驟越多,失敗率越高,越要求系統有更高的健壯性降低失敗。我們今天主要講的就是如何實現一個低延時、高并發、高可用、高性能的系統,我將主要從以下幾個方面來說明。首先是高度靈活的配置生成系統,相當于將業務相關的東西從主系統中抽離放到配置系統中,使主系統專注于基礎性能優化和基礎服務。第二點要講的是基于DAG的邏輯組織框架即用工作流引擎去組織任務之間的依賴。最后會講一下高可用、高性能的任務調度器對系統的重要作用。3. 微博視頻轉碼服務架構設計3.1 木林森高度靈活的配置生成系統
對于靈活配置,我們取名為木林森。它是一個基于樹形結構的規則引擎,即我們的配置結果都是樹形結構,多棵樹即可組成森林,所以我們取名為木林森。木林森支持靈活的配置生成。微博有些業務場景下產品方只要求快速而不在意視頻輸出屬性,這時我們可以直接使現有輸出業務與輸入業務連接完成業務接入。用這種方式可以提升新業務接入效率。下面是一個簡單的示例。
如圖,例如我們有微博原生視頻接入業務,現在要接入的億幕視頻希望與原生視頻有相同的輸出。此時我們在輸出業務以下到轉碼輸出都不需要改變,我們只需要將節點連接,輸入的億幕視頻就與微博原生視頻有了相同的輸出。只需通過后臺點擊配置就可將視頻接入。右圖所示是微博視頻的輸出配置。
復雜場景下,原生視頻,秒拍視頻,VIP視頻的輸出業務配置如圖。不同用戶端視頻經過系統輸出的視頻是不同的。通過配置可完成復雜場景下的業務邏輯抽離。3.2 DAG基于DAG的邏輯組織框架
我們自己實現了一套工作流引擎框架來支撐我們的業務,首先介紹一下框架的思想。我們是基于Java開發的,這里用Java舉例。對于一般的上傳系統,代碼實現只有下載、轉碼、上傳的過程。在這一段代碼的基礎上,我們要實現分片轉碼,邊傳邊轉等復雜的邏輯流。最簡單的方法就是我們將一般上傳的代碼復制改動,這時我們的方式如右圖。上傳過程變為下載,切片,將切片結果上傳,下載切片,切片轉碼,上傳切片,然后使這個過程循環往復,這時可多臺機器并行工作,最后將切片合并。由于過程復雜,所有我們希望能用有向無環圖連接組織,將基礎服務固化,通過腳本將不同功能組織起來。這時我們無論下載文件轉碼上傳還是分片上傳,只需簡單連接即可,兩個下載之間的代碼是不需要改動的。我們將可固化的部分固化,將代碼拆成一個個可獨立執行的閉包,通過DAG管理包與包之間的關系,在DAG內部實現閉包的執行。這就是我們關于DAG框架的想法。這是我們轉碼服務的圖示。如圖中,Center部分就是中央調度的服務,Runner部分是執行轉碼任務的服務,videoTrans是DAG組織任務間關系的腳本。我們的腳本通過Groovy實現。框架名字叫做Olympiadane,是通過Groovy引擎執行連成的關系,其中的Group是可獨立調度的單位,即圖中白色的部分。任務先經過調度器,調度器根據情況分發到執行器,執行器內部根據前后依賴關系順序執行Task,在此例中就是下載,轉碼,上傳。另一臺機器也是一樣的。這樣就實現了執行流與業務之間的解耦,如果要接入其他的新服務的話,我們只需要再實現一個Task,將此Task的依賴關系放入腳本即可完成。另外通過腳本生成的就是圖中的Job。這是我們DAG架構。實現DAG框架后,可以通過腳本快速接入支持業務,由于腳本變動但Feature不是經常變動的,所以Feature可在腳本間共用,也可以獨立測試,這樣我們便可以完成可組裝的獨立組件。這些獨立組件具備可以獨立測試,易擴展,易部署,高性能的特性。這里描述的是DAG的過程。前面我們提到的分片轉碼,過程分是下載,切片,上傳分片結果幾步。例如有三個機器同時并行完成下載分片,轉碼,上傳結果的工作。當并行過程結束后,會有一個新的依賴關系,如圖中,下載所有分片,合并轉碼后的視頻,不同清晰度的文件都是在不同機器上并行工作的。這是對我們轉碼服務優化中,通過DAG組織的一次實踐。如圖中,灰色的部分變成了綠色,這表示這個過程是可以觀測的,這也是通過DAG方式實現的一個優勢。我們可以觀測任務執行到了哪一步,也可以更快的定位出現問題的地方。另外,由于我們進行了拆分,可以對獨立Feature進行DAG切面,例如我們可以統計它的耗時,這樣我們可以知道哪種類型的業務耗時較長,也有助于觀察系統的穩定性。在DAG的優化方面,我們通過字節碼編譯技術做到了腳本快速執行。另外我們引入了一些Protostuff技術快速完成資源存儲。3.3 調度器
高可用、高性能的任務調度器
我們通過木林森將業務系統抽離出來,通過DAG系統將實現時的依賴關系抽離,因此我們需要一個好的調度系統來支撐。由于我們進行了切片,因此調度任務達到了萬次每秒。我們也會需要更細粒度的調度任務,比起粗粒度的調度,對基礎組件性能要求更高。我們對調度器的另外一個設計目標就是調度占比要低于百分之五,這就意味著系統損耗更低。這對調度器有極高要求,我們要使百分之九十九的調度任務在10ms內分派到對應機器,并且我們希望它的調度是最優調度,即能準確把任務分派到空閑機器。在設計調度器時我們也做了一些思考。我們對中心化調度器和非中心化調度器做了對比。中心化調度器的調度準確度高,它將資源隊列信息放到中心化存儲中,對監控更親和。但是它的資源依賴較多,我們將隊列放到了資源中,因此資源訪問讀寫中會產生一定依賴,也會有一定性能損耗。對于去中心化調度器來說,它的擴展性更強,但是它存在調度不準確的問題。最終我們選擇了中心化調度方式。
上圖是調度器調度過程。左邊是調度器,右邊是執行器。調度器和執行器之間通過心跳注冊,心跳時間是可配置的。注冊完后會將機器信息放到機器隊列,中心資源中有一個任務優先級隊列,我們可以對不同任務映射不同優先級。另外一個是機器空閑優先級隊列,就是我們將機器空閑度映射為優先級。在派發時,我們會取到高優先級任務,取到空閑度優先級高的執行器,然后將任務派到指定機器,即可將任務放到執行隊列中。執行隊列的重要作用在后面會講到。執行結束后,會進行一次回調,從執行隊列中移除任務。我們通過三個隊列完成任務調度,由于存在資源依賴,所以我們對這些資源進行了哈希計算,不同機器可以使用不同資源,只要資源滿足就可分派任務。但是這里會有一個問題。心跳會匯報情況,但它會有一定延遲,如果Executor與資源中存儲的狀態產生差異,任務可能會被分派到一臺無法工作的機器。為解決此問題,我們設計了一個帶鎖的雙發調度。與之前介紹的相同,我們依然從隊列選擇機器。不同的是,我們會在空閑優先級隊列中取到最優的同時,取一個隨機機器去完成分派。分派后,執行器會再一次調用調度器確認由誰完成任務,再去執行。當最優任務不可執行時,另外一個機器可完成任務。這樣,我們就可以實現百分之九十九的任務在10毫秒內完成分派的目的。同樣的,帶鎖雙發調度也會有哈希計算的存在。同時,我們會使用WatchDog觀察執行隊列中的任務是否在規定時間完成,若沒有完成,我們會重新觸發調度器分派任務。這樣我們可以有效減慢失敗率提升。通過以上設計,我們的調度器可以實現毫秒級派發。對于微博業務來說,可能會出現緊急大流量出現,我們在設計時也考慮了水平伸縮方式,使它支持彈性擴縮容。通過WatchDog機制,我們可以實現宕機自動摘除。在實際應用中,我們每天都會有機器擴縮容,我們的做法是讓待擴容機器不接受任務,先完成已有任務,再做機器擴縮容工作。但這樣做還會有未完成的任務存在,通過WatchDog機制,我們可以確保這些任務重新分派完成。同時我們實現了4個9可用性。3.4 部署
在轉碼服務部署方面,我們在兩個IDC部署了完全相同的兩套資源,它們有獨立的域名,獨立的部署。這么做的好處是我們可以在兩個機房間隨意的切流量,任一機房出現問題,我們都可以切換,但是兩個機房的部署并不是一比一的冗余。我們常備的機房是一個大規模集群,另一個機房是一個小規模的,或許只有常備機房十分之一的量。兩個機房在使用時可以分開,例如我們轉一些不影響用戶發博的轉碼輸出時,可以使用小機房完成任務,這樣大機房出現“災難性”情況時,可以把流量切到小機房。當然小機房是不能滿足那么大流量的,但是調度器本身的隊列有堆積的特性,可以將堆積的任務慢慢執行。沒有大量機器冗余可以充分利用機器。4. 總結接下來,我將所有內容做一個總結。通過轉碼服務的優化提升,我們整體轉碼提速了5倍,集群利用率標準差下降了百分之五十。這里的標準差指由于分派任務不合理,分到不同清閑度的任務導致機器CPU利用率忽高忽低的情況。通過好的調度方式,對集群的利用率標準差有很大降低。另外,我們業務支撐的效率也成倍提升。我們通過各種方式進行解耦,將變化大的和變化小的分開放到不同位置。
在服務架構設計開發的過程中,我們使用了很多并行手段,包括機器并行、進程并行、線程的并行以及算法、CPU核的并行等,通過這些手段發揮機器最大的價值。今天我們設計的目的是一個低延時高可用的系統,我們用到的并行上傳,并行轉碼,極致上傳等手段都用了算法上分治、遞歸、貪心的思想。在高可用方面使用了高內聚低耦合的思想,用到了動靜分離、自動容錯、異地多活的手段。最后想和大家分享,我們在做系統架構、設計優化不知道該如何實現的時候,就可以無腦的把這些高內聚低耦合、空間換時間等常見的思想往系統上套,或許就可以得到想要的結果。優化架構并不是多么復雜深奧的東西,我們要去思考的是前人總結的這些手段在我們自己系統上的能否達到效果,如果得到了滿意的效果,那么這些思想就會轉化為我們自己的東西。
LiveVideoStack?秋季招聘
LiveVideoStack正在招募編輯/記者/運營,與全球頂尖多媒體技術專家和LiveVideoStack年輕的伙伴一起,推動多媒體技術生態發展。同時,也歡迎你利用業余時間、遠程參與內容生產。了解崗位信息請在BOSS直聘上搜索“LiveVideoStack”,或通過微信“Tony_Bao_”與主編包研交流。
總結
以上是生活随笔為你收集整理的新浪微博:大规模离线视频处理系统的架构设计的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 叶琰:AI压缩技术在追上传统编码技术
- 下一篇: LiveVideoStackCon深圳-