一、任務(wù)調(diào)度

任務(wù)調(diào)度多指系統(tǒng)根據(jù)當(dāng)前負(fù)載情況，將不同任務(wù)放到合適的計算資源中去執(zhí)行的相關(guān)操作。一個完善的調(diào)度系統(tǒng)往往需要平衡不同特點(diǎn)的任務(wù)間的隔離以及效率最優(yōu)這兩個需求。函數(shù)計算異步任務(wù)采用了獨(dú)立隊列模型及自動負(fù)載均衡策略，具備在不影響處理性能的前提下進(jìn)行多租隔離的能力。

Serverless Task 任務(wù)調(diào)度模型

當(dāng)用戶提交一次任務(wù)后，系統(tǒng)會將該任務(wù)轉(zhuǎn)換為一條消息，并通過異步下發(fā)的方式放入到內(nèi)部隊列中。一條消息的處理流程如下圖所示：

圖 1

整個系統(tǒng)在任務(wù)調(diào)度方面的多租隔離及消息積壓控制方面主要依賴的是 Scheduler 對于隊列的消費(fèi)及控制。我們事先會為每一位用戶劃分一個賬號級別的隊列，該用戶的所有函數(shù)的異步調(diào)用（包括任務(wù)調(diào)用）會共享該隊列。

這樣的模型結(jié)構(gòu)會保證每個用戶的異步執(zhí)行請求（包括任務(wù)調(diào)用）均不會受到其他用戶的調(diào)用情況的影響。但是在一些大規(guī)模應(yīng)用場景，如一個用戶的函數(shù)很多，并且每個函數(shù)的調(diào)用量都很大的情況下，所有的異步消息共用一個隊列難免造成調(diào)用間的相互影響。部分長尾調(diào)用可能會過多的消耗隊列的資源，導(dǎo)致其他函數(shù)的執(zhí)行出現(xiàn)饑餓的現(xiàn)象。

為了避免這種情況影響重要函數(shù)的執(zhí)行，函數(shù)計算提供了更細(xì)力度的隊列 - 函數(shù)級別的隊列?？梢酝ㄟ^對每個不同函數(shù)設(shè)置單獨(dú)的隊列，確保高優(yōu)先級函數(shù)的消費(fèi)情況不會受同賬號下的其他函數(shù)執(zhí)行的影響。隊列間的關(guān)系如下圖所示:

圖 2

典型的應(yīng)用場景

假設(shè)某用戶 A 具有 2 個不同的任務(wù)函數(shù)。其中一個任務(wù) A 由于下游服務(wù)的限制，需要一個消息一個消息的執(zhí)行；而另外一個任務(wù) B 是大并發(fā)任務(wù)，并且希望盡快執(zhí)行完。在默認(rèn)模式下，任務(wù) A 和 B 共享同一個用戶隊列；這時會出現(xiàn)如下場景：任務(wù) A 由于具有并發(fā)度限制，函數(shù)計算側(cè)會對整個任務(wù)隊列進(jìn)行出隊速率控制。這就導(dǎo)致了任務(wù) B 的任務(wù)遲遲無法出隊。

而當(dāng)任務(wù) A 執(zhí)行完后，任務(wù) B 得到了出隊機(jī)會，此時并發(fā)度升高，任務(wù) B 的消息搶占了資源池進(jìn)行執(zhí)行，任務(wù) A 又變得難以出隊，很長時間也無法開始一次執(zhí)行。這樣的結(jié)果就是無論 A 還是 B 都受到了對方業(yè)務(wù)的嚴(yán)重干擾。

當(dāng)進(jìn)行隊列調(diào)整后，任務(wù) A 和 B 分別獨(dú)占隊列。在這種情況下任務(wù) A 和 B 的消費(fèi)速度不受對方影響，都可以達(dá)到自身的訴求。

目前 Serverless Task 提供了任務(wù)積壓大盤，您可以在任務(wù)界面獲取目前已經(jīng)積壓的任務(wù)數(shù)，綜合分析是否需要開啟函數(shù)的獨(dú)占隊列。

