此次LiveVideoStackCon 2021音頻和視頻技術(shù)會議北京站邀請了新浪微博視頻平臺設(shè)計師——黃良全。他介紹了微博視頻處理系統(tǒng)的體系結(jié)構(gòu)演變，探索了云原始的道路，選擇自建的原因，以及如何實現(xiàn)基于現(xiàn)有基本服務(wù)的FAAS平臺。

為嘗試云原生架構(gòu)模式的開發(fā)者提供參考。

文 | 黃陽全

整理 | LiveVideoStack

大家好，我是來自微博視頻平臺的黃陽全，今天分享的主題是微博視頻處理系統(tǒng)云原生之路。

我在2017年加入微博研發(fā)中心，負責(zé)微博視頻基礎(chǔ)組件的開發(fā)與維護，多次參與了微博視頻架構(gòu)升級，主導(dǎo)了微博視頻中臺的建設(shè)。目前正在建設(shè)基于云原生架構(gòu)的微博視頻處理系統(tǒng)。

本次分享主要分為4部分：

1.背景介紹：主要介紹微博視頻，微博視頻處理系統(tǒng)，微博視頻處理系統(tǒng)所包含子模塊，以及它的特點；

2.原視頻處理系統(tǒng)架構(gòu)：針對微博視頻處理系統(tǒng)所具有的特點，我們設(shè)計出基本滿足需求的原架構(gòu)，但是隨著業(yè)務(wù)的發(fā)展，逐漸發(fā)現(xiàn)了原架構(gòu)的短板；

3.FaaS平臺的探索與實踐：針對短板，我們在云原生領(lǐng)域開始了如火如荼的FaaS平臺的探索，在原基礎(chǔ)服務(wù)之上開發(fā)出了解決業(yè)務(wù)痛點的FaaS平臺；

4.總結(jié)與未來展望。

一、背景介紹

隨著4G/5G技術(shù)和設(shè)備的不斷普及，越來越多的用戶選擇通過視頻或者直播來記錄生活，傳遞知識，表達觀點。

微博作為一個即時分享平臺，視頻所占的比例也越來越大，目前微博視頻的日發(fā)布量已達到百萬級，日播放量也早已突破十億級。

圖示為一個微博視頻從生產(chǎn)到消費經(jīng)歷的整條鏈路：

首先視頻創(chuàng)作者從手機、PC等設(shè)備上傳視頻或是開啟直播，視頻處理服務(wù)接收請求后進行視頻的處理。處理完成且審核通過后，視頻發(fā)布，最后用戶能通過播放服務(wù)看到視頻。

下面放大視頻處理服務(wù)部分（黃色部分）。

視頻處理系統(tǒng)包含四個子模塊：視頻轉(zhuǎn)碼，視頻內(nèi)容理解，直播錄制和轉(zhuǎn)碼實驗室

1、視頻轉(zhuǎn)碼：對于用戶上傳的視頻，我們需要將視頻轉(zhuǎn)碼成不同的清晰度（1080p、720p等），以滿足不同場景下用戶的播放需求。對于用戶來說，上傳后視頻越快發(fā)出，體驗越好，所以視頻轉(zhuǎn)碼有速度要求。另外視頻微博的上行有熱點特性，需要有較好的峰值應(yīng)對能力。

2、視頻內(nèi)容理解：負責(zé)提取視頻中的內(nèi)容信息，轉(zhuǎn)換成結(jié)構(gòu)化數(shù)據(jù)，助力于業(yè)務(wù)發(fā)展。內(nèi)容理解具有資源多樣，算法多樣，服務(wù)多樣的特性。

3、直播錄制：從源站拉取直播流，轉(zhuǎn)碼后的視頻存儲到文件服務(wù)，以供用戶點播觀看。

4、轉(zhuǎn)碼實驗室：顧名思義，是各種轉(zhuǎn)碼算法、圖像算法、內(nèi)容理解算法的試驗田。轉(zhuǎn)碼實驗室是離線處理任務(wù)，對實時性要求不高，可能白天需要驗證的算法，晚上跑，第二天能得出結(jié)果就可以。

綜上所述，微博視頻處理系統(tǒng)具有大流量、實時性、核心服務(wù)、峰值明顯、在線/離線同時存在、資源多樣的特點。

二、原視頻處理系統(tǒng)

