使用 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\"]}" \
https://:8080

当向服务发送此请求时，工作流的一个新实例开始，并执行规范中定义的所有操作。

此示例中包含更多内容。有关如何部署和构建它的全面说明，请参阅 Github 存储库上的示例页面。

Knative 事件集成¶

基于此生成的服务，您可以构建一个镜像，以便使用Kogito Operator 部署在安装了Knative Eventing 的 Kubernetes 集群上。Operator 将创建所有必要的 Knative 资源来配置此服务并将其订阅到 Knative broker。

Knative 和 Kogito 集成 Knative Eventing 和 Kogito Operator 集成

Kogito Operator 创建了一个 Knative Trigger 资源，将服务和 Broker 连接在一起。在此示例中，它将过滤类型为 new.patients.events 的事件。这意味着每当此类型的新事件到达 Broker 时，它都会被重定向到 Kogito 服务。

同样的概念也适用于工作流引擎产生的事件。在这种情况下，Operator 将创建一个 Knative SinkBinding 资源，并将其绑定到 Knative Broker。每次服务产生事件时，一个表示该事件的 CloudEvent 都将发送到 Broker。下图说明了 Kogito 服务通过 SinkBinding 向 Knative Broker 发送事件的实现细节。

Knative 和 Kogito 集成 Knative Eventing 和 Kogito 服务事件生产者

总结¶

无服务器工作流规范可以帮助我们定义复杂的跨平台和云提供商的工作流。在这篇文章中，我们分享了如何将规范与 Kogito 结合使用，以及与 Knative 作为无服务器平台集成的可能性。

虽然规范的实施是 Kogito 项目正在进行的工作，但我们的目标是拥有一个完全符合标准和规范的平台。

您可以在本地环境中尝试本文中演示的示例。如果您正在寻找更复杂的场景，请查看我们的使用 Kogito 和 Knative Eventing 的 Github Bot 示例。

延伸阅读¶

要了解有关无服务器工作流规范的更多信息，我们建议阅读 Github 存储库中的规范文档，并加入社区！

要了解有关 Knative Eventing 以及该平台如何帮助您在 Kubernetes 上创建事件驱动架构的更多信息，请查看官方文档。

关于作者¶

Ricardo Zanini 是一名软件工程师，目前从事 Kogito 社区项目。他自 2000 年以来一直从事软件工程领域的工作。他是 CNCF 无服务器工作流规范的维护者。

Tihomir Surdilovic 是 Red Hat 的一名软件开发人员，从事业务自动化工作。他自 2008 年以来一直参与业务自动化和开源项目。他还担任 CNCF 无服务器工作流规范的活跃负责人。