企業應用從微服務架構向 Serverless（無服務器）架構演進，開啟了無服務器時代，面向無服務器計算領域的 Serverless 工作流也應運而生。許多 Serverless 應用程序不是由單個事件觸發的簡單函數，而是由一系列函數多個步驟組成的，而函數在不同步驟中由不同事件觸發。Serverless 工作流用于將函數編排為協調的微服務應用程序。

Serverless 工作流由于自身可編排、有狀態、持久化、可視化監控、異常處理、云服務集成等特性，適用于很多應用場景，比如：

1. 復雜度高需要抽象的業務（訂單管理，CRM 等）

2. 業務需要自動中斷 / 恢復能力，如多個任務之間需要人工干預的場景（人工審批，部署流水線等）

3. 業務需要手動中斷 / 恢復（數據備份 / 恢復等）

4. 需要詳細監控任務執行狀態的場景

5. 流式處理（日志分析，圖片 / 視頻處理等）

當前大部分 Serverless Workflow 平臺更多關注控制流程的編排，忽視了工作流中數據流的編排和高效傳輸，上述場景 1-4 中，由于數據流相對簡單，所以各大平臺支持都比較好，但是對于文件轉碼等存在超大數據流的場景，當前各大平臺沒有給出很好的解決方案。華為云 FunctionGraph 函數工作流針對該場景，提出了 Serverless Streaming 的流式處理方案，支持毫秒級響應文件處理。本文將以圖片處理的場景作為例子詳細描述當前的問題以及華為云 FunctionGraph 函數工作流在面對該問題時采取的一系列實踐。

先以一個圖片處理的場景舉例，用戶想要執行一個圖片壓縮并且加水印的任務，這個場景在典型的工作流系統中，可以用如圖一所示的方式進行處理。

圖 1：一個典型的圖片處理工作流

如上圖所示，圖片壓縮和圖片加水印的結果都是二進制文件格式，但是當前主流的 Serverless Workflow 平臺在多個步驟之間傳輸上下文都只能支持文本格式傳輸，所以圖片壓縮和加水印的結果都需要經過 BASE64 或者其他轉碼方式轉成文本進行數據流傳輸。

但是這種方案的限制和使用成本都比較高：

1. 函數的 Response Body 通常有大小限制，所以這種方式無法處理超大文件。

2. 執行結果轉換為文本，需要消耗大量內存，內存成本比較高。

如何簡單高效的進行文件處理，業界也給出了其他解決方案，如通過云存儲進行中間結果轉儲、AWS 的 Lambda Object 文件轉換方案。下面給出了這兩個方案的優缺點分析。

該方案如圖 2 所示：

圖 2：云存儲轉儲運行方式示意圖

兩個步驟之間的文件流通過云存儲去傳遞，這種方案支持大文件流的傳輸，但是由于中間多了一次到云存儲的網絡傳輸，如果業務對時延要求不高，該方案問題不大，但是對于時延敏感類業務，這種多出的時延是無法接受的。另外云存儲轉儲需要額外的成本，如果調用量比較大，使用成本較高。

圖 3：AWS 解決方案示意圖 [1]

AWS 對于這種文件處理場景，提出了基于 S3 和 Lambda 的 Lambda Object 的方案，參考 [1]，簡單來說，是支持為 S3 文件桶的 getObject API 提供 Access Point，AccessPoint 可以指向某一個 Lambda 函數，在函數中可以對原來的桶數據文件進行修改，比如可以將原始視頻轉碼，得到轉碼后的結果返回到客戶端。雖然解決了時延和大文件處理的問題，但是這個方案強依賴 S3 的 API，用戶無法進行流程編排，也無法通過事件觸發，不是一個真正通用的方案。

簡單總結如表 1 所示，當前業界提供的各個方案或多或少存在一些局限性，沒有辦法在同時滿足低時延的情況下支持可編排的文件處理。然而低時延和可編排都是大量客戶所追求的關鍵能力，如何解決這些關鍵痛點，提升客戶體驗，成為了當前我們重點想要攻克的難題。

表 1：業界文件處理方案對比

針對當前業界缺少高效，可編排的文件處理方案的痛點，華為云 FunctionGraph 函數工作流提出 Serverless Streaming 的流式可編排的文件處理解決方案，步驟與步驟之間通過數據流驅動，更易于用戶理解。本章通過圖片處理的例子解釋該方案的實現機制。

如果需要驅動一個工作流執行，工作流系統需要處理兩個部分：

1. 控制流：控制工作流的步驟間流轉，以及步驟對應的 Serverless 函數的執行。確保步驟與步驟之間有序執行。

