企業(yè)應(yīng)用從微服務(wù)架構(gòu)向 Serverless（無(wú)服務(wù)器）架構(gòu)演進(jìn)，開(kāi)啟了無(wú)服務(wù)器時(shí)代，面向無(wú)服務(wù)器計(jì)算領(lǐng)域的 Serverless 工作流也應(yīng)運(yùn)而生。許多 Serverless 應(yīng)用程序不是由單個(gè)事件觸發(fā)的簡(jiǎn)單函數(shù)，而是由一系列函數(shù)多個(gè)步驟組成的，而函數(shù)在不同步驟中由不同事件觸發(fā)。Serverless 工作流用于將函數(shù)編排為協(xié)調(diào)的微服務(wù)應(yīng)用程序。

Serverless 工作流由于自身可編排、有狀態(tài)、持久化、可視化監(jiān)控、異常處理、云服務(wù)集成等特性，適用于很多應(yīng)用場(chǎng)景，比如：

1. 復(fù)雜度高需要抽象的業(yè)務(wù)（訂單管理，CRM 等）

2. 業(yè)務(wù)需要自動(dòng)中斷 / 恢復(fù)能力，如多個(gè)任務(wù)之間需要人工干預(yù)的場(chǎng)景（人工審批，部署流水線等）

3. 業(yè)務(wù)需要手動(dòng)中斷 / 恢復(fù)（數(shù)據(jù)備份 / 恢復(fù)等）

4. 需要詳細(xì)監(jiān)控任務(wù)執(zhí)行狀態(tài)的場(chǎng)景

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

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

先以一個(gè)圖片處理的場(chǎng)景舉例，用戶想要執(zhí)行一個(gè)圖片壓縮并且加水印的任務(wù)，這個(gè)場(chǎng)景在典型的工作流系統(tǒng)中，可以用如圖一所示的方式進(jìn)行處理。

圖 1：一個(gè)典型的圖片處理工作流

如上圖所示，圖片壓縮和圖片加水印的結(jié)果都是二進(jìn)制文件格式，但是當(dāng)前主流的 Serverless Workflow 平臺(tái)在多個(gè)步驟之間傳輸上下文都只能支持文本格式傳輸，所以圖片壓縮和加水印的結(jié)果都需要經(jīng)過(guò) BASE64 或者其他轉(zhuǎn)碼方式轉(zhuǎn)成文本進(jìn)行數(shù)據(jù)流傳輸。

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

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

2. 執(zhí)行結(jié)果轉(zhuǎn)換為文本，需要消耗大量?jī)?nèi)存，內(nèi)存成本比較高。

如何簡(jiǎn)單高效的進(jìn)行文件處理，業(yè)界也給出了其他解決方案，如通過(guò)云存儲(chǔ)進(jìn)行中間結(jié)果轉(zhuǎn)儲(chǔ)、AWS 的 Lambda Object 文件轉(zhuǎn)換方案。下面給出了這兩個(gè)方案的優(yōu)缺點(diǎn)分析。

該方案如圖 2 所示：

圖 2：云存儲(chǔ)轉(zhuǎn)儲(chǔ)運(yùn)行方式示意圖

兩個(gè)步驟之間的文件流通過(guò)云存儲(chǔ)去傳遞，這種方案支持大文件流的傳輸，但是由于中間多了一次到云存儲(chǔ)的網(wǎng)絡(luò)傳輸，如果業(yè)務(wù)對(duì)時(shí)延要求不高，該方案問(wèn)題不大，但是對(duì)于時(shí)延敏感類業(yè)務(wù)，這種多出的時(shí)延是無(wú)法接受的。另外云存儲(chǔ)轉(zhuǎn)儲(chǔ)需要額外的成本，如果調(diào)用量比較大，使用成本較高。

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

