新浪微博：大規(guī)模離線視頻處理系統(tǒng)的架構(gòu)設(shè)計(jì)

時(shí)間：2023-05-15 17:30:01 | 來源：網(wǎng)站運(yùn)營(yíng)

時(shí)間：2023-05-15 17:30:01 來源：網(wǎng)站運(yùn)營(yíng)

新浪微博：大規(guī)模離線視頻處理系統(tǒng)的架構(gòu)設(shè)計(jì)：

微博視頻平臺(tái)在4億月活用戶吃瓜嗨聊的高并發(fā)、大流量背景下，既要保證用戶微博生產(chǎn)和消費(fèi)體驗(yàn)，又要支持業(yè)務(wù)快速迭代，確保正確性、穩(wěn)定性和高可用性。本次演將以微博視頻大規(guī)模視頻離線處理系統(tǒng)的架構(gòu)設(shè)計(jì)為主題為大家?guī)泶笠?guī)模分布式系統(tǒng)的架構(gòu)設(shè)計(jì)，性能優(yōu)化和高可用保障等一線實(shí)戰(zhàn)經(jīng)驗(yàn)。

文 / 霍東海

整理 / LiveVideoStack




大家好，我是來自新浪微博視頻平臺(tái)和微博平臺(tái)研發(fā)部的架構(gòu)師霍東海，從2017年加入微博，目前在微博視頻平臺(tái)負(fù)責(zé)微博視頻離線處理系統(tǒng)架構(gòu)等相關(guān)工作，包括大規(guī)模離線微服務(wù)系統(tǒng)的架構(gòu)設(shè)計(jì)和服務(wù)保障體系的建設(shè)等。近期專注于視頻平臺(tái)技術(shù)體系的提升對(duì)用戶體驗(yàn)提升的幫助，主導(dǎo)構(gòu)建了微博SVE(Streaming Video Engine)系統(tǒng)，支持大并發(fā)場(chǎng)景下對(duì)視頻進(jìn)行并行轉(zhuǎn)碼，大幅度提升轉(zhuǎn)碼效率。




1. 背景介紹













微博本身有大并發(fā)、大流量的特性，有4億+的月活，同時(shí)微博也是一個(gè)開放平臺(tái)，支持多種第三方分享，每天都會(huì)有百萬視頻分享需進(jìn)行處理。













微博視頻業(yè)務(wù)大概分兩種業(yè)余形態(tài)，一個(gè)如左圖所示，是豎版的短視頻分享，另一個(gè)是如右圖所示的稍微長(zhǎng)一點(diǎn)的橫向播放的短視頻。

微博視頻還有一些特殊的場(chǎng)景，例如在微博PC端點(diǎn)視頻按鈕會(huì)跳轉(zhuǎn)到酷燃網(wǎng)，它是一個(gè)5到15分鐘的短小綜藝類視頻分享的網(wǎng)站，如圖中，下面都是一些優(yōu)酷，愛奇藝，騰訊等視頻網(wǎng)站分享到微博的視頻。







我們微博視頻團(tuán)隊(duì)面臨的業(yè)務(wù)場(chǎng)景是及其復(fù)雜的，我們要在復(fù)雜的場(chǎng)景下解決視頻處理的問題。如圖中，我們有微博視頻，酷燃視頻，付費(fèi)視頻，微博故事，秒拍，以及通過開放平臺(tái)接入的視頻分享網(wǎng)站，微博在最上層會(huì)接入極其多的業(yè)務(wù)方。中間會(huì)引入業(yè)務(wù)調(diào)度中心，即業(yè)務(wù)調(diào)度層，對(duì)上層業(yè)務(wù)進(jìn)行調(diào)度。










