使用 Knative 和 Kogito 編排事件 ¶

發佈於：2020-12-16 ，修訂於： 2024-01-17

使用 Knative 和 Kogito 編排事件¶

作者：Ricardo Zanini，RedHat 首席軟體工程師，以及 Tihomir Surdilovic，Red Hat 軟體開發人員

Kogito 是一個用於開發雲原生業務自動化應用程式的平台。它旨在針對雲原生架構，並提供一系列功能，讓架構師和開發人員可以輕鬆建立業務應用程式。

Kogito 實作了 CNCF 無伺服器工作流程專案，這是一個用於定義協調事件驅動、無伺服器應用程式的工作流程模型的規格。它專注於定義一個供應商中立、平台獨立和宣告式的工作流程模型，用於協調可以在多個雲端和容器平台使用的服務。截至目前，無伺服器工作流程規格是一個 CNCF 沙箱專案。

作為無伺服器工作流程實作的一部分，Kogito 提供了一個 Kubernetes Operator，可使用 Knative 部署這些工作流程。目標是盡可能簡化在雲端環境中部署和管理使用者定義的工作流程。Knative Eventing 在此場景中扮演著非常重要的角色，它為事件驅動架構提供了底層基礎設施。

Kogito 無伺服器工作流程¶

為了示範 Kogito 工作流程實作如何在 Knative 的事件驅動架構上運作，我們將使用病患入職範例。在此範例中，我們模擬醫院用於讓新病患入職並將其分配給正確醫生的工作流程。

以下圖片取自規格範例頁面，說明了這個工作流程

病患入職工作流程表示

此工作流程會在收到包含病患資訊的 CloudEvent 物件後開始。然後，規格會依序呼叫三個函式：(1) 儲存病患資訊、(2) 根據病患的症狀將病患分配給醫生，以及 (3) 為該病患安排與已分配醫生的預約。

以下是基於此規格的病患入職工作流程 YAML 範例

id: onboarding
version: '1.0'
name: Patient Onboarding Workflow
states:
- name: Onboard
  type: event
  start:
    kind: default
  onEvents:
  - eventRefs:
    - NewPatientEvent
    actionMode: sequential
    actions:
    - functionRef:
        refName: StoreNewPatient
    - functionRef:
        refName: AssignPatientToDoctor
    - functionRef:
        refName: SchedulePatientAppointment
  end:
    kind: default
events:
- name: NewPatientEvent
  type: new.patient.events
  source: "/hospital/entry"
functions:
- name: StoreNewPatient
  operation: classpath:openapi.json#storeNewPatient
- name: AssignPatientToDoctor
  resource: classpath:openapi.json#assignPatientToDoctor
- name: SchedulePatientAppointment
  resource: classpath:openapi.json#schedulePatientAppointment

上述工作流程定義基於三個部分。第一部分是 states 陣列，其中包含工作流程控制流程邏輯。在此情況下，它是一個 event，會接收新的病患雲端事件，並執行先前提及的三個函式。

工作流程的第二部分是 events 陣列，其中包含基於 CloudEvent 規格的事件定義。工作流程中事件的定義方式與 CloudEvent 格式的表示方式之間存在 1:1 的對應關係。

第三部分 functions 陣列包含函式定義，這些定義向執行階段提供有關如何執行所需服務的更多資訊。

無伺服器工作流程規格基於標準，並利用 OpenAPI 規格來定義服務 restful 執行的詳細資訊。在此 gist 中，您可以查看上述範例中函式所參考的 OpenAPI 檔案。

您可以參考無伺服器工作流程規格，以取得有關規格提供的所有語言結構的資訊。

請注意，此規格允許 JSON 和 YAML 工作流程格式。此範例使用 YAML，但 JSON 被認為是等效的，並且也可由執行階段剖析。

在編譯期間，Kogito 執行階段會剖析此 YAML 檔案，並產生代表此工作流程定義的 Java 程式碼。產生的程式碼基於 Quarkus 框架。結果是一個 OpenAPI 標準 REST 服務，可以部署在您的架構中的任何位置。

Kogito 執行階段工作流程剖析程序 Kogito 執行階段剖析流程

在此範例中，我們也將 Knative Kogito Eventing 外掛程式新增至專案，這表示它可以透過根路徑上的 HTTP 接受 CloudEvent 物件。例如

$ curl -X POST \
      -H "content-type: application/json"  \
      -H "ce-specversion: 1.0"  \
      -H "ce-source: /hospital/entry"  \
      -H "ce-type: new.patients.events"  \
      -H "ce-id: 12346"  \
      -d "{ \"name\": \"Mick\", \"dateOfBirth\": \"1983-08-15\", \"symptoms\":[\"seizures\"]}" \
http://localhost:8080

當將此請求傳送到服務時，工作流程的新執行個體會啟動，並執行規格中定義的所有作業。

此範例中包含更多內容。如需有關如何部署和建置的完整指示，請參閱 Github 儲存庫上的範例頁面。

Knative 事件整合¶

基於此產生的服務，您可以建置映像，以便與安裝了 Knative Eventing 的 Kubernetes 叢集上的 Kogito Operator 一起部署。Operator 會建立所有必要的 Knative 資源，以設定此服務並將其訂閱到 Knative 代理。

Knative 和 Kogito 整合 Knative 事件和 Kogito Operator 整合

Kogito Operator 會建立一個 Knative 觸發器 (Trigger) 資源，將服務和訊息中介 (broker) 連接在一起。在這個範例中，它會篩選類型為 new.patients.events 的事件。這表示每次有此類型的新事件傳送到訊息中介時，都會被重新導向到 Kogito 服務。

相同的概念也適用於工作流程引擎產生的事件。在這種情況下，Operator 會建立一個 Knative SinkBinding 資源，並將其綁定到 Knative 訊息中介。每次服務產生事件時，代表該事件的 CloudEvent 將會被傳送到訊息中介。下圖說明了 Kogito 服務透過 SinkBinding 向 Knative 訊息中介發送事件的實作細節。

Knative 和 Kogito 整合 Knative 事件處理與 Kogito 服務事件生產者

結論¶

無伺服器工作流程規範可以幫助我們定義複雜的工作流程，這些工作流程可以在許多平台和雲端供應商之間使用。在這篇文章中，我們分享了如何將該規範與 Kogito 一起使用，以及與 Knative 作為無伺服器平台整合的可能性。

雖然該規範的實作仍在 Kogito 專案中進行，但我們的目標是擁有一個完全符合標準和規範的平台。

您可以在您的本機環境中嘗試本文中展示的範例。如果您正在尋找更複雜的案例，請查看我們使用 Kogito 和 Knative 事件處理的Github Bot 範例。

延伸閱讀¶

要進一步了解無伺服器工作流程規範，我們建議您閱讀 Github 儲存庫中的規範文件，並加入社群！

要更了解 Knative 事件處理以及該平台如何幫助您在 Kubernetes 上建立事件驅動的架構，請參考官方文件。

關於作者¶

Ricardo Zanini 是一位軟體工程師，目前在 Kogito 社群專案工作。他自 2000 年以來一直從事軟體工程領域的工作。他是 CNCF 無伺服器工作流程規範的維護者。

Tihomir Surdilovic 是 Red Hat 的軟體開發人員，從事業務自動化工作。他自 2008 年以來一直參與業務自動化和開源專案。他也是 CNCF 無伺服器工作流程規範的活躍領導者。