對于視頻轉(zhuǎn)碼來說，保證轉(zhuǎn)碼的效率是至關(guān)重要的。

這是一個整文件轉(zhuǎn)碼和分片轉(zhuǎn)碼的對比示意圖，整文件轉(zhuǎn)碼分為下載、轉(zhuǎn)碼，上傳。分片轉(zhuǎn)碼將下載好的視頻分片后并行處理，從而提高轉(zhuǎn)碼速度，可以看到分片轉(zhuǎn)碼速度遠優(yōu)于整文件轉(zhuǎn)碼速度，特別是轉(zhuǎn)碼大視頻文件時，這也是業(yè)內(nèi)通用的解決方案。

但是分片轉(zhuǎn)碼也帶來了新的挑戰(zhàn)：

1、流程編排復(fù)雜：如果采用傳統(tǒng)的編碼方式進行分布式分片并行轉(zhuǎn)碼是比較困難的，另外還要考慮失敗超時重試等情況，整個流程會非常復(fù)雜。

2、高并發(fā)，低延遲：在微博的場景下，結(jié)合前面講到的微博視頻的特點，我們還有高并發(fā)低延遲的挑戰(zhàn)。

有的同學(xué)會疑惑，視頻上傳這種上行接口大概是幾百qps，怎么會達到高并發(fā)？這里解釋一下，假如微博的上傳qps是100，一個視頻分成100個分片，需要轉(zhuǎn)出10個label的清晰度，那么系統(tǒng)內(nèi)部需要承載的qps將被放大到10w。

為了解決這兩個問題，我們開發(fā)出了流程編排引擎和高性能的調(diào)度器。

首先是DAG有向無環(huán)圖的框架和Olympiadane。我們采用與Java親和度比較高的Grovvy定義DAG流程。

這是DAG編排后的分片轉(zhuǎn)碼流程圖，每一個task（綠色節(jié)點）是一個單獨的實現(xiàn)類，以此解耦流程和任務(wù)，DAG還提供重試重做，可視化的功能。

有了流程的編排，還需要將任務(wù)下發(fā)到機器上執(zhí)行，于是我們開發(fā)了TaskScheduler任務(wù)調(diào)度器。

任務(wù)調(diào)度器采用任務(wù)優(yōu)先級隊列和機器優(yōu)先級隊列相結(jié)合的方式，將調(diào)度性能優(yōu)化到一次redis命令執(zhí)行，支撐轉(zhuǎn)碼10w級并發(fā)，毫秒級調(diào)度的需求。

此外，TaskScheduler還具有雙發(fā)調(diào)度，任務(wù)組發(fā)、水平伸縮、宕機自動摘除，忙時堆積等特性。

這是任務(wù)調(diào)度執(zhí)行的全景圖，有了DAG和TaskScheduler，視頻處理任務(wù)由DAG描述依賴關(guān)系，通過調(diào)度器調(diào)度到Worker上執(zhí)行。

以上是原視頻處理系統(tǒng)的一些關(guān)鍵設(shè)計。

那么，隨著業(yè)務(wù)的發(fā)展，我們遇到了哪些挑戰(zhàn)，系統(tǒng)又隨之顯露了哪些短板呢？

問題一：資源整體利用率不高

算力緊張，但是資源整體利用率不高：業(yè)務(wù)高速發(fā)展同時伴隨著越來越多新算法的不斷落地，對資源的需求也越來越多，不斷舔磚加瓦的同時，我們也在審視當(dāng)前的服務(wù)資源使用情況。

右圖是某一時刻服務(wù)資源利用率的橫截面圖，由于不同的服務(wù)模塊具有資源差異（計算密集型業(yè)務(wù)/內(nèi)存密集型系統(tǒng)），和運行時段的差異（業(yè)務(wù)流量高峰期/凌晨流量低谷），雖然我們盡量做到局部最優(yōu)，但還是很難達到全局最優(yōu)。

這是線上某臺轉(zhuǎn)碼機器的CPU利用率的截圖，可以看到，機器CPU利用率存在明顯的波峰波谷。高峰期，機器利用率可高達95%，但是低谷期，利用率還不到10%

在評估服務(wù)資源的時候，為了保證系統(tǒng)的可靠性，往往需要根據(jù)服務(wù)的峰值進行評估，另外還要預(yù)留一定的冗余度。