另外是數(shù)據(jù)同步，所有的視頻呈現(xiàn)在微博都是博文的形式，始終是需要和我們自己的系統(tǒng)進(jìn)行交互的。業(yè)務(wù)調(diào)度層的另外一個(gè)作用就是對(duì)視頻內(nèi)容進(jìn)行分析。往下一層是文件存儲(chǔ)，媒體庫(kù)層。文件存儲(chǔ)包括文件上傳，文件存儲(chǔ)方面等的問題。媒體庫(kù)是視頻對(duì)象的源信息，如視頻分辨率URL，視頻長(zhǎng)寬，用戶ID，博文內(nèi)容等信息存儲(chǔ)。最下層是轉(zhuǎn)碼服務(wù)。我們重點(diǎn)介紹的就是轉(zhuǎn)碼服務(wù)在微博場(chǎng)景下的思考。




2. 微博視頻轉(zhuǎn)碼服務(wù)架構(gòu)與挑戰(zhàn)

2.1 視頻處理系統(tǒng)傳統(tǒng)架構(gòu)













在講微博面臨的問題之前，先來了解一下視頻處理系統(tǒng)的傳統(tǒng)架構(gòu)。例如，某一用戶在PC端或手機(jī)端有一個(gè)1080p，5Mbps的視頻需要上傳。在傳統(tǒng)的架構(gòu)中，會(huì)先將文件傳到文件上傳服務(wù)，文件上傳服務(wù)將其傳到底層存儲(chǔ)。傳到存儲(chǔ)后，文件上傳服務(wù)會(huì)告知轉(zhuǎn)碼服務(wù)文件需進(jìn)行轉(zhuǎn)碼。轉(zhuǎn)碼時(shí)轉(zhuǎn)碼服務(wù)通過調(diào)度器將轉(zhuǎn)碼任務(wù)傳到對(duì)應(yīng)的轉(zhuǎn)碼集群中的轉(zhuǎn)碼服務(wù)器。真正轉(zhuǎn)碼的機(jī)器，從存儲(chǔ)中下載用戶上傳的源文件，轉(zhuǎn)換成特定格式后回存到存儲(chǔ)中。

2.2 微博視頻轉(zhuǎn)碼服務(wù) – 業(yè)務(wù)繁雜













對(duì)微博視頻而言，我們有非常繁雜的業(yè)務(wù)，例如業(yè)務(wù)方會(huì)有不同的水印，一些用戶會(huì)對(duì)自己的視頻有特殊要求，另外系統(tǒng)要能滿足線上驗(yàn)證優(yōu)化轉(zhuǎn)碼算法的需求，再加上轉(zhuǎn)碼服務(wù)本身會(huì)提供抽幀等基礎(chǔ)服務(wù)，要使這些融合在一起快速方便的支持業(yè)務(wù)方的需求，我們面臨很大的挑戰(zhàn)。

2.3 微博視頻轉(zhuǎn)碼服務(wù) – 提速優(yōu)化










另外，在優(yōu)化視頻基礎(chǔ)體驗(yàn)的時(shí)候，我們會(huì)提出并行上傳來提高用戶上傳成功率，做類似斷點(diǎn)續(xù)傳的功能，我們還會(huì)做并行轉(zhuǎn)碼完成云廠商提出的分片轉(zhuǎn)碼。甚至我們做到了用戶邊轉(zhuǎn)邊存，使視頻在用戶手機(jī)端完成分片，一邊分片一邊上傳，上傳的同時(shí)后臺(tái)進(jìn)行轉(zhuǎn)碼，上傳完成的同時(shí)，轉(zhuǎn)碼即可完成，最后合并視頻完成發(fā)送。這極大的提高了用戶上傳視頻到發(fā)布微博這一過程的體驗(yàn)。










提速優(yōu)化舉例




第一個(gè)是順序上傳?，F(xiàn)在順序上傳的過程一般是二進(jìn)制切片，切片后依次上傳，整個(gè)系統(tǒng)延遲會(huì)比較長(zhǎng)，做并行上傳時(shí)，例如兩個(gè)進(jìn)程同時(shí)上傳，會(huì)比順序上傳提速一倍。













