一個Netflix開發的微服務編排引擎，支持可視化工作流定義（netflix微服務架構）

導讀：相對于傳統架構,微服務架構下更需要通過各微服務之間的協作來實現一個完整的業務流程,可以說服務編排是微服務架構下的必備功能。Netflix Conductor作為服務編排的佼佼者，從推出就引起很大關注。本文深入淺出的介紹了起基本功能和設計。

Netflix內容平臺工程團隊支撐了許多業務，這些業務流程由微服務任務異步驅動的。 其中一些任務是持續數天的長期進程。 這些進程在為全球觀眾提供字幕方面發揮著至關重要的作用。

比如：

• Studio合作伙伴內容集成

• 來自合作伙伴的基于IMF的內容集成

• 在Netflix中設置新標題

• 接收內容，編碼和部署到CDN

傳統做法中，這些進程是臨時編排的，使用pub/sub 組合起來，直接進行REST調用，并使用數據庫來管理狀態。 然而，隨著微服務數量和流程復雜性的增加，如果沒有中央協調器，就無法了解這些分布式工作流（workflow）。

我們將Conductor“作為編排引擎”構建，以滿足以下需求，在應用程序中消除了模板，并提供反應流：

• 使用基于JSON DSL 的藍圖定義執行流程。

• 跟蹤和管理工作流。

• 能夠暫停，恢復和重新啟動進程。

• 用戶界面可視化處理流程。

• 能夠在需要時同步處理所有任務。

• 能夠擴展到數百萬個并發運行的流程。

• 由客戶端提取出來的的隊列服務支持。

• 能夠通過HTTP或其他方式操作，例如GRPC。

Conductor旨在滿足上述需求，現在已在Netflix使用了將近一年。 迄今為止，它調度超過260萬個工作流，從簡單的線性工作流到運行多天的非常復雜的動態工作流。

如今Conductor已經開源，我們希望Conductor可以服務于有類似需求的場景，并提升其能力。 你可以在此處找到Conductor的開發人員文檔。

為什么不進行點對點編排？

隨著業務需求和復雜性的增長，使用點對點任務編排會難以擴展。 發布/訂閱模型適用于最簡單的流程，也有一些問題：

• 流程分散在多個應用程序的代碼中

• 通常圍繞輸入/輸出，SLA等存在緊密耦合和假設，PUB/SUB難以適應不斷變化的需求

• 幾乎沒有辦法系統地回答“設置電影還有什么沒完成”？

為什么是微服務？

在微服務領域，許多業務流程自動化都是通過協調服務來實現的。 Conductor支持跨服務的協調，同時提供交互式控制和可視性。 能夠跨進行微服務協調，有助于我們利用現有服務構建新流程或更新現有流程，從而非常快速地普及Conductor。

架構總覽

引擎的核心是狀態機服務，即Decider服務。 當工作流事件發生時（例如任務完成，失敗等），Decider將工作流藍圖與工作流的當前狀態相匹配，識別下一個狀態，并安排適當的任務，或更新工作流的狀態。

Decider與分布式隊列一起使用來管理計劃任務。我們使用dyno-queues作為分布式延遲隊列，dyno-queues使用dynomite作為K-V存儲。該隊列已于今年早些時候開源，欲知詳情請看這里。

Task Worker實現

task由worker應用程序實現，其通過API層進行通信。 woker實現了可由流程引擎調用的REST接口，或者通過定期檢查掛起任務的狀態來達到此目的。 Worker實際上是冪等的無狀態函數。 輪詢模型允許處理worker的壓力，并在可能的情況下根據隊列深度支持自動伸縮。 Conductor提供API以檢查worker的工作負載大小。

API層

API通過HTTP公開 – 使用HTTP可以輕松地與不同客戶端集成。 添加其他協議（例如gRPC）也是很簡單的。

存儲

我們使用Dynomite作為存儲引擎，并使用Elasticsearch來索引執行流程。 存儲API是可插拔的，可以適用于各種存儲系統，包括傳統的RDBMS或Apache Cassandra。

關鍵概念

工作流定義

使用基于JSON的DSL定義工作流。 工作流藍圖定義了一系列需要執行的任務。 每個任務是控制任務（例如，fork，join，決策，子工作流等）或worker任務（譯者注：提供具體的數據處理功能）。 工作流定義支持版本，可以靈活地管理升級和遷移。

工作流定義概述：

