作者：不瞋 （阿里雲 Serverless 技術負責人）

當我們構建一個應用，總是希望它是響應迅速，成本低廉的。而在實際中，我們的系統卻面臨各種各樣的挑戰，例如不可預測的流量高峰，依賴的下游服務變得緩慢，少量請求卻消耗大量 CPU/記憶體資源。這些因素常常導致整個系統被拖慢，甚至不能響應請求。為了讓應用服務總是響應迅速，很多時候不得不預留更多的計算資源，但大部分時候，這些計算資源都是閒置的。一種更好的做法是將耗時緩慢，或者需要消耗大量資源的處理邏輯從請求處理主邏輯中剝離出來，交給更具資源彈性的系統非同步執行，不但讓請求能夠被迅速處理返回給使用者，也節省了成本。

一般來說，**長耗時，消耗大量資源，或者容易出錯的邏輯**，非常適合從請求主流程中剝離出來，非同步執行。例如新使用者註冊，註冊成功後，系統通常會傳送一封歡迎郵件。傳送歡迎郵件的動作就可以從註冊流程中剝離出來。另一個例子是使用者上傳圖片，圖片上傳後通常需要生成不同大小的縮圖。但圖片處理的過程不必包含在圖片上傳處理流程中，使用者上傳圖片成功後就可以結束流程，生成縮圖等處理邏輯可以作為非同步任務執行。這樣應用伺服器避免被圖片處理等計算密集型任務壓垮，使用者也能更快的得到響應。常見的非同步執行任務包括：

- 傳送電子郵件/即時訊息
- 檢查垃圾郵件
- 文件處理（轉換格式，匯出，……）
- 音影片，圖片處理（生成縮圖，加水印，鑑黃，轉碼，……）
- 呼叫外部的三方服務
- 重建搜尋索引
- 匯入/匯出大量資料
- 網頁爬蟲
- 資料清洗
- ……

