蜜桃av色欲a片精品一区,麻豆aⅴ精品无码一区二区,亚洲人成网站在线播放影院在线,亚洲 素人 字幕 在线 最新

  騰訊百億級(jí)大規(guī)模內(nèi)容處理系統(tǒng)探究

發(fā)布日期：2022/8/30 11:17:38      瀏覽量：

作者 | 騰訊內(nèi)容處理中臺(tái)技術(shù)團(tuán)隊(duì)

1. 背景介紹

騰訊內(nèi)容處理中臺(tái)是打通騰訊內(nèi)容生產(chǎn)、內(nèi)容處理、內(nèi)容分發(fā)、內(nèi)容變現(xiàn)等內(nèi)容生態(tài)閉環(huán)的核心基礎(chǔ)服務(wù)。作為銜接內(nèi)容生產(chǎn)端和內(nèi)容消費(fèi)端的關(guān)鍵路徑，旨在通過(guò)智能化、規(guī)?；娜藱C(jī)協(xié)同內(nèi)容處理和內(nèi)容審核等關(guān)鍵技術(shù)方案，對(duì)內(nèi)容供給端產(chǎn)生的各種形態(tài)內(nèi)容如視頻、圖文、商品、評(píng)論等，進(jìn)行安全化、標(biāo)準(zhǔn)化、算法化等流水線工業(yè)化處理，并將處理后的內(nèi)容統(tǒng)一分發(fā)到騰訊視頻、QQ 瀏覽器、騰訊新聞等多端渠道，為不同的用戶群體提供更好、更高效的內(nèi)容服務(wù)體驗(yàn)。

圖 1-1 內(nèi)容生態(tài)概覽圖

2. 問(wèn)題和挑戰(zhàn)

騰訊內(nèi)容處理中臺(tái)作為工業(yè)化內(nèi)容處理技術(shù)基座，面對(duì)多元化的業(yè)務(wù)渠道以及海量復(fù)雜多樣的內(nèi)容處理訴求，需要不斷抽象業(yè)務(wù)模型，構(gòu)建高效穩(wěn)定的場(chǎng)景化內(nèi)容處理審核服務(wù)拓?fù)滏溌?，?lái)滿足內(nèi)容生態(tài)各種內(nèi)容處理場(chǎng)景。因此，我們需要重點(diǎn)解決解決以下幾個(gè)關(guān)鍵核心問(wèn)題。

圖 2-1 內(nèi)容處理中臺(tái)關(guān)鍵問(wèn)題

問(wèn)題 1：百億級(jí)的異構(gòu)元數(shù)據(jù)內(nèi)容物料接入

由于騰訊每個(gè)渠道產(chǎn)品都有自身產(chǎn)品的內(nèi)容類型及內(nèi)容調(diào)性需求，比如視頻、圖文、音頻、直播、商品、評(píng)論、賬號(hào)、標(biāo)簽等，面對(duì)這樣多態(tài)性的內(nèi)容，需要進(jìn)行標(biāo)準(zhǔn)模板化處理，并提供業(yè)務(wù)場(chǎng)景化的內(nèi)容預(yù)處理機(jī)制，同時(shí)為了能夠唯一識(shí)別內(nèi)容，從中臺(tái)視角，需要提供內(nèi)容中臺(tái)的統(tǒng)一內(nèi)容 ID 以及和各業(yè)務(wù)渠道映射關(guān)聯(lián)的 ID-Mapping 服務(wù)。

問(wèn)題 2：?jiǎn)捂溌窋?shù)百個(gè)算子微服務(wù)低代碼樂(lè)高式編排

由于騰訊各個(gè)渠道業(yè)務(wù)既有通用公共內(nèi)容處理邏輯訴求，又有各自個(gè)性化的內(nèi)容處理邏輯訴求，且內(nèi)容處理服務(wù)鏈路通常涉及到 AI 能力和審核等多個(gè)服務(wù)提供方和多種協(xié)同模式的編排。因此，如何支持快速集成到端到端處理流程，提高研發(fā)效率，降低搭建內(nèi)容處理流程成本，成為內(nèi)容中臺(tái)架構(gòu)的核心關(guān)鍵之一。內(nèi)容中臺(tái)需要對(duì)系統(tǒng)進(jìn)行高度的抽象化處理，通過(guò)可插拔的插件模式進(jìn)行標(biāo)準(zhǔn)化，并提供高度靈活的低代碼形態(tài)多元化內(nèi)容處理服務(wù)編排能力。

問(wèn)題 3：每日數(shù)十億次任務(wù)毫秒級(jí)優(yōu)先級(jí)可靠調(diào)度執(zhí)行

面對(duì)每天數(shù)千萬(wàn)的各類圖文、視頻等海量?jī)?nèi)容處理需求，需要在數(shù)千個(gè)內(nèi)容編排任務(wù)鏈路上在線流式運(yùn)行，保障數(shù)十億次任務(wù)調(diào)度毫秒級(jí)的延遲，并保障存儲(chǔ)資源的低成本訴求，對(duì)我們構(gòu)建消息隊(duì)列系統(tǒng)、調(diào)度系統(tǒng)、運(yùn)行系統(tǒng)、存儲(chǔ)系統(tǒng)等都形成了較大挑戰(zhàn)。同時(shí)，在面對(duì)復(fù)雜內(nèi)容處理系統(tǒng)，如何構(gòu)建全鏈路運(yùn)行優(yōu)化機(jī)制也十分重要，只有這樣才能為騰訊內(nèi)部各個(gè)渠道業(yè)務(wù)方提供高效穩(wěn)定的定制化內(nèi)容分發(fā)服務(wù)。

問(wèn)題 4：端到端的可觀測(cè)性和服務(wù)穩(wěn)定性

系統(tǒng)中每一條內(nèi)容處理流程接入數(shù)百個(gè)處理能力，每一個(gè)能力的處理容量，可用性，服務(wù)方式都不一樣，如何保障系統(tǒng)在各種協(xié)同系統(tǒng)故障時(shí)能夠快速發(fā)現(xiàn)、定位、解決問(wèn)題，以及如何應(yīng)對(duì)突發(fā)流量，提升系統(tǒng)穩(wěn)定性等問(wèn)題都對(duì)系統(tǒng)提出了更高的要求。

3. 系統(tǒng)詳解

3.1 整體架構(gòu)

為了更好地理解內(nèi)容處理中臺(tái)工作的交互流程，下面將從業(yè)務(wù)架構(gòu)圖和技術(shù)架構(gòu)圖對(duì)內(nèi)容生態(tài)領(lǐng)域工業(yè)化處理中臺(tái)進(jìn)行簡(jiǎn)要的介紹。

3.1.1 業(yè)務(wù)架構(gòu)圖

圖 3-1 內(nèi)容處理中臺(tái)業(yè)務(wù)架構(gòu)圖

內(nèi)容處理工業(yè)化業(yè)務(wù)架構(gòu)和我們熟悉的傳統(tǒng)工廠流水線生產(chǎn)模式極為相似。我們從端到端將整個(gè)內(nèi)容工業(yè)流水線生命周期分為了 7 大子系統(tǒng)：接入系統(tǒng)、消息系統(tǒng)、存儲(chǔ)系統(tǒng)、組件系統(tǒng)、編排系統(tǒng)、調(diào)度系統(tǒng)、運(yùn)行系統(tǒng)等。同時(shí)對(duì)關(guān)鍵核心功能進(jìn)行了關(guān)鍵解耦，以滿足騰訊內(nèi)部各渠道對(duì)內(nèi)容原料的復(fù)雜多變的私有化處理需求，支持多渠道高效分發(fā)。

3.1.2 技術(shù)架構(gòu)圖

圖 3-2 內(nèi)容處理中臺(tái)技術(shù)概覽圖

接入系統(tǒng)：針對(duì)問(wèn)題 1，主要解決騰訊內(nèi)部各渠道多形態(tài)內(nèi)容物料的自動(dòng)化接入適配問(wèn)題，支持對(duì)內(nèi)容進(jìn)行預(yù)處理，比如篩選、合并等。同時(shí)，為了保障內(nèi)容物料在內(nèi)容處理中臺(tái)的唯一性，中臺(tái)對(duì)內(nèi)容進(jìn)行唯一識(shí)別碼賦值?；诮y(tǒng)一的內(nèi)容 ID 體系，內(nèi)容作為最基本的數(shù)據(jù)單元在各系統(tǒng)間流轉(zhuǎn)和調(diào)度，中臺(tái)也以內(nèi)容為核心視角來(lái)構(gòu)建業(yè)務(wù)。

插件系統(tǒng)：針對(duì)問(wèn)題 2，主要解決內(nèi)容處理服務(wù)能力原子化和標(biāo)準(zhǔn)化的問(wèn)題，使用戶能夠在全鏈路復(fù)用、共享、擴(kuò)展內(nèi)容處理能力，同時(shí)大幅降低業(yè)務(wù)使用方的開(kāi)發(fā)成本。通過(guò)對(duì)服務(wù)處理能力的協(xié)議抽象，有效地避免了對(duì)基礎(chǔ)內(nèi)容處理功能的重復(fù)建設(shè)，比如常見(jiàn)的內(nèi)容算法服務(wù)、內(nèi)容工具服務(wù)等；同時(shí)，也對(duì)內(nèi)容處理服務(wù)提出了標(biāo)準(zhǔn)化的服務(wù)范式，提供零開(kāi)發(fā)組件導(dǎo)入，組件同步執(zhí)行、異步執(zhí)行的能力。