在做并行轉(zhuǎn)碼時(shí)，相當(dāng)于把視頻做成二進(jìn)制分片上傳后，合并起來進(jìn)行轉(zhuǎn)碼。轉(zhuǎn)碼時(shí)再將視頻切分成不同時(shí)長(zhǎng)的片段進(jìn)行分片轉(zhuǎn)碼，完成后合并視頻。這種方式下通過提高并行程度降低了延時(shí)。在邊傳邊轉(zhuǎn)方式下，客戶端上傳存儲(chǔ)后，馬上進(jìn)行轉(zhuǎn)碼，客戶端操作與服務(wù)端服務(wù)并行，最后服務(wù)端會(huì)將源視頻、目標(biāo)視頻分別合并。

2.4 微博視頻處理系統(tǒng)面臨的挑戰(zhàn)













我們面對(duì)業(yè)務(wù)繁雜，需進(jìn)行基礎(chǔ)服務(wù)優(yōu)化的雙重挑戰(zhàn)。另外，微博業(yè)務(wù)具有很強(qiáng)的實(shí)時(shí)性，這就要求我們每環(huán)節(jié)都得快速完成，包括我們實(shí)現(xiàn)代碼的時(shí)間，接入業(yè)務(wù)方上線的時(shí)間。我們必須實(shí)現(xiàn)一個(gè)低延時(shí)、高并發(fā)、高可用、高性能的視頻轉(zhuǎn)碼服務(wù)。













視頻轉(zhuǎn)碼服務(wù)本身需要大量計(jì)算，需要大規(guī)模的集群支持這項(xiàng)服務(wù)。我們面臨的另外一個(gè)挑戰(zhàn)就是對(duì)大量集群的管理。由于我們使用了分片轉(zhuǎn)碼，邊傳邊轉(zhuǎn)的優(yōu)化方式，一個(gè)視頻切成十片，轉(zhuǎn)碼量會(huì)變成十倍，這導(dǎo)致轉(zhuǎn)碼任務(wù)量陡增，同時(shí)也會(huì)產(chǎn)生一個(gè)更細(xì)粒度的調(diào)度。切片給我們帶來更加復(fù)雜的任務(wù)依賴關(guān)系，我們要管理切片、分片并行轉(zhuǎn)碼以及合并整個(gè)過程中的任務(wù)依賴。過程中步驟越多，失敗率越高，越要求系統(tǒng)有更高的健壯性降低失敗。













我們今天主要講的就是如何實(shí)現(xiàn)一個(gè)低延時(shí)、高并發(fā)、高可用、高性能的系統(tǒng)，我將主要從以下幾個(gè)方面來說明。首先是高度靈活的配置生成系統(tǒng)，相當(dāng)于將業(yè)務(wù)相關(guān)的東西從主系統(tǒng)中抽離放到配置系統(tǒng)中，使主系統(tǒng)專注于基礎(chǔ)性能優(yōu)化和基礎(chǔ)服務(wù)。第二點(diǎn)要講的是基于DAG的邏輯組織框架即用工作流引擎去組織任務(wù)之間的依賴。最后會(huì)講一下高可用、高性能的任務(wù)調(diào)度器對(duì)系統(tǒng)的重要作用。

3. 微博視頻轉(zhuǎn)碼服務(wù)架構(gòu)設(shè)計(jì)




3.1 木林森










高度靈活的配置生成系統(tǒng)





對(duì)于靈活配置，我們?nèi)∶麨槟玖稚Ｋ且粋€(gè)基于樹形結(jié)構(gòu)的規(guī)則引擎，即我們的配置結(jié)果都是樹形結(jié)構(gòu)，多棵樹即可組成森林，所以我們?nèi)∶麨槟玖稚?。木林森支持靈活的配置生成。微博有些業(yè)務(wù)場(chǎng)景下產(chǎn)品方只要求快速而不在意視頻輸出屬性，這時(shí)我們可以直接使現(xiàn)有輸出業(yè)務(wù)與輸入業(yè)務(wù)連接完成業(yè)務(wù)接入。用這種方式可以提升新業(yè)務(wù)接入效率。下面是一個(gè)簡(jiǎn)單的示例。