[Slack](https://slack.engineering/scaling-slacks-job-queue/)，[Pinterest](https://slack.engineering/scaling-slacks-job-queue/)，[Facebook](https://engineering.fb.com/2020/08/17/production-engineering/async/) 等公司都廣泛的使用非同步任務，實現更好的服務可用性，更低的成本。根據[Dropbox 統計](https://dropbox.tech/infrastructure/asynchronous-task-scheduling-at-dropbox)，他們的業務場景中一共有超過100種不同型別的非同步任務。一個功能完備的非同步任務處理系統能帶來顯著的收益：

- **更快的系統響應時間**。將長耗時的，重資源消耗的邏輯從請求處理流程中剝離，在別的地方非同步執行，能有效的降低請求響應延時，帶來更好的使用者體驗。
- **更好的處理大量突發性請求**。在電商等很多場景下，常常有大量突發性請求對系統造成衝擊。同樣的，如果將重資源消耗邏輯從請求處理流程中剝離，在別的地方非同步執行，那麼相同資源容量的系統能響應更大峰值的請求流量。
- **更低的成本。**非同步任務的執行時長通常在數百毫秒到數小時之間，根據不同的任務型別，合理的選擇任務執行時間和更彈性的使用資源，就能實現更低的成本。
- **更完善的重試策略和錯誤處理能力**。任務保證被可靠的執行（at-least-once），並且按照配置的重試策略進行重試，從而實現更好的容錯能力。例如呼叫第三方的下游服務，如果能變成非同步任務，設定合理的重試策略，即使下游服務偶爾不穩定，也不影響任務的成功率。
- **更快的完成任務處理**。多個任務的執行是高度並行化的。透過伸縮非同步任務處理系統的資源，海量的任務能夠在合理的成本內更快的完成。
- **更好的任務優先順序管理和流控**。任務根據型別，通常按照不同的優先順序處理。非同步任務管理系統能幫助使用者更好的隔離不同優先順序的任務，既讓高優先順序任務能更快的被處理，又讓低優先順序任務不至於被餓死。
- **更多樣化的任務觸發方式**。任務的觸發方式是多種多樣的，例如透過 API 直接提交任務，或是透過事件觸發，或是定時執行等等。
- **更好的可觀測性**。非同步任務處理系統通常會提供任務日誌，指標，狀態查詢，鏈路追蹤等能力，讓非同步任務更好的被觀測、更容易診斷問題。
- **更高的研發效率**。使用者專注於任務處理邏輯的實現，任務排程，資源擴縮容，高可用，流控，任務優先順序等功能都由任務處理系統完成，研發效率大幅提高。
## 任務處理系統架構
任務處理系統通常包括三部分：任務 API 和可觀測，任務分發和任務執行。我們首先介紹這三個子系統的功能，然後再討論整個系統面臨的技術挑戰和解決方案。
![](https://cdn.nlark.com/yuque/0/2022/png/995498/1649891686412-4d26db6a-8163-416f-9b2a-06616007ded6.png#crop=0&crop=0&crop=1&crop=1&from=url&height=61&id=QhuwP&margin=%5Bobject%20Object%5D&originHeight=122&originWidth=1042&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=&width=521#crop=0&crop=0&crop=1&crop=1&from=url&id=Q1kBS&margin=%5Bobject%20Object%5D&originHeight=122&originWidth=1042&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)
### 任務 API/Dashboard

該子系統提供一組任務相關的 API，包括任務建立、查詢、刪除等等。使用者透過 GUI，命令列工具，後者直接呼叫 API 的方式使用系統功能。以 Dashboard 等方式呈現的可觀測能力也非常重要。好的任務處理系統應當包括以下可觀測能力：

- 日誌：能夠收集和展示任務日誌，使用者能夠快速查詢指定任務的日誌。
- 指標：系統需要提供排隊任務數等關鍵指標，幫助使用者快速判斷任務的執行情況。
- 鏈路追蹤：任務從提交到執行過程中，各個環節的耗時。比如在佇列中排隊的時間，實際執行的時間等等。下圖展示了 [Netflix Cosmos](https://netflixtechblog.com/the-netflix-cosmos-platform-35c14d9351ad) 平臺的 tracing 能力。

![](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/6894/1645086401597-c8c2e078-3a09-4fca-9487-12a54525934b.png%23clientId=u5db6220f-1924-4&crop=0&crop=0&crop=1&crop=1&from=paste&height=253&id=ucfa3346a&margin=%5Bobject%20Object%5D&name=%E5%9B%BE%E7%89%87.png&originHeight=506&originWidth=1400&originalType=binary&ratio=1&rotation=0&showTitle=false&size=147533&status=done&style=none&taskId=u7fbf3a4a-ba84-408e-bca8-ac9eb8b89e2&title=&width=700#crop=0&crop=0&crop=1&crop=1&from=url&id=dVrOc&margin=%5Bobject%20Object%5D&originHeight=506&originWidth=1400&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)
### 任務分發

任務分發負責任務的排程分發。一個能應用於生產環境的任務分發系統通常要具備以下功能：

- **任務的可靠分發**：任務一旦提交成功後，無論遇到任何情況，系統都應當保證該任務被排程執行。
- **任務的定時/延時分發**：很多型別的任務，希望在指定的時間執行，例如定時傳送郵件/訊息，或者定時生成資料包表。另一種情況是任務可以延時較長一段時間執行也沒問題，例如下班前提交的資料分析任務在第二天上班前完成即可，這類任務可以放到凌晨資源消耗低峰的時候執行，透過錯峰執行降低成本。
- **任務去重**：我們總是不希望任務被重複執行。除了造成資源浪費，任務重複執行可能造成更嚴重的後果。比如一個計量任務因為重複執行算錯了賬單。要做到**任務只執行一次**（exactly-once），需要在任務提交，分發，執行全鏈路上的每個環節都做到，包括使用者在實現任務處理程式碼時也要在執行成功，執行失敗等各種情況下，做到 exactly-once。如何實現完整的 exactly-once 比較複雜，超出了本文的討論範圍。很多時候，系統提供一個簡化的語義也很有價值，即**任務只成功執行一次**。任務去重需要使用者在提交任務時指定任務 ID，系統透過 ID來判斷該任務是否已經被提交和成功執行過。
- **任務錯誤重試**：合理的任務重試策略對高效、可靠的完成任務非常關鍵。任務的重試要考慮幾個因素：1）要匹配下游任務執行系統的處理能力。比如收到下游任務執行系統的流控錯誤，或者感知到任務執行成為瓶頸，需要指數退避重試。不能因為重試反而加大了下游系統的壓力，壓垮下游；2）重試的策略要簡單清晰，易於使用者理解和配置。首先要對錯誤進行分類，區分不可重試錯誤，可重試錯誤，流控錯誤。不可重試錯誤是指確定性失敗的錯誤，重試沒有意義，比如引數錯誤，許可權問題等等。可重試錯誤是指導致任務失敗的因素具有偶然性，透過重試任務最終會成功，比如網路超時等系統內部錯誤。流控錯誤是一種比較特殊的可重試錯誤，通常意味著下游已經滿負荷，重試需要採用退避模式，控制傳送給下游的請求量。
- **任務的負載均衡**：任務的執行時間變化很大，短的幾百毫秒，長的數十小時。簡單的 round-robin 方式分發任務，會導致執行節點負載不均。實踐中常見的模式是將任務放置到佇列中，執行節點根據自身任務執行情況主動拉取任務。使用佇列儲存任務，讓根據節點的負載把任務分發到合適的節點上，讓節點的負載均衡。任務負載均衡通常需要分發系統和執行子系統配合實現。
- **任務按優先順序分發**：任務處理系統通常對接很多的業務場景，他們的任務型別和優先順序各不相同。位於業務核心體驗相關的任務執行優先順序要高於邊緣任務。即使同樣是訊息通知，淘寶上買家收到一個商品評論通知的重要性肯定低於新冠疫情中的核酸檢測通知。但另一方面，系統也要保持一定程度的公平，不要讓高優先順序任務總是搶佔資源，而餓死低優先順序任務。
- **任務流控**：任務流控典型的使用場景是削峰填谷，比如使用者一次性提交數十萬的任務，期望在幾個小時內慢慢處理。因此係統需要限制任務的分發速率，匹配下游任務執行的能力。任務流控也是保證系統可靠性的重要手段，某類任務提交量突然爆發式增長，系統要透過流控限制其對系統的衝擊，減小對其他任務的影響。
- **批次暫停和刪除任務**：在實際生產環境，提供任務批次暫停和刪除非常重要。使用者總是會出現各種狀況，比如任務的執行出現了某些問題，最好能暫停後續任務的執行，人工檢查沒有問題後，再恢復執行；或者臨時暫停低優先順序任務，釋放計算資源用於執行更高優先順序的任務。另一種情況是提交的任務有問題，執行沒有意義。因此係統要能讓使用者非常方便的刪除正在執行和排隊中的任務。任務的暫停和刪除需要分發和執行子系統配合實現。

任務分發的架構可分為拉模式和推模式。拉模式透過任務佇列分發任務。執行任務的例項主動從任務佇列中拉取任務，處理完畢後再拉取新任務。相對於拉模式，推模式增加了一個分配器的角色。分配器從任務佇列中讀取任務，進行排程，推送給合適的任務執行例項。
![](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/6894/1649892508207-9eb5a281-c809-4fc3-9b80-fbd38bd1b708.png%23clientId=u51636503-b4c1-4&crop=0&crop=0&crop=1&crop=1&from=paste&height=376&id=u0ad59be2&margin=%5Bobject%20Object%5D&name=%E5%9B%BE%E7%89%87.png&originHeight=752&originWidth=1442&originalType=binary&ratio=1&rotation=0&showTitle=false&size=242432&status=done&style=none&taskId=u3f84522e-92ef-421f-82fd-9f17e09cc67&title=&width=721#crop=0&crop=0&crop=1&crop=1&from=url&id=QKUuN&margin=%5Bobject%20Object%5D&originHeight=752&originWidth=1442&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)

拉模式的架構清晰，基於 Redis 等流行軟體可以快速搭建任務分發系統，在簡單任務場景下表現良好。但如果要支援任務去重，任務優先順序，批次暫停或刪除，彈性的資源擴縮容等複雜業務場景需要的功能，拉模式的實現複雜度會迅速增加。實踐中，拉模式面臨以下一些主要的挑戰：

- 資源自動伸縮和負載均衡複雜。任務執行例項和任務佇列建立連線，拉取任務。當任務執行例項規模較大時，對任務佇列的連線資源會造成很大的壓力。因此需要一層對映和分配，任務例項只和對應的任務佇列連線。下圖是 [Slack](https://slack.engineering/scaling-slacks-job-queue/) 公司的非同步任務處理系統架構。Worker 節點只和部分 Redis 例項相連。這解決了 worker 節點大規模擴充套件的能力，但是增加了排程和負載均衡的複雜度。![](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/6894/1649892942986-87ea18fc-d5ec-431c-8979-062b3501f3c3.png%23clientId=u51636503-b4c1-4&crop=0&crop=0&crop=1&crop=1&from=paste&height=301&id=u84179af0&margin=%5Bobject%20Object%5D&name=%E5%9B%BE%E7%89%87.png&originHeight=602&originWidth=1442&originalType=binary&ratio=1&rotation=0&showTitle=false&size=234759&status=done&style=none&taskId=uf44b5c8d-dec4-4b0f-bc8a-d2e3869e77e&title=&width=721#crop=0&crop=0&crop=1&crop=1&from=url&id=b4SoQ&margin=%5Bobject%20Object%5D&originHeight=602&originWidth=1442&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)
-

- 從支援任務優先順序，隔離和流控等需求的角度考慮，最好能使用不同的佇列。但佇列過多，又增加了管理和連線資源消耗，如何平衡很有挑戰。
- 任務去重，任務批次暫停或者刪除等功能依賴訊息佇列功能，但很少有訊息類產品能滿足所有需求，常常需要自行開發。例如從可擴充套件性的角度，通常做不到每一類任務都對應單獨的任務佇列。當任務佇列中包含多種型別的任務時，要批次暫停或者刪除其中某一類的任務，是比較複雜的。
- 任務佇列的任務型別和任務處理邏輯耦合。如果任務佇列中包含多種型別的任務，要求任務處理邏輯也要實現相應的處理邏輯，對使用者不友好。在實踐中，A 使用者的任務處理邏輯不會預期接收到別的使用者任務，因此任務佇列通常由使用者自行管理，進一步增加了使用者的負擔。

推模式的核心思想是將任務佇列和任務執行例項解耦，平臺側和使用者的邊界更加清晰。使用者只需要專注於任務處理邏輯的實現，而任務佇列，任務執行節點資源池的管理都由平臺負責。推模式的解耦也讓任務執行節點的擴容不再受任務佇列的連線資源等方面的限制，能夠實現更高的彈性。但推模式也引入了很多的複雜度，任務的優先順序管理，負載均衡，排程分發，流控等都由分配器負責，分配器需要和上下游系統聯動。
總的來說，當任務場景變得複雜後，無論拉還是推模式，系統複雜度都不低。但推模式讓平臺和使用者的邊界更清晰，簡化了使用者的使用複雜度，因此有較強技術實力的團隊，實現平臺級的任務處理系統時，通常會選擇推模式。
### 任務執行

任務執行子系統管理一批執行任務的 worker 節點，以彈性、可靠的方式執行任務。典型的任務執行子系統需具備如下功能：

- **任務的可靠執行**。任務一旦提交成功，無論任何情況，系統應當保證任務被執行。例如執行任務的節點當機，任務應當排程到其他的節點執行。任務的可靠執行通常是任務分發和任務執行子系統共同配合實現。
- **共享資源池**。不同型別的任務處理資源共享統一的資源池，這樣才能削峰填谷，提高資源利用效率，降低成本。例如把計算密集，io密集等不同型別的任務排程到同一臺 worker 節點上，就能更充分的利用節點上的CPU，記憶體，網路等多個維度的資源。共享資源池對容量管理，任務資源配額管理，任務優先順序管理，資源隔離提出了更高的要求。
- **資源彈性伸縮**。系統能根據負載的執行情況伸縮執行節點資源，降低成本。伸縮的時機和數量非常關鍵。常見的根據任務執行節點的 CPU，記憶體等資源水位情況伸縮，時間較長，不能滿足實時性要求高的場景。很多系統也使用排隊任務數等指標進行伸縮。另一個值得關注的點是執行節點的擴容需要匹配上下游系統的能力。例如當任務分發子系統使用佇列來分發任務時，worker 節點的擴容要匹配佇列的連線能力。
- **任務資源隔離**。在 worker 節點上執行多個不同的任務時，資源是相互隔離的。通常使用容器的隔離機制實現。
- **任務資源配額**。使用者的使用場景多樣，常常包含多種任務型別和優先順序。系統要支援使用者為不同優先順序的任務或者處理函式設定資源配額，為高優先順序任務預留資源，或者限制低優先順序任務能使用的資源。
- **簡化任務處理邏輯的編碼**。好的任務處理系統，能夠讓使用者專注於實現單個任務處理邏輯，系統自動並行、彈性、可靠的執行任務。
- **平滑升級**。底層系統的升級不要中斷長時任務的執行。
- **執行結果通知**。實時通知任務執行狀態和結果。對於執行失敗的任務，任務的輸入被儲存到死信佇列中，方便使用者隨時手動重試。

任務執行子系統通常使用 K8s 管理的容器叢集作為資源池。K8s 能夠管理節點，將執行任務的容器例項排程到合適的節點上。K8s 也內建了作業（Jobs）和定時作業（Cron Jobs）的支援，簡化了使用者使用 Job 負載的難度。K8s 有助於實現共享資源池管理，任務資源隔離等功能。但 K8s 主要能力還是在POD/例項管理上，很多時候需要開發更多的功能來滿足非同步任務場景的需求。例如：

- K8s 的 HPA 一般難以滿足任務場景下的自動伸縮。[Keda](https://keda.sh/) 等開源專案提供了按排隊任務數等指標伸縮的模式。AWS 也結合 CloudWatch 提供了[類似的解決方案](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/autoscaling-asynchronous-job-queues.pdf)。
- K8s 一般需要配合佇列來實現非同步任務，佇列資源的管理需要使用者自行負責。
- K8s 原生的作業排程和啟動時間比較慢，而且提交作業的 tps 一般小於 200，所以不適合高 tps，短延時的任務。

注意：K8s 中的作業（Job）和本文討論的任務（task）有一些區別。K8s 的 Job 通常包含處理一個或者多個任務。本文的任務是一個原子的概念，單個任務只在一個例項上執行。執行時長從幾十毫秒到數小時不等。
![](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/6894/1649900723262-b503c2c6-2ada-4b58-bbdc-4e7d2d2b4220.png%23clientId=u024d96f6-966c-4&crop=0&crop=0&crop=1&crop=1&from=paste&height=341&id=u50bd2a9f&margin=%5Bobject%20Object%5D&name=%E5%9B%BE%E7%89%87.png&originHeight=682&originWidth=1542&originalType=binary&ratio=1&rotation=0&showTitle=false&size=325635&status=done&style=none&taskId=u942d2cc7-c4f3-4f2a-98e3-923630bb278&title=&width=771#crop=0&crop=0&crop=1&crop=1&from=url&id=v1sPE&margin=%5Bobject%20Object%5D&originHeight=682&originWidth=1542&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)
## 大規模多租戶非同步任務處理系統實踐

接下來，筆者以阿里雲函式計算的非同步任務處理系統為例，探討大規模多租戶[非同步任務](https://help.aliyun.com/document_detail/372531.html)處理系統的一些技術挑戰和應對策略。在阿里雲函式計算平臺上，使用者只需要建立任務處理函式，然後提交任務即可。整個非同步任務的處理是彈性、高可用的，具備完整的可觀測能力。在實踐中，我們採用了多種策略來實現多租戶環境的隔離、伸縮、負載均衡和流控，平滑處理海量使用者的高度動態變化的負載。
### 動態佇列資源伸縮和流量路由

如前所述，非同步任務系統通常需要佇列實現任務的分發。當任務處理中臺對應很多業務方，那麼為每一個應用/函式，甚至每一個使用者都分配單獨的佇列資源就不再可行。因為絕大多數應用都是長尾的，呼叫低頻，會造成大量佇列，連線資源的浪費。並且輪詢大量佇列也降低了系統的可擴充套件性。

但如果所有使用者都共享同一批佇列資源，則會面臨多租戶場景中經典的“noisy neighbor”問題，A 應用突發式的負載擠佔佇列的處理能力，影響其他應用。

實踐中，函式計算構建了動態佇列資源池。一開始資源池內會預置一些佇列資源，並將應用雜湊對映到部分佇列上。如果某些應用的流量快速增長時，系統會採取多種策略：

- 如果應用的流量持續保持高位，導致佇列積壓，系統將為他們自動建立單獨的佇列，並將流量分流到新的佇列上。
- 將一些延時敏感，或者優先順序高的應用流量遷移到其他佇列上，避免被高流量應用產生的佇列積壓影響。
- 允許使用者設定任務的過期時間，對於有實時性要求的任務，在發生積壓時快速丟棄過期任務，確保新任務能更快的處理。
### 負載隨機分片

在一個多租環境中，防止“破壞者”對系統造成災難性的破壞是系統設計的最大挑戰。破壞者可能是被 DDoS 攻擊的使用者，或者在某些 corner case 下正好觸發了系統 bug 的負載。下圖展示了一種非常流行的架構，所有使用者的流量以 round-robin 的方式均勻的傳送給多臺伺服器。當所有使用者的流量符合預期時，系統工作得很好，每臺伺服器的負載均勻，而且部分伺服器當機也不影響整體服務的可用性。但當出現“破壞者”後，系統的可用性將出現很大的風險。
![](https://cdn.nlark.com/yuque/0/2022/png/995498/1650332024053-43a5d96f-93fa-49bf-82a9-2d700304e136.png#crop=0&crop=0&crop=1&crop=1&from=url&id=KEeGa&margin=%5Bobject%20Object%5D&originHeight=422&originWidth=522&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)

如下圖所示，假設紅色的使用者被 DDoS 攻擊或者他的某些請求可能觸發伺服器當機的 bug，那麼他的負載將可能打垮所有的伺服器，造成整個服務不可用。

![](https://cdn.nlark.com/yuque/0/2022/png/995498/1650332057401-8d08b7f5-9a23-40d3-8eb4-d3271d108970.png#crop=0&crop=0&crop=1&crop=1&from=url&id=cOiru&margin=%5Bobject%20Object%5D&originHeight=422&originWidth=522&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)

上述問題的本質是任何使用者的流量都會被路由到所有伺服器上，這種沒有任何負載隔離能力的模式在面臨“破壞者”時相當脆弱。對於任何一個使用者，如果他的負載只會被路由到部分伺服器上，能不能解決這個問題？如下圖所示，任何使用者的流量最多路由到2臺伺服器上，即使造成兩臺伺服器當機，綠色使用者的請求仍然不受影響。這種將使用者的負載對映到**部分而非全部**伺服器的負載分片模式，能夠很好的實現負載隔離，降低服務不可用的風險。代價則是系統需要準備更多的冗餘資源。

![](https://cdn.nlark.com/yuque/0/2022/png/995498/1650332082064-6658166d-4f00-41dc-9983-9ded81c66629.png#crop=0&crop=0&crop=1&crop=1&from=url&id=fzHtF&margin=%5Bobject%20Object%5D&originHeight=422&originWidth=522&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)

接下來，讓我們調整下使用者負載的對映方式。如下圖所示，每個使用者的負載**均勻的**對映到兩臺伺服器上。不但負載更加均衡，更棒的是，即使兩臺伺服器當機，除紅色的使用者負載都不受影響。如果我們把分割槽的大小設為2，那麼從3臺伺服器中選擇2臺伺服器的組合方式有 C_{3}^{2}=3 種，即3種可能的分割槽方式。透過隨機演算法，我們將負載均勻的對映到分割槽上，那麼任意一個分割槽不可服務，則最多影響1/3的負載。假設我們有100臺伺服器，分割槽的大小仍然是2，那麼分割槽的方式有C_{100}{2}=4950種，單個分割槽不可用只會影響1/4950=0.2%的負載。隨著伺服器的增多，隨機分割槽的效果越明顯。對負載隨機分割槽是一個非常簡潔卻強大的模式，在保障多租系統的可用性中起到了關鍵的作用。

![](https://cdn.nlark.com/yuque/0/2022/png/995498/1650332103866-3615afeb-381c-44cc-ad53-a9888122193a.png#crop=0&crop=0&crop=1&crop=1&from=url&id=oh2fT&margin=%5Bobject%20Object%5D&originHeight=422&originWidth=522&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)
### 自適應下游處理能力的任務分發

函式計算的任務分發採用了推模式，這樣使用者只需要專注於任務處理邏輯的開發，平臺和使用者的邊界也很清晰。在推模式中，有一個任務分配器的角色，負責從任務佇列拉取任務並分配到下游的任務處理例項上。任務分配器要能根據下游處理能力，自適應的調整任務分發速度。當使用者的佇列產生積壓時，我們希望不斷增加 dispatch worker pool 的任務分發能力；當達到下游處理能力的上限後，worker pool 要能感知到該狀態，保持相對穩定的分發速度；當任務處理完畢後，work pool 要縮容，將分發能力釋放給其他任務處理函式。

![](https://cdn.nlark.com/yuque/0/2022/png/995498/1650332889471-3366d3d4-2aa7-4086-a658-8f23a04214c3.png?x-oss-process=image%2Fresize%2Cw_1442%2Climit_0#crop=0&crop=0&crop=1&crop=1&from=url&id=AEjaX&margin=%5Bobject%20Object%5D&originHeight=342&originWidth=1442&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)
在實踐中，我們借鑑了 tcp 擁塞控制演算法的思想，對 worker pool 的擴縮容採取 AIMD 演算法（Additive Increase Multiplicative Decrease，和性增長，乘性降低）。當使用者短時間內提交大量任務時，分配器不會立即向下遊傳送大量任務，而是按照“和性增長”策略，線性增加分發速度，避免對下游服務的衝擊。當收到下游服務的流控錯誤後，採用“乘性減少”的策略來，按照一定的比例來縮容 worker pool。其中流控錯誤需要滿足錯誤率和錯誤數的閾值後才觸發縮容，避免 worker pool 的頻繁擴縮容。

### 向上遊的任務生產方傳送背壓（back pressure）

如果任務的處理能力長期落後於任務的生產能力，佇列中積壓的任務會越來越多，雖然可以使用多個佇列並進行流量路由來減小租戶之間的相互影響。但任務積壓超過一定閾值後，應當更積極的向上遊的任務生產方反饋這種壓力，例如開始流控任務提交的請求。在多租共享資源的場景下，背壓的實施會更加有挑戰。例如A，B應用共享任務分發系統的資源，如果A應用的任務積壓，如何做到：

- 公平。儘可能流控A而不是B應用。流控本質是一個機率問題，為每一個物件計算流控機率，機率越準確，流控越公平。
- 及時。背壓要傳遞到系統最外層，例如在任務提交時就對A應用流控，這樣對系統的衝擊最小。

如何在多租場景中識別到需要流控的物件很有挑戰，我們在實踐中借鑑了[Sample and Hold](https://dl.acm.org/citation.cfm?id=633056)演算法，取得了較好的效果。感興趣的讀者可以參考相關論文。
## 非同步任務處理系統的能力分層

根據前述對非同步任務處理系統的架構和功能的分析，我們將非同步任務處理系統的能力分為以下三層：

- **Level 1**：一般需 1-5 人研發團隊，系統是透過整合 K8s 和訊息佇列等開源軟體/雲服務的能力搭建的。系統的能力受限於依賴的開源軟體/雲服務，難以根據業務需求進行定製。資源的使用偏靜態，不具備資源伸縮，負載均衡的能力。能夠承載的業務規模有限，隨著業務規模和複雜度增長，系統開發和維護的代價會迅速增加。
- **Level 2**：一般需 5-10人研發團隊，在開源軟體/雲服務的基礎之上，具備一定的自主研發能力，滿足常見的業務需求。不具備完整的任務優先順序、隔離、流控的能力，通常是為不同的業務方配置不同的佇列和計算資源。資源的管理比較粗放，缺少實時資源伸縮和容量管理能力。系統缺乏可擴充套件性，資源精細化管理能力，難以支撐大規模複雜業務場景。
- **Level 3**：一般需 10+ 人研發團隊，能夠打造平臺級的系統。具備支撐大規模，複雜業務場景的能力。採用共享資源池，在任務排程，隔離流控，負載均衡，資源伸縮等方面能力完備。平臺和使用者界限清晰，業務方只需要專注於任務處理邏輯的開發。具備完整的可觀測能力。

|  | **Level 1** | **Level 2** | **Level 3** |
| --- | --- | --- | --- |
| 任務的可靠分發 | 支援 | 支援 | 支援 |
| 任務定時/延時傳送 | 取決於選擇的訊息佇列能力。一般支援定時任務，但不支援延時任務 | 支援 | 支援 |
| 任務去重 | 不支援 | 支援 | 支援 |
| 任務錯誤自動重試 | 有限支援。一般依賴於 K8s Jobs 內建的重試策略。對於未使用 K8s Jobs 的任務，則需使用者在任務處理邏輯中自行實現 | 有限支援。一般依賴於 K8s Jobs 內建的重試策略。對於未使用 K8s Jobs 的任務，則需使用者在任務處理邏輯中自行實現 | 支援。平臺和使用者界限清晰，根據使用者設定的策略重試 |
| 任務負載均衡 | 有限支援。在任務執行例項規模小的情況下透過訊息佇列實現 | 有限支援。在任務執行例項規模小的情況下透過訊息佇列實現 | 支援。系統具備大規模節點的負載均衡能力 |
| 任務優先順序 | 不支援 | 有限支援。允許使用者為高優先順序任務預留資源，或者限制低優先順序任務的資源使用 | 支援。高優先順序任務可搶佔低優先順序任務資源，同時系統會兼顧公平，避免低優先順序任務被餓死 |
| 任務流控 | 不支援 | 不支援。一般是為不同任務型別或者業務方配置獨立的佇列和計算資源 | 在系統的每個環節具備流控能力，系統不會因為任務爆發式提交雪崩 |
| 任務批次暫停/刪除 | 不支援 | 有限支援。取決於是否為不同任務型別或者業務方配置獨立的佇列和計算資源 | 支援 |
| 共享資源池 | 有限支援。依賴 K8s 的排程能力。一般是為各個業務方搭建不同的叢集 | 有限支援。依賴 K8s 的排程能力。一般是為各個業務方搭建不同的叢集 | 支援。不同型別的任務，不同業務場景共享同一個資源池 |
| 資源彈性伸縮 | 不支援。K8s 的 HPA 通常難以滿足任務場景下的伸縮要求 | 不支援。K8s 的 HPA 通常難以滿足任務場景下的伸縮要求 | 支援。根據排隊任務數，節點資源利用率等多維度實時伸縮 |
| 任務資源隔離 | 支援。依賴容器的資源隔離能力 | 支援。依賴容器的資源隔離能力 | 支援。依賴容器的資源隔離能力 |
| 任務資源配額 | 不支援 | 支援 | 支援 |
| 簡化任務處理邏輯編碼 | 不支援。任務處理邏輯需要自行拉取任務，執行任務 | 不支援。任務處理邏輯需要自行拉取任務，執行任務 | 支援 |
| 系統平滑升級 | 不支援 | 不支援 | 支援 |
| 執行結果通知 | 不支援 | 不支援 | 支援 |
| 可觀測性 | 依賴 K8s，訊息佇列等開源軟體自身的可觀測能力。具備基本的任務狀態查詢 | 依賴 K8s，訊息佇列等開源軟體自身的可觀測能力。具備基本的任務狀態查詢 | 具備從任務到系統各個層面的完整可觀測能力 |

## 結論

非同步任務是構建彈性、高可用，響應迅速應用的重要手段。本文對非同步任務的適用場景和收益進行了介紹，並討論了典型非同步任務系統的架構、功能和工程實踐。要實現一個能夠滿足多種業務場景需求，彈性可擴充套件的非同步任務處理平臺具有較高的複雜度。而阿里雲函式計算 FC 為使用者提供了開箱即用的，接近於Level ß3能力的非同步任務處理服務。使用者只需要建立任務處理函式，透過控制檯，命令列工具，API/SDK，事件觸發等多種方式提交任務，就可以彈性、可靠、可觀測完備的方式處理任務。函式計算非同步任務覆蓋任務處理時長從毫秒到24小時的場景，被阿里雲資料庫自制服務 DAS，支付寶小程式壓測平臺，網易雲音樂，新東方，分眾傳媒，米連等集團內外客戶廣泛應用。
## 附錄

1. 函式計算非同步任務和 K8S Jobs 的能力對比。
| **對比項** | **函式計算非同步任務** | **K8S Jobs** |
| --- | --- | --- |
| 適用場景 | 適合任務執行時長數十毫秒的實時任務和任務執行時長几十小時的離線任務 | 適合任務提交速度要求不高，任務負載比較固定，任務實時性要求不高的離線任務 |
| 任務可觀測能力 | 支援。提供日誌，任務排隊數等指標，任務鏈路耗時，任務狀態查詢等豐富可觀測能力 | 自行整合開源軟體實現。 |
| 任務例項自動擴縮容 | 支援。根據任務排隊數，例項資源使用率自動擴縮容 | 不支援。一般透過任務佇列，自行實現自動擴縮容和例項負載均衡，複雜度高 |
| 任務例項伸縮速度 | 毫秒級 | 分鐘級 |
| 任務例項資源利用率 | 使用者只需要選擇合適的例項規格，例項自動伸縮，按實際處理任務的時長計量，資源利用率高 | 需在作業（Job）提交時確定例項的規格和數目。例項難以自動伸縮和負載均衡，資源利用率低 |
| 任務提交速度 | 單個使用者支援每秒提交數萬任務 | 整個叢集每秒最多啟動數百作業（Jobs） |
| 任務定時/延時提交 | 支援 | 支援定時任務，不支援延時任務 |
| 任務去重 | 支援 | 不支援 |
| 暫停/恢復任務執行 | 支援 | Alpha 狀態（K8S v1.21） |
| 終止指定任務 | 支援 | 有限支援。透過終止任務例項間接實現 |
| 任務流控 | 支援。可在使用者，任務處理函式等不同粒度進行流控 | 不支援 |
| 任務結果自動回撥 | 支援 | 不支援 |
| 開發運維成本 | 只需要實現任務的處理邏輯 | 需維護K8S叢集 |

1. [網易雲音樂 Serverless Jobs 實踐，音訊處理演算法業務落地速度10x提升](https://developer.aliyun.com/article/801501)
1. [其他非同步任務案例](https://developer.aliyun.com/article/815182)

若有收穫，就點個贊吧

非同步任務處理系統，如何解決業務長耗時、高併發難題？

相關文章