雖然我們已經(jīng)做了基于公有云的晚高峰彈性擴縮容，比如每天晚上8點開始擴容，到凌晨流量下降時再縮容。但整體看來，服務(wù)還存在著巨大的冗余與浪費

圖中的金幣部分就是浪費的的資源。

問題二：開發(fā)運維效率不高

需求緊急，但是開發(fā)運維效率不高。

這是一個真實的案例，產(chǎn)品組大半夜發(fā)來消息：“算法Demo已經(jīng)跑通了！似乎可以上線了！明天能灰度了嗎？”。

但后端開發(fā)人員遇到的問題遠不止于此：

1.算法代碼如何轉(zhuǎn)成工程代碼，有沒有坑？

2.代碼寫在哪個工程里？會不會有沖突？后期怎么維護？

3.灰度功能在哪兒加？

4.如何保證系統(tǒng)的可用性？

5.流量熱點怎么應(yīng)對？

6.擴縮容怎么做？

這些問題都需要考慮。

在當(dāng)前服務(wù)模式下，從算法到上線，再到有數(shù)據(jù)，需要經(jīng)歷哪些步驟呢？

首先，需要將算法翻譯成工程代碼，因為負責(zé)算法的同學(xué)關(guān)注算法本身的正確性多于工程方面，所以他們提供的算法可能并不能直接應(yīng)用于工程。然后進行適配開發(fā)，加入到現(xiàn)有的工程中，假設(shè)轉(zhuǎn)碼后有幾萬行代碼，這就需要考慮AB測試，兼容性，后期維護，高可用等問題。通過測試后，即可打包為線上鏡像并上線，上線完成后，還需要考慮服務(wù)保障、擴縮容等，最后才能得到效果數(shù)據(jù)

總結(jié)可得在開發(fā)效率方面遇到的三個問題：

1、開發(fā)縱深太深，新手難以上手；

2、開發(fā)流程復(fù)雜；

3、運維難度大。

如果無法妥善處理這三個問題，結(jié)果就會如左圖所示只有工程開發(fā)在默默挖坑。

三、FaaS平臺的探索與實踐

現(xiàn)有的服務(wù)模式似乎難以解決資源利用率低及開發(fā)運維效率低的問題，于是我們開啟了對FaaS平臺的探索與實踐。

FaaS的全稱是Function as a service，是為用戶提供開發(fā)、運行和管理的函數(shù)服務(wù)平臺

以承載”函數(shù)”的方式來啟動基礎(chǔ)應(yīng)用框架，并對應(yīng)用實現(xiàn)資源編排、自動伸縮、全生命周期覆蓋等保障，從而實現(xiàn)云服務(wù)的Serverless。

由IaaS發(fā)展到現(xiàn)在的FaaS（左圖），開發(fā)者需要關(guān)注的內(nèi)容越來越少，可擴容單元越來越小。

介紹了FaaS后，我們將遇到的痛點和FaaS平臺可以解決的問題進行以下對比。

痛點一：開發(fā)縱深太長；FAAS平臺可以消除技術(shù)壁壘，理論上只需要了解函數(shù)的輸入輸出就可以，開發(fā)人員沒有其他心智負擔(dān)；

痛點二：開發(fā)流程復(fù)雜；FAAS可以提供部署、發(fā)布、監(jiān)控“一條龍”的服務(wù)，并提供穩(wěn)定性保障；

痛點三：運維難度大，體現(xiàn)在服務(wù)保障，宕機處理等方面；FAAS平臺免運維，全托管；

痛點四：資源整體利用率不高；通過平臺化的思想，整合資源，共享冗余，實現(xiàn)按需調(diào)度，從而提高整體資源利用率。

對于FaaS平臺的選型，我們有三個選擇：云廠商、開源FaaS框架和自建。

1、云廠商：由于只能覆蓋公有云的場景，微博場景下暫時不考慮；

2、開源FaaS框架：根據(jù)對常用FaaS框架進行調(diào)研的結(jié)構(gòu)顯示，在場景、語言以及適配上有一定的局限性，現(xiàn)有系統(tǒng)遷移起來難度比較大，而且有些框架還不夠成熟。

于是我們選擇了自建FaaS平臺，通過復(fù)用現(xiàn)在的基礎(chǔ)設(shè)施和框架，打造適配微博處理系統(tǒng)的FaaS平臺。

