技術架構解密 - 應用與服務編排工作流 ASW

技術架構解密 - 應用與服務編排工作流 ASW

騰訊雲應用與服務編排工作流 ASW(Application Service Workflow)是新一代計算架構體系下的服務編排解決方案,用來協調分散式任務執行的編排產品。在應用與服務編排工作流中設定好任務執行步驟,可以將多個騰訊雲服務按步驟進行排程,完成各種業務應用場景。能簡化開發和執行業務流程所需要的任務協調、狀態管理以及錯誤處理等繁瑣工作,更簡單、更高效的構建應用。 像膠水一樣粘合雲上各種產品和服務,提供面向使用者場景的端到端解決方案。

01。 應用與服務編排工作流 ASW 背景介紹

技術架構解密 - 應用與服務編排工作流 ASW

隨著雲計算技術的發展和進步,函式即服務(FaaS)、無服務(Serverless)等新一代技術方案越來越多的成為使用者上雲的首選解決方案。無服務並不是指開發者沒有服務,而是指開發者使用的來說,不用更多的去考慮伺服器的相關內容,無需再去考慮伺服器的規格大小、儲存型別、網路頻寬、自動擴縮容問題;同時,也無需再對伺服器進行運維了,無需不斷的打系統補丁、應用補丁、無需進行資料備份、軟體配置等工作了。

Serverless 在開發便捷性、高效能、彈性擴縮容、部署便捷性、成本等方面具有天然的優勢。使用者從以前需要購買計算例項,部署應用程式程式碼的使用模式,逐漸轉變為基於函式做面向最終業務的開發。騰訊雲 Serverless 函式計算產品 - 雲函式(Serverless Cloud Function,SCF),非常方便的提供面向單次請求或事物的處理能力;而云函式自身的執行、擴縮絨、部署等,均有 Serverless 服務提供商解決,對用於層面透明。隨著 Serverless 架構應用的越來越多,越來越廣,很多使用者也逐漸將越來越多的業務以 Serverless 的方式進行部署。

此時,多個雲函式和其他雲服務之間的編排組合便成為了新的技術挑戰。為了解決眾多原子服務的串聯和編排需求,ASW 應運而生。

ASW(Application Service Workflow)

以工作流的形式,對包括雲函式在內的雲服務進行統一編排,支援順序、並行、迴圈、失敗重試、異常捕獲、輸入輸出處理等功能,真正做到面向開發者的最終場景,從輸入到輸出,端到端提供解決方案。

舉例來說,開發者想要實現一個影片字幕 OCR 的功能,在沒有 ASW 的情況下,需要手工將影片幀採集、影片影象擷取、影象儲存、OCR 介面呼叫、結果儲存等處理節點進行組合串聯。這可能涉及到一系列的運維、擴容、監控、失敗處理等邏輯的開發和元件對接,而使用 ASW 工作流,使用者不需要考慮,只需要按照最終場景,使用 TCSL 語言編寫工作流即可快速完成業務上線。

工作流提供 TCSL 語言(Tencent Cloud States Language),一種基於 Json 的結構化語言,用來描述和定義工作流中的業務邏輯。 該語言靈活方便,可寫出可讀性強、易於維護的狀態機定義程式碼。語言相容亞馬遜 Step Functions 的 ASL 語法。提供任務節點(Task)、傳遞節點(Pass)、選擇節點(Choice)、並行節點(Parallel)、迴圈節點(Map)。

02。 技術挑戰解析

在設計並實現這樣一個極為靈活的工作流系統時,需要考慮的問題很多;本部分將從資料量、可觀測性、架構彈性等角度分析。

1. 工作流 ASW 產品是一個數據密集型產品。

使用者串聯的所有微服務,資料均需要經過 ASW 進行轉發或傳遞。同時有大批次資料在 ASW 內部進行流轉。此時,CPU 的負載並不是最高的,記憶體、網路等涉及大量資料 IO 的硬體,會首先是效能瓶頸。這也要求 ASW 產品在設計時,需要慎重的選擇資料庫中介軟體、儲存中介軟體等。

按照設計要求,每天 100 億次執行,對應著會產生 100 億次執行記錄資料;會產生遠超 100 億的執行歷史記錄資料。這些資料特點為寫入數量遠大於查詢數量、順序寫入、需要做過期邏輯。

對於執行資料我們採取的解決方案是使用 Redis 來順序寫入執行資料,開發專門的清潔工程式,負責過期資料清理。後續可進一步改造,使用原生支援過期邏輯的資料中介軟體上。對於執行歷史記錄,ASW 使用