Serverless Task 任務(wù)隊列負(fù)載均衡模型

上面介紹了如何通過函數(shù)級別隊列來避免出現(xiàn) “Noisy Neighbour” 問題。但是在一些場景下，如果任務(wù)的并發(fā)量級過大，即便對該任務(wù)劃分了單隊列，也會導(dǎo)致任務(wù)的積壓。這個問題的解決需要引入 Serverless Task 的負(fù)載均衡策略。

函數(shù)計算的任務(wù)處理模塊具有 Partition 的概念。每個用戶默認(rèn)屬于一個 Partition，負(fù)責(zé)該 Partition 的 Scheduler 會監(jiān)聽用戶對應(yīng)的任務(wù)隊列。當(dāng)出現(xiàn)嚴(yán)重積壓時，我們會為用戶按照負(fù)載情況分配多個 Partition，并交由不同的 Scheduler 負(fù)責(zé)消費(fèi)，來提升任務(wù)整體的消費(fèi)速度。

圖 3

可以看到，阿里云函數(shù)計算在任務(wù)隊列管理方面默認(rèn)做到了多租及隔離的能力，可以適用于絕大多數(shù)場景。針對一些重負(fù)載、長執(zhí)行、并發(fā)量大的場景，函數(shù)計算還支持橫向擴(kuò)容，加快消費(fèi)速度。在任務(wù)隔離方面，函數(shù)計算支持針對不同優(yōu)先級的函數(shù)進(jìn)行單獨(dú)隔離，避免出現(xiàn) Noisy Neighbour 的問題。

二、可觀測性

任務(wù)的可觀測能力是任務(wù)系統(tǒng)必不可少的能力之一。強(qiáng)大的可觀測性將有助于業(yè)務(wù)方減少在任務(wù)運(yùn)行的各個階段所需要額外進(jìn)行的工作量。

開發(fā)階段：任務(wù)的在線調(diào)試能力、運(yùn)行結(jié)果的 Debug 能力將直接影響業(yè)務(wù)上線進(jìn)度；

業(yè)務(wù)常規(guī)運(yùn)行階段：各種監(jiān)控、流量情況的統(tǒng)計以及運(yùn)行時日志將協(xié)助用戶快速了解業(yè)務(wù)的發(fā)展、變化，以及出現(xiàn)故障時的快速定位 & 處理；

階段性審計：任務(wù)的歷史記錄存儲及保留將為用戶提供良好的可追溯能力，可以根據(jù)歷史信息進(jìn)行后續(xù)的業(yè)務(wù)規(guī)劃。

ServerlessTask 可觀測性支持 - 開發(fā)測試階段

業(yè)務(wù)的開發(fā)階段最主要的訴求就是快速調(diào)試并定位問題。在對該階段的支持中，ServerlessTask 提供了登錄實(shí)例及實(shí)時日志的能力。當(dāng)代碼開發(fā)并上傳后，測試 - debug - 修改代碼 - 再次測試的流程可以全部在控制臺完成，極大的提高了研發(fā)效率。如果有需要性能調(diào)試、第三方 Binary 調(diào)試（如音視頻處理領(lǐng)域的 FFmpeg 調(diào)試）等可以借助登錄實(shí)例功能完成。操作流程如下圖所示：

選擇想登錄實(shí)例的任務(wù)，點(diǎn)擊實(shí)例鏈接。

會進(jìn)入到實(shí)例監(jiān)控頁面，點(diǎn)擊右上角的登錄實(shí)例功能，即可登錄到對應(yīng)的實(shí)例上。

ServerlessTask 可觀測性支持 - 業(yè)務(wù)上線后運(yùn)行階段

