Zeebe架构和核心

客户向Zeebe发送指令:

发布工作流(部署工作流)

执行业务逻辑(执行业务逻辑)

创建工作流实例(启动工作流实例)发布消息(激活作业)完成作业(失败作业)。

处理运营问题。

更新工作流实例变量并解决异常。

1.客户端程序可以完全独立于Zeebe进行伸缩——Zeebe代理不执行任何业务逻辑。

2.客户端是嵌入在应用程序中的库(执行业务逻辑的微服务)，用于与Zeebe集群连接和通信。

3.客户端通过基于HTTP/2协议的gRPC与Zeebe网关连接。

4.Zeebe官方提供Java和Go客户端。该社区提供C#、Ruby和Java客户端实现。

5.五分钟后。客户端，执行单个任务的单元称为作业工人。

网关作为Zeebe集群的入口，将请求转发给代理。网关是无状态和无会话的，可以根据需要添加节点以实现负载平衡和高可用性。

Broker是一个分布式流程引擎，它维护正在运行的流程实例的状态。可以对代理进行分区以实现水平扩展，并通过复制来实现容错。通常，Zeebe集群有多个节点。

需要强调的是，broker不包含任何业务逻辑，只负责:

处理客户发送的指令

存储和管理正在运行的流程实例的状态。

向工作人员分配任务

Brokes形成了一个对等网络，因此集群不会出现单点故障。集群中的所有节点承担相同的责任，因此当一个节点不可用时，该节点的任务将透明地重新分配给网络中的其他节点。

导出器系统提供了Zeebe中状态变化的事件流。这些事件流数据有许多潜在用途，包括但不限于:

监控当前运行的流程实例的状态。

分析审计或BI的历史工作流数据。

跟踪Zeebe抛出的异常。

Exporter提供了一个简洁的API，可以将数据传输到任何存储系统。Zeebe官方提供了开箱即用的Elasticsearch导出器，社区也提供了其他导出器。

Zeebe可以实现高吞吐量和高可用性的微服务编排，这得益于三个关键实现:

1.Zeebe的设计考虑到了分布式部署。不依赖外部组件就可以构建zeebe broker集群，集群中的节点形成一个对等网络。在网络中，所有节点都有相同的职责，因此整个集群不会出现单点故障。

2.Zeebe内部抽象出一个只写队列(可以类比理解为卡夫卡的主题)来处理和存储数据。当集群有多个代理节点时，队列将被分成多个分区(或碎片)并分配给每个节点。每个分区都有多个副本。在所有副本中，将根据raft协议选择一个领导者，领导者负责接收请求并执行所有处理逻辑。其他经纪人的副本是被动的追随者。当领导者不可用时，追随者将透明地选择新的领导者。

Zeebe消息驱动架构体现在两个方面:

1.Zeebe Broker在内部使用队列(即LogStream，它只追加写入)来异步处理请求。

2.Zeebe JobWorker和Broker通过发布订阅模式进行交互。当工作流任务状态发生变化时，Broker会发布相应的事件。JobWorker订阅通过轮询来处理自己的相关事件。

2.2.1代理内部流程处理模型

Zeebe的内部实现实际上是一系列作用于记录流的流处理器。作为统一的实现，流处理模型提供:

命令协议(即请求响应)

记录导出/流式传输

工作流演算(评估、异步后台任务)

当Zeebe处理任务、工作流程或内部维护时，它会产生有序的记录流:

————————————————————————————————————

原文链接:/A/456966231 _ 10093134