編排系統(tǒng)：針對(duì)問(wèn)題 2，主要解決用戶構(gòu)建內(nèi)容處理鏈路的易用性、高效性問(wèn)題，低代碼 + 代碼化多元化模式構(gòu)建內(nèi)容處理工業(yè)化流水線工作。

• Pipeline 模式：適合更低的熟悉成本、更快的開(kāi)發(fā)，基于算子插件組成 stage，stage 內(nèi)部的多個(gè)插件并行執(zhí)行，多個(gè) stage 之間串行流轉(zhuǎn)構(gòu)成內(nèi)容處理鏈路。同時(shí)，我們提供基于 YAML 構(gòu)建任務(wù)拓?fù)?、更好的編碼體驗(yàn)、代碼式多版本管理。

• DAG 模式：適合較低的開(kāi)發(fā)成本、較好的業(yè)務(wù)理解，基于有向無(wú)環(huán)圖，構(gòu)建業(yè)務(wù)場(chǎng)景化內(nèi)容處理服務(wù)分支鏈路，讓開(kāi)發(fā)同學(xué)可以有更清晰的業(yè)務(wù)認(rèn)知。

調(diào)度系統(tǒng)：針對(duì)問(wèn)題 3，主要解決日均數(shù)十億次任務(wù)調(diào)度的低延遲、優(yōu)先級(jí)隊(duì)列等問(wèn)題，并建設(shè)智能反壓機(jī)制。

運(yùn)行系統(tǒng)：針對(duì)問(wèn)題 3，主要解決全鏈路端到端，涵蓋請(qǐng)求智能路由、彈性執(zhí)行、代理執(zhí)行、執(zhí)行流控、狀態(tài)微批持久化、結(jié)果共享等核心運(yùn)行優(yōu)化機(jī)制。

存儲(chǔ)系統(tǒng)：主要解決內(nèi)容處理的列更新場(chǎng)景以及寬表存儲(chǔ)問(wèn)題，同時(shí)，在降本提效的基礎(chǔ)上，基于多租戶機(jī)制，建設(shè)私有和共有的存儲(chǔ)服務(wù)。

觀測(cè)系統(tǒng)：針對(duì)問(wèn)題 4，主要解決多系統(tǒng)融合后的可觀測(cè)性，包括對(duì)內(nèi)容粒度和工程質(zhì)量的核心指標(biāo)秒級(jí)觀測(cè)洞察等。

相關(guān)術(shù)語(yǔ)

3.2 接入系統(tǒng)

為了應(yīng)對(duì)百億級(jí)的異構(gòu)元數(shù)據(jù)內(nèi)容物料接入的挑戰(zhàn)，針對(duì)多元化的騰訊各業(yè)務(wù)渠道的內(nèi)容數(shù)據(jù)，接入系統(tǒng)主要需要解決的是數(shù)據(jù)標(biāo)準(zhǔn)化處理與自動(dòng)化接入的問(wèn)題，并把業(yè)務(wù)內(nèi)容及其原始屬性轉(zhuǎn)化為星航系統(tǒng)能夠標(biāo)記、識(shí)別和處理的元素。

圖 3-3 接入系統(tǒng)流程

為更好的支撐復(fù)雜業(yè)務(wù)場(chǎng)景以及敏捷接入需求，接入系統(tǒng)在設(shè)計(jì)實(shí)現(xiàn)上具備了以下能力要素：

• 標(biāo)準(zhǔn)化：針對(duì)常用的內(nèi)容形式制定了不同內(nèi)容類型的標(biāo)準(zhǔn)化協(xié)議，最大程度提高星航管線間的能力復(fù)用以及降低數(shù)據(jù)理解成本；

• 可擴(kuò)展：在標(biāo)準(zhǔn)化協(xié)議之上保留了可擴(kuò)展性，業(yè)務(wù)可以通過(guò)追加附加協(xié)議定制個(gè)性化的數(shù)據(jù)字段，滿足標(biāo)準(zhǔn)字段外的業(yè)務(wù)個(gè)性化需求；

• 低代碼：JSON 協(xié)議定義的高度可擴(kuò)展性以及 JsonPath 解析的靈活性以及完備的數(shù)據(jù) schema 和校驗(yàn)，實(shí)現(xiàn)業(yè)務(wù)接入特征的配置化解析；

• 自動(dòng)化：提供管理端，業(yè)務(wù)方按照約定的方式自助錄入內(nèi)容接入以及特征定義，節(jié)約對(duì)接運(yùn)營(yíng)成本；

3.2.1 內(nèi)容類型

由于騰訊內(nèi)部不同渠道業(yè)務(wù)的調(diào)性定位不同，接入系統(tǒng)需要高度抽象，統(tǒng)一處理不同類型的內(nèi)容信息。

圖 3-4 各業(yè)務(wù)的內(nèi)容類型

3.2.2 內(nèi)容 ID 體系

由于歷史發(fā)展原因，各渠道業(yè)務(wù)線的內(nèi)容 ID 體系不一，ID 存在生成方案不統(tǒng)一、長(zhǎng)短不一、ID 可能沖突的問(wèn)題。內(nèi)容中臺(tái)作為內(nèi)容的橋梁，需要對(duì)各渠道的 ID 進(jìn)行標(biāo)準(zhǔn)化映射到星航平臺(tái)內(nèi)容統(tǒng)一 ID，并進(jìn)行統(tǒng)一管理。

圖 3-5 內(nèi)容中臺(tái) ID 和各渠道業(yè)務(wù) ID 映射體系

為便于騰訊各業(yè)務(wù)層面的內(nèi)容運(yùn)營(yíng)管理，內(nèi)容處理中臺(tái)的內(nèi)容 ID 中，希望能夠日期信息方便數(shù)據(jù)管理和定位；同時(shí)，系統(tǒng)層面上，需滿足以下要求：

• 全局唯一：全局唯一不能重復(fù)

• 趨勢(shì)遞增：日期相關(guān)，盡量保障數(shù)據(jù)的有序性

• 低延遲：接口耗時(shí)低，毫秒級(jí)別

• 高可用：底層服務(wù)，系統(tǒng)可用性要求高

• 容量：億級(jí) / 天

基于底層組件的穩(wěn)定性以及運(yùn)維成本考慮，我們選擇分布式數(shù)據(jù)庫(kù)自增的方式。為了規(guī)避 DB 取號(hào)段的過(guò)程消耗網(wǎng)絡(luò)耗時(shí)影響請(qǐng)求響應(yīng)，采用雙 buffer 的方式，程序內(nèi)存有兩個(gè)號(hào)段緩存區(qū) segment。當(dāng)前號(hào)段已下發(fā)特定百分比時(shí)，如果下一個(gè)號(hào)段未更新，則另啟一個(gè)更新線程去更新下一個(gè)號(hào)段。當(dāng)前號(hào)段全部下發(fā)完后，如果下個(gè)號(hào)段準(zhǔn)備好了則切換到下個(gè)號(hào)段為當(dāng)前 segment 接著下發(fā)，循環(huán)往復(fù)。

3.3 插件系統(tǒng)

插件是內(nèi)容處理平臺(tái)編排的核心組件之一，它是對(duì)算法特征、質(zhì)量特征、策略邏輯、人工審核處理等的原子化微服務(wù)或者云函數(shù)能力抽象，插件包含了插件 ID、版本、微服務(wù)的服務(wù)名、輸入、輸出、分類等重要屬性。

圖 3-6 插件的分類和示例

在業(yè)務(wù)層面上，插件主要分為：算法特征、質(zhì)量特征、策略邏輯、人工審核等類型；在平臺(tái)層面上，為了適配不同性能的插件，按照耗時(shí)長(zhǎng)短分成同步插件、異步插件。異步插件包含發(fā)送插件與查詢插件。

3.3.1 開(kāi)發(fā)模式

對(duì)于業(yè)務(wù)使用方，研發(fā)效率的關(guān)鍵主要包括插件開(kāi)發(fā)和管線編排等鏈路環(huán)節(jié)，插件主要包括兩大類：自定義協(xié)議插件和代理協(xié)議插件（普通插件、腳本插件、函數(shù)插件）。因此，我們?cè)诓寮_(kāi)發(fā)模式的道路上也做了大量的探索和迭代演進(jìn)。

3.3.1.1 代理協(xié)議插件

圖 3-7 代理協(xié)議插件開(kāi)發(fā)模式演進(jìn)

普通模式

普通插件的創(chuàng)建流程主要分為如下 7 個(gè)步驟：

• 開(kāi)發(fā)部署；

• • 熟悉 RPC 開(kāi)發(fā)框架，了解星航插件協(xié)議；

  • 代碼開(kāi)發(fā)、同步 git 倉(cāng)庫(kù)；

  • 服務(wù)創(chuàng)建、審批、編譯、發(fā)布、測(cè)試；

• 注冊(cè)插件；

• 編排管線；

• 管線執(zhí)行；

圖 3-8 普通插件開(kāi)發(fā)模式

對(duì)于普通開(kāi)發(fā)模式，內(nèi)容處理中臺(tái)本身無(wú)需介入管線開(kāi)發(fā)者的開(kāi)發(fā)和部署環(huán)節(jié)，只要開(kāi)發(fā)者實(shí)現(xiàn)了上文提到的插件協(xié)議即可。但是，普通模式存在一定的優(yōu)化空間，因?yàn)閯?chuàng)建一個(gè)功能簡(jiǎn)單的插件，也需要上述多個(gè)步驟，導(dǎo)致創(chuàng)建普通插件成本相對(duì)較高。

