讓你真正的了解Zeebe

一.  Zeebe是什么？

1. Zeebe介紹

Zeebe是一個用於微服務編排的開源工作流引擎。它基於BPMN2.0可定義圖形化工作流 ，可使用Docker和Kubernetes進行部署，可構建來自Apache Kafka和其他消息傳遞平台的事件的工作流，可水平擴展處理非常高的吞吐量，可以導出用於監視和分析的工作流數據，具有很好容錯能力，可無縫伸縮以處理不斷增長的事務量。

Zeebe旨在解決大規模微服務編排問題，並且為實現這一目標，它提供了：

1. 橫向可擴展性:  不依賴外部數據庫；相反，Zeebe將數據直接寫入同一服務器上的文件 系統中，並且可以輕松地在計算機集群之間分布處理以提供高吞吐量。
2. 容錯機制:  通過易於配置的復制機制實現容錯，確保Zeebe可以從機器或軟件故障中恢      復，而不會造成數據丟失和最小的停機時間。
3. 消息驅動架構:  所有與工作流相關的事件都被寫入僅用於追加的日志。這些事件可以導 出到外部系統進行長期存儲，以提供一個完整的工作流審計日志。
4. 發布-訂閱交互模型:  該模型使連接到Zeebe的微服務可以保持高度的控制權，同時提 供處理背壓機制。
5. 可視化工作流：基於標准BPMN 2.0，使技術和非技術利益相關者可以使用通用語言進 行工作流程設計協作。
6. 與語言無關的客戶端模型：幾乎可以使用構建微服務的任何編程語言來構建Zeebe客 戶端。

2. Zeebe的特性

1. Zeebe的設計考慮了大型工作流程（每秒及以后啟動多達數萬個新工作流程實例）。Zeebe不依賴外部數據庫，而是將數據以不可變日志的形式直接存儲在部署Zeebe的服務器上。這種架構是Zeebe處理高吞吐量和水平擴展能力的關鍵。

2. 當前，Zeebe代理與外部服務之間的所有通信均由Zeebe的客戶處理。Zeebe的客戶端協議與編程語言無關，這意味着可以使用許多常見的編程語言輕松生成客戶端。

3. 與更成熟的工作流引擎（例如Camunda BPM）相比，Zeebe當前涵蓋的BPMN符號更少。但是，Zeebe會定期添加對新符號的支持，最終，Zeebe將提供對工作流程自動化有意義的BPMN符號的完整介紹。

二. Zeebe解決問題及其重要性

1. Zeebe解決了什么問題

微服務架構近年來越來越受歡迎，但是微服務的松耦合，獨立的部署周期卻帶來了巨大挑戰。

微服務體系結構的核心原則是每個微服務僅負責一個業務功能。在微服務體系結構中，每個微服務僅負責仔細監視的業務功能，默認情況下卻沒人負責端到端工作流程。

許多微服務架構都依賴純編排模式進行通信，在這種模式下，微服務通過在沒有中央控制器的情況下將事件發布到消息傳遞平台並從消息傳遞平台使用事件來進行協作（該模型也稱為“發布-訂閱”或“發布-訂閱”）。編排確實確實為微服務開發人員提供了一定程度的靈活性。但是，在其典型實現中，編排不提供：

1. 對業務當前狀態的可見性：正在進行多少個端到端工作流實例，它們的狀態是什么？在過去的24小時內，有多少個工作流實例未成功完成？為什么這些工作流程實例未成功完成？完成工作流程實例或工作流程中的特定步驟平均需要多少時間？

2.故障處理：如果作為工作流一部分的服務發生故障，誰負責處理故障？工作流的重試邏輯是什么？如果需要人工干預，我們的及時解決問題的規則是什么？

因此，微服務架構面臨生產出了好的軟件（在微服務級別上）但產生不良業務成果的風險。

開發團隊如何在確保健壯的端到端工作流的同時獲得微服務架構的好處？

這就是為什么要使用Zeebe.

2. Zeebe如何解決端到端的工作流問題

Zeebe使用戶能夠：

1. 明確定義和建模跨多個微服務的工作流
2. 詳細了解工作流程的執行情況並了解存在問題的地方
3. 編排微服務，以實現已定義的工作流，以確保所有工作流實例均按計划完成，即使 過程中存在問題。

