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

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

比如：

• Studio合作伙伴內(nèi)容集成

• 來自合作伙伴的基于IMF的內(nèi)容集成

• 在Netflix中設置新標題

• 接收內(nèi)容，編碼和部署到CDN

傳統(tǒng)做法中，這些進程是臨時編排的，使用pub/sub 組合起來，直接進行REST調(diào)用，并使用數(shù)據(jù)庫來管理狀態(tài)。 然而，隨著微服務數(shù)量和流程復雜性的增加，如果沒有中央?yún)f(xié)調(diào)器，就無法了解這些分布式工作流（workflow）。

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

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

• 跟蹤和管理工作流。

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

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

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

• 能夠擴展到數(shù)百萬個并發(fā)運行的流程。

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

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

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

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

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

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

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

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

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

為什么是微服務？

在微服務領域，許多業(yè)務流程自動化都是通過協(xié)調(diào)服務來實現(xiàn)的。 Conductor支持跨服務的協(xié)調(diào)，同時提供交互式控制和可視性。 能夠跨進行微服務協(xié)調(diào)，有助于我們利用現(xiàn)有服務構(gòu)建新流程或更新現(xiàn)有流程，從而非?？焖俚仄占癈onductor。

架構(gòu)總覽

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

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

Task Worker實現(xiàn)

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

API層

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

存儲

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

關鍵概念

工作流定義

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

工作流定義概述：

{ \"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}\" }}

任務定義

每個任務的行為都由其模板控制。 任務定義為每個任務提供控制參數(shù)，例如超時，重試策略等。任務既可以是由應用程序?qū)崿F(xiàn)的worker任務，也可以是由編排服務執(zhí)行的系統(tǒng)任務。 Conductor提供一些開箱即用的系統(tǒng)任務，例如Decision，F(xiàn)ork，Join，Sub Workflows，并且允許加入自定義系統(tǒng)任務的SPI。 我們已經(jīng)添加了對HTTP任務的支持，這有助于調(diào)用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}

輸入輸出

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

任務輸入定義：

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

具體例子

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

• 內(nèi)容檢查：檢查輸入文件是否正確/完整

• 編碼：生成視頻編碼

• 發(fā)布：發(fā)布到CDN

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

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

UI

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

• 任務調(diào)度的時間戳，worker接收并完成任務的時間戳。

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

• 重試次數(shù)

• 執(zhí)行任務的主機。

• 任務的輸入和輸出。

以下是UI展示：

其他方案

AMAZON SWF

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

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

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

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

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

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

Amazon Step Function

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

統(tǒng)計數(shù)據(jù)

以下是我們一年多來在生產(chǎn)環(huán)境運行Conductor的統(tǒng)計數(shù)據(jù)。 內(nèi)容平臺工程中使用這些工作流來支持內(nèi)容獲取和編碼等工作。

未來功能

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

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

• 記錄每個任務的執(zhí)行數(shù)據(jù)，有助于故障排除。

• 能夠從UI創(chuàng)建和管理工作流藍圖。

• 支持states語言。

原文地址：

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

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

高可用架構(gòu)

改變互聯(lián)網(wǎng)的構(gòu)建方式