腳本模式

在許多輕量的內(nèi)容處理業(yè)務(wù)場(chǎng)景中，我們可能只需要一些對(duì)內(nèi)容進(jìn)行簡(jiǎn)單的邏輯處理。為了優(yōu)化普通插件開(kāi)發(fā)的成本，星航提供了一種用戶僅需提供業(yè)務(wù)處理邏輯代碼，無(wú)需關(guān)注創(chuàng)建插件的過(guò)程中無(wú)需了解協(xié)議、編譯、部署、擴(kuò)縮容等問(wèn)題的腳本開(kāi)發(fā)模式。

圖 3-9 腳本插件開(kāi)發(fā)模式

如下圖創(chuàng)建一個(gè)簡(jiǎn)單的 echo demo，創(chuàng)建插件的過(guò)程中，用戶只需要關(guān)注業(yè)務(wù)代碼，極大簡(jiǎn)化了插件的創(chuàng)建流程，而且修改代碼后邏輯可直接生效，沒(méi)有延遲。

圖 3-10 腳本插件開(kāi)發(fā) UI 示例

函數(shù)模式

對(duì)于腳本插件模式，由于是基于 Go + 腳本語(yǔ)言實(shí)現(xiàn)，主要存在 2 類問(wèn)題：

a）腳本插件存在調(diào)試?yán)щy、適用于簡(jiǎn)單的需求場(chǎng)景、外部系統(tǒng)交互不易實(shí)現(xiàn)等缺點(diǎn)；

b）腳本插件多任務(wù)處理流中共享代碼邏輯，因此，邏輯更新、結(jié)果共享都存在一定的局限性。

基于以上問(wèn)題，我們參考云原生時(shí)代的解決方案，實(shí)現(xiàn)了函數(shù)插件。用戶僅需關(guān)注業(yè)務(wù)代碼，平臺(tái)側(cè)根據(jù)用戶提供的代碼信息，完成從函數(shù)到服務(wù)完全自動(dòng)的 CICD【函數(shù) ->可編譯的服務(wù) -> 鏡像 -> 發(fā)布 -> 運(yùn)行擴(kuò)縮容】。具體流程如下圖：

圖 3-11 函數(shù)插件開(kāi)發(fā)模式

3.3.1.2 自定義協(xié)議插件

由于開(kāi)發(fā)環(huán)境和歷史因素，部分渠道業(yè)務(wù)的插件能力使用了自定義協(xié)議，為了不額外增加開(kāi)發(fā)部署代理協(xié)議插件模式的適配層服務(wù)，需要解決快速導(dǎo)入渠道自定義插件服務(wù)的共性問(wèn)題。

圖 3-12 自定義協(xié)議插件流程示例

PB 協(xié)議除開(kāi)常用的靜態(tài)引用，還存在動(dòng)態(tài)解析執(zhí)行的方式，因此中臺(tái)可以提供服務(wù) PB 協(xié)議的注冊(cè)、解析功能。具體的操作與執(zhí)行步驟如下：

• ?插件開(kāi)發(fā)者，首先在平臺(tái)注冊(cè)自定義的 PB 協(xié)議，中臺(tái)協(xié)議代理保存并動(dòng)態(tài)預(yù)反射解析協(xié)議；

• 插件開(kāi)發(fā)者創(chuàng)建新插件時(shí)，引用新協(xié)議，并配置插件協(xié)議與自定義協(xié)議的字段 JsonPath 映射關(guān)系列表?；

• 中臺(tái)的執(zhí)行器在調(diào)用插件代理時(shí)，協(xié)議代理會(huì)按照 JsonPath 映射關(guān)系，把插件協(xié)議的請(qǐng)求轉(zhuǎn)換成自定義協(xié)議的請(qǐng)求，進(jìn)而繼續(xù)調(diào)用 PB 中指定的 RPC 接口；

• 中臺(tái)獲得響應(yīng)后，采用類似的方式，把自定義協(xié)議的響應(yīng)再轉(zhuǎn)換成插件協(xié)議的響應(yīng)。最終執(zhí)行器拿到了插件協(xié)議的響應(yīng)，繼續(xù)調(diào)用后續(xù)插件。

對(duì)于插件開(kāi)發(fā)者來(lái)說(shuō)，整個(gè)過(guò)程是自助化、配置化的，沒(méi)有開(kāi)發(fā)協(xié)議轉(zhuǎn)換代碼與轉(zhuǎn)換服務(wù)，可以達(dá)到快速導(dǎo)入自定義協(xié)議服務(wù)的目的。

3.3.2 調(diào)試模式

插件創(chuàng)建成功后，為了便捷地驗(yàn)證接口與功能的正確性，插件支持在線模式的調(diào)試。按照預(yù)定義的插件輸入?yún)?shù)列表進(jìn)行填充輸入?yún)?shù)，通過(guò)隨機(jī)選擇后臺(tái)任一節(jié)點(diǎn)方式，即可獲取插件的響應(yīng)結(jié)果。另外，還支持生產(chǎn)環(huán)境下的插件灰度調(diào)試功能：先灰度發(fā)布少量服務(wù)節(jié)點(diǎn)，再到頁(yè)面指定灰度節(jié)點(diǎn)進(jìn)行請(qǐng)求調(diào)試。

圖 3-13 在線調(diào)試示例

3.3.3 運(yùn)營(yíng)模式

開(kāi)放是協(xié)作的基石，足夠開(kāi)放，才可以讓協(xié)作足夠順暢。為了解決內(nèi)容生態(tài)基建能力的復(fù)用性和擴(kuò)展性，我們采用多方共建維護(hù)的運(yùn)營(yíng)模式，打造了算法插件市場(chǎng)，連接騰訊內(nèi)部多個(gè)部門的職能，共同營(yíng)造現(xiàn)代化的內(nèi)容處理鏈路。比如：插件開(kāi)發(fā)者在機(jī)器學(xué)習(xí)平臺(tái)訓(xùn)練算法模型并部署服務(wù)后，可以直接注冊(cè)成插件。再當(dāng)試跑數(shù)據(jù)滿足準(zhǔn)召指標(biāo)后，即可被引入到插件市場(chǎng)。

圖 3-14 插件運(yùn)營(yíng)模式

當(dāng)前 30 多個(gè)團(tuán)隊(duì)參與共建，插件累計(jì)達(dá)到數(shù)千個(gè)。

圖 3-15 插件市場(chǎng)線上示例

3.4 編排系統(tǒng)

為了應(yīng)對(duì)單鏈路數(shù)百個(gè)算子微服務(wù)低代碼樂(lè)高式編排的挑戰(zhàn)，內(nèi)容處理中臺(tái)提供了兩種編排模式：pipeline 模式鏈?zhǔn)骄幣牛m合比較簡(jiǎn)單的業(yè)務(wù)場(chǎng)景；DAG 模式有向無(wú)環(huán)圖編排，適合分支較多、比較復(fù)雜的業(yè)務(wù)場(chǎng)景。

圖 3-16 任務(wù)編排拓?fù)漕愋?

值得注意的是，每個(gè)管線允許多個(gè)編排版本的存在，內(nèi)容會(huì)根據(jù)灰度比例進(jìn)入不同版本的編排，實(shí)現(xiàn)不同的流程。

3.4.1 Pipeline

3.4.1.1 管線

管線的基本元素有 Materials（內(nèi)容源）、Triggers（觸發(fā)事件）、Stage（階段）、Task（任務(wù) / 插件）、Deliverpoint（交付點(diǎn)）、Deliverables（交付物），其含義為

圖 3-17 Pipeline 編排模式示意圖

3.4.1.2 插件集

對(duì)于流程比較簡(jiǎn)單的業(yè)務(wù)，我們提供了插件集模式（Pipelite）。插件集是簡(jiǎn)化版的管線功能，將整個(gè)管線流程封裝成一個(gè)同步接口，用戶通過(guò) RPC 調(diào)用的方式輸入內(nèi)容材料（Materials），接口輸出內(nèi)容特征（Deliverables）。

圖 3-18 插件集示意圖

管線和插件集的區(qū)別如下：

3.4.2 DAG

我們基于 BPMN（Business Process Model and Notation）2.0 標(biāo)準(zhǔn)，構(gòu)建了管線編排的 DAG 模式，用于支持比較復(fù)雜的業(yè)務(wù)模型。主要的元素有：

圖 3-19 DAG 編排模式示例

上圖為線上一個(gè)基礎(chǔ)的 DAG 管線，內(nèi)容通過(guò)事件網(wǎng)關(guān)區(qū)分不同事件流程，在不同的分支上進(jìn)行處理，最后匯總到結(jié)束點(diǎn)。

3.5 消息系統(tǒng)

消息是調(diào)度系統(tǒng)運(yùn)轉(zhuǎn)的催化劑，內(nèi)容處理系統(tǒng)整個(gè)生命周期中產(chǎn)生大量數(shù)十億級(jí)的消息信號(hào)，如業(yè)務(wù)內(nèi)容類消息、外部干預(yù)類消息、系統(tǒng)工程類消息信號(hào)等。因此，需要一個(gè)統(tǒng)一的消息系統(tǒng)來(lái)及時(shí)可靠地處理這些海量消息。

