簡介
本文我們將圍繞工作流話題，介紹：
- 什麼是工作流，適用哪些場景？
- 阿里雲的全託管工作流服務：Serverless 工作流
- Serverless 工作流適用場景
- Serverless 工作流編排函數計算的最佳實踐
什麼是工作流，適用哪些場景？
維基百科對工作流的定義是：對工作流程及其各操作步驟之間業務規則的抽象、概括描述。我們認為工作流的主要職責是：
- 保證結果一致性，提高容錯性要求：對錯誤重試，捕獲，執行回滾或補償邏輯
- 為長時間運行的流程維護持久化狀態，保證任務調度可靠性
- 控制邏輯和任務邏輯解耦：細化責任，便於管理、維護和擴展
- 流程控制中心化、可視化：增強進度可觀測性，簡化來自不同背景人群的交流
- 模板方式定義控制邏輯和任務依賴：減少重複工作，統一流程描述標準
工作流通常適用於有狀態的（stateful），異步 (async)，長時間執行（long running）等特性的業務場景。其中比較典型的場景包括：
- 視頻，音頻，圖片處理工作流
- 訂單、審批流程
- 數據處理流水線
- 自動化運維
- 機器學習流水線、基因測序工作流
常見的開源工作流服務軟件如 Apache Airflow，Activiti，Flowable，Netflix Conductor 等提供了使用代碼，DSL 或是 BPMN 這類標準的工作流描述方式，允許開發者自己搭建工作流服務。不同雲服務廠商也提供了各自的工作流服務如 AWS Step Functions, AWS Simple Workflow Service，Azure Durable Functions。那麼阿里雲有沒有一個全託管的工作流服務呢？下面的文章將為您介紹阿里雲 Serverless 工作流，其適用場景和最佳實踐。
Serverless 工作流 （原函數工作流 FnF）
如下面的膠片所示，Serverless 工作流是一個專注於提供分佈式任務編排的全託管 Serverless 阿里雲服務。它不僅有完善的工作流功能，也提供了和阿里雲多個雲服務豐富的原生集成。開發者可以將任務編寫成函數計算的函數，構成完全 Serverless 的流程和任務，也可以將無法遷移到函數或者雲上的任務繼續在自己的 VPC 或是自建機房中運行，將編排和調度控制邏輯在雲上執行。Serverless 的特性決定了工作流並行執行數可以彈性水平擴展，無需為工作流服務花費人力資源，僅按使用量付費，不為閒置資源付費。
場景 1 - 視頻處理
視頻處理場景通常涉及多個處理步驟如分片，合併，不同格式轉碼，不同的處理邏輯需要靈活低排列組合實現完成的視頻處理業務，例如有些任務需要藉助於函數計算或者 ECS 自建低成本轉碼，有些任務需要藉助於阿里雲媒體處理（MPS），點播 （VOD）實現敏感內容審核，CDN 刷新等。取決於原視頻的時長，視頻處理流程的時間通常也都以分鐘，小時，甚至若干個小時為單位計算。這樣長時間運行的業務需要可靠的狀態維護，錯誤捕獲和重試。視頻處理通常在一天中有週期性的波峰波谷，或是突發的海量視頻上傳。Serverless 彈性伸縮和 Pay-as-you-go 的特性可以從視頻處理吞吐量以及成本等角度更好地滿足視頻處理場景的需求。詳細博客參考輕鬆構建基於 Serverless 架構的彈性高可用音視頻處理系統
場景 2 - 數據處理流水線
離線大數據 ETL 流水線，海量 OSS 文件批量處理，超大 OSS 壓縮包解壓等場景通常有執行時間長，對彈性，成本要求高，對結果正確性有較嚴格要求，且有云服務事件觸發或者定時觸發的需求。Serverless 工作流最長可以支持執行時長 1 年的流程執行，Serverless 免運維，自動擴容縮容，自帶錯誤重試（retry）和捕獲（catch）機制。持久化的狀態和消息保證數據處理流水線的最終一致性。通過 FC 的定時觸發器也可以觸發工作流的週期執行。詳見博客使用函數工作流+函數計算輕鬆構建 ETL 離線數據處理系統。
場景 3 - 訂單、審批流程
電商訂單，出遊行程訂單等涉及支付，庫存預留等關鍵業務對於數據一致性有極強的要求。在分佈式微服務的框架下，任何接口調用都有失敗的風險。訂單的工作流程設計需要充分考慮各個步驟可能的失敗，後果和響應的補償邏輯。例如在一個涉及多個分佈式支付的流程中，如果第三步支付失敗，工作流程需要自動將已經扣款的前兩部取消並完成退款。Serverless 工作流的 try/catch，持久化狀態維護等特點幫助開發者簡化 SAGA 模式的開發，實現分佈式多步驟事務。審批流程有人工介入，審批網絡不統一等場景特點，Serverless 工作流提供的任務分發至隊列+回調功能可以幫助審批流程開發者輕鬆滿足此類需求。
場景 4 - 自動化運維
生產環境的自動化運維工作流如 ECS 鏡像，快照的構建，集群上下線機器需要可靠且靈活的邏輯描述能力。相比於描述依賴關係的 DAG （有向無環圖）模型，Serverless 工作流提供了 FDL 這樣更加強大和靈活的描述能力。定時觸發，長時間執行，低成本和 100% 資源利用率也都是可以滿足自動化運維場景中的常見需求。
場景 5 - 機器學習流水線
機器學習流水線設計算法開發，數據清洗，轉化處理，模型訓練，模型部署等多個步驟。生產環境中需要一個輕量的工作流引擎實現一個完整的 ML 反饋迴路。Serverless Workflow 提供的人工介入能力，長時間執行和狀態靠的特點可以很好地滿足 ML 流水線。詳見博客生產中的 Serverless 機器學習流水線
FC 函數編排最佳實踐
這個段落我們將介紹函數計算（FC）異步任務編排的最佳實踐。下圖列出了 Serverless Workflow 結合 FC 的優勢。
強化單個異步函數
需要澄清的是，工作流並非只適用於多個函數的編排，實際上任何一個需要狀態觀測（可查詢），執行時間長，結果重要不允許消息丟失的場景，如下圖的事件觸發場景所示，即使整個邏輯只有一個 FC 函數，也推薦使用工作流強化，保證函數有足夠的重試機會。另一個使用工作流來強化單函數的應用場景是使函數計算 HTTP 觸發器能夠支持異步調用，目前 FC HTTP 觸發器僅限於同步調用。使用 HTTP FC 發起工作流（StartExecution）後即返回。使用另一個 HTTP FC 函數 (DescribeExecution) 達到了 HTTP 異步觸發任務且可以使用 HTTP 查詢的效果。
編排多個函數
下面的一系列圖列舉了編排多個函數常見的 4 種方式：
- 方式 1：單體函數（Monolith functions）: 整個流程在同一個進程中運行
- 方式 2：函數編排（Function orchestration）: 整個流程由一個編排函數同步調用多個任務函數完成
- 方式 3：事件觸發點對點調用（Choreography）：沒有中心化的控制器，每個任務負責異步觸發下一個任務
- 方式 4：Serverless 工作流編排（Workflow orchestration）: 由中心化的工作流服務調度不同函數
下圖是對於 4 種調用方式的對比分析。可以看到單體編排更適用於要求極低延遲，無狀態 （stateless）的在線業務，邏輯相對簡單，執行時間短的場景。FC 函數編排從維護上與微服務模型更加相似，更易於維護和多個團隊協作，由於單函數的執行時間限制，同樣不適用於長時間執行，也不適用於需要狀態持久化 (stateful) 的流程。事件觸發通過異步調用可以突破函數執行時長的限制，並且獲得一定程度的狀態持久化。然後持久化以及重試的程度並不能自定義，可觀測性較低和開發成本偏高。對於長時間執行，需要狀態維護，自定義重試等場景的關鍵流程，我們推薦用 Serverless 工作流的方式編排，獲得最高的容錯性，無限的執行時長，最優化的成本。
總結
本文我們簡單介紹了工作流以及阿里雲的工作流服務 Serverless Workflow。工作流適用於視頻處理，數據處理流水線，訂單、審批流程，自動化運維機器學習流水線等依賴工作流引擎的場景。使用工作流可以很好地補充完善單個 FC 異步函數的可靠性和可觀測性。對於多個 FC 函數的編排，我們給出了 4 種不同的方法編排方式的最佳實踐以及其對比分析，您可以根據實際場景選擇編排方式。如果您的異步流程對正確性和持久化要求較高，執行時間較長 （分鐘級別），關注異步任務的狀態，我們推薦使用工作流編排 FC。如名字所示，全託管免運維，自動伸縮，100% 資源使用率，成本優化是 Serverless 解決方案的核心價值。
聯繫我們
如果您對工作流，函數計算，或者 Serverless 相關話題感興趣歡迎加入我們的官網釘釘群交流、分享、討論。