如圖，例如我們有微博原生視頻接入業(yè)務(wù)，現(xiàn)在要接入的億幕視頻希望與原生視頻有相同的輸出。此時(shí)我們?cè)谳敵鰳I(yè)務(wù)以下到轉(zhuǎn)碼輸出都不需要改變，我們只需要將節(jié)點(diǎn)連接，輸入的億幕視頻就與微博原生視頻有了相同的輸出。只需通過后臺(tái)點(diǎn)擊配置就可將視頻接入。右圖所示是微博視頻的輸出配置。













復(fù)雜場(chǎng)景下，原生視頻，秒拍視頻，VIP視頻的輸出業(yè)務(wù)配置如圖。不同用戶端視頻經(jīng)過系統(tǒng)輸出的視頻是不同的。通過配置可完成復(fù)雜場(chǎng)景下的業(yè)務(wù)邏輯抽離。

3.2 DAG










基于DAG的邏輯組織框架





我們自己實(shí)現(xiàn)了一套工作流引擎框架來支撐我們的業(yè)務(wù)，首先介紹一下框架的思想。我們是基于Java開發(fā)的，這里用Java舉例。對(duì)于一般的上傳系統(tǒng)，代碼實(shí)現(xiàn)只有下載、轉(zhuǎn)碼、上傳的過程。在這一段代碼的基礎(chǔ)上，我們要實(shí)現(xiàn)分片轉(zhuǎn)碼，邊傳邊轉(zhuǎn)等復(fù)雜的邏輯流。最簡(jiǎn)單的方法就是我們將一般上傳的代碼復(fù)制改動(dòng)，這時(shí)我們的方式如右圖。上傳過程變?yōu)橄螺d，切片，將切片結(jié)果上傳，下載切片，切片轉(zhuǎn)碼，上傳切片，然后使這個(gè)過程循環(huán)往復(fù)，這時(shí)可多臺(tái)機(jī)器并行工作，最后將切片合并。由于過程復(fù)雜，所有我們希望能用有向無環(huán)圖連接組織，將基礎(chǔ)服務(wù)固化，通過腳本將不同功能組織起來。這時(shí)我們無論下載文件轉(zhuǎn)碼上傳還是分片上傳，只需簡(jiǎn)單連接即可，兩個(gè)下載之間的代碼是不需要改動(dòng)的。我們將可固化的部分固化，將代碼拆成一個(gè)個(gè)可獨(dú)立執(zhí)行的閉包，通過DAG管理包與包之間的關(guān)系，在DAG內(nèi)部實(shí)現(xiàn)閉包的執(zhí)行。這就是我們關(guān)于DAG框架的想法。













這是我們轉(zhuǎn)碼服務(wù)的圖示。如圖中，Center部分就是中央調(diào)度的服務(wù)，Runner部分是執(zhí)行轉(zhuǎn)碼任務(wù)的服務(wù)，videoTrans是DAG組織任務(wù)間關(guān)系的腳本。我們的腳本通過Groovy實(shí)現(xiàn)。框架名字叫做Olympiadane，是通過Groovy引擎執(zhí)行連成的關(guān)系，其中的Group是可獨(dú)立調(diào)度的單位，即圖中白色的部分。任務(wù)先經(jīng)過調(diào)度器，調(diào)度器根據(jù)情況分發(fā)到執(zhí)行器，執(zhí)行器內(nèi)部根據(jù)前后依賴關(guān)系順序執(zhí)行Task，在此例中就是下載，轉(zhuǎn)碼，上傳。另一臺(tái)機(jī)器也是一樣的。這樣就實(shí)現(xiàn)了執(zhí)行流與業(yè)務(wù)之間的解耦，如果要接入其他的新服務(wù)的話，我們只需要再實(shí)現(xiàn)一個(gè)Task，將此Task的依賴關(guān)系放入腳本即可完成。另外通過腳本生成的就是圖中的Job。這是我們DAG架構(gòu)。