當(dāng)業(yè)務(wù)上線后，經(jīng)常容易出現(xiàn)因容量預(yù)估不足導(dǎo)致下游系統(tǒng)無法承載壓力，導(dǎo)致故障。因此 ServerlessTask 提供了運(yùn)行時指標(biāo)，即一段時間內(nèi)的任務(wù)提交數(shù)、完成數(shù)及執(zhí)行情況。用戶可以根據(jù)這張指標(biāo)圖快速了解當(dāng)前業(yè)務(wù)的負(fù)載情況。當(dāng)用戶任務(wù)的下游消費(fèi)較慢，可能造成任務(wù)積壓，這種情況也很容易在指標(biāo)圖中反映出，進(jìn)而快速做出相應(yīng)的反應(yīng)。目前 ServerlessTask 所提供的相關(guān)指標(biāo)如下：

任務(wù)監(jiān)控大盤提供以下任務(wù)監(jiān)控數(shù)據(jù)：

在快速定位問題方面，函數(shù)計算支持實(shí)時查看函數(shù)日志及實(shí)例指標(biāo)。您可以進(jìn)入到任務(wù)的列表頁面，找到實(shí)際執(zhí)行失敗的任務(wù)，進(jìn)入日志頁面及實(shí)例頁面進(jìn)行問題定位：

ServerlessTask 可觀測性支持 - 階段性審計

當(dāng)線上任務(wù)運(yùn)行一段時間后，往往需要進(jìn)行一系列的階段性審計工作，比如上一周的執(zhí)行總?cè)蝿?wù)數(shù)，執(zhí)行失敗的任務(wù)數(shù)及執(zhí)行失敗的時間。目前除了控制臺以外，函數(shù)計算提供了豐富的 API 能力來進(jìn)行任務(wù)的審計工作。主要包括以下幾方面能力：

根據(jù)狀態(tài)進(jìn)行過濾，只查詢某一個狀態(tài)的執(zhí)行；

根據(jù)觸發(fā)時間進(jìn)行過濾，如查詢過去某一段時間內(nèi)發(fā)起的任務(wù)；

根據(jù)任務(wù)名稱查詢。如果您的任務(wù)具有業(yè)務(wù)上下游的 TraceID，您可以在觸發(fā)任務(wù)時指定一個有意義的任務(wù)ID。后續(xù)可以根據(jù) ID 前綴進(jìn)行范圍查詢；

上面的幾個過濾方式可以組合，達(dá)到更便捷的需求。控制臺所支持的過濾條件如下圖所示：

更多參數(shù)內(nèi)容可參考：
ListStatefulAsyncInvocation 。

ServerlessTask 可觀測性支持 - 死信隊列及業(yè)務(wù)補(bǔ)償

在消息領(lǐng)域，有一個非常重要的概念 - 死信隊列。當(dāng)一些消息無法被消費(fèi)時，這些消息往往需要存儲到一個地方，以便后續(xù)人為的介入處理，避免因未進(jìn)行處理而造成業(yè)務(wù)損失。Serverless Task 也支持了這樣一類功能。您可以對 Serverless Task 設(shè)置目標(biāo)功能；當(dāng)任務(wù)執(zhí)行失敗后，函數(shù)計算支持自動將執(zhí)行失敗的上下文信息推送到消息隊列等消息服務(wù)中，以便后續(xù)處理。如果您的處理邏輯支持自動化，函數(shù)計算還支持將失敗任務(wù)的上下文信息推送回函數(shù)計算，執(zhí)行一段您的自定義業(yè)務(wù)邏輯來實(shí)現(xiàn)業(yè)務(wù)補(bǔ)償。

您可以在異步調(diào)用配置頁面配置成功及失敗目標(biāo)。

更多配置內(nèi)容請參考：
PutFunctionAsyncInvokeConfig。

綜上所述，Serverless Task 所提供的可觀測能力可以有效支持任務(wù)全生命周期的監(jiān)測需求。所有控制臺能力均可以使用開放 API 進(jìn)行定制化開發(fā)，來滿足更多的需求。Serverless Task 的目標(biāo)功能除了可以做到任務(wù)失敗補(bǔ)償以外，還可以作為 Event-Driven 模式的數(shù)據(jù)源，自動的將處理后的事件投遞到下游服務(wù)中。