3.5.1 設(shè)計(jì)目標(biāo)

消息系統(tǒng)需要從多方面保障其服務(wù)質(zhì)量，主要包括如下：

（1）消息需要保證可靠性，特別是發(fā)文消息還需要保證時(shí)序性；

（2）不同類型的消息對(duì)時(shí)效性要求不同，需要分級(jí)處理消息隊(duì)列；

（3）整體消息量非常大，需要保證處理及時(shí)；

（4）推送失敗時(shí)，需要重試但不能阻塞后續(xù)消息；

3.5.2 技術(shù)架構(gòu)

圖 3-20 消息系統(tǒng)架構(gòu)

（1）消息接入服務(wù)：作為接入層，負(fù)責(zé)消息的接入和校驗(yàn)等工作，并根據(jù)消息類型路由到不同的消息隊(duì)列。通過(guò)為不同的業(yè)務(wù)分配不同的 topic 進(jìn)行業(yè)務(wù)隔離，創(chuàng)建多分區(qū)來(lái)提高吞吐量。同時(shí)為了保證同一個(gè)內(nèi)容的消息的時(shí)序性，使用星航平臺(tái)統(tǒng)一內(nèi)容 ID，作為 key 保證哈希到同一個(gè)分區(qū)。

（2）消息處理服務(wù)：負(fù)責(zé)持續(xù)消費(fèi)消息隊(duì)列，根據(jù)消息類型調(diào)用對(duì)應(yīng)的服務(wù)。其中對(duì)外部干預(yù)類消息的處理，需要考慮一條消息會(huì)干預(yù)多個(gè)管線中的同一條內(nèi)容。例如，外部檢測(cè)到一篇文章的熱度達(dá)到了閾值，需要干預(yù)多條管線中的這篇文章都跳轉(zhuǎn)到人審環(huán)節(jié)，這時(shí)需要并發(fā)調(diào)用多個(gè)管線的狀態(tài)跳轉(zhuǎn)服務(wù)。如果對(duì)有些管線處理失敗了，需要將這條消息以及這次各個(gè)管線處理的結(jié)果，都發(fā)送到延時(shí)隊(duì)列，用于下次重試時(shí)不重復(fù)處理。使用延時(shí)隊(duì)列，能夠避免阻塞消息隊(duì)列里后面的消息。而對(duì)于延時(shí)策略，使用指數(shù)退避算法（Exponential Backoff），根據(jù)失敗次數(shù)延長(zhǎng)下次調(diào)度時(shí)間，失敗次數(shù)每增加 1 次，延時(shí)時(shí)長(zhǎng)增加 1 倍，同時(shí)為了避免同時(shí)到期，還在延時(shí)上增加一個(gè)波動(dòng)值。另外還考慮到，如果延時(shí)一直增加，當(dāng)接收服務(wù)的故障恢復(fù)時(shí)無(wú)法及時(shí)感知，因此會(huì)延遲遞增到設(shè)定值后會(huì)周期性重頭計(jì)算。

（3）狀態(tài)跳轉(zhuǎn)服務(wù)：每個(gè)管線有對(duì)應(yīng)的狀態(tài)跳轉(zhuǎn)服務(wù)，接收外部干預(yù)類消息，判斷管線中的內(nèi)容應(yīng)該跳轉(zhuǎn)到哪個(gè)步驟，并更新存儲(chǔ)狀態(tài)，然后存儲(chǔ)代理發(fā)送調(diào)度消息到消息隊(duì)列，供調(diào)度系統(tǒng)進(jìn)行調(diào)度。

3.6 調(diào)度系統(tǒng)

對(duì)于每日數(shù)十億次任務(wù)毫秒級(jí)優(yōu)先級(jí)可靠調(diào)度執(zhí)行的挑戰(zhàn)，調(diào)度系統(tǒng)是內(nèi)容處理鏈路的核心子系統(tǒng)之一，它需要保障每天千萬(wàn)級(jí)內(nèi)容數(shù)十億次任務(wù)的高效調(diào)度處理工作，由多個(gè)任務(wù)單元組成，任務(wù)單元之間存在時(shí)間先后順序和前后依賴關(guān)系，本質(zhì)是一個(gè)任務(wù)鏈路編排是一個(gè)工作流，需要由調(diào)度系統(tǒng)對(duì)多個(gè)工作流進(jìn)行管理和調(diào)度。

對(duì)工作流的描述方式，常用的有 FSM（Finite State Machine，有限狀態(tài)機(jī)）和 DAG（Directed Acyclic Graph，有向無(wú)環(huán)圖）。這兩種方式各有優(yōu)缺點(diǎn)，適用的場(chǎng)景有所不同。

FSM 為每個(gè)步驟設(shè)定一個(gè)狀態(tài)，每個(gè)步驟可以有多個(gè)任務(wù)并行執(zhí)行，步驟之間順序執(zhí)行，也能跳轉(zhuǎn)到指定步驟重復(fù)執(zhí)行。FSM 適合處理過(guò)程簡(jiǎn)單，狀態(tài)明確的內(nèi)容處理場(chǎng)景。

DAG 是每個(gè)節(jié)點(diǎn)一個(gè)狀態(tài)，能描述復(fù)雜的依賴關(guān)系，還支持子圖減少重復(fù)執(zhí)行步驟，但所有節(jié)點(diǎn)的狀態(tài)集合才能表示當(dāng)前的狀態(tài)，不便于觀測(cè)。DAG 適合處理過(guò)程復(fù)雜，條件繁多的內(nèi)容處理場(chǎng)景。

目前星航調(diào)度系統(tǒng)支持這兩種工作流模型，跟據(jù)當(dāng)前的狀態(tài)執(zhí)行對(duì)應(yīng)的任務(wù)步驟，然后更新?tīng)顟B(tài)和結(jié)果屬性，記錄執(zhí)行的事件流水，方便全鏈路觀測(cè)。

3.6.1 設(shè)計(jì)目標(biāo)

（1）調(diào)度任務(wù)以內(nèi)容為粒度，任務(wù)量大，時(shí)效性要求高；

（2）需要支持內(nèi)容級(jí)別的調(diào)度優(yōu)先級(jí)；

（3）需要支持分布式調(diào)度，動(dòng)態(tài)調(diào)配資源，并支持業(yè)務(wù)隔離；

（4）能夠?qū)γ織l內(nèi)容進(jìn)行全鏈路觀測(cè)。

3.6.2 技術(shù)架構(gòu)

圖 3-21 工作流調(diào)度系統(tǒng)示意圖

Scheduler：任務(wù)調(diào)度模塊，負(fù)責(zé)從存儲(chǔ)模塊獲取任務(wù)分配給執(zhí)行器。

Executor：執(zhí)行器模塊，負(fù)責(zé)從調(diào)度模塊獲取任務(wù)，從元數(shù)據(jù)中心獲取工作流配置，調(diào)用相關(guān)插件進(jìn)行計(jì)算，最后將結(jié)果寫回存儲(chǔ)模塊。

Storage：加工存儲(chǔ)模塊，存儲(chǔ)內(nèi)容處理任務(wù)狀態(tài)屬性和事件流水。

MetaCenter：元數(shù)據(jù)中心，存儲(chǔ)用戶編排的工作流配置和管線其他相關(guān)元數(shù)據(jù)。

Plugin：插件，統(tǒng)一封裝業(yè)務(wù)方提供的原子化的計(jì)算能力。

3.6.3 執(zhí)行機(jī)制

3.6.3.1 優(yōu)先調(diào)度隊(duì)列

內(nèi)容處理的調(diào)度，需要考慮任務(wù)量大，時(shí)效性要求高，還要能按內(nèi)容優(yōu)先級(jí)進(jìn)行調(diào)度。借鑒流式處理方式，調(diào)度流程使用消息隊(duì)列進(jìn)行傳輸任務(wù)。

圖 3-22 調(diào)度系統(tǒng)流程示意

• 加工存儲(chǔ)模塊，記錄每條任務(wù)的狀態(tài)和執(zhí)行結(jié)果，在收到新增和更新的請(qǐng)求后，會(huì)將需要調(diào)度的任務(wù)發(fā)送到 kakfa 任務(wù)隊(duì)列。這種方式比起常規(guī)的輪詢?nèi)蝿?wù)的方式，時(shí)效性更高，并且能減少重復(fù)的任務(wù)發(fā)送。

• 為了增加系統(tǒng)可靠性，當(dāng)任務(wù)隊(duì)列集群不穩(wěn)定或故障時(shí)，會(huì)將任務(wù)發(fā)送到補(bǔ)償隊(duì)列，保障任務(wù)不丟失。

• 調(diào)度隊(duì)列服務(wù)，不斷地從任務(wù)隊(duì)列和補(bǔ)償隊(duì)列中消費(fèi)任務(wù)，計(jì)算每個(gè)任務(wù)的動(dòng)態(tài)優(yōu)先級(jí)，然后送入 redis 優(yōu)先級(jí)隊(duì)列。動(dòng)態(tài)優(yōu)先級(jí)的計(jì)算，結(jié)合了業(yè)務(wù)指定優(yōu)先級(jí)和調(diào)度因素（如狀態(tài)變更時(shí)間和失敗次數(shù)等），保證高優(yōu)內(nèi)容及時(shí)處理的同時(shí)，避免長(zhǎng)時(shí)間失敗導(dǎo)致影響低優(yōu)任務(wù)的處理。