實(shí)現(xiàn)DAG框架后，可以通過腳本快速接入支持業(yè)務(wù)，由于腳本變動(dòng)但Feature不是經(jīng)常變動(dòng)的，所以Feature可在腳本間共用，也可以獨(dú)立測(cè)試，這樣我們便可以完成可組裝的獨(dú)立組件。這些獨(dú)立組件具備可以獨(dú)立測(cè)試，易擴(kuò)展，易部署，高性能的特性。



















這里描述的是DAG的過程。前面我們提到的分片轉(zhuǎn)碼，過程分是下載，切片，上傳分片結(jié)果幾步。













例如有三個(gè)機(jī)器同時(shí)并行完成下載分片，轉(zhuǎn)碼，上傳結(jié)果的工作。當(dāng)并行過程結(jié)束后，會(huì)有一個(gè)新的依賴關(guān)系，如圖中，下載所有分片，合并轉(zhuǎn)碼后的視頻，不同清晰度的文件都是在不同機(jī)器上并行工作的。這是對(duì)我們轉(zhuǎn)碼服務(wù)優(yōu)化中，通過DAG組織的一次實(shí)踐。













如圖中，灰色的部分變成了綠色，這表示這個(gè)過程是可以觀測(cè)的，這也是通過DAG方式實(shí)現(xiàn)的一個(gè)優(yōu)勢(shì)。我們可以觀測(cè)任務(wù)執(zhí)行到了哪一步，也可以更快的定位出現(xiàn)問題的地方。另外，由于我們進(jìn)行了拆分，可以對(duì)獨(dú)立Feature進(jìn)行DAG切面，例如我們可以統(tǒng)計(jì)它的耗時(shí)，這樣我們可以知道哪種類型的業(yè)務(wù)耗時(shí)較長(zhǎng)，也有助于觀察系統(tǒng)的穩(wěn)定性。













在DAG的優(yōu)化方面，我們通過字節(jié)碼編譯技術(shù)做到了腳本快速執(zhí)行。另外我們引入了一些Protostuff技術(shù)快速完成資源存儲(chǔ)。

3.3 調(diào)度器










高可用、高性能的任務(wù)調(diào)度器





我們通過木林森將業(yè)務(wù)系統(tǒng)抽離出來，通過DAG系統(tǒng)將實(shí)現(xiàn)時(shí)的依賴關(guān)系抽離，因此我們需要一個(gè)好的調(diào)度系統(tǒng)來支撐。由于我們進(jìn)行了切片，因此調(diào)度任務(wù)達(dá)到了萬次每秒。我們也會(huì)需要更細(xì)粒度的調(diào)度任務(wù)，比起粗粒度的調(diào)度，對(duì)基礎(chǔ)組件性能要求更高。我們對(duì)調(diào)度器的另外一個(gè)設(shè)計(jì)目標(biāo)就是調(diào)度占比要低于百分之五，這就意味著系統(tǒng)損耗更低。這對(duì)調(diào)度器有極高要求，我們要使百分之九十九的調(diào)度任務(wù)在10ms內(nèi)分派到對(duì)應(yīng)機(jī)器，并且我們希望它的調(diào)度是最優(yōu)調(diào)度，即能準(zhǔn)確把任務(wù)分派到空閑機(jī)器。













在設(shè)計(jì)調(diào)度器時(shí)我們也做了一些思考。我們對(duì)中心化調(diào)度器和非中心化調(diào)度器做了對(duì)比。中心化調(diào)度器的調(diào)度準(zhǔn)確度高，它將資源隊(duì)列信息放到中心化存儲(chǔ)中，對(duì)監(jiān)控更親和。但是它的資源依賴較多，我們將隊(duì)列放到了資源中，因此資源訪問讀寫中會(huì)產(chǎn)生一定依賴，也會(huì)有一定性能損耗。對(duì)于去中心化調(diào)度器來說，它的擴(kuò)展性更強(qiáng)，但是它存在調(diào)度不準(zhǔn)確的問題。最終我們選擇了中心化調(diào)度方式。













