使用 Knative 和 Zeebe 編排 CloudEvents

發布於：2020-10-14 ，  修訂於：2024-01-17

使用 Knative 和 Zeebe 編排 CloudEvents

作者：Mauricio Salatino (Salaboy)，Camunda 和 LearnK8s 的首席軟體工程師及講師

幾週前，我在 Knative Meetup (影片、簡報) 上介紹如何利用雲原生工作流程引擎 Zeebe 來理解、增強和編排已經使用 CloudEvents 的應用程式。

我想稍微擴展一下這些工具如何幫助您更深入地了解分散式應用程式的運作方式。

您可以在 GitHub 上找到示範應用程式、安裝說明以及一些應用程式和工具實際運作的影片。

我建構的應用程式由四個微服務組成，這些微服務使用 CloudEvents 進行通訊，並執行應用程式的典型（正常路徑）流程：「購買演唱會門票」。每個服務都以 Knative 服務的形式執行，並使用 Knative 事件來與其他服務交換訊息。

該應用程式嚴重依賴 Knative 事件，因為所有服務都會將事件發送到 Broker，並註冊 Knative 觸發器（訂閱），以便接收它們感興趣的事件。

應用程式會為每個想要在我們網站上購買門票的使用者發出以下事件

請注意，這個雲原生應用程式使用 WebSocket，這在您考慮擴展它時會增加額外的複雜性。

即使您有追蹤（使用類似 OpenTracing 的工具和集中式記錄系統），要了解事件驅動應用程式內部發生什麼仍然相當棘手。您可以這樣想 -- 假設我們只有 10 位客戶同時嘗試購買門票，要了解每位客戶在流程中的位置，或潛在的瓶頸出現在哪裡，都具有挑戰性。

到目前為止，這只是一個普通的 Knative 應用程式，而且因為您正在使用原生支援 CloudEvents 的 Knative 事件，您可以將更多工具整合到生態系統中，如下一節所示。

視覺化/理解

無需變更應用程式程式碼或設定中的任何內容，您就可以利用事件流，並使用 Zeebe 和 Camunda Operate 繪製對客戶旅程有意義的事件並將其視覺化。

您可以從建立一個工作流程模型開始，該模型使用應用程式發出的事件來報告狀態，如下面的模型所示

這個簡單的工作流程模型會等待應用程式事件，並在每個事件到達時將流程向前推進。沒錯，您猜對了，它適用於 CloudEvents :)。

對於每個加入隊列購買門票的客戶，都會建立一個新的工作流程實例來追蹤他們。擁有這些實例可讓您追蹤個別客戶，並快速了解每個人在特定時間點的位置。

Zeebe 隨附 Camunda Operate，可讓您幾乎即時地查看所有這些資訊，並獲得有關工作流程執行和相關資料的詳細稽核追蹤。

裝飾/增強

現在您擁有工作流程引擎的能力，您可以利用它的一些功能來裝飾或增強您的應用程式。增強版的工作流程模型可能如下所示

現在，當客戶到達 付款已發送 狀態時，表示他們已完成預訂，模型會等待 付款已發送 CloudEvent 到達。

如上所示，有兩個計時器邊界事件與 付款已發送 狀態相關聯。底部的事件，帶有虛線，是非中斷事件，表示它不會中斷實際流程，它只會以觸發後即忘的方式觸發。這會導致傳送付款提醒，並且因為它可以配置為週期性計時器，因此它會每隔 X 時間觸發一次（在簡報中設定為 10 秒）。

上面的圖片顯示了前端的通知，該通知是由工作流程引擎產生，路由到網站後端，並使用 WebSocket 轉發到客戶瀏覽器中的網站前端。

頂部以實線表示的，是一個中斷事件，這表示它會使模型的正常流程被捨棄，並且只會繼續執行從計時器定義的步驟（在此案例中為 預約逾時）。對於這個情境，中斷計時器設定在訂票預約完成後的 X 時間後觸發（為了演示，設定為 2 分鐘）。在預約逾時後，網站會將客戶重新導向回起點。

對於這兩種計時器，您都可以獲得完整的可追溯性（例如，它們何時以及觸發頻率）。您可以在 操作 中以圖形方式查看這些詳細資訊。

您可以看到非中斷計時器被觸發了數次，在前端產生了付款提醒。即使我們沒有實作前端通知，您也可以使用這些計時器來測量和分類客戶實際完成付款所需的時間。這對於分類不同類別非常有用；例如，人們平均需要多少時間提供付款資訊。

這些計時器與 Cronjobs（例如在 Kubernetes 中） 的一個主要區別在於，這些計時器與它們相關聯的狀態有關，這表示一旦收到 付款已發送 的 CloudEvent，這兩個計時器都會自動取消並進行垃圾回收。對於這個特定情境，您希望發送有關付款的通知，同時確保如果付款已發送，則預約不會逾時。工作流程引擎以對使用者透明的方式處理這些非常常見的需求，這些使用者有興趣將基於時間的事件註冊為其應用程式的一部分。