{ \"name\": \"workflow_name\", \"description\": \"Description of workflow\", \"version\": 1, \"tasks\": [ { \"name\": \"name_of_task\", \"taskReferenceName\": \"ref_name_unique_within_blueprint\", \"inputParameters\": { \"movieId\": \"${workflow.input.movieId}\", \"url\": \"${workflow.input.fileLocation}\" }, \"type\": \"SIMPLE\", ... (any other task specific parameters) }, {} ... ], \"outputParameters\": { \"encoded_url\": \"${encode.output.location}\" }}

任務定義

每個任務的行為都由其模板控制。 任務定義為每個任務提供控制參數，例如超時，重試策略等。任務既可以是由應用程序實現的worker任務，也可以是由編排服務執行的系統任務。 Conductor提供一些開箱即用的系統任務，例如Decision，Fork，Join，Sub Workflows，并且允許加入自定義系統任務的SPI。 我們已經添加了對HTTP任務的支持，這有助于調用REST服務。

任務定義：

{ \"name\": \"encode_task\", \"retryCount\": 3, \"timeoutSeconds\": 1200, \"inputKeys\": [ \"sourceRequestId\", \"qcElementType\" ], \"outputKeys\": [ \"state\", \"skipped\", \"result\" ], \"timeoutPolicy\": \"TIME_OUT_WF\", \"retryLogic\": \"FIXED\", \"retryDelaySeconds\": 600, \"responseTimeoutSeconds\": 3600}

輸入輸出

任務的輸入是一種映射，其作為工作流實例化的一部分或某些其他任務的輸出。 允許將來自工作流或其他任務的輸入/輸出作為隨后執行的任務的輸入。 例如，可以將編碼任務的輸出作為輸入提供給發布任務以部署到CDN。

任務輸入定義：

{ \"name\": \"name_of_task\", \"taskReferenceName\": \"ref_name_unique_within_blueprint\", \"inputParameters\": { \"movieId\": \"${workflow.input.movieId}\", \"url\": \"${workflow.input.fileLocation}\" }, \"type\": \"SIMPLE\" }

具體例子

這里總共有3個worker任務和一個控制任務：

• 內容檢查：檢查輸入文件是否正確/完整

• 編碼：生成視頻編碼

• 發布：發布到CDN

這三個任務由不同的worker實現，這些worker使用任務API輪詢待處理的任務。 這些任務是冪等任務，worker根據給予任務的輸入進行操作，執行處理流程并更新狀態。

在完成每個任務時，Decider會根據藍圖（對應于工作流實例的版本）評估工作流實例的狀態，并標識要調度的下一組任務，或者在完成所有任務后標記工作流為完成。

UI

UI是監視和排除工作流程執行故障的主要手段。 通過基于各種參數（包括輸入/輸出參數）的搜索，UI實現了處理流程的可視化，并提供藍圖和其采取的執行路徑的可視化表示，以更好地理解流程執行的過程。 對于每個工作流實例，UI提供每個任務執行的詳細信息，并提供以下詳細信息：

• 任務調度的時間戳，worker接收并完成任務的時間戳。

• 如果任務失敗，失敗的原因是什么。

• 重試次數

• 執行任務的主機。

• 任務的輸入和輸出。

以下是UI展示：

其他方案

AMAZON SWF

早期我們使用過AWS SWF。 然而考慮到SWF的一些限制，我們選擇構建Conductor：

• 需要基于藍圖的編排，而不是SWF要求的編程決策。

• 用于工作流的可視化UI。

• 更需要同步API（而不是純粹基于消息的方式）

• 需要為工作流和任務索引輸入和輸出，以及基于此索引的搜索工作流的能力。

• 需要維護一個單獨的數據存儲來保存工作流事件以從故障，搜索等中恢復。

Amazon Step Function

最近宣布的AWS Step Functions添加了一些我們在編排引擎中需要的功能。 Conductor有可能采用states語言(譯者注：這也是一種基于Json的用于描述狀態機的語言)來定義工作流程。

統計數據

以下是我們一年多來在生產環境運行Conductor的統計數據。 內容平臺工程中使用這些工作流來支持內容獲取和編碼等工作。

未來功能

• 支持AWS Lambda（或類似）功能，作為serverless 任務。

• 與容器編排框架更緊密的集成，允許worker實例自動擴展。

• 記錄每個任務的執行數據，有助于故障排除。

• 能夠從UI創建和管理工作流藍圖。

• 支持states語言。

原文地址：

https://medium.com/netflix-techblog/netflix-conductor-a-microservices-orchestrator-2e8d4771bf40

本文由方圓翻譯。轉載本文請注明出處，歡迎更多小伙伴加入翻譯及投稿文章的行列，詳情請戳公眾號菜單「聯系我們」。

高可用架構

改變互聯網的構建方式