上圖是調(diào)度器調(diào)度過程。左邊是調(diào)度器，右邊是執(zhí)行器。調(diào)度器和執(zhí)行器之間通過心跳注冊(cè)，心跳時(shí)間是可配置的。注冊(cè)完后會(huì)將機(jī)器信息放到機(jī)器隊(duì)列，中心資源中有一個(gè)任務(wù)優(yōu)先級(jí)隊(duì)列，我們可以對(duì)不同任務(wù)映射不同優(yōu)先級(jí)。另外一個(gè)是機(jī)器空閑優(yōu)先級(jí)隊(duì)列，就是我們將機(jī)器空閑度映射為優(yōu)先級(jí)。在派發(fā)時(shí)，我們會(huì)取到高優(yōu)先級(jí)任務(wù)，取到空閑度優(yōu)先級(jí)高的執(zhí)行器，然后將任務(wù)派到指定機(jī)器，即可將任務(wù)放到執(zhí)行隊(duì)列中。執(zhí)行隊(duì)列的重要作用在后面會(huì)講到。執(zhí)行結(jié)束后，會(huì)進(jìn)行一次回調(diào)，從執(zhí)行隊(duì)列中移除任務(wù)。我們通過三個(gè)隊(duì)列完成任務(wù)調(diào)度，由于存在資源依賴，所以我們對(duì)這些資源進(jìn)行了哈希計(jì)算，不同機(jī)器可以使用不同資源，只要資源滿足就可分派任務(wù)。













但是這里會(huì)有一個(gè)問題。心跳會(huì)匯報(bào)情況，但它會(huì)有一定延遲，如果Executor與資源中存儲(chǔ)的狀態(tài)產(chǎn)生差異，任務(wù)可能會(huì)被分派到一臺(tái)無法工作的機(jī)器。為解決此問題，我們?cè)O(shè)計(jì)了一個(gè)帶鎖的雙發(fā)調(diào)度。與之前介紹的相同，我們依然從隊(duì)列選擇機(jī)器。不同的是，我們會(huì)在空閑優(yōu)先級(jí)隊(duì)列中取到最優(yōu)的同時(shí)，取一個(gè)隨機(jī)機(jī)器去完成分派。分派后，執(zhí)行器會(huì)再一次調(diào)用調(diào)度器確認(rèn)由誰完成任務(wù)，再去執(zhí)行。當(dāng)最優(yōu)任務(wù)不可執(zhí)行時(shí)，另外一個(gè)機(jī)器可完成任務(wù)。這樣，我們就可以實(shí)現(xiàn)百分之九十九的任務(wù)在10毫秒內(nèi)完成分派的目的。同樣的，帶鎖雙發(fā)調(diào)度也會(huì)有哈希計(jì)算的存在。同時(shí)，我們會(huì)使用WatchDog觀察執(zhí)行隊(duì)列中的任務(wù)是否在規(guī)定時(shí)間完成，若沒有完成，我們會(huì)重新觸發(fā)調(diào)度器分派任務(wù)。這樣我們可以有效減慢失敗率提升。













通過以上設(shè)計(jì)，我們的調(diào)度器可以實(shí)現(xiàn)毫秒級(jí)派發(fā)。對(duì)于微博業(yè)務(wù)來說，可能會(huì)出現(xiàn)緊急大流量出現(xiàn)，我們?cè)谠O(shè)計(jì)時(shí)也考慮了水平伸縮方式，使它支持彈性擴(kuò)縮容。通過WatchDog機(jī)制，我們可以實(shí)現(xiàn)宕機(jī)自動(dòng)摘除。在實(shí)際應(yīng)用中，我們每天都會(huì)有機(jī)器擴(kuò)縮容，我們的做法是讓待擴(kuò)容機(jī)器不接受任務(wù)，先完成已有任務(wù)，再做機(jī)器擴(kuò)縮容工作。但這樣做還會(huì)有未完成的任務(wù)存在，通過WatchDog機(jī)制，我們可以確保這些任務(wù)重新分派完成。同時(shí)我們實(shí)現(xiàn)了4個(gè)9可用性。

