在上篇文章《解密函式計算非同步任務能力之「任務的狀態及生命週期管理」》中，我們介紹了任務系統的狀態管理，並介紹了使用者應如何根據需求，對任務狀態資訊進行實時的查詢等操作。在本篇中我們將會進一步走進函式計算非同步任務，介紹非同步任務的排程方案以及系統在可觀測性方面所支援的各項功能。
**一、任務排程**
任務排程多指系統根據當前負載情況，將不同任務放到合適的計算資源中去執行的相關操作。一個完善的排程系統往往需要平衡不同特點的任務間的隔離以及效率最優這兩個需求。函式計算非同步任務採用了獨立佇列模型及自動負載均衡策略，具備在不影響處理效能的前提下進行多租隔離的能力。
### Serverless Task 任務排程模型
當使用者提交一次任務後，系統會將該任務轉換為一條訊息，並透過非同步下發的方式放入到內部佇列中。一條訊息的處理流程如下圖所示：

![圖片.png](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/151014/1646807253326-de6f2089-4063-4d19-a703-80409683f5d7.png#clientId=u54517da7-08bc-4&crop=0&crop=0&crop=1&crop=1&from=paste&height=464&id=u971ee15f&margin=%5Bobject%20Object%5D&name=%E5%9B%BE%E7%89%87.png&originHeight=575&originWidth=581&originalType=binary&ratio=1&rotation=0&showTitle=false&size=331830&status=done&style=none&taskId=ue7458482-684d-476a-a282-cd88442f728&title=&width=469)
圖 1
整個系統在任務排程方面的多租隔離及訊息積壓控制方面主要依賴的是 Scheduler 對於佇列的消費及控制。我們事先會為每一位使用者劃分一個賬號級別的佇列，該使用者的所有函式的非同步呼叫（包括任務呼叫）會共享該佇列。

這樣的模型結構會保證每個使用者的非同步執行請求（包括任務呼叫）均不會受到其他使用者的呼叫情況的影響。但是在一些大規模應用場景，如一個使用者的函式很多，並且每個函式的呼叫量都很大的情況下，所有的非同步訊息共用一個佇列難免造成呼叫間的相互影響。部分長尾呼叫可能會過多的消耗佇列的資源，導致其他函式的執行出現飢餓的現象。

為了避免這種情況影響重要函式的執行，函式計算提供了更細力度的佇列 - 函式級別的佇列。可以透過對每個不同函式設定單獨的佇列，確保高優先順序函式的消費情況不會受同賬號下的其他函式執行的影響。佇列間的關係如下圖所示:
![圖片.png](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/151014/1646809059370-beb1bb73-0438-47d6-ae03-c7e296bf7dfc.png#clientId=u54517da7-08bc-4&crop=0&crop=0&crop=1&crop=1&from=paste&height=905&id=vM6Fb&margin=%5Bobject%20Object%5D&name=%E5%9B%BE%E7%89%87.png&originHeight=905&originWidth=1282&originalType=binary&ratio=1&rotation=0&showTitle=false&size=555515&status=done&style=none&taskId=uf9cf25d3-3676-4d40-818e-763b05db828&title=&width=1282)圖 2

### 典型的應用場景
假設某使用者 A 具有 2 個不同的任務函式。其中一個任務 A 由於下游服務的限制，需要一個訊息一個訊息的執行；而另外一個任務 B 是大併發任務，並且希望儘快執行完。在預設模式下，任務 A 和 B 共享同一個使用者佇列；這時會出現如下場景：任務 A 由於具有併發度限制，函式計算側會對整個任務佇列進行出隊速率控制。這就導致了任務 B 的任務遲遲無法出隊。而當任務 A 執行完後，任務 B 得到了出隊機會，此時併發度升高，任務 B 的訊息搶佔了資源池進行執行，任務 A 又變得難以出隊，很長時間也無法開始一次執行。這樣的結果就是無論 A 還是 B 都受到了對方業務的嚴重干擾。

當進行佇列調整後，任務 A 和 B 分別獨佔佇列。在這種情況下任務 A 和 B 的消費速度不受對方影響，都可以達到自身的訴求。

目前 Serverless Task 提供了任務積壓大盤，您可以在任務介面獲取目前已經積壓的任務數，綜合分析是否需要開啟函式的獨佔佇列。
### 
Serverless Task 任務佇列負載均衡模型
上面介紹瞭如何透過函式級別佇列來避免出現 “Noisy Neighbour” 問題。但是在一些場景下，如果任務的併發量級過大，即便對該任務劃分了單佇列，也會導致任務的積壓。這個問題的解決需要引入 Serverless Task 的負載均衡策略。

函式計算的任務處理模組具有 Partition 的概念。每個使用者預設屬於一個 Partition，負責該 Partition 的 Scheduler 會監聽使用者對應的任務佇列。當出現嚴重積壓時，我們會為使用者按照負載情況分配多個 Partition，並交由不同的 Scheduler 負責消費，來提升任務整體的消費速度。

![圖片.png](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/151014/1646815230568-60ddb309-281a-44d5-b2b5-68ba4b869381.png#clientId=u4b3b550e-4e01-4&crop=0&crop=0&crop=1&crop=1&from=paste&height=335&id=u19cf447c&margin=%5Bobject%20Object%5D&name=%E5%9B%BE%E7%89%87.png&originHeight=604&originWidth=754&originalType=binary&ratio=1&rotation=0&showTitle=false&size=219216&status=done&style=none&taskId=u4c47b6e5-70de-4dd7-a90e-ff688772b6f&title=&width=418)
圖 3

可以看到，阿里雲函式計算在任務佇列管理方面預設做到了**多租**及**隔離**的能力，可以適用於絕大多數場景。針對一些重負載、長執行、併發量大的場景，函式計算還支援橫向擴容，加快消費速度。在任務隔離方面，函式計算支援針對不同優先順序的函式進行單獨隔離，避免出現 Noisy Neighbour 的問題。

# 二、**可觀測性**
任務的可觀測能力是任務系統必不可少的能力之一。強大的可觀測性將有助於業務方減少在任務執行的各個階段所需要額外進行的工作量。

1. 開發階段：任務的線上除錯能力、執行結果的 Debug 能力將直接影響業務上線進度；
1. 業務常規執行階段：各種監控、流量情況的統計以及執行時日誌將協助使用者快速瞭解業務的發展、變化，以及出現故障時的快速定位 & 處理；
1. 階段性審計：任務的歷史記錄儲存及保留將為使用者提供良好的可追溯能力，可以根據歷史資訊進行後續的業務規劃。
### ServerlessTask 可觀測性支援 - 開發測試階段
業務的開發階段最主要的訴求就是快速除錯並定位問題。在對該階段的支援中，ServerlessTask 提供了登入例項及實時日誌的能力。當程式碼開發並上傳後，測試 - debug - 修改程式碼 - 再次測試的流程可以全部在控制檯完成，極大的提高了研發效率。如果有需要效能除錯、第三方 Binary 除錯（如音影片處理領域的 FFmpeg 除錯）等可以藉助登入例項功能完成。操作流程如下圖所示：

選擇想登入例項的任務，點選例項連結。
![圖片.png](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/151014/1646877871917-1689f37f-0fcc-4a83-8ea6-513845f2a166.png#clientId=uecb3db33-3241-4&crop=0&crop=0&crop=1&crop=1&from=paste&height=204&id=u4fbd9059&margin=%5Bobject%20Object%5D&name=%E5%9B%BE%E7%89%87.png&originHeight=408&originWidth=2412&originalType=binary&ratio=1&rotation=0&showTitle=false&size=209696&status=done&style=none&taskId=udbfa7da9-3158-41e5-acad-405f1cf21e6&title=&width=1206)
會進入到例項監控頁面，點選右上角的登入例項功能，即可登入到對應的例項上。

### ServerlessTask 可觀測性支援 - 業務上線後執行階段
當業務上線後，經常容易出現因容量預估不足導致下游系統無法承載壓力，導致故障。因此 ServerlessTask 提供了執行時指標，即一段時間內的任務提交數、完成數及執行情況。使用者可以根據這張指標圖快速瞭解當前業務的負載情況。當使用者任務的下游消費較慢，可能造成任務積壓，這種情況也很容易在指標圖中反映出，進而快速做出相應的反應。目前 ServerlessTask 所提供的相關指標如下：![圖片.png](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/151014/1646877945725-a3a1601f-779e-4473-963a-968c41d669bc.png#clientId=uecb3db33-3241-4&crop=0&crop=0&crop=1&crop=1&from=paste&height=158&id=u63c2c812&margin=%5Bobject%20Object%5D&name=%E5%9B%BE%E7%89%87.png&originHeight=316&originWidth=1500&originalType=binary&ratio=1&rotation=0&showTitle=false&size=147856&status=done&style=none&taskId=ued2cccf6-72b1-4459-a854-9a2c9b8e873&title=&width=750)任務監控大盤提供以下任務監控資料：

| **監控指標** | **說明** |
| --- | --- |
| **提交的任務數** | **在過去 1 分鐘內所提交的任務總數，包括執行中的、已完成的及未出隊的數量。** |
| **完成的任務數** | **在過去 1 分鐘內提交的任務所完成的任務數，包括執行成功或失敗的。** |
| **排隊中的任務數** | **在過去 1 分鐘內提交的任務，還在排隊中的數量。如果該數量不為 0，則說明任務有積壓。** |
| **執行中的任務數** | **在過去 1 分鐘內提交的任務處於執行中的任務數。** |
| **執行失敗任務數** | **在過去 1 分鐘內提交的任務處於執行失敗的任務數。** |
| **執行已佔用例項數** | **在過去 1 分鐘內提交的任務處於執行成功的任務數。** |

在快速定位問題方面，函式計算支援實時檢視函式日誌及例項指標。您可以進入到任務的列表頁面，找到實際執行失敗的任務，進入日誌頁面及例項頁面進行問題定位：
![圖片.png](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/151014/1646878320435-f6f2a8a0-d6cb-47d4-b288-1086238acb57.png#clientId=uecb3db33-3241-4&crop=0&crop=0&crop=1&crop=1&from=paste&height=290&id=u379d4dba&margin=%5Bobject%20Object%5D&name=%E5%9B%BE%E7%89%87.png&originHeight=1094&originWidth=2482&originalType=binary&ratio=1&rotation=0&showTitle=false&size=542004&status=done&style=none&taskId=ucf37c936-c41d-4ed4-869c-8c2176f468f&title=&width=659)
### ServerlessTask 可觀測性支援 - 階段性審計
當線上任務執行一段時間後，往往需要進行一系列的階段性審計工作，比如上一週的執行總任務數，執行失敗的任務數及執行失敗的時間。目前除了控制檯以外，函式計算提供了豐富的 API 能力來進行任務的審計工作。主要包括以下幾方面能力：

1. 根據狀態進行過濾，只查詢某一個狀態的執行；
1. 根據觸發時間進行過濾，如查詢過去某一段時間內發起的任務；
1. 根據任務名稱查詢。如果您的任務具有業務上下游的 TraceID，您可以在觸發任務時指定一個有意義的任務ID。後續可以根據 ID 字首進行範圍查詢；

上面的幾個過濾方式可以組合，達到更便捷的需求。控制檯所支援的過濾條件如下圖所示：![圖片.png](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/151014/1646878403474-93c69ab2-90a9-4757-98d8-9482281a67b4.png#clientId=uecb3db33-3241-4&crop=0&crop=0&crop=1&crop=1&from=paste&height=136&id=u2c666f77&margin=%5Bobject%20Object%5D&name=%E5%9B%BE%E7%89%87.png&originHeight=272&originWidth=2466&originalType=binary&ratio=1&rotation=0&showTitle=false&size=105220&status=done&style=none&taskId=ud2f43f22-5026-46c4-b78e-23e2c7902fc&title=&width=1233)更多引數內容可參考： [ListStatefulAsyncInvocation](https://help.aliyun.com/document_detail/256588.html) 。
### ServerlessTask 可觀測性支援 - 死信佇列及業務補償
在訊息領域，有一個非常重要的概念 - 死信佇列。當一些訊息無法被消費時，這些訊息往往需要儲存到一個地方，以便後續人為的介入處理，避免因未進行處理而造成業務損失。Serverless Task 也支援了這樣一類功能。您可以對 Serverless Task 設定目標功能；當任務執行失敗後，函式計算支援自動將執行失敗的上下文資訊推送到訊息佇列等訊息服務中，以便後續處理。如果您的處理邏輯支援自動化，函式計算還支援將失敗任務的上下文資訊推送回函式計算，執行一段您的自定義業務邏輯來實現業務補償。

您可以在非同步呼叫配置頁面配置成功及失敗目標。
![圖片.png](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/151014/1646878526541-a3216bce-232a-484e-bbfa-1ebc42eee837.png#clientId=uecb3db33-3241-4&crop=0&crop=0&crop=1&crop=1&from=paste&height=490&id=u071b0f9e&margin=%5Bobject%20Object%5D&name=%E5%9B%BE%E7%89%87.png&originHeight=980&originWidth=2450&originalType=binary&ratio=1&rotation=0&showTitle=false&size=576021&status=done&style=none&taskId=udff31a0e-01ba-4921-b806-733a985197c&title=&width=1225)
更多配置內容請參考：[PutFunctionAsyncInvokeConfig]()。

綜上所述，Serverless Task 所提供的可觀測能力可以有效支援**任務全生命週期的監測需求**。所有控制檯能力均可以使用開放 API 進行定製化開發，來滿足更多的需求。Serverless Task 的目標功能除了可以做到任務失敗補償以外，還可以作為 Event-Driven 模式的資料來源，自動的將處理後的事件投遞到下游服務中。

詳解非同步任務 | 看 Serverless Task 如何解決任務排程&可觀測性中的問題

相關文章