以下是基于原框架基礎(chǔ)構(gòu)建FaaS平臺的步驟：

第一步，將DagTask抽象為function，使其能夠獨立部署運維，上文提到DagTask是單獨的實現(xiàn)類，與原項目代碼有耦合。假設(shè)內(nèi)容理解工程中有幾十個task，會使工程代碼量膨脹，增加開發(fā)人員的心智負擔(dān)。而在Function的設(shè)計中，開發(fā)人員只需關(guān)注輸入輸出，開發(fā)更簡單高效；

第二步，原DagTask會依賴整個服務(wù)的部署，轉(zhuǎn)碼時整個服務(wù)中會部署幾十個task且task的升級和擴容都不能獨立進行。Function的設(shè)計中完全解決了這一問題，它提供了函數(shù)級別的部署運維，可獨立伸縮。

另外，原DagTask僅支持Java，F(xiàn)unction不限制語言，目前已支持了Java、go、python，為算法人員提供便利。

第二點升級是將原DAG流程服務(wù)化。原DAG流程采用grovvy描述、SDK依賴的方式。那么在升級DAG流程時，需要上線兩次，首先全量上線class文件，否則當(dāng)task被調(diào)度到?jīng)]有此class的機器上時，會出現(xiàn)“class Not Found”。

WeiboFlow采用yaml文件描述DAG，通過服務(wù)化管理DAG版本，對版本迭代更友好。

此外，由于原DAG流程采用了grovvy描述、SDK依賴的方式，與項目代碼耦合。服務(wù)化之后可與項目代碼徹底解耦。

完成以上兩個重要改造之后，基本形成了FaaS平臺雛形。

將FaaS平臺分為兩層，第一層是服務(wù)化的WeiboFlow函數(shù)編排層，負責(zé)函數(shù)的編排流程管理，第二層是WeiboFunction提供的云函數(shù)層，負責(zé)具體的函數(shù)調(diào)度執(zhí)行。

這是FaaS平臺的任務(wù)調(diào)度鏈路圖，主要分為三部分：

1、WeiboFlow，上文提到是DAG服務(wù)化的版本，主要功能是對DAG進行版本管理及DAG的執(zhí)行。

2、WeiboFunction，主要負責(zé)函數(shù)管理及部署管理，其中的重要組件Task Scheduler是復(fù)用了原有的Task Scheduler從而進行函數(shù)的調(diào)度。

3、具體執(zhí)行的node節(jié)點，其中的重要組件FunctionLet負責(zé)接收任務(wù)，與WeiboFunction保持心跳，上報函數(shù)信息和機器槽數(shù)。

藍色虛線表示任務(wù)的調(diào)用鏈路，應(yīng)用可直接調(diào)用WeiboFlow的submit接口提交完整的轉(zhuǎn)碼流程或內(nèi)容理解流程，也可以直接調(diào)用WeiboFunction執(zhí)行某一個函數(shù)。

WeiboFlow收到調(diào)用請求后，開始執(zhí)行DAG上的節(jié)點，每一個節(jié)點可對應(yīng)一個Function，調(diào)用到WeiboFunction執(zhí)行，F(xiàn)unction收到請求后，使用Task Scheduler下發(fā)調(diào)度任務(wù)，將優(yōu)先級最高的任務(wù)和最優(yōu)的機器進行匹配后調(diào)度到具體的機器上執(zhí)行，具體的node，F(xiàn)unctionLet收到請求后進行函數(shù)執(zhí)行及回調(diào)。以上就是整個調(diào)用鏈路。

介紹完FaaS平臺后，再回到最初的問題，它是如何解決以上兩個問題的呢（資源利用率低、開發(fā)運維效率低）？

3.1 提高資源利用率

3.1.1 整合管理所有資源

FaaS平臺將不同機器型號，資源類型統(tǒng)一抽象為槽數(shù)，比如8核16G抽象為2000個槽，16核32G抽象為4000個槽，同時將GPU和FPGA設(shè)備也抽象為相應(yīng)的槽數(shù)。還可對此轉(zhuǎn)換公式進行配置，統(tǒng)一了資源的度量衡。

通過這一層抽象，F(xiàn)aaS平臺能夠統(tǒng)一管理調(diào)度多類型的資源。