AWS 對(duì)于這種文件處理場(chǎng)景，提出了基于 S3 和 Lambda 的 Lambda Object 的方案，參考 [1]，簡(jiǎn)單來(lái)說(shuō)，是支持為 S3 文件桶的 getObject API 提供 Access Point，AccessPoint 可以指向某一個(gè) Lambda 函數(shù)，在函數(shù)中可以對(duì)原來(lái)的桶數(shù)據(jù)文件進(jìn)行修改，比如可以將原始視頻轉(zhuǎn)碼，得到轉(zhuǎn)碼后的結(jié)果返回到客戶端。雖然解決了時(shí)延和大文件處理的問(wèn)題，但是這個(gè)方案強(qiáng)依賴 S3 的 API，用戶無(wú)法進(jìn)行流程編排，也無(wú)法通過(guò)事件觸發(fā)，不是一個(gè)真正通用的方案。

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

表 1：業(yè)界文件處理方案對(duì)比

針對(duì)當(dāng)前業(yè)界缺少高效，可編排的文件處理方案的痛點(diǎn)，華為云 FunctionGraph 函數(shù)工作流提出 Serverless Streaming 的流式可編排的文件處理解決方案，步驟與步驟之間通過(guò)數(shù)據(jù)流驅(qū)動(dòng)，更易于用戶理解。本章通過(guò)圖片處理的例子解釋該方案的實(shí)現(xiàn)機(jī)制。

如果需要驅(qū)動(dòng)一個(gè)工作流執(zhí)行，工作流系統(tǒng)需要處理兩個(gè)部分：

1. 控制流：控制工作流的步驟間流轉(zhuǎn)，以及步驟對(duì)應(yīng)的 Serverless 函數(shù)的執(zhí)行。確保步驟與步驟之間有序執(zhí)行。

2. 數(shù)據(jù)流：控制整個(gè)工作流的數(shù)據(jù)流轉(zhuǎn)，通常來(lái)說(shuō)上一個(gè)步驟的輸出是下一個(gè)步驟的輸入，比如上述圖片處理工作流中，圖片壓縮的結(jié)果是打水印步驟的輸入數(shù)據(jù)。

在普通的服務(wù)編排中，由于需要精準(zhǔn)控制各個(gè)服務(wù)的執(zhí)行順序，所以控制流是工作流的核心部分。然而在文件處理等流式處理場(chǎng)景中，對(duì)控制流的要求并不高，以上述圖片處理場(chǎng)景舉例，可以對(duì)大圖片進(jìn)行分塊處理，圖片壓縮和加水印的任務(wù)不需要嚴(yán)格的先后順序，圖片壓縮處理完一個(gè)分塊可以直接流轉(zhuǎn)到下一個(gè)步驟，而不需要等待圖片壓縮把所有分塊處理完再開(kāi)始加水印的任務(wù)。

基于上述理解，華為云 FunctionGraph 工作流的 Serverless Streaming 方案架構(gòu)設(shè)計(jì)如圖四所示：

圖 4：Serverless Streaming 流式處理架構(gòu)圖

在 Serverless Streaming 的流程中，弱化控制流中步驟之間的先后執(zhí)行順序，允許異步同時(shí)執(zhí)行，步驟與步驟之間的交互通過(guò)數(shù)據(jù)流驅(qū)動(dòng)。其中數(shù)據(jù)流的控制通過(guò) Stream Bridge 組件來(lái)實(shí)現(xiàn)。

同時(shí)函數(shù) SDK 增加流式數(shù)據(jù)返回接口，用戶不需要將整個(gè)文件內(nèi)容返回，而是通過(guò) gRPC Stream 的方式將數(shù)據(jù)寫入到 Stream Bridge，Stream Bridge 用來(lái)分發(fā)數(shù)據(jù)流到下一個(gè)步驟的函數(shù) Pod 中。

這種方式存在如下優(yōu)點(diǎn)：

