使用 Knative 和 Zeebe 编排 CloudEvents ¶

发布时间：2020-10-14 ，修订时间：2024-01-17

使用 Knative 和 Zeebe 编排 CloudEvents¶

作者：Mauricio Salatino (Salaboy)，@ Camunda 的首席软件工程师和 LearnK8s 教师

几周前，我在 Knative 会议 (视频，幻灯片) 上介绍了如何利用云原生工作流引擎 Zeebe 来理解、增强和编排您已经使用 CloudEvents 的应用程序。

我想详细说明一下这些工具如何帮助您更深入地了解分布式应用程序的工作原理。

您可以在 GitHub 上找到演示应用程序、安装说明以及一些应用程序和工具实际操作的视频。

我构建的应用程序包含四个微服务，它们使用 CloudEvents 进行通信并执行应用程序的典型（正常路径）流程：“购买音乐会门票”。每个服务都作为 Knative 服务运行，使用 Knative Eventing 与其他服务交换消息。

Knative Application

应用程序严重依赖 Knative Eventing，因为所有服务都会向代理发出事件，并向它们感兴趣的事件注册 Knative 触发器（订阅）。

对于每个想要在我们的网站上购买门票的用户，应用程序都会发出以下事件

Application Events

请注意，此云原生应用程序使用 WebSocket，当您考虑扩展它时，它会增加一层额外的复杂性。

即使您有跟踪（使用诸如 OpenTracing 和集中式日志记录系统），理解事件驱动的应用程序内部发生了什么也很棘手。想想这样 - 假设我们只有 10 个客户同时尝试购买门票，理解每个客户在流程中的位置，或者潜在的瓶颈出现在哪里，都是很困难的。

到目前为止，这只是一个普通的 Knative 应用程序，因为您使用的是 Knative Eventing，它原生支持 CloudEvents，因此您可以像下一节中将看到的那样，将更多工具集成到生态系统中。

可视化/理解¶

无需更改应用程序代码或设置中的任何内容，您就可以进入事件流，映射对客户旅程有意义的事件，并使用 Zeebe 和 Camunda Operate 可视化它们

Knative and Zeebe

您可以从创建一个工作流模型开始，该模型使用应用程序发出的事件来报告状态，如下面的模型所示

Workflow model v1

这个简单的工作流模型等待应用程序事件，并在每个事件到达时向前推进流程。是的，您猜对了，它适用于 CloudEvents :)。

对于每个加入队列购买门票的客户，都会创建一个新的工作流实例来跟踪他们。拥有这些实例可以让您跟踪单个客户，并快速了解每个人在特定时间的进度。

workflow model instances

Zeebe 附带 Camunda Operate，它允许您几乎实时地查看所有这些信息，并详细了解工作流执行和与之关联的数据的审计跟踪。

Operate UI

装饰/增强¶

既然您拥有了工作流引擎的功能，就可以利用它的一些特性来装饰或增强您的应用程序。工作流模型的增强版本可能看起来像这样

Workflow model v2

现在，当客户达到 已发送付款 状态时，表示他们已经预订了门票，模型将等待 已发送付款 CloudEvent 到达。

timers

如上所示，两个定时器边界事件已与 已发送付款 状态相关联。底部的那个（虚线）是一个非中断事件，表示它不会中断实际流程，而只会以触发后立即执行的方式触发。这将导致发送付款提醒，并且由于它可以配置为定期定时器，因此它将每隔 X 量时间触发一次（对于演示，此时间设置为 10 秒）。

Websockets push notification

上面的图片显示了前端的通知，该通知是由工作流引擎生成的，路由到网站后端，然后使用 WebSocket 转发到客户浏览器中的网站前端。

顶部的那个（实线）是一个中断事件，表示它将导致模型的正常流程被丢弃，并且只继续执行定时器中定义的步骤（在本例中为 预订超时）。对于此场景，中断定时器设置为在预订门票后 X 量时间后触发（对于演示，此时间设置为 2 分钟）。在预订超时后，网站将客户重定向回起点。

对于这两个定时器，您都获得了完整的可追溯性（例如，何时以及如何触发它们）。您可以在 Operate 中以图形方式查看这些详细信息