騰訊雲日誌服務 CLS

來儲存海量執行記錄。

2. 工作流產品需要提供足夠的可觀測性

工作流 ASW 是面向使用者最終場景的解決方案,每一個工作流,都是使用者的一個業務,工作流的抖動或不可用,會導致使用者業務直接受損。因此,提供必要的可觀測性是十分必須的。需要提供每秒啟動執行次數、執行成功次數、執行失敗次數、執行耗時等指標。這些資料,需要從 ASW 的執行程式碼中進行上報。雖然埋點並不困難,但是應對如此巨大的資料量,也同樣是個不小的挑戰。

對於可觀測性要求,ASW 使用

騰訊雲監控 CM

。對執行過程中產生的指標資料進行收集整理。分別提供啟動執行次數、執行成功次數、執行失敗次數、執行耗時 4 個指標的監控、告警、Dashboard 視覺化能力。

最後,考慮到隨時可能到來的流量洪峰,需要系統整體有足夠的彈性來應對。工作流產品,部署在公有云上,會有不可預期的流量洪峰到來,因此要求整體技術架構有足夠好的橫向拓展能力,以應對流量挑戰。

彈性方面,ASW 使用

騰訊雲容器服務 TKE

,針對流量洪峰,配置 HPA 策略,使用 TKE 提供的監控來觀測容器自身執行狀態,同時,所有服務也都是基於容器進行部署的。

03。 應用與服務編排工作流 ASW 系統架構

技術架構解密 - 應用與服務編排工作流 ASW

ASW 整體架構包含如下部分:前端+SDK、許可權服務、排程服務、模板服務、執行器以及為了支撐整體執行的外部底座設施和中介軟體。

各個模組各司其職,相互配合,在效能、可拓展性、成本間取得了很好的平衡。下面來分別簡要介紹每一個模組的核心作用。

許可權服務

主要功能包含兩部分:

對控制檯來的使用者進行鑑權,校驗使用者賬戶中,是否有ASW需要的角色等;

狀態機執行時,涉及到呼叫雲上資源,則需要獲取臨時秘鑰。

許可權服務的第二個核心功能就是換票和票據快取、過期、更新等邏輯。其中執行器呼叫許可權服務的請求量,可達每天數十億次。

模板服務

用於和控制檯、SDK 進行互動,對模板資料進行增刪改查管理。使用者的建立、編輯狀態機的請求,均由模板服務提供支援。該模組因為主要和使用者側互動,併發量並不會特別大。

排程服務

使用者透過控制檯或 SDK,發起執行(呼叫 StartExecution)介面時,經過騰訊雲 API 轉發後,流量會到達排程器,由排程器進行入參校驗、TCSL 程式碼獲取、負載均衡、生成 ExecutionQRN、寫入執行資料等操作後,將請求傳送給負載均衡模組選擇出的某個執行器來實際執行一個狀態機。因使用者的核心邏輯均依賴啟動執行功能,因此要求有足夠的效能和彈性。其他功能還涉及到停止執行、獲取執行狀態、獲取執行列表、執行器心跳檢查等。

執行器

ASW 核心執行模組,只和排程器進行互動,提供啟動執行、停止執行等 API。啟動執行的過程包括 TCSL 語法校驗、input 引數校驗、TCSL 語法解析並建立有向無環圖、狀態機節點間輸入輸出處理、RPC 呼叫雲服務等。並需要根據啟動執行時的引數,將執行歷史記錄資料(每個 Node 的輸入和輸出)上報到外部資料中介軟體。因 ASW 專案和

騰訊雲智天樞人工智慧服務平臺 TI Matrix

專案共用執行器,因此除雲 SDK 外,還支援 K8s 相關的服務呼叫。

04。 架構演進方向

目前的架構可在大流量背景下,提供穩定、可觀測、彈性的服務,但在如下幾個方面依舊可以進一步最佳化。包括但不限於:資源隔離、私有化、成本降低等。

一張圖快速讀懂「騰訊雲 ASW 工作流」

技術架構解密 - 應用與服務編排工作流 ASW

識別下方 二維碼,即可加入騰訊雲 ASW 交流群。

技術架構解密 - 應用與服務編排工作流 ASW

One More Thing

立即體驗騰訊雲 Serverless Demo,領取 Serverless 新使用者禮包

騰訊雲 Serverless 新手體驗

歡迎訪問:

Serverless 中文網