• 優(yōu)先級(jí)隊(duì)列為每個(gè)執(zhí)行器模塊的 worker 建一個(gè)子隊(duì)列，一個(gè)管線配置多個(gè) worker，每個(gè) worker 只從對(duì)應(yīng)的子隊(duì)列獲取任務(wù)。任務(wù)入隊(duì)服務(wù)使用一致性哈希算法，計(jì)算每個(gè)任務(wù)哈希到對(duì)應(yīng)管線的某個(gè)子隊(duì)列，當(dāng) worker 動(dòng)態(tài)調(diào)整數(shù)量時(shí)，會(huì)重新計(jì)算，動(dòng)態(tài)均衡。子隊(duì)列方案比起常規(guī)的高低級(jí)雙隊(duì)列方案，優(yōu)先級(jí)粒度更小，減少爭(zhēng)搶，調(diào)度效率更高。

• 延時(shí)隊(duì)列，對(duì)失敗任務(wù)進(jìn)行延時(shí)調(diào)度，減少無(wú)效調(diào)度，降低對(duì)插件計(jì)算服務(wù)的壓力。

• 任務(wù)分配服務(wù)，接收?qǐng)?zhí)行器模塊的請(qǐng)求，從對(duì)應(yīng)的優(yōu)先級(jí)隊(duì)列中返回任務(wù)，可以控制分配速率。

3.6.3.2 動(dòng)態(tài)流控反壓

調(diào)度系統(tǒng)還考慮了動(dòng)態(tài)流控，當(dāng)任務(wù)大量執(zhí)行失敗時(shí)，自動(dòng)減少對(duì)故障環(huán)節(jié)的壓力，幫助快速恢復(fù)。

圖 3-23 動(dòng)態(tài)流控示意

當(dāng)插件服務(wù)故障持續(xù)發(fā)生，待調(diào)度任務(wù)不斷增加，監(jiān)控到優(yōu)先級(jí)隊(duì)列積壓到一定閾值時(shí)，會(huì)啟用反壓機(jī)制（Back Pressure）。一方面調(diào)度隊(duì)列服務(wù)會(huì)減少任務(wù)入隊(duì)速度，一方面任務(wù)分配服務(wù)減少初始任務(wù)的分配，先消化處理中的任務(wù)，降低執(zhí)行模塊的負(fù)擔(dān)。等故障恢復(fù)后，越來(lái)越多的任務(wù)由于執(zhí)行成功，會(huì)進(jìn)入正常優(yōu)先級(jí)隊(duì)列，再快速恢復(fù)處理速度。動(dòng)態(tài)流控的效果主要如下：

• 對(duì)故障插件減少平均 60+% 的無(wú)效調(diào)度，利于插件服務(wù)恢復(fù)。對(duì)插件的調(diào)用峰值減少 60%，避免發(fā)生雪崩。

• 故障恢復(fù)后，10 分鐘內(nèi)整體調(diào)度速度恢復(fù)正常。

目前，星航管線調(diào)度系統(tǒng)，實(shí)現(xiàn)了分布式高可用、秒級(jí)調(diào)度延遲、動(dòng)態(tài)優(yōu)先級(jí)、動(dòng)態(tài)流控、多租戶管理等多種特性，支持了騰訊內(nèi)容開(kāi)放平臺(tái)、騰訊新聞、騰訊視頻、小世界等二十多個(gè)重要業(yè)務(wù)上百條管線，每天處理千萬(wàn)級(jí)內(nèi)容量，累計(jì)處理近百億級(jí)內(nèi)容量。

3.7 運(yùn)行系統(tǒng)

3.7.1 Pipeline

Pipeline 執(zhí)行引擎基于 FSM（finite-state machine）有限狀態(tài)機(jī)實(shí)現(xiàn)，每個(gè) stage 對(duì)應(yīng)一個(gè)狀態(tài)。正常情況下，每執(zhí)行完一個(gè) stage, 狀態(tài) +1。當(dāng)某個(gè)階段的插件執(zhí)行失敗時(shí)，狀態(tài)在原地流轉(zhuǎn)。流程運(yùn)行異常時(shí)會(huì)進(jìn)入攔截狀態(tài)，停止流轉(zhuǎn)。被攔截的內(nèi)容收到觸發(fā)消息后，可以再次激活流程。流程運(yùn)行結(jié)束后進(jìn)入完成狀態(tài)。

圖 3-24 Pipeline 執(zhí)行機(jī)制流程示意

由于我們支持 Pipeline 的多版本管理和執(zhí)行，運(yùn)行系統(tǒng)需要對(duì)并發(fā)執(zhí)行進(jìn)行控制。在一些場(chǎng)景下，兩個(gè)執(zhí)行器會(huì)拿到同一個(gè)內(nèi)容的任務(wù)，我們用數(shù)據(jù)版本 row_version 作為樂(lè)觀鎖進(jìn)行并發(fā)控制。當(dāng)執(zhí)行器 A 和執(zhí)行器 B 同時(shí)拿到 row_version = 1 的某條任務(wù)時(shí)，先提交的執(zhí)行器會(huì)將這條任務(wù)的 row_version 改為 2。此時(shí)后完成的執(zhí)行器 B 便無(wú)法提交成功了。并發(fā)執(zhí)行機(jī)制確保了任務(wù)只會(huì)在一個(gè)執(zhí)行器里執(zhí)行，避免數(shù)據(jù)寫臟。

圖 3-25 Pipeline 多版本并發(fā)執(zhí)行控制

3.7.2 DAG

DAG 引擎的設(shè)計(jì)理念是一個(gè)純抽象、可復(fù)用、與業(yè)務(wù)邏輯無(wú)關(guān)的引擎，驅(qū)動(dòng)流程在 DAG 圖上的流轉(zhuǎn)。將業(yè)務(wù)邏輯通過(guò)開(kāi)放接口的形式，交給業(yè)務(wù)系統(tǒng)實(shí)現(xiàn)。主要模塊包含以下部分：

圖 3-26 DAG 執(zhí)行機(jī)制流程示意

3.7.3 插件代理

由于各渠道業(yè)務(wù)提供的插件服務(wù)的性能與耗時(shí)存在較大差異，但被調(diào)用的流程相似，因此需要引入插件代理。插件代理對(duì)插件行為進(jìn)行抽象，屏蔽實(shí)現(xiàn)方式，統(tǒng)一插件的調(diào)用流程。

圖 3-27 插件代理示意

插件代理向上面向執(zhí)行引擎時(shí)，插件代理屏蔽各類插件實(shí)現(xiàn)細(xì)節(jié)，表現(xiàn)出一致性；向下面向插件時(shí)，提供全局統(tǒng)一的緩存、限流能力，轉(zhuǎn)發(fā)流量到各類具體插件或插件中間件。

插件的標(biāo)準(zhǔn)協(xié)議，使用自描述結(jié)構(gòu)表征每個(gè)字段，并使用 Protocol Buffers 新增的 Map 類型包裹全部業(yè)務(wù)字段，從而定義出通用的插件協(xié)議。

3.7.3.1 插件共享

由于多個(gè)管線可能引入相同的內(nèi)容源，插件在這些管線被引用時(shí)，會(huì)導(dǎo)致相同內(nèi)容的特征會(huì)重復(fù)計(jì)算，浪費(fèi)大量機(jī)器資源，因此需要引入插件共享機(jī)制。

圖 3-28 插件結(jié)果共享示意

插件共享用于多個(gè)管線之間共享相同內(nèi)容的能力特征。用戶在插件上，可以配置是否開(kāi)啟緩存共享、緩存主鍵、有效期等參數(shù)。當(dāng)內(nèi)容處理中臺(tái)的管線之間存在重復(fù)內(nèi)容時(shí)，對(duì)于用戶開(kāi)啟了共享功能的插件，如果沒(méi)有命中某條內(nèi)容的緩存，則調(diào)用插件開(kāi)發(fā)者提供的特征能力服務(wù)，獲取特征能力結(jié)果并創(chuàng)建緩存。其他管線如果命中了緩存，則優(yōu)先使用緩存的特征能力結(jié)果，不再調(diào)用特征能力服務(wù)。通過(guò)對(duì)插件共享，實(shí)現(xiàn)了能力特征的跨管線復(fù)用，節(jié)省了機(jī)器計(jì)算資源（CPU、GPU）。

3.7.3.2 流量控制

圖 3-29 流量控制示意

當(dāng)前線上每天有十億級(jí)別的插件流量，每個(gè)插件的計(jì)算能力都有極限，如何平衡在線系統(tǒng)的插件流量和離線系統(tǒng)的插件流量是個(gè)值得思考的問(wèn)題。

平臺(tái)采用流量分級(jí)機(jī)制，對(duì)管線的流量進(jìn)行實(shí)時(shí)采集、實(shí)時(shí)計(jì)算，評(píng)估出主要業(yè)務(wù)所需的插件流量配額。并將剩余的插件流量配額（增量桶）分配給離線任務(wù)，配額的計(jì)算窗口秒級(jí)動(dòng)態(tài)調(diào)整。

3.7.3.3 同步異步

對(duì)于執(zhí)行引擎而言，所有插件都被統(tǒng)一成了同步調(diào)用過(guò)程。插件模型主要有以下幾種分類：