Workflow model v2 in Operate

您可以看到非中断定时器被触发了多次，在前端生成了付款提醒。即使我们没有实现前端通知，您也可以使用这些定时器来衡量和分类客户实际完成付款所需的时间。这对于分类不同的类别非常有用；例如，人们平均需要多少时间才能提供付款信息。

这些定时器与 Cronjobs（例如 Kubernetes 中的）之间的最大区别在于，这些定时器是与它们相关联的状态上下文相关的，这意味着一旦收到 已发送付款 CloudEvent，这两个定时器就会自动取消并被垃圾回收。对于此特定场景，您需要有关付款的通知，但也需要确保如果已发送付款，则预订不会超时。工作流引擎以对对注册时间相关事件感兴趣的用户透明的方式处理这些非常常见的要求。

编排¶

如上模型所示，付款提醒和预订超时状态代表我们从简单地监听事件到实际从工作流模型中发出 CloudEvents 的转变。现在工作流模型不仅帮助您可视化和理解您的云原生应用程序的行为，而且还能驱动并与您的服务交互。

在使用工作流引擎编排 CloudEvents 时，您可以轻松使用各种新工具来处理更复杂的场景。

工作流模型的版本 3 显示了一个更复杂的图表，其中子流程可用于将一组状态分组。通过这样做，您可以快速识别工作流中的阶段，以及注册这些阶段的事件，例如计时器或消息事件。

Workflow Model V3

工作流可以在客户购买门票阶段内的任何时间对 CloudEvent 客户放弃队列做出反应。这将触发客户清理事件，以从所有缓存数据的服务中收集与客户会话相关的所有数据。

在以下屏幕截图中，在 Camunda Operate 中，您可以快速可视化工作流在给定阶段有多少实例，以及有多少工作流已完成，以及它们以何种状态完成。

Workflow Model V3 in Operate

使用工作流引擎的另一个优势是流控制。通过使用流控制元素（如排他网关），您可以将一些高级决策（通常编码业务逻辑）委派给工作流引擎。

Workfloe Model V4

如上模型所示，排他网关用于根据条件在两个不同的路径之间进行选择。在这种情况下，条件是在评估客户预订的门票数量，并且基于此，模型在正常信用卡付款和更复杂的汇款之间进行选择。

架构和下一步¶

从架构的角度来看，工作流引擎和 Knative 之间的集成非常简单。它依赖于CloudEvents和一个负责将事件路由到正确工作流的组件，以及反过来。

该Zeebe CloudEvents 路由器负责公开一个可以转发事件的端点，同时了解从工作流模型中推送事件的位置。

Knative and Zeebe Detailed

如上图所示，Zeebe CloudEvents 路由器并不孤单。负责配置或连接到远程工作流引擎的Zeebe 运算符能够部署和管理工作流定义。这意味着它可以解析和了解工作流模型是否发出或使用云事件，该信息可用于动态配置Knative 通道并为每个模型创建Knative 触发器，就像在Knative Flow（顺序和并行）中那样。

例如，对于我们工作流模型的版本 1

Workflow Model V1

创建以下 Knative 触发器

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 通道和Zeebe CloudEvents 路由器。在将来的版本中，Zeebe 运算符将了解 CloudEvents 路由器以配置和管理 Knative 和 CloudEvents 集成。

总结¶

在这篇博文中，我花了一些时间介绍了在 Knative 应用程序之上使用像 Zeebe 这样的工作流引擎可以做些什么。我个人在使用 Knative 时玩得很开心，因为提供的抽象帮助我构建了一个非常健壮的应用程序，我可以轻松地将其移动到不同的云提供商，而无需更改任何服务。在这里观看此演示：{{< youtube msDDdqmyEFA >}} 这篇博文中显示的项目和集成正在积极开发中，因此如果您有兴趣或想参与进来，请通过 Twitter 联系我们：@salaboy 或加入我们的 Slack 频道：zeebe-io.slack.com

如果您想在自己的 Kubernetes 集群中运行此演示，您可以在此处找到说明：https://github.com/salaboy/orchestrating-cloud-events/，如果您想给存储库加一颗星，我们将不胜感激！