2. 數據流：控制整個工作流的數據流轉，通常來說上一個步驟的輸出是下一個步驟的輸入，比如上述圖片處理工作流中，圖片壓縮的結果是打水印步驟的輸入數據。

在普通的服務編排中，由于需要精準控制各個服務的執行順序，所以控制流是工作流的核心部分。然而在文件處理等流式處理場景中，對控制流的要求并不高，以上述圖片處理場景舉例，可以對大圖片進行分塊處理，圖片壓縮和加水印的任務不需要嚴格的先后順序，圖片壓縮處理完一個分塊可以直接流轉到下一個步驟，而不需要等待圖片壓縮把所有分塊處理完再開始加水印的任務。

基于上述理解，華為云 FunctionGraph 工作流的 Serverless Streaming 方案架構設計如圖四所示：

圖 4：Serverless Streaming 流式處理架構圖

在 Serverless Streaming 的流程中，弱化控制流中步驟之間的先后執行順序，允許異步同時執行，步驟與步驟之間的交互通過數據流驅動。其中數據流的控制通過 Stream Bridge 組件來實現。

同時函數 SDK 增加流式數據返回接口，用戶不需要將整個文件內容返回，而是通過 gRPC Stream 的方式將數據寫入到 Stream Bridge，Stream Bridge 用來分發數據流到下一個步驟的函數 Pod 中。

這種方式存在如下優點：

1. 由于控制流的弱化，完全通過數據流來驅動流程執行，不需要再強限制步驟之間完成的先后順序，如圖片處理場景中，壓縮和加水印的步驟可以做到完全并行執行，這樣可以加速整個流程的執行速度。

2. 每次請求都開辟獨立緩沖區，緩沖區限制大小，數據流僅在內網傳輸，保證整體數據傳輸的可靠性和安全性。

3. 不依賴其他外部服務，使用成本低。

4. 對于開發人員來講，只需要關注數據流的處理，而不需要關心數據流如何轉發，如何存儲，降低開發難度。

5. 底層流式傳輸通過 gRPC 進行，整體數據傳輸效率高

1. 首先創建一個圖片壓縮的函數，其中代碼在處理返回數據通過 ctx.Write() 函數將結果以流式數據的形式返回：

FunctionGraph 通過 ctx.Write() 函數提供了流式返回的能力，對開發者來說，只需要將最終結果通過流的方式返回，而不需要關注網絡傳輸的細節。

2. 在函數控制臺中啟用該函數的流式返回能力

3. 用上面的方式完成其他函數的編寫，最后在 FunctionGraph 的函數流控制臺完成工作流編排，舉例如下：

4. 調用工作流的同步執行接口，獲取最終結果的文件流，數據將以 chunked 流式返回的方式返回到客戶端

針對圖片處理的具體場景，我們測試對比了不同大小圖片（333k、1m、4m、7m、10m、12m）進行圖片切割和圖片壓縮的場景，由于 BASE64 轉碼方案無法支持大文件，AWS Lambda Object 方案無法支持編排，所以這里只對比使用 OBS 轉儲方案和基于流式返回的 Servlerss Streaming 方案的時延數據。具體對比數據圖表如下：

圖 5：測試數據對比

響應時延：指客戶端發出請求到收到第一個字節消耗的時延（單位：秒）

端到端時延：指客戶端發出請求到收到最后一個字節消耗的時延（單位：秒）

從測試數據可以看出，響應時延和端到端時延使用流式返回方案后都得到了不同程度的降低。其中響應時延降低幅度較大，OBS 轉儲方案響應時延隨著圖片大小增大，響應時延呈線性上升，超過 4M 的圖片響應時延就達到秒級，使用流式返回方案后，響應時延持續穩定在毫秒級的水平。從中可以發現，基于 Serverless Streaming 的流式返回方案不僅具備流式處理和可編排的能力，并且在文件處理場景中可以顯著降低時延，從多個方面提升了用戶使用體驗。

本文主要討論了 Serverless Workflow 在大文件處理時碰到的問題，FunctionGraph 通過簡化數據傳輸鏈路，提升文件流處理效率, 給出了一種穩定高效、極低時延的大文件處理方法 Serverless Streaming，支持毫秒級的文件流式處理, 顯著改善函數編排在文件處理等場景中的用戶體驗。

FunctionGraph 作為華為元戎加持的下一代 Serverless 函數計算與編排服務，將圍繞通用全場景 Serverless 的前沿理論及案例實踐，持續分享。

參考資料：

[1]Introducing Amazon S3 Object Lambda (https://aws.amazon.com/cn/blogs/aws/introducing-amazon-s3-object-lambda-use-your-code-to-process-data-as-it-is-being-retrieved-from-s3/)