FaaS平臺還實現(xiàn)了動態(tài)資源標(biāo)簽化，以此實現(xiàn)機器資源的隔離，結(jié)合上文提到的多隊列調(diào)度器，即可充分利用資源。

3.1.2 動態(tài)擴縮容

FAAS平臺實現(xiàn)了基于函數(shù)維度的動態(tài)擴縮容，左圖顯示了原晚高峰的擴縮容，右圖顯示了基于函數(shù)的動態(tài)擴縮容。

得益于函數(shù)啟動的速度更快，動態(tài)擴縮容更貼合服務(wù)權(quán)限。

我們將動態(tài)擴縮容功能分為四層：決策、聚合、Function擴縮容和Node擴縮容。

決策層：在做服務(wù)冗余度決策時，可根據(jù)服務(wù)冗余量或當(dāng)前隊列堆積情況，動態(tài)計算服務(wù)冗余度，還可根據(jù)時間策略，通過某一時刻的流量情況進行決策，人工干預(yù)也算作一種決策。

聚合層：聚合決策層下發(fā)的不同策略后做出最終的決策——服務(wù)最終的擴縮容策略。

Function擴縮容：在服務(wù)容量足夠的情況下進行動態(tài)的函數(shù)擴縮容。

Node擴縮容：當(dāng)服務(wù)容量滿載，有些服務(wù)沒有空余槽時，會觸發(fā)Node層的擴縮容。Node層由微博的DCP平臺打造而來，目前DCP平臺可以達到5min，2000臺機器，基本滿足我們的要求。

動態(tài)擴縮容能夠提升高峰期的資源利用率，那么如何解決常備資源量以下的浪費呢？

方式一：分時復(fù)用，在A服務(wù)的冗余度達到某一水平時，對A服務(wù)進行自動縮容，再部署B(yǎng)服務(wù)，以此達到分時復(fù)用的目的。

此方法可應(yīng)用于轉(zhuǎn)碼服務(wù)和轉(zhuǎn)碼實驗室服務(wù)（無論在線或離線）。白天轉(zhuǎn)碼實驗室的任務(wù)由少量機器處理，先進行堆積，到凌晨時，轉(zhuǎn)碼服務(wù)縮容，部署轉(zhuǎn)碼實驗室，消耗隊列中待處理的任務(wù)。

方式二：挖礦?？臻e資源代表“礦”，執(zhí)行完即銷毀的Function代表“挖礦工具”。

執(zhí)行完即銷毀的Function：云函數(shù)的服務(wù)模型分為兩種，常駐進程型和用完即毀型。常駐進程型的函數(shù)不會被銷毀，而用完即毀型的函數(shù)在一次調(diào)用完畢后就會被銷毀。我們將Gif轉(zhuǎn)碼任務(wù)設(shè)計為用完即毀型，因其運行周期較短，Gif任務(wù)也常作為“挖礦工具”。

如何“挖礦”呢？

這是1~5，五臺服務(wù)器，Node1有4000個slots，Node2有3500個slots。假設(shè)5臺服務(wù)器都部署了A服務(wù)，此時A服務(wù)只占3000個slots，那么會出現(xiàn)1000個slots的冗余。如何減少冗余呢？

假設(shè)要對Node1~4進行挖礦，只需要給1~4打上B的tag，此時調(diào)用器通過心跳感知這些機器，會將函數(shù)B調(diào)度到機器1~4上執(zhí)行。

如果Node1空閑1000個slots，而函數(shù)B的一個請求占100個slots，那么Node1上可以并行跑10個函數(shù)B，Node2可以并行跑5個函數(shù)B，通過調(diào)用器實現(xiàn)“指哪挖哪，哪里有礦挖哪里，有多少挖多少”。

進一步探索“挖礦”——如何更高效率地“挖礦”呢？

執(zhí)行完即銷毀的function采用冷啟動的方式，（如圖）先start up，再run stack，如此反復(fù)，每次都需要重新start up，累積下來對機器的損耗較大。

于是我們進行了以下優(yōu)化，采用熱啟動的方式，一次函數(shù)啟動后，如果在最大空閑時間內(nèi)有請求進來，就繼續(xù)執(zhí)行任務(wù)，不被銷毀；如果超過最大空閑時間內(nèi)無請求進入，那么函數(shù)運行環(huán)境會被銷毀，下次任務(wù)到來時需要重新啟動。通過以上步驟達到連續(xù)挖礦的目的。

