摘要：本文将以圖檔處理的場景作為例子較長的描述目前的問題以及華為雲FunctionGraph函數工作流在面對該問題時采取的一系列實踐。
文章作者｜舊浪：華為雲Serverless研發專家、平山：華為雲中間件Serverless負責人
一、背景
企業應用從微服務架構向 Serverless（無伺服器）架構演進，開啟了無伺服器時代，面向無伺服器計算領域的 Serverless 工作流也應運而生。許多Serverless 應用程式不是由單個事件觸發的簡單函數，而是由一系列函數多個步驟組成的，而函數在不同步驟中由不同僚件觸發。Serverless工作流用于将函數編排為協調的微服務應用程式。
Serverless工作流由于自身可編排、有狀态、持久化、可視化監控、異常處理、雲服務內建等特性，适用于很多應用場景，比如：
- 複雜度高需要抽象的業務（訂單管理，CRM等）
- 業務需要自動中斷/恢複能力，如多個任務之間需要人工幹預的場景（人工審批，部署流水線等）
- 業務需要手動中斷/恢複（資料備份/恢複等）
- 需要詳細監控任務執行狀态的場景
- 流式處理（日志分析，圖檔/視訊處理等）
目前大部分Serverless Workflow平台更多關注控制流程的編排，忽視了工作流中資料流的編排和高效傳輸，上述場景1-4中，由于資料流相對簡單，是以各大平台支援都比較好，但是對于檔案轉碼等存在超大資料流的場景，目前各大平台沒有給出很好的解決方案。華為雲FunctionGraph函數工作流針對該場景，提出了Serverless Streaming的流式處理方案，支援毫秒級響應檔案處理。本文将以圖檔處理的場景作為例子較長的描述目前的問題以及華為雲FunctionGraph函數工作流在面對該問題時采取的一系列實踐。
二、問題描述
先以一個圖檔處理的場景舉例，使用者想要執行一個圖檔壓縮并且加水印的任務，這個場景在典型的工作流系統中，可以用如圖一所示的方式進行處理。
圖1：一個典型的圖檔處理工作流
如上圖所示，圖檔壓縮和圖檔加水印的結果都是二進制檔案格式，但是目前主流的Serverless Workflow平台在多個步驟之間傳輸上下文都隻能支援文本格式傳輸，是以圖檔壓縮和加水印的結果都需要經過BASE64或者其他轉碼方式轉成文本進行資料流傳輸。
但是這種方案的限制和使用成本都比較高：
- 函數的Response Body通常有大小限制，是以這種方式無法處理超大檔案。
- 執行結果轉換為文本，需要消耗大量記憶體，記憶體成本比較高。
如何簡單高效的進行檔案處理，業界也給出了其他解決方案，如通過雲存儲進行中間結果轉儲、AWS的Lambda Object檔案轉換方案。下面給出了這兩個方案的優缺點分析。
方案一：中間結果通過雲存儲進行轉儲
該方案如圖2所示：
圖2：雲存儲轉儲運作方式示意圖
兩個步驟之間的檔案流通過雲存儲去傳遞，這種方案支援大檔案流的傳輸，但是由于中間多了一次到雲存儲的網絡傳輸，如果業務對時延要求不高，該方案問題不大，但是對于時延敏感類業務，這種多出的時延是無法接受的。另外雲存儲轉儲需要額外的成本，如果調用量比較大，使用成本較高。
方案二：AWS Lambda Object
圖3：AWS解決方案示意圖[1]
AWS對于這種檔案處理場景，提出了基于S3和Lambda的Lambda Object的方案，參考[1]，簡單來說，是支援為S3檔案桶的getObject API提供Access Point，AccessPoint可以指向某一個Lambda函數，在函數中可以對原來的桶資料檔案進行修改，比如可以将原始視訊轉碼，得到轉碼後的結果傳回到用戶端。雖然解決了時延和大檔案處理的問題，但是這個方案強依賴S3的API，使用者無法進行流程編排，也無法通過事件觸發，不是一個真正通用的方案。
業界方案總結
簡單總結如表1所示，目前業界提供的各個方案或多或少存在一些局限性，沒有辦法在同時滿足低延遲時間的情況下支援可編排的檔案處理。然而低延遲時間和可編排都是大量客戶所追求的關鍵能力，如何解決這些關鍵痛點，提升客戶體驗，成為了目前我們重點想要攻克的難題。
表1：業界檔案處理方案對比
三、華為雲FunctionGraph的Serverless Streaming流式處理方案
針對目前業界缺少高效，可編排的檔案處理方案的痛點，華為雲FunctionGraph函數工作流提出Serverless Streaming的流式可編排的檔案處了解決方案，步驟與步驟之間通過資料流驅動，更易于使用者了解。本章通過圖檔處理的例子解釋該方案的實作機制。
如果需要驅動一個工作流執行，工作流系統需要處理兩個部分：
- 控制流：控制工作流的步驟間流轉，以及步驟對應的Serverless函數的執行。確定步驟與步驟之間有序執行。
- 資料流：控制整個工作流的資料流轉，通常來說上一個步驟的輸出是下一個步驟的輸入，比如上述圖檔處理工作流中，圖檔壓縮的結果是打水印步驟的輸入資料。
在普通的服務編排中，由于需要精準控制各個服務的執行順序，是以控制流是工作流的核心部分。然而在檔案處理等流式處理場景中，對控制流的要求并不高，以上述圖檔處理場景舉例，可以對大圖檔進行分塊處理，圖檔壓縮和加水印的任務不需要嚴格的先後順序，圖檔壓縮處理完一個分塊可以直接流轉到下一個步驟，而不需要等待圖檔壓縮把所有分塊處理完再開始加水印的任務。
基于上述了解，華為雲FunctionGraph工作流的Serverless Streaming方案架構設計如圖四所示：
圖4： Serverless Streaming流式處理架構圖
在Serverless Streaming的流程中，弱化控制流中步驟之間的先後執行順序，允許異步同時執行，步驟與步驟之間的互動通過資料流驅動。其中資料流的控制通過Stream Bridge元件來實作。
同時函數SDK增加流式資料傳回接口，使用者不需要将整個檔案内容傳回，而是通過gRPC Stream的方式将資料寫入到Stream Bridge，Stream Bridge用來分發資料流到下一個步驟的函數Pod中。
這種方式存在如下優點：
- 由于控制流的弱化，完全通過資料流來驅動流程執行，不需要再強限制步驟之間完成的先後順序，如圖檔處理場景中，壓縮和加水印的步驟可以做到完全并行執行，這樣可以加速整個流程的執行速度。
- 每次請求都開辟獨立緩沖區，緩沖區限制大小，資料流僅在内網傳輸，保證整體資料傳輸的可靠性和安全性。
- 不依賴其他外部服務，使用成本低。
- 對于開發人員來講，隻需要關注資料流的處理，而不需要關心資料流如何轉發，如何存儲，降低開發難度。
- 底層流式傳輸通過gRPC進行，整體資料傳輸效率高
在FunctionGraph中開發檔案處理工作流
目前FunctionGraph已經基于上述方案支援了在函數工作流中進行資料流處理，并且将結果通過流資料的方式傳回到用戶端，以建構一個圖檔處理工作流舉例：
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/
點選關注，第一時間了解華為雲新鮮技術~
華為雲部落格_大資料部落格_AI部落格_雲計算部落格_開發者中心-華為雲
#華為雲開發者聯盟#