Netflix Conductor等開源工作流引擎的使用經驗分享 | 駭客新聞

https://temporal.io/
 
freeqaz：工作流程和編排是我的難題-這就是我們試圖簡化的 https://refinery.io
Conductor是一項很酷的技術，並且在快速增長的工作流引擎空間中是行之有效的參與者。
我曾經在Uber工作，而那家公司曾有一段時間出現過微服務。他們建立了專案Cadence [0]來減輕這種情況。它在許多方面與導體類似。
一個值得關注的專案是Argo [1]，它是CNCF支援的專案。
也有一些嘗試[2]標準化工作流程規範。
Serverless在業務流程引擎必須管理的內容中增加了全新的生機，我很好奇未來的發展趨勢。Kubernetes也增加了問題空間的複雜性。
如果有人有興趣於微服務地獄或用於業務邏輯的複雜狀態機，我會很高興進行聊天。我一直在尋找更多現實世界中的問題來幫助解決（作為一家早期創業公司的創始人），而更多地接觸他人正在苦苦掙扎的事情會有所幫助！
0： https://github.com/uber/cadence
1： https://argoproj.github.io/argo/
2： https://serverlessworkflow.github.io/

 

dap問：感謝您的資源！似乎許多實現都希望在某些微服務體系結構中作為獨立管理的服務執行。您是否知道任何應用程式庫中實現為庫的工作流引擎，可能是由外部資料庫支援的儲存？我認為，只要資料庫支援該模型，您仍然可以擁有一個高度可用的模型。
manyxcxi回：有趣的是，即使Conductor並非旨在如此-這正是我們使用它的方式。儘管如此，在Kotlin和Spring Boot程式碼庫中！

theptip: 略讀文件的快速注意事項：
* Conductor實現了一個工作流程編排系統，該系統看起來在最高層次上類似於Airflow，但有一些重要的細節。
*沒有“worker”，而是由現有的微服務執行任務。
* Orchestrator不會將工作推送給工作人員（例如，氣流觸發操作員執行DAG），而是客戶端輪詢Orchestrator的任務並在找到任務時執行。
我的觀點：
如果您已經擁有非常龐大的協作微服務網格，並希望在其任務之上提取業務流程層，那麼該系統可能是一個很好的選擇。
您在此處執行的大多數操作也可以使用HTTPOperator或GRPCOperator在Airflow中實現，該操作會觸發服務來啟動其任務。但是，您不會得到諸如暫停之類的東西。另一方面，您確實能夠在Airflow操作員中執行簡單/一次性任務，而不必構建服務來執行簡單的Python函式。
我不確定推/拉是否更好。我認為這在很大程度上取決於您的情況。我傾向於說，在大多數情況下，讓Orchestrator透過HTTP推送任務是更好的預設設定，因為您可以簡單地負載均衡那些請求並水平擴充套件您的工作池，並且手動測試管道更容易（例如（對於開發環境）），如果工作人員響應簡單的HTTP請求，而不必提供協調器的存根/測試實現。（特別是我正在考慮“在k8s中在本地計算機上執行prod env” －儘管這在Netflix規模上不切實際。）
 
tupac：我們已經在我的工作場所使用Conductor大約一年了。紮紮實實的基礎，但是一旦您深入瞭解它，文件就很不錯了。我們必須求助於github問題，以找到尚未真正記錄的相當基本的功能。我覺得Conductor是Netflix開源的東西，然後就被OS社群拋棄了。
例如，沒有關於如何使用其Java客戶端實現Worker的示例，我們必須挖掘一個部落格文章來做到這一點，儘管這非常簡單，但是一個非常基本的實現Worker介面的示例將是不錯的選擇。
他們也沒有清楚地說明任務和工作流程之間的確切關係，很難找到網際網路上可用的相對複雜的工作流程和任務定義的良好示例，除了Netflix的準系統和他們提供的廚房水槽工作流程之外，這是很糟糕的。預設情況下在當前API上。
配置還提到了很多未記錄的欄位，例如您可以將持久層換成其他東西，但是我不知道它是如何工作的。
 
TheColorYellow：驚訝地看到Camunda在這裡沒有更多提及。
具有成功歷史的開源BPMN相容工作流處理。據推測，高盛（Goldman Sachs）用它來管理他們的內部組織。
目標用例略有不同，但是Camunda確實在微服務編排中大放異彩，我發現實現複雜的工作流和管理任務依賴性非常容易。
 
MrSaints：我已經在接近生產產能中使用了Conductor，Zeebe和Cadence。這只是我的個人經歷。
在我看來，Conductor的JSON DSL有點像噩夢。但除此之外，它的工作還可以。感覺更類似於步進功能。
可以說，一旦您克服了BPMN的最初障礙，Zeebe是最容易上手的。他們的工作處理模型非常簡單，因此，以任何語言為其編寫SDK都非常容易。最大的缺點是，它還沒有準備好投入生產，他們的Slack聊天中一直抱怨它缺乏穩定性，並且效能相對較差。Zeebe不需要外部儲存，因為工作流是臨時的，可以使用自己的RocksDB和Raft設定進行復制。如果要保留工作流程的歷史記錄，或者甚至要對其進行管理，則需要匯出工作流程併為其編制索引。這最終是一致的。
但是，對於Conductor和Zeebe來說，如果您有足夠複雜的線上工作流程，則很難在各自的DSL中對它們進行建模。特別是在您具有動態工作流程的情況下。而且這種複雜性可以轉化為業務流程級別的錯誤，除非執行不同的場景，否則您不會發現這些錯誤。
Cadence（Temporal）可以很好地處理此問題。您實際上是使用程式語言本身，帶有適當的包裝器/裝飾器和輔助器來編寫工作流的。本身無需學習新的DSL。但是，結果是，用一種特定的程式語言為其構建SDK並非易事，目前，穩定的實現是在Java和Go中進行的。效能和可靠性方面，它很棒（依賴於Cassandra，但是有SQL介面卡，但是還不成熟）。
我們已經與Temporal合作了一段時間，我們已經對Temporal有了一些解決。我們還探討了Lyft的Flyte，但它似乎更適合於資料工程和離線處理。
就像在其他地方提到的那樣，我們也使用Argo，但是我認為它與我提到的這些工作流引擎不在同一空間內（它可以更好地處理複雜業務邏輯的編排，而不是像CI這樣的簡單管道。 / CD或ETL）。
還值得一提的是，我們使用了工作流引擎來減少樣板，並減少編寫業務流程邏輯/粘合程式碼所需的時間/精力。您在許多專案中都不知道要執行此操作。我們絕對覺得我們已經成功實現了這一目標。我覺得這是一個令人興奮的空間。
 
jiehong：我們在2016年左右開始在我工作的公司中使用它。我們決定使用它來自動為每個產品手動進行新客戶的手動設定。它逐漸發展為使用我們自己的安全和許可權系統，並且我們還新增了其他資料庫支援（我們正在開發開源軟體）。我們還更改了Jason API以符合我們公司範圍內的標準。
當時，我們希望我們可以託管，維護，開源並且可以正常工作的東西！
如今，內部團隊也使用它來自動化他們自己的流程。
我們可能會選擇“基於推送”的工作流引擎，也許是基於事件的，主要是出於延遲和負載的原因，但是到目前為止，我們還是可以接受的（儘管有些方法可以監聽事件，但這不是那麼容易）
如果我沒記錯的話，Netflix會使用它來自動對節目進行影片編碼，但這可能已經過時了。
總體而言，我們對此感到高興。但是這有一些缺點：我們希望可以將某些服務分離出來（例如只讀服務，或者從執行中分離出工作流定義，等等），但是程式碼並不是如此容易拆分的架構：例如，推送工作者執行任務計算的結果會觸發當前工作流，以確定要排程的下一個任務，但是它是在內部完成的，而不是透過定義的介面進行的）api的安全性並不那麼容易，因為它不是真正的模組化（不同於資料庫實現，這很棒）。儘管這一點正在研究中，所以對未來充滿希望。