（1）同步插件：短耗時(shí)服務(wù)只需要注冊(cè)一個(gè)插件。執(zhí)行器同步阻塞調(diào)用插件指定的服務(wù)。

圖 3-30 同步插件

（2）異步發(fā)送與查詢插件：異步插件都包含發(fā)送與查詢兩個(gè)步驟，需要注冊(cè)兩個(gè)插件。執(zhí)行器通過(guò)發(fā)送插件，把任務(wù)發(fā)送給業(yè)務(wù)。執(zhí)行器再通過(guò)查詢插件，查詢?nèi)蝿?wù)結(jié)果。

圖 3-31 異步發(fā)送與查詢插件

（3）異步發(fā)送與回調(diào)插件：業(yè)務(wù)把結(jié)果回調(diào)給中臺(tái)，中臺(tái)統(tǒng)一存，執(zhí)行器到存儲(chǔ)中查詢結(jié)果。

圖 3-32 異步發(fā)送與回調(diào)插件

（4）同步轉(zhuǎn)異步插件：由于業(yè)務(wù)處理視頻時(shí)，較多特征能力耗時(shí)都會(huì)較長(zhǎng)，如果使用第二種異步插件模型，那么會(huì)迫使業(yè)務(wù)重復(fù)開(kāi)發(fā)多個(gè)異步系統(tǒng)，增加特征上線周期與難度。因此，內(nèi)容處理中臺(tái)提供了同步轉(zhuǎn)異步中間件，把業(yè)務(wù)的同步服務(wù)在管線上轉(zhuǎn)換成異步服務(wù)。執(zhí)行器把任務(wù)通過(guò)發(fā)送插件發(fā)給同步轉(zhuǎn)異步中間件系統(tǒng)，它再調(diào)度任務(wù)并實(shí)際調(diào)用業(yè)務(wù)的同步服務(wù)，并把返回的結(jié)果寫入到內(nèi)容處理中臺(tái)存儲(chǔ)，執(zhí)行器再到中臺(tái)存儲(chǔ)查詢?nèi)蝿?wù)結(jié)果。最終達(dá)到了業(yè)務(wù)只需要提供同步特征服務(wù)，即可快速上線。

圖 3-33 同步轉(zhuǎn)異步插件

3.7.4 狀態(tài)管理

管線的執(zhí)行流程往往很長(zhǎng)，為了提高執(zhí)行效率、減少存儲(chǔ)壓力，平臺(tái)采取狀態(tài)連續(xù)執(zhí)行，結(jié)果合并回寫的方案進(jìn)行狀態(tài)管理。

圖 3-34 執(zhí)行過(guò)程狀態(tài)持久化

• 狀態(tài)的回寫時(shí)機(jī)包括：

• 流程進(jìn)行到分發(fā)點(diǎn)

• 流程執(zhí)行結(jié)束

• 插件執(zhí)行失敗

• 連續(xù)執(zhí)行超過(guò) N 個(gè)狀態(tài)

3.7.5 干預(yù)機(jī)制

區(qū)別于常規(guī)的 workflow 工作流系統(tǒng)，星航所面臨的內(nèi)容處理流程訴求更加復(fù)雜多樣，諸如特定插件結(jié)果變更以及批量洗數(shù)據(jù)等。有些應(yīng)用場(chǎng)景業(yè)務(wù)希望有觸發(fā)信號(hào)干預(yù)影響系統(tǒng)的流轉(zhuǎn)走向圖，當(dāng)業(yè)務(wù)信號(hào)發(fā)生時(shí)流程跳轉(zhuǎn)到指定位置運(yùn)轉(zhuǎn)。另外一些應(yīng)用場(chǎng)景業(yè)務(wù)希望對(duì)大規(guī)模內(nèi)容數(shù)據(jù)進(jìn)行數(shù)據(jù)清洗，同時(shí)要求對(duì)常規(guī)的增量?jī)?nèi)容處理流程不受影響。對(duì)此，星航提供了不同的干預(yù)能力以覆蓋不同的業(yè)務(wù)需求場(chǎng)景。

• 特定內(nèi)容信號(hào)觸發(fā)器

圖 3-35 星航系統(tǒng)信號(hào)干預(yù)觸發(fā)示例

特定內(nèi)容的信號(hào)觸發(fā)可以通俗理解成編程語(yǔ)言中的“goto”語(yǔ)句。星航允許用戶自定義觸發(fā)器并在管線特定位置配置引入觸發(fā)器，當(dāng)業(yè)務(wù)方通過(guò)回調(diào)觸發(fā)器 Callback API 發(fā)送觸發(fā)信號(hào)后，系統(tǒng)通過(guò)事件接入模塊存儲(chǔ)該信號(hào)并對(duì)關(guān)聯(lián)觸發(fā)器的管線進(jìn)行信號(hào)廣播；調(diào)度服務(wù)接收到觸發(fā)信號(hào)后把內(nèi)容對(duì)應(yīng)調(diào)度狀態(tài)重置成目標(biāo)狀態(tài)并進(jìn)行進(jìn)一步調(diào)度處理。業(yè)務(wù)可以自由定義回調(diào)信號(hào)對(duì)應(yīng)的附加數(shù)據(jù)以用于流程控制。

• 大規(guī)模數(shù)據(jù)回溯處理

圖 3-36 大規(guī)模數(shù)據(jù)回溯示例

星航提供的大規(guī)模數(shù)據(jù)回溯處理能力根植于“輕量級(jí)”管線即插件集能力之上，通過(guò)旁路任務(wù)隊(duì)列接收數(shù)據(jù)回溯任務(wù)數(shù)據(jù)，基于插件集調(diào)度處理獲取回溯結(jié)果之后在回寫至對(duì)應(yīng)管線，在節(jié)約了數(shù)據(jù)回溯存儲(chǔ)成本的同時(shí)也避免了對(duì)常規(guī)增量?jī)?nèi)容的流程影響。

• 管理端干預(yù)能力

除了前面提到的信號(hào)觸發(fā)器以及大規(guī)模數(shù)據(jù)回溯能力，星航還在管理端內(nèi)置了內(nèi)容干預(yù)入口，方便用戶對(duì)少量數(shù)據(jù)進(jìn)行狀態(tài)干預(yù)處理。

3.8 存儲(chǔ)系統(tǒng)

3.8.1 設(shè)計(jì)目標(biāo)

• 內(nèi)容屬性寬表 schema 需要靈活擴(kuò)展，同時(shí)需要對(duì)字段進(jìn)行規(guī)范管理；

• 需要提供單個(gè)內(nèi)容的詳細(xì)處理流水供業(yè)務(wù)查詢追溯；

• 需要支持 PB 級(jí)的數(shù)據(jù)存儲(chǔ)，以及對(duì)內(nèi)容萬(wàn)級(jí) qps 的在線讀寫能力，以及較高的可用性；

• 需要支持不同業(yè)務(wù)個(gè)性化的關(guān)鍵字段的檢索需求；

• 需要有離線 + 實(shí)時(shí)數(shù)倉(cāng)提供給業(yè)務(wù)進(jìn)行各種查詢分析；

• 在降本的背景下還需要平衡好資源成本。

3.8.2 解決方案

實(shí)際場(chǎng)景中，業(yè)務(wù)數(shù)據(jù)主要分為兩類：

• 以內(nèi)容 id 為主鍵的屬性數(shù)據(jù)，既包括業(yè)務(wù)原料庫(kù)中的數(shù)據(jù)（比如標(biāo)題 / 封面等），也包括內(nèi)容加工的產(chǎn)出特征（比如機(jī)器分類標(biāo)簽 / 人審結(jié)果等）；

• 內(nèi)容每個(gè)步驟的變更流水，時(shí)序數(shù)據(jù)。

綜合考慮，采用了以 HBase 為主要存儲(chǔ)，輔以 ES/Clickhouse 等組件的異構(gòu)存儲(chǔ)系統(tǒng)，中間利用 Kafka 進(jìn)行數(shù)據(jù)同步。寫操作時(shí)，先更新 HBase 屬性表，成功后寫結(jié)構(gòu)化的事件日志到 Kafka，后續(xù)再異步消費(fèi) Kafka+ 查屬性快照的方式將數(shù)據(jù)同步到后續(xù)各個(gè)存儲(chǔ)。綜合考慮性能和業(yè)務(wù)數(shù)據(jù)特點(diǎn)，此處 HBase+Kafka 雙寫的模式實(shí)現(xiàn)上不保證原子性，僅對(duì) Kafka 增加了一個(gè)容災(zāi)集群，當(dāng)兩個(gè)集群都失敗時(shí)需要主調(diào)方進(jìn)行重試。如下圖所示：

圖 3-37 存儲(chǔ)數(shù)據(jù)流示意圖

HBase 具有高性能 / 高可用 / 低成本 / 列易擴(kuò)展的優(yōu)勢(shì)，比較適合平臺(tái)的場(chǎng)景。根據(jù)兩類數(shù)據(jù)的特點(diǎn)，使用了兩個(gè)不同的集群提供服務(wù)：

• HBase 屬性寬表。需要同時(shí)支持較高隨機(jī)讀寫，故而該集群使用了高性能 SSD 硬盤，開(kāi)啟自帶的內(nèi)存緩存；同時(shí)利用 rs group 來(lái)區(qū)分核心 / 非核心業(yè)務(wù)，做到互不影響 ;

