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

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

比如：

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

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

• 在Netflix中設(shè)置新標(biāo)題

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

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

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

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

• 跟蹤和管理工作流。

• 能夠暫停，恢復(fù)和重新啟動(dòng)進(jìn)程。

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

• 能夠在需要時(shí)同步處理所有任務(wù)。

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

• 由客戶端提取出來的的隊(duì)列服務(wù)支持。

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

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

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

為什么不進(jìn)行點(diǎn)對(duì)點(diǎn)編排？

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

• 流程分散在多個(gè)應(yīng)用程序的代碼中

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

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

為什么是微服務(wù)？

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

架構(gòu)總覽

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

Decider與分布式隊(duì)列一起使用來管理計(jì)劃任務(wù)。我們使用dyno-queues作為分布式延遲隊(duì)列，dyno-queues使用dynomite作為K-V存儲(chǔ)。該隊(duì)列已于今年早些時(shí)候開源，欲知詳情請(qǐng)看這里。

Task Worker實(shí)現(xiàn)

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

API層

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

存儲(chǔ)

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

關(guān)鍵概念

工作流定義

使用基于JSON的DSL定義工作流。 工作流藍(lán)圖定義了一系列需要執(zhí)行的任務(wù)。 每個(gè)任務(wù)是控制任務(wù)（例如，fork，join，決策，子工作流等）或worker任務(wù)（譯者注：提供具體的數(shù)據(jù)處理功能）。 工作流定義支持版本，可以靈活地管理升級(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}\" }}

任務(wù)定義

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

任務(wù)定義：

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

輸入輸出

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

任務(wù)輸入定義：

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

具體例子

這里總共有3個(gè)worker任務(wù)和一個(gè)控制任務(wù)：

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

• 編碼：生成視頻編碼

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

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

在完成每個(gè)任務(wù)時(shí)，Decider會(huì)根據(jù)藍(lán)圖（對(duì)應(yīng)于工作流實(shí)例的版本）評(píng)估工作流實(shí)例的狀態(tài)，并標(biāo)識(shí)要調(diào)度的下一組任務(wù)，或者在完成所有任務(wù)后標(biāo)記工作流為完成。

UI

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

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

• 如果任務(wù)失敗，失敗的原因是什么。

• 重試次數(shù)

• 執(zhí)行任務(wù)的主機(jī)。

• 任務(wù)的輸入和輸出。

以下是UI展示：

其他方案

AMAZON SWF

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

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

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

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

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

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

Amazon Step Function

最近宣布的AWS Step Functions添加了一些我們?cè)诰幣乓嬷行枰墓δ堋?Conductor有可能采用states語言(譯者注：這也是一種基于Json的用于描述狀態(tài)機(jī)的語言)來定義工作流程。

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

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

未來功能

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

• 與容器編排框架更緊密的集成，允許worker實(shí)例自動(dòng)擴(kuò)展。

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

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

• 支持states語言。

原文地址：

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

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

高可用架構(gòu)

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