1. 由于控制流的弱化，完全通過(guò)數(shù)據(jù)流來(lái)驅(qū)動(dòng)流程執(zhí)行，不需要再?gòu)?qiáng)限制步驟之間完成的先后順序，如圖片處理場(chǎng)景中，壓縮和加水印的步驟可以做到完全并行執(zhí)行，這樣可以加速整個(gè)流程的執(zhí)行速度。

2. 每次請(qǐng)求都開(kāi)辟獨(dú)立緩沖區(qū)，緩沖區(qū)限制大小，數(shù)據(jù)流僅在內(nèi)網(wǎng)傳輸，保證整體數(shù)據(jù)傳輸?shù)目煽啃院桶踩浴?/span>

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

4. 對(duì)于開(kāi)發(fā)人員來(lái)講，只需要關(guān)注數(shù)據(jù)流的處理，而不需要關(guān)心數(shù)據(jù)流如何轉(zhuǎn)發(fā)，如何存儲(chǔ)，降低開(kāi)發(fā)難度。

5. 底層流式傳輸通過(guò) gRPC 進(jìn)行，整體數(shù)據(jù)傳輸效率高

1. 首先創(chuàng)建一個(gè)圖片壓縮的函數(shù)，其中代碼在處理返回?cái)?shù)據(jù)通過(guò) ctx.Write() 函數(shù)將結(jié)果以流式數(shù)據(jù)的形式返回：

FunctionGraph 通過(guò) ctx.Write() 函數(shù)提供了流式返回的能力，對(duì)開(kāi)發(fā)者來(lái)說(shuō)，只需要將最終結(jié)果通過(guò)流的方式返回，而不需要關(guān)注網(wǎng)絡(luò)傳輸?shù)募?xì)節(jié)。

2. 在函數(shù)控制臺(tái)中啟用該函數(shù)的流式返回能力

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

4. 調(diào)用工作流的同步執(zhí)行接口，獲取最終結(jié)果的文件流，數(shù)據(jù)將以 chunked 流式返回的方式返回到客戶端

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

圖 5：測(cè)試數(shù)據(jù)對(duì)比

響應(yīng)時(shí)延：指客戶端發(fā)出請(qǐng)求到收到第一個(gè)字節(jié)消耗的時(shí)延（單位：秒）

端到端時(shí)延：指客戶端發(fā)出請(qǐng)求到收到最后一個(gè)字節(jié)消耗的時(shí)延（單位：秒）

從測(cè)試數(shù)據(jù)可以看出，響應(yīng)時(shí)延和端到端時(shí)延使用流式返回方案后都得到了不同程度的降低。其中響應(yīng)時(shí)延降低幅度較大，OBS 轉(zhuǎn)儲(chǔ)方案響應(yīng)時(shí)延隨著圖片大小增大，響應(yīng)時(shí)延呈線性上升，超過(guò) 4M 的圖片響應(yīng)時(shí)延就達(dá)到秒級(jí)，使用流式返回方案后，響應(yīng)時(shí)延持續(xù)穩(wěn)定在毫秒級(jí)的水平。從中可以發(fā)現(xiàn)，基于 Serverless Streaming 的流式返回方案不僅具備流式處理和可編排的能力，并且在文件處理場(chǎng)景中可以顯著降低時(shí)延，從多個(gè)方面提升了用戶使用體驗(yàn)。

本文主要討論了 Serverless Workflow 在大文件處理時(shí)碰到的問(wèn)題，F(xiàn)unctionGraph 通過(guò)簡(jiǎn)化數(shù)據(jù)傳輸鏈路，提升文件流處理效率, 給出了一種穩(wěn)定高效、極低時(shí)延的大文件處理方法 Serverless Streaming，支持毫秒級(jí)的文件流式處理, 顯著改善函數(shù)編排在文件處理等場(chǎng)景中的用戶體驗(yàn)。

FunctionGraph 作為華為元戎加持的下一代 Serverless 函數(shù)計(jì)算與編排服務(wù)，將圍繞通用全場(chǎng)景 Serverless 的前沿理論及案例實(shí)踐，持續(xù)分享。

參考資料：

[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/)