• HBase 事件流水表。寫量極大，存儲(chǔ)量大，但是讀量極少，主要用于運(yùn)營(yíng)展示頁(yè)面流水查詢，故而選擇廉價(jià)磁盤型機(jī)器搭建集群，能夠很好的滿足寫多讀少低成本的需求；

由于在內(nèi)容接入時(shí)已經(jīng)為不同業(yè)務(wù)生成了星航平臺(tái)內(nèi)容統(tǒng)一 ID，從其生成的機(jī)制看，經(jīng)過(guò)稍加轉(zhuǎn)換便能保證很好的隨機(jī)性，從而避免了 HBase 分區(qū)的數(shù)據(jù)傾斜

為了支持除星航平臺(tái)內(nèi)容統(tǒng)一 ID 之外的其他關(guān)鍵字段的檢索（比如標(biāo)題、作者、分類、標(biāo)簽等等），目前會(huì)根據(jù)每個(gè)業(yè)務(wù)的配置，把其需要檢索的字段入到 ES，從 ES 檢索出數(shù)據(jù)后，根據(jù)需要再?gòu)?HBase 中查詢完整的屬性。這里設(shè)計(jì)上的幾個(gè)優(yōu)化點(diǎn)：

• 盡量只存儲(chǔ)需要檢索的字段，以便減少存儲(chǔ)量，降低 ES 成本

• 根據(jù)不同業(yè)務(wù)規(guī)模，按季 / 月 / 天分索引，同時(shí)采用冷熱分離的設(shè)置，有定時(shí)任務(wù)定期將熱索引落冷，減少集群整體成本

• 根據(jù)需要預(yù)先配置好索引模板（比如讓字段名形如 *_ik 的字段值自動(dòng)分詞），針對(duì)實(shí)際業(yè)務(wù)數(shù)據(jù)特點(diǎn)設(shè)置的配置肯定會(huì)優(yōu)于 ES 自動(dòng)生成的配置

• 不同業(yè)務(wù)可配置 Jsonpath 規(guī)則，定義 HBase 到 ES 字段的解析映射邏輯，以滿足不同業(yè)務(wù)可配置化的檢索需求

同時(shí)，這里也會(huì)異步消費(fèi)事件 Kafka，將屬性 + 事件數(shù)據(jù)寫到離線數(shù)倉(cāng)和實(shí)時(shí)數(shù)倉(cāng)，離線數(shù)倉(cāng)主要采用司內(nèi)統(tǒng)一的大數(shù)據(jù)平臺(tái)，實(shí)時(shí)數(shù)倉(cāng)則是選擇 Clickhouse 大寬表，作為后續(xù)衍生的各種平臺(tái)分析 + 監(jiān)控功能的數(shù)據(jù)底座。

3.9 監(jiān)控系統(tǒng)

對(duì)于端到端的可觀測(cè)性和服務(wù)穩(wěn)定性的挑戰(zhàn)，復(fù)雜系統(tǒng)的可觀測(cè)性是非常重要的問(wèn)題。平臺(tái)的監(jiān)控不僅包含核心系統(tǒng)的可觀測(cè)性，也包括外圍業(yè)務(wù)系統(tǒng)的可觀測(cè)。這里分為 Metrics（指標(biāo)）、Tracing（鏈路）、Logging（日志）三部分來(lái)介紹。

圖 3-38 管線監(jiān)控示意圖

4. 系統(tǒng)效果

本文基于騰訊內(nèi)部多個(gè)渠道的對(duì)內(nèi)容的場(chǎng)景需求，高度抽象并深度優(yōu)化內(nèi)容處理中臺(tái)架構(gòu)，端到端地對(duì)系統(tǒng)進(jìn)行了解耦設(shè)計(jì)和優(yōu)化開(kāi)發(fā)，有效地支持了內(nèi)容生態(tài)的業(yè)務(wù)場(chǎng)景。

4.1 技術(shù)效果

• 接入效率：強(qiáng)大的接入能力，累計(jì)處理百億級(jí)內(nèi)容數(shù)據(jù)，支持自定義和模板化的近 10 種異構(gòu)內(nèi)容接入，管線創(chuàng)建實(shí)現(xiàn)自舉，接入周期從 1 周降低至 2 個(gè)小時(shí)。

• 研發(fā)效率：端到端的效率優(yōu)化，提供三種不同的高效插件開(kāi)發(fā)模式和在線調(diào)試模式，支持 30 多個(gè)團(tuán)隊(duì)的自定義協(xié)議和代理協(xié)議進(jìn)行高效封裝算法、業(yè)務(wù)邏輯等數(shù)千個(gè)算子插件的微服務(wù)；算法能力引入從天級(jí)別降低至 1 小時(shí)，引入百余個(gè)算法插件算子；鏈路編排，提供低代碼樂(lè)高式自助化編排，支持任意復(fù)雜的內(nèi)容處理鏈路拓?fù)渚幣?、調(diào)試與上線，整體鏈路迭代的交付周期從月級(jí)別降低到天級(jí)別。

• 運(yùn)行效率：每天數(shù)十億的消息信號(hào)，高效的延遲隊(duì)列補(bǔ)償保障，水平擴(kuò)展優(yōu)先級(jí)隊(duì)列處理機(jī)制；融合統(tǒng)一 Pipeline 和 DAG 的調(diào)度架構(gòu)，輔以智能反壓穩(wěn)定性保障；插件共享，每天緩存命中數(shù)億次，為業(yè)務(wù)節(jié)省萬(wàn)余核 CPU、千余張 GPU。基于插件的共享機(jī)制和執(zhí)行狀態(tài)微批持久化等多種執(zhí)行優(yōu)化方案，和列式低成本存儲(chǔ)機(jī)制，支撐起每日千萬(wàn)級(jí)的高效內(nèi)容處理加工。

• 維護(hù)效率：全鏈路秒級(jí)業(yè)務(wù)內(nèi)容視角和平臺(tái)工程視角健康性和追蹤性可觀測(cè)能力。管線的故障恢復(fù)、資源伸縮、流量調(diào)控通過(guò)自動(dòng)駕駛模塊統(tǒng)一管理。目前故障自動(dòng)處理率 75%+，自愈率 75%+，平均故障恢復(fù)時(shí)間 2.4 分鐘。

4.2 業(yè)務(wù)效果

4.2.1 內(nèi)容分發(fā)

內(nèi)容處理中臺(tái)高效支持了騰訊視頻、騰訊新聞、QQ 瀏覽器、微視、騰訊體育等 10+ 個(gè)業(yè)務(wù)的高效的內(nèi)容特征級(jí)粒度任意鏈路節(jié)點(diǎn)結(jié)果進(jìn)行高效分發(fā)。圖文處理端到端 P95 耗時(shí)下降 59%，視頻處理端到端 P95 耗時(shí)下降 96%，分發(fā)服務(wù)最大數(shù)據(jù)延遲小于 3s，可用率>99.9%。

中臺(tái)提供了事件流訂閱和內(nèi)容特征獲取兩種內(nèi)容分發(fā)能力。平臺(tái)上流轉(zhuǎn)的內(nèi)容定義成一個(gè) doc，一個(gè)完整的 doc 包含了兩部分字段，一部分來(lái)自輸入字段，一部分來(lái)自鏈路中編排的能力，隨編排邏輯動(dòng)態(tài)變化。在運(yùn)行過(guò)程中，doc 中的字段值隨著處理流程的調(diào)度執(zhí)行逐漸被寫入。

實(shí)際生產(chǎn)環(huán)境的內(nèi)容處理鏈路通常比較復(fù)雜，整體耗時(shí)在分鐘級(jí)完成，除了在鏈路執(zhí)行成功和中止之外，往往需要實(shí)時(shí)感知中間態(tài)的關(guān)鍵結(jié)果產(chǎn)出，因此平臺(tái)提供了自定義分發(fā)點(diǎn)的能力，支持在流程中任意執(zhí)行階段進(jìn)行內(nèi)容分發(fā)，即在流程的任意階段向變更事件流中寫入一次 doc 數(shù)據(jù)。

圖 4-1 內(nèi)容分發(fā)示意圖

通過(guò)內(nèi)容特征服務(wù)可以獲取到最新的 doc 特征，但是由于需要調(diào)用方發(fā)起請(qǐng)求，因此會(huì)有實(shí)時(shí)性的問(wèn)題，通常只在一次性查詢的場(chǎng)景使用。事件流訂閱支持按行按列（即內(nèi)容維度和特征維度）的規(guī)則過(guò)濾，對(duì)接收方提供 at least once 的變更數(shù)據(jù)投遞和最終一致性保證，使用方可以實(shí)時(shí)感知自身關(guān)注的內(nèi)容和關(guān)鍵處理過(guò)程。

4.2.2 內(nèi)容審核

內(nèi)容審核是星航平臺(tái)的重要使用場(chǎng)景，也是當(dāng)前內(nèi)容行業(yè)必不可少的業(yè)務(wù)環(huán)節(jié)，結(jié)合團(tuán)隊(duì)自研的通航審核平臺(tái)，業(yè)務(wù)可以快速搭建人機(jī)協(xié)同的內(nèi)容審核鏈路。并只需要專注在具體業(yè)務(wù)場(chǎng)景的需求上，整體交付周期縮短 90% 以上。

