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

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

比如：

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

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

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

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

傳統(tǒng)做法中，這些進程是臨時編排的，使用pub/sub 組合起來，直接進行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 的藍圖定義執(zhí)行流程。

• 跟蹤和管理工作流。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

架構(gòu)總覽

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

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

Task Worker實現(xiàn)

task由worker應(yīng)用程序?qū)崿F(xiàn)，其通過API層進行通信。 woker實現(xiàn)了可由流程引擎調(diào)用的REST接口，或者通過定期檢查掛起任務(wù)的狀態(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。

關(guān)鍵概念

工作流定義

使用基于JSON的DSL定義工作流。 工作流藍圖定義了一系列需要執(zhí)行的任務(wù)。 每個任務(wù)是控制任務(wù)（例如，fork，join，決策，子工作流等）或worker任務(wù)（譯者注：提供具體的數(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}\" }}

任務(wù)定義

每個任務(wù)的行為都由其模板控制。 任務(wù)定義為每個任務(wù)提供控制參數(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)添加了對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ù)的輸入是一種映射，其作為工作流實例化的一部分或某些其他任務(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個worker任務(wù)和一個控制任務(wù)：

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

• 編碼：生成視頻編碼

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

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

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

UI

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

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

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

• 重試次數(shù)

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

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

以下是UI展示：

其他方案

AMAZON SWF

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

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

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

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

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

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

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 任務(wù)。

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

• 記錄每個任務(wù)的執(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)建方式