3.4 部署













在轉(zhuǎn)碼服務(wù)部署方面，我們?cè)趦蓚€(gè)IDC部署了完全相同的兩套資源，它們有獨(dú)立的域名，獨(dú)立的部署。這么做的好處是我們可以在兩個(gè)機(jī)房間隨意的切流量，任一機(jī)房出現(xiàn)問題，我們都可以切換，但是兩個(gè)機(jī)房的部署并不是一比一的冗余。我們常備的機(jī)房是一個(gè)大規(guī)模集群，另一個(gè)機(jī)房是一個(gè)小規(guī)模的，或許只有常備機(jī)房十分之一的量。兩個(gè)機(jī)房在使用時(shí)可以分開，例如我們轉(zhuǎn)一些不影響用戶發(fā)博的轉(zhuǎn)碼輸出時(shí)，可以使用小機(jī)房完成任務(wù)，這樣大機(jī)房出現(xiàn)“災(zāi)難性”情況時(shí)，可以把流量切到小機(jī)房。當(dāng)然小機(jī)房是不能滿足那么大流量的，但是調(diào)度器本身的隊(duì)列有堆積的特性，可以將堆積的任務(wù)慢慢執(zhí)行。沒有大量機(jī)器冗余可以充分利用機(jī)器。

4. 總結(jié)













接下來，我將所有內(nèi)容做一個(gè)總結(jié)。通過轉(zhuǎn)碼服務(wù)的優(yōu)化提升，我們整體轉(zhuǎn)碼提速了5倍，集群利用率標(biāo)準(zhǔn)差下降了百分之五十。這里的標(biāo)準(zhǔn)差指由于分派任務(wù)不合理，分到不同清閑度的任務(wù)導(dǎo)致機(jī)器CPU利用率忽高忽低的情況。通過好的調(diào)度方式，對(duì)集群的利用率標(biāo)準(zhǔn)差有很大降低。另外，我們業(yè)務(wù)支撐的效率也成倍提升。我們通過各種方式進(jìn)行解耦，將變化大的和變化小的分開放到不同位置。













在服務(wù)架構(gòu)設(shè)計(jì)開發(fā)的過程中，我們使用了很多并行手段，包括機(jī)器并行、進(jìn)程并行、線程的并行以及算法、CPU核的并行等，通過這些手段發(fā)揮機(jī)器最大的價(jià)值。今天我們?cè)O(shè)計(jì)的目的是一個(gè)低延時(shí)高可用的系統(tǒng)，我們用到的并行上傳，并行轉(zhuǎn)碼，極致上傳等手段都用了算法上分治、遞歸、貪心的思想。在高可用方面使用了高內(nèi)聚低耦合的思想，用到了動(dòng)靜分離、自動(dòng)容錯(cuò)、異地多活的手段。最后想和大家分享，我們?cè)谧鱿到y(tǒng)架構(gòu)、設(shè)計(jì)優(yōu)化不知道該如何實(shí)現(xiàn)的時(shí)候，就可以無腦的把這些高內(nèi)聚低耦合、空間換時(shí)間等常見的思想往系統(tǒng)上套，或許就可以得到想要的結(jié)果。優(yōu)化架構(gòu)并不是多么復(fù)雜深?yuàn)W的東西，我們要去思考的是前人總結(jié)的這些手段在我們自己系統(tǒng)上的能否達(dá)到效果，如果得到了滿意的效果，那么這些思想就會(huì)轉(zhuǎn)化為我們自己的東西。