背景與價值

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

• 復雜度高需要抽象的業務（訂單管理，CRM 等）
• 業務需要自動中斷 / 恢復能力，如多個任務之間需要人工干預的場景（人工審批，部署流水線等）
• 業務需要手動中斷 / 恢復（數據備份 / 恢復等）
• 需要詳細監控任務執行狀態的場景
• 流式處理（日志分析，圖片 / 視頻處理等）當前大部分 Serverless Workflow 平臺更多關注控制流程的編排，忽視了工作流中數據流的編排和高效傳輸，上述場景創建函數流觸發器中，由于數據流相對簡單，所以各大平臺支持都比較好，但是對于文件轉碼等存在超大數據流的場景，當前各大平臺沒有給出很好的解決方案。FunctionGraph函數工作流針對該場景，提出了 Serverless Streaming 的流式處理方案，支持毫秒級響應文件處理。

技術原理

FunctionGraph函數工作流提出 Serverless Streaming 的流式可編排的文件處理解決方案，步驟與步驟之間通過數據流驅動，更易于用戶理解。本章通過圖片處理的例子解釋該方案的實現機制。

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

• 控制流：控制工作流的步驟間流轉，以及步驟對應的 Serverless 函數的執行。確保步驟與步驟之間有序執行。
• 數據流：控制整個工作流的數據流轉，通常來說上一個步驟的輸出是下一個步驟的輸入，比如上述圖片處理工作流中，圖片壓縮的結果是打水印步驟的輸入數據。

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

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

在 Serverless Streaming 的流程中，弱化控制流中步驟之間的先后執行順序，允許異步同時執行，步驟與步驟之間的交互通過數據流驅動。其中數據流的控制通過 Stream Bridge 組件來實現。同時函數 SDK 增加流式數據返回接口，用戶不需要將整個文件內容返回，而是通過 gRPC Stream 的方式將數據寫入到 Stream Bridge，Stream Bridge 用來分發數據流到下一個步驟的函數 Pod 中。

操作步驟

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

說明
目前只支持go函數！

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

在FunctionGraph 的函數流控制臺完成工作流編排，舉例如下。

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