使用Zeebe编排云事件（上）

使用Zeebe编排云事件（上）

使用Kubernetes时，您会发现使用不同语言和使用不同技术堆栈编写的服务的机会非常高。CloudEvents（cloudevents.io  /  CNCF规范）的诞生是为了使这些系统能够通过以标准方式描述其事件来交换信息，而不管这些服务使用的是哪种传输方式（HTTP，消息传递AMPQ / JMS，Protobuf等）。

在这种情况下，您的事件是由不同的系统产生和使用的，当系统变得更大时，就会出现一些共同的要求，例如：

1. 可见性：能够从业务角度查看和理解事件交互。
2. 协调：有时，您只需要定义并检查是否发生了一定顺序的事件或为满足某些目标而发生了这些事件。
3. 错误处理：一种机制，用于在情况未达到预期的情况下处理问题，以确保我们纠正这些情况，并且从业务角度出发，我们会跟踪并不断改善我们的运营方式。
4. 合规性：在这些事件之间强制执行某些规则和命令，以确保符合规定。
5. 为了在不重新设计轮子的情况下解决此类需求，您可以使用工作流引擎，该引擎为这些常见需求集提供了非常灵活的解决方案。在此博客文章中，我将介绍 Zeebe（云原生工作流引擎）以及如何从工作流使用和发出Cloud Events。

例如：

让我们想象一下，我们有两种服务可以与希望在我们的网站上购买音乐演唱会门票的客户打交道。当新的音乐会上线时，这些系统中的大多数系统都需要处理高负载，因为歌迷可能想在短时间内购买所有门票。

网站和客户流如下所示：

在后端，将有一个服务来排队想要购买票的客户，还有一个服务来处理付款。由于需求量大，因此需要设置超时时间，以确保不愿意购买票证的客户在花太多时间进行决策时将他们从队列中删除。

这两个服务在设计时都考虑了 事件驱动的体系结构 ，因此它们发出事件并对事件做出反应。TicketsService消耗并发出以下事件 ：

1. Tickets.CustomerQueueJoined： 客户有兴趣购买票证，因此他们已加入队列以购买票证
2. Tickets.Requested：  客户已为音乐会选择一张或多张门票，并准备结账。
3. Tickets.CheckedOut： 客户确认了结帐动作。
4. 票证：已发出：票证已发给客户。
5. Notifications.Requested： 已将通知发送给客户。在我们的示例中，这可能是由于检出票时超时或授权付款时支付服务超时所致。

另一方面，  PaymentService 可以做出反应并发出以下事件：

1. Payments.RequestReceived： 已收到付款请求，该请求已排队等待处理。
2. Payments.Authorized： 付款已成功处理和授权。

通过查看这些事件，您可以快速意识到这些服务与网站上的客户之间的交互是异步的。事件被发出，并且其他一些服务将做出反应并对其进行处理，结果可能会发出另一个事件。 

在以下各节中，将介绍编排方法而无需更改我们的服务，并且我们可以解决导言中提到的要点（可见性，协调，错误处理，合规性）。