一般業(yè)務(wù)都會(huì)有“機(jī)審 + 人審”的流程需求，通常采用機(jī)審在前，人審在后的方式，這樣可以盡量減少人力成本。在人審過(guò)程中往往需要采用人機(jī)協(xié)同的方式，使用星航平臺(tái)可以便捷的將算法計(jì)算結(jié)果打通到通航平臺(tái)，在通航平臺(tái)內(nèi)部實(shí)現(xiàn)人機(jī)協(xié)同，提高審核效率。這個(gè)過(guò)程中只需要編排相應(yīng)的算法插件并調(diào)整送審插件的參數(shù)而無(wú)需開(kāi)發(fā)。

相較于傳統(tǒng)的開(kāi)發(fā)方式，搭建一條新的審核鏈路的成本大大降低，開(kāi)發(fā)者可以從重復(fù)的工作中解放出來(lái)。

圖 4-2 內(nèi)容審核示意圖

需要注意的是，內(nèi)容審核相比機(jī)器計(jì)算具有耗時(shí)更長(zhǎng)、計(jì)算成本更高、結(jié)果可變更的特點(diǎn)。為了讓審核過(guò)程不阻塞內(nèi)容處理流程，同時(shí)可以更好的響應(yīng)審核結(jié)果。內(nèi)容審核使用異步插件與觸發(fā)器相結(jié)合的方式接入星航。

對(duì)于先發(fā)后審的業(yè)務(wù)場(chǎng)景，星航平臺(tái)提供流量觸發(fā)器的方式并結(jié)合規(guī)則引擎，實(shí)現(xiàn)靈活的送審策略定制，包括流量觸發(fā)、算法模型觸發(fā)等。同時(shí)基于規(guī)則引擎，業(yè)務(wù)可以控制內(nèi)容流向的審核隊(duì)列或者目錄，不同的隊(duì)列之間可以采用串聯(lián)或者并聯(lián)的方式，視業(yè)務(wù)需求而定。內(nèi)容進(jìn)入通航后，不同隊(duì)列或者目錄內(nèi)的任務(wù)由專業(yè)審核人員進(jìn)行審核，達(dá)到質(zhì)量和效率的最優(yōu)配置。

5. 未來(lái)展望

未來(lái)，我們將從全鏈路 TCO 成本出發(fā)，以降本提效為目標(biāo)，從開(kāi)發(fā)效率、運(yùn)行效率等路徑視角，進(jìn)一步深挖技術(shù)給內(nèi)容業(yè)務(wù)可能帶來(lái)的價(jià)值。

圖 5-1 未來(lái)工作方向概要

5.1 插件開(kāi)發(fā)效率

提升心流式插件開(kāi)發(fā)體驗(yàn)，插件作為根基角色，進(jìn)一步深度探索低代碼 + 函數(shù)插件極速開(kāi)發(fā)流程，以云原生函數(shù)服務(wù) FAAS 為基礎(chǔ)，打造全鏈路自動(dòng)化開(kāi)發(fā)、提交、編譯、部署、實(shí)驗(yàn)、上線、洞察等更成熟的開(kāi)發(fā)方案，讓開(kāi)發(fā)者只專注對(duì)業(yè)務(wù)核心邏輯開(kāi)發(fā)。

5.2 智能鏈路效率

5.2.1 智能編排

提高任務(wù)鏈路編排效率，探索低代碼化 + 智能化編排模式，當(dāng)前開(kāi)發(fā)者可以基于插件開(kāi)發(fā)業(yè)務(wù)場(chǎng)景的服務(wù)編排任務(wù)，但存在兩個(gè)問(wèn)題，一方面，如果相同或者類似算法插件多，開(kāi)發(fā)者面臨選擇問(wèn)題；另一方面，插件和插件之間還存在著依賴血緣關(guān)系，面臨熟悉成本。所以，后面我們將探索以業(yè)務(wù)場(chǎng)景訴求為出發(fā)點(diǎn)，智能化整合相關(guān)插件，提供插件邏輯視圖模塊化能力，用戶直接從業(yè)務(wù)功能級(jí)出發(fā)選擇插件模塊，無(wú)需直接通過(guò)插件到拓?fù)涞木幣?，提高開(kāi)發(fā)效率。

5.2.2 路由尋優(yōu)

提高系統(tǒng)穩(wěn)定性并降低系統(tǒng)平響，優(yōu)化網(wǎng)絡(luò)請(qǐng)求路由算法，當(dāng)前一些基礎(chǔ)的路由算法不能夠滿足我們的業(yè)務(wù)場(chǎng)景，引入網(wǎng)絡(luò)請(qǐng)求更靈活的 Locality-aware 路由算法，并融合多維度系統(tǒng)特征和業(yè)務(wù)的實(shí)時(shí)特征，構(gòu)建路由權(quán)重模型，從資源實(shí)際能力角度處理業(yè)務(wù)請(qǐng)求；同時(shí)，我們還將基于全鏈路效果視角，進(jìn)一步探索 N3 算法（N 個(gè)最近鄰居）在路由權(quán)重的應(yīng)用優(yōu)化。

5.2.3 彈性伸縮

持續(xù)降低內(nèi)容處理成本，除了系統(tǒng)級(jí)資源自動(dòng)伸縮，我們將從業(yè)務(wù)本身視角進(jìn)行物理資源的智能化伸縮，比如，失敗率，mttr，業(yè)務(wù)的某些請(qǐng)求閾值等視角，并通過(guò)上文提及的血緣關(guān)系，進(jìn)行水平或者級(jí)聯(lián)等多策略資源伸縮，提高的服務(wù)質(zhì)量，保障用戶體驗(yàn)。

5.3 任務(wù)運(yùn)行效率

提高 CPU 資源利用率和并發(fā)能力，在早期系統(tǒng)通過(guò)配置及反壓的方案上，為了更靈活地動(dòng)態(tài)適配請(qǐng)求的波峰波谷，引入 actor 響應(yīng)式編程，通過(guò)對(duì) actor 的自動(dòng)伸縮更好利用計(jì)算資源，智能化處理計(jì)算需求。

6. 結(jié)語(yǔ)

移動(dòng)互聯(lián)網(wǎng)內(nèi)容生態(tài)繁榮而復(fù)雜多樣，內(nèi)容作為移動(dòng)時(shí)代的信息知識(shí)載體，對(duì)于不同業(yè)務(wù)場(chǎng)景，我們往往面對(duì)著各種各樣的業(yè)務(wù)和技術(shù)挑戰(zhàn)，因此，我們將在內(nèi)容生態(tài)業(yè)務(wù)場(chǎng)景的基礎(chǔ)上，不斷用技術(shù)創(chuàng)新去驅(qū)動(dòng)降本提效，并持續(xù)優(yōu)化內(nèi)容中臺(tái)用戶體驗(yàn)。

作者簡(jiǎn)介：

李欣，騰訊內(nèi)容處理中臺(tái)總監(jiān)，負(fù)責(zé)內(nèi)容處理中臺(tái)的產(chǎn)品規(guī)劃、技術(shù)研發(fā)和團(tuán)隊(duì)管理工作。

王冬，騰訊內(nèi)容處理中臺(tái)技術(shù)負(fù)責(zé)人，熟悉后端架構(gòu)領(lǐng)域、大數(shù)據(jù)領(lǐng)域的技術(shù)產(chǎn)品化工作。

蔣靖，騰訊內(nèi)容處理中臺(tái)后端開(kāi)發(fā)負(fù)責(zé)人，關(guān)注內(nèi)容處理、流程引擎、微服務(wù)治理等技術(shù)方向。

施馭，騰訊內(nèi)容處理中臺(tái)后端研發(fā)工程師，關(guān)注云原生、微服務(wù)、高并發(fā)架構(gòu)領(lǐng)域技術(shù)。

李湘軍，騰訊內(nèi)容處理中臺(tái)后端研發(fā)工程師，專注于高并發(fā)、高吞吐場(chǎng)景的架構(gòu)設(shè)計(jì)與研發(fā)。

唐偉，騰訊內(nèi)容處理中臺(tái)后端研發(fā)工程師，關(guān)注內(nèi)容處理業(yè)務(wù)方向的分布式調(diào)度與計(jì)算方向。

李會(huì)珠，騰訊內(nèi)容處理中臺(tái)后端研發(fā)工程師，海量后端服務(wù)設(shè)計(jì)開(kāi)發(fā)經(jīng)驗(yàn)。

賈洪強(qiáng)，騰訊內(nèi)容處理中臺(tái)后端開(kāi)發(fā)負(fù)責(zé)人，關(guān)注關(guān)系和非關(guān)系型存儲(chǔ)中間件方向。

劉斌，騰訊內(nèi)容處理中臺(tái)后端研發(fā)工程師，關(guān)注消息隊(duì)列、云原生領(lǐng)域等技術(shù)方向。

黎帆，騰訊內(nèi)容處理中臺(tái)后端研發(fā)工程師，關(guān)注大數(shù)據(jù)，分布式存儲(chǔ)等方向。

陳昇輝，騰訊內(nèi)容處理中臺(tái)后端研發(fā)工程師，關(guān)注微服務(wù)、領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)等方向。

李瀚，騰訊內(nèi)容處理中臺(tái)前端開(kāi)發(fā)負(fù)責(zé)人，長(zhǎng)期關(guān)注 React/Node 相關(guān)技術(shù)方向。

最后，感謝 kyler、richard、gemini 等的大力支持，以及騰訊內(nèi)容處理中臺(tái)團(tuán)隊(duì)和相關(guān)業(yè)務(wù)團(tuán)隊(duì)每一位成員的共同付出