協調

上圖模型中顯示的 付款提醒 和 預約逾時 狀態，代表我們從單純監聽事件跨越到實際從工作流程模型發出 CloudEvents 的時刻。現在，工作流程模型不僅可以幫助您視覺化和理解您的雲原生應用程式正在執行的操作，還可以驅動和與您的服務互動。

當使用工作流程引擎來協調 CloudEvents 時，您可以輕鬆使用許多新工具來處理更複雜的場景。

工作流程模型第 3 版顯示了一個更複雜的圖表，其中子流程可用於將一組狀態組合在一起。這樣做，您可以快速識別工作流程中的階段，並為這些階段註冊事件，例如計時器或訊息事件。

在 客戶購買票券 階段內的任何時間，工作流程都可以對 CloudEvent 客戶放棄排隊 做出反應。這將觸發客戶 清理 事件，以從所有快取資料的服務中垃圾回收與客戶會話相關的所有資料。

在以下螢幕截圖中，在 Camunda Operate 中，您可以快速視覺化有多少工作流程實例處於特定階段，以及有多少工作流程已完成及其完成時的狀態。

使用工作流程引擎的另一個優勢是流程控制。透過使用流程控制元素（例如互斥閘道），您可以將一些高階決策（通常是編碼業務邏輯）委派給工作流程引擎。

如上述模型所示，互斥閘道用於根據條件選擇兩個不同的路徑。在此案例中，條件正在評估客戶正在預訂多少張票，並根據此條件，模型會在正常的信用卡付款或更複雜的匯款之間選擇。

架構和後續步驟

從架構角度來看，工作流程引擎和 Knative 之間的整合非常簡單。它依賴 CloudEvents 和一個負責將事件路由到正確工作流程的元件，反之亦然。

Zeebe CloudEvents Router 負責公開一個端點，事件可以轉發到該端點，同時了解從工作流程模型將事件推送到何處。

如上圖所示，Zeebe CloudEvents Router 並非孤立存在。Zeebe Operator 負責佈建或連線到遠端工作流程引擎，它具有部署和管理工作流程定義的能力。這表示它可以解析並理解工作流程模型是否發出或消耗雲端事件，這些資訊可用於動態佈建 Knative Channels 並為每個模型建立 Knative Triggers，如同在 Knative Flow (順序和並行) 中所做的那樣。

例如，對於我們工作流程模型的第 1 版

將會建立以下 Knative Triggers

apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: router-queue-join-trigger
  namespace: default
spec:
  broker: default
  filter:
    attributes:
      type: Queue.CustomerJoined
  subscriber:
    uri: http://zeebe-cloud-events-router.default.svc.cluster.local/message

---
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: router-queue-exit-trigger
  namespace: default
spec:
  broker: default
  filter:
    attributes:
      type: Queue.CustomerExited
  subscriber:
    uri: http://zeebe-cloud-events-router.default.svc.cluster.local/message

---
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: router-tickets-reserved-trigger
  namespace: default
spec:
  broker: default
  filter:
    attributes:
      type: Tickets.Reserved
  subscriber:
    uri: http://zeebe-cloud-events-router.default.svc.cluster.local/message

---
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: router-tickets-payment-sent-trigger
  namespace: default
spec:
  broker: default
  filter:
    attributes:
      type: Tickets.PaymentSent
  subscriber:
    uri: http://zeebe-cloud-events-router.default.svc.cluster.local/message

---
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: router-tickets-payment-authorized-trigger
  namespace: default
spec:
  broker: default
  filter:
    attributes:
      type: Tickets.PaymentsAuthorized
  subscriber:
    uri: http://zeebe-cloud-events-router.default.svc.cluster.local/message

如前所述，更深入的整合應處理訊息層的更進階拓撲。例如，能夠在邏輯上將工作流程模型分組，以使用專用的 Knative Channel 和 Zeebe CloudEvents Router。在未來的版本中，Zeebe Operator 將會知道 CloudEvents Router 以佈建和管理 Knative 和 CloudEvents 整合。

總結

在這篇部落格文章中，我花了一些時間描述您可以在 Knative 應用程式之上使用像 Zeebe 這樣的工作流程引擎所做的事情。我個人在使用 Knative 時玩得很開心，因為它提供的抽象化功能幫助我建立了一個非常強大的應用程式，我可以輕鬆地將其移動到不同的雲端供應商，而無需更改任何服務。在此處觀看此示範直播：{{< youtube msDDdqmyEFA >}} 這篇部落格文章中展示的專案和整合正在積極開發中，因此如果您有興趣或想參與其中，請透過 Twitter 聯繫：@salaboy 或加入我們的 slack 頻道：zeebe-io.slack.com

如果您想在自己的 Kubernetes 叢集中執行此示範，可以在這裡找到說明：https://github.com/salaboy/orchestrating-cloud-events/ 如果您想為該儲存庫加星標，我們將會非常感激 :)