優(yōu)化后的效果如圖，使整個服務(wù)的資源曲線更加貼合服務(wù)的流量，提高了資源利用率。

3.2 提高開發(fā)運維效率

1、FaaS平臺提供了開箱即用的模板工程實現(xiàn)統(tǒng)一工程化及標(biāo)準(zhǔn)化。

一個云函數(shù)對應(yīng)一個gitlab的項目，函數(shù)開發(fā)與發(fā)布都圍繞單個項目進行CI/CD，高效且安全。從而使開發(fā)人員更關(guān)注業(yè)務(wù)邏輯，達到提高開發(fā)效率的目的。

2、FaaS平臺提供了云函數(shù)的高可用保障。

這是任務(wù)從WeiboFunction調(diào)度到具體機器上執(zhí)行的細致流程圖：

在FunctionLet和Function之間利用QueQiao進行通信，F(xiàn)unctionLet在接收到任務(wù)的時候，寫入TaskQueue，F(xiàn)unction讀取TaskQueue進行函數(shù)邏輯處理，處理完畢后將結(jié)果寫入ResultQueue，F(xiàn)unctionLet讀取ResultQueue中的結(jié)果，并返回。

這樣的設(shè)計如何提供高可用保障呢？

1）假設(shè)WeiboFunction宕機或者脫網(wǎng)導(dǎo)致回調(diào)失敗，此時無需重新運行所有任務(wù)，已執(zhí)行完的任務(wù)會將結(jié)果寫入ResultQueue中，F(xiàn)unctionLet回調(diào)失敗后也會將回調(diào)失敗的任務(wù)重新寫入ResultQueue中，等待WeiboFunction恢復(fù)后，重新將執(zhí)行完成的ResultQueue進行回調(diào)，已執(zhí)行完畢的任務(wù)不會丟失或被再次執(zhí)行。

2）假設(shè)FunctionLet上線重啟或者服務(wù)異常，已執(zhí)行完畢的任務(wù)也會被寫入隊列，等待FunctionLet恢復(fù)后重新回調(diào)。

3）假設(shè)Function掛了，F(xiàn)unctionLet將停止接收新的任務(wù)，F(xiàn)unctionLet對Function有具體函數(shù)的保護，重新啟動函數(shù)，執(zhí)行Queue中任務(wù)進行回調(diào)。

那么假設(shè)Node節(jié)點整個都掛了，且處于不可恢復(fù)的狀態(tài)時，執(zhí)行完畢的任務(wù)會丟失嗎？

答案是否定的，我們在Task Scheduler層設(shè)計了派發(fā)重試及故障轉(zhuǎn)移的功能。除了node上各個組件的高可用，還保證了node級別的高可用。

當(dāng)任務(wù)被派發(fā)到執(zhí)行機器上時出現(xiàn)了超時的情況，任務(wù)會從Task Scheduler的執(zhí)行任務(wù)隊列中取出并選擇一臺當(dāng)前活躍而且空閑度最高的機器重新派發(fā)，以實現(xiàn)派發(fā)重試的功能。

當(dāng)Node無法恢復(fù)時，會被移出執(zhí)行器隊列，后續(xù)的任務(wù)不再被派發(fā)到這臺機器，以實現(xiàn)故障的轉(zhuǎn)移。

WeiboFunction還提供了Function級別的調(diào)諧?；顧C制，根據(jù)申明的服務(wù)節(jié)點個數(shù)重新找到合適的節(jié)點，啟動服務(wù)，以保證服務(wù)達到申明的最終狀態(tài)。

3、下沉通用功能。

我們將常用的比如限流降級，AB測試等下沉到平臺來實現(xiàn)，這樣用戶不用自己實現(xiàn)，只需要在FAAS后臺通過配置的方式即可操作。

1）AB測試：可通過WeiboFlow的DAG配置來實現(xiàn)，如右圖所示，將80%流量打到圖1，20%流量打到圖2，開發(fā)人員通過配置即可實現(xiàn)流量的分發(fā)。

2）任務(wù)動態(tài)優(yōu)先級：每個任務(wù)都有對應(yīng)優(yōu)先級，在轉(zhuǎn)碼服務(wù)中，假設(shè)用戶發(fā)博的任務(wù)是480P，那么此480P任務(wù)的優(yōu)先級就相對較高，可以通過動態(tài)調(diào)整任務(wù)節(jié)點的優(yōu)先級，并配合調(diào)度，先執(zhí)行優(yōu)先級高的任務(wù)。

3）任務(wù)動態(tài)權(quán)重：一個h265的任務(wù)通常需要占用更多的slots，此時可以通過任務(wù)動態(tài)權(quán)重功能達到資源的平衡利用。

4）限流降級：為每個節(jié)點配置限流降級的閾值。

5）錯誤處理：節(jié)點錯誤后可以配置重試頻率及重試次數(shù)。

6）大小圖、父子圖：針對復(fù)雜的流程圖，提供了大小圖和父子圖的方式，每一個節(jié)點都有可能是另外一個完整的圖，可以理解為對節(jié)點進行foreach的操作，分片完畢后，如有100分片，就對分片進行foreach循環(huán)，每一個循環(huán)都有一套處理邏輯，而處理邏輯是可以復(fù)用的，這就可以通過大小圖的方式解決。

7）多種語義控制：目前提供了pass/foreach/return/suspense/choice等語義，可支持復(fù)雜的流程編排。

4、Faas平臺提供了多維度的可觀測性。

右圖1是執(zhí)行完畢的轉(zhuǎn)碼DAG圖，截自Weibo Funciton后臺，展示了整個執(zhí)行鏈路，節(jié)點出現(xiàn)問題時會變紅，便于追蹤鏈路，排除故障。此外。每個節(jié)點還有統(tǒng)計信息，執(zhí)行時間、橫向或縱向的Metrics。點擊每個節(jié)點，會出現(xiàn)右圖2所示的詳細信息，其中包含整個執(zhí)行關(guān)鍵日志，便于用戶調(diào)看。

5、FaaS平臺重建了開發(fā)流程。

開發(fā)人員在代碼編寫完畢后，通過本地測試構(gòu)建鏡像，注冊或升級函數(shù)，再進行遠端測試，最后發(fā)布函數(shù)，函數(shù)即可彈性執(zhí)行。

通過用戶維護WeiboFlow流程或者其他事件可觸發(fā)執(zhí)行函數(shù)。

四、總結(jié)與未來展望

微博視頻處理系統(tǒng)在具有實時性、大流量、核心服務(wù)、峰值明顯、資源多樣、在線/離線等特點的背景下，為了解決高并發(fā)，低延遲及流程編排復(fù)雜的問題，我們開發(fā)出了DAG編排引擎及任務(wù)調(diào)度器。

但隨著業(yè)務(wù)的發(fā)展，陸續(xù)出現(xiàn)了資源利用率低，研發(fā)運維效率低的問題，于是我們開啟了云原生架構(gòu)中的探索，開發(fā)了高彈性，全托管的FaaS平臺，通過資源整合、按需調(diào)度、減小開發(fā)粒度，下沉通用能力以解決利用率和運維效率的問題。

最終達到的效果，主要分為兩方面：

1、降低成本：集群負載標(biāo)準(zhǔn)差優(yōu)化30%，視頻轉(zhuǎn)碼彈性成本了降低44%，通過分時復(fù)用、挖礦的方式將算法迭代周期從40天優(yōu)化至6天。

2、提高效率：支持算法的上線周期由天級或者周級優(yōu)化至小時級。舉一個真實的案例，在奧運會期間，我們收到了識別某logo的需求， 從中午接到需求到下午上線完成得到數(shù)據(jù)，僅用了幾個小時。

未來，我們希望FaaS平臺能夠支持更多的場景，比如在WeiboFunction增加負載均衡層，從而支持傳統(tǒng)微服務(wù)場景。

其次是冷啟動優(yōu)化，雖然目前已經(jīng)支持常駐內(nèi)存的方式減少冷啟動帶來的消耗，但在需要頻繁冷啟動的場景下，還會造成較大的損耗，未來我們會在冷啟動方面投入更多時間精力。

最后是智能化運維，在FaaS的運維場景下加入服務(wù)畫像，根據(jù)服務(wù)畫像動態(tài)調(diào)整服務(wù)容量，達到更高的利用效率。

以上是本次的分享，謝謝！

---