使用Zeebe解決工作流程問題，第1步：了解工作流程的事件監視

回顧一下：平時我們的微服務架構

1. 您的業務依賴於成功完成一個或多個長期運行的工作流程
2. 這些工作流由獨立開發和獨立部署的微服務執行，這些微服務通過pub-sub進行通信而沒有中央控制機制
3. 盡管您可能了解給定微服務的性能，但對工作流的端到端運行狀況以及業務的當前狀態了解甚少。

Zeebe針對單個微服務的運行狀況的范圍，可提供了以下方面的可見性：

1．業務的當前狀態：目前有多少個跨微服務工作流正在運行，它們的狀態如何？

2．是否有由於錯誤或其他問題而“卡死”了運行中的流程？

3．我們平均的端到端流程持續時間是多少？我們在哪里遇到流程中的問題？

使用Zeebe解決工作流程問題，第2步：微服務編排

通過以下圖，顯示了Zeebe如何用於微服務編排

 

通過途中可以看到Zeebe與參與工作流的微服務直接通信。

您可以將Zeebe的工作流程編排方法視為狀態機。當工作流實例執行某項任務時，Zeebe發送一條消息以通知負責的工作人員服務，然后等待工作人員完成任務。

任務完成后，工作人員服務會通知Zeebe，然后流程繼續進行下一步。如果工作人員未能完成任務，則工作流將保留在當前步驟，可能會重試該任務，直到最終成功為止；如果需要人工干預，則升級為其他團隊。

Zeebe將任務通知消息的創建與實際工作分離開來，這意味着Zeebe可以以最大可能的速率發送任務通知消息，而不管是否有可用於工作的工人服務。

Zeebe將任務通知排隊，直到可以將其推送給工作人員為止。如果當前沒有可用的工作程序服務，則工作消息將保持排隊狀態。如果訂閱了工作者服務，則Zeebe的反壓協議可確保工作者可以控制他們接收任務的速率。

這種微服務編排方法仍可提供對工作流和工作流實例的完整可見性，同時還可以確保工作流根據其定義完成，即使在途中出現故障時也是如此。

3. 為什么選擇Zeebe

1. Zeebe水平縮放

Zeebe在微服務編排中需要提高吞吐量，為了處理大量的工作流實例，可能需要 跨計算機集群分發Zeebe，以滿足吞吐量需求。

2. Zeebe具有容錯能力並且高度可用

Zeebe允許用戶在創建主題時配置復制因子。復制因子確定在其他代理上存儲多 少個分區的“熱備份”副本。如果一個代理宕機，另一個代理可以替換它而不 會丟失數據。由於數據是在集群中的代理之間分布的，因此Zeebe 無需外部數據 庫即可提供容錯能力和高可用性，直接將數據存儲在部署它的服務器中的文件系統 上。Zeebe也不需要外部集群協調器，例如ZooKeeper。Zeebe完全獨立且自給 自足。

3. Zeebe允許可視化地定義工作流程

Zeebe定義工作流的默認建模語言是基於BPMN 2.0的。工作流程是在視覺上定 義的，技術和非技術利益相關者都可以充分參與。盡管Zeebe對BPMN 符號的 涵蓋范圍不像Camunda BPM這樣的更成熟的BPM平台涵蓋的范圍廣泛，但 Zeebe路線圖中包括定期添加對新符號的支持。

4. Zeebe與語言無關

當前，Zeebe用Java和Go提供了兩個開箱即用的客戶端。Zeebe客戶端基於 gRPC，這意味着可以使用構建微服務的許多編程語言輕松生成 Zeebe客戶端。

5. Zeebe是完全由消息驅動的

Zeebe代理和客戶端完全通過發布-訂閱進行通信，遵守松散耦合的原理，可以 實現Zeebe與參與工作流的微服務之間的異步通信。Zeebe的訂閱協議包括背壓 機制，以確保客戶端不會因Zeebe的工作而過載。

6. Zeebe可以方便地存儲用於審計事件的完整歷史

Zeebe導出器使將工作流事件數據傳輸到存儲系統變得很容易，因此可以無限 期地使用這些數據。這對於報告和可見性很重要，並且由於您所在的行業，出於監 管原因，也可能有必要。