Zeebe 介绍
![](https://img-blog.csdnimg.cn/img_convert/7b892790e6a42f5f2d9c9f03c04e1083.png)
Zeebe 是开源的用于微服务编排的分布式工作流引擎 github
-
Camunda 由 Jakob Freund 和 Bernd Rücker 于 2008 年创立,是一家德国业务流程管理 (BPM) 咨询公司
-
2013 年 3 月 18 日,Camunda 分叉了 Activiti 项目,将 Camunda BPM 作为开源项目推出
-
Zeebe 来源于 Camunda 公司构建的下一代工作流引擎,用于取代 Camunda BPM
-
基于BPMN2.0(Business Process Modeling Notation) 标准业务流程建模符号进行编排
-
提供可视化的流程控制界面进行管理
微服务架构存在的问题
-
缺乏服务流程编排:每个微服务仅处理自己所负责的业务逻辑,微服务越多越容易导致链路复杂度提高,服务之间关系混乱
-
缺乏对业务中工作流状态的监控:正在进行多少个端到端工作流实例,它们的状态是什么?在过去的 24 小时内,有多少个工作流实例未成功完成?为什么这些工作流程实例未成功完成?完成工作流程实例或工作流程中的特定步骤平均需要多少时间?
-
缺乏故障处理:如果作为工作流一部分的服务发生故障,谁负责处理故障?工作流的重试逻辑是什么?如果需要人工干预,我们的及时解决问题的规则是什么?
因此 Zeebe 的出现,就是为了解决大规模微服务的流程编排、监控和故障处理问题
Zeebe 提供的能力
-
横向可扩展性:不依赖外部数据库;相反,Zeebe 将数据直接写入同一服务器上的文件系统中,并且可以轻松地在计算机集群之间分布处理以提供高吞吐量
-
容错机制:通过易于配置的复制机制实现容错,确保 Zeebe 可以从机器或软件故障中恢复,而不会造成数据丢失和最小的停机时间
-
消息驱动架构:所有与工作流相关的事件都被写入仅用于追加的日志。这些事件可以导出到外部系统进行长期存储,以提供一个完整的工作流审计日志
-
发布-订阅交互模型:该模型使连接到 Zeebe 的微服务可以保持高度的控制权,同时提供处理背压机制。
-
可视化工作流:基于标准 BPMN 2.0,使技术和非技术利益相关者可以使用通用语言进行工作流程设计协作。
-
与语言无关的客户端模型:几乎可以使用构建微服务的任何编程语言来构建 Zeebe 客户端。
Zeebe 特性 & 优点
-
采用 GRPC + PB 支持多种语言客户端
-
能够部署在 Docker 和 K8s
-
支持从 Kafka 等 MQ 获取消息执行
-
水平伸缩性强、应对高吞吐量
-
具有容错性,不依赖关系型数据库
-
提供审计跟踪和工作流状态的历史纪录
Zeebe 架构
![](https://img-blog.csdnimg.cn/img_convert/2512a6f827c87e18310b8fdd6680543c.png)
Zeebe 主要由三个部分组成
-
业务的具体执行者 Job Worker & Client,Zeebe 的接入点
-
Zeebe 核心逻辑的 Zeebe cluster
-
日志收集通 Exporter 并写入 ES
Clients & Job Workers
-
基本功能
-
部署流程
-
执行业务逻辑、启动流程实例、发布消息、激活工作、完成工作、失败的工作
-
处理操作问题、更新流程实例变量、解决错误
-
客户端应用程序可以完全独立于 Zeebe 进行扩展和缩减 - Zeebe broker 不执行任何业务逻辑。
-
嵌入微服务中以连接到 Zeebe 集群
-
客户端通过 gRPC 连接到 Zeebe 网关,使用基于 HTTP/2 的传输
-
官方支持的 Java 和 Go 客户端。 社区客户端是用其他语言创建的,包括 C#、Ruby 和 JavaScript,gRPC 能够实现跨语言的通信
Zeebe Cluster
![](https://img-blog.csdnimg.cn/img_convert/93becbd8fea22415856eb9100c228262.png)
Zeebe Cluster 是实现任务流程调度的核心,通过 Gateway 分发请求到 brokers
-
基本功能
-
分布式工作流引擎:保持工作流 process 实例的状态
-
能够水平扩展 broker 数量:实现水平扩展性并设置 Replica 实现容错
-
不实现任何业务逻辑,只进行调度和管控
-
处理客户端命令
-
存储和管理 process 流程实例的状态
-
分配 jobs 给 job worker
-
实现原理
-
由多个 Brokers 组成组成一个 cluster,每个 Broker 都具有相同的响应能效,并执行相同的任务,形成一个对等网络,避免了单点故障
-
采用 P2P 的方式去中心化,通过 Gossip protocol 发现 cluster 中当前的 broker
-
采用 多个 brokers 组成 partition
-
通过 Raft protocol 选举 partition 中的 leader
Partitions
类似 Kafka 中的 partition,Zeebe 中将 Process 分发到所有的 partition
-
基本功能
-
当部署一个 process 时,会分发给所有的 partition,通过唯一 process key 进行识别,每次执行时创建的实例,同一个实例只在一个 partition 中进行,能够保证 partition 中的顺序
-
partion 是一个持久的队列流,顺序执行操作
-
具有容错性,partion 有 leader 和 followers 组成,当 leader 无法运行时会选举出新的 leader
-
实现原理
-
通过 broker 数量,partition 数量,replication 因子,将 cluster 中 Brokers 分发到不同的 partition
-
follower 仅仅只是一份 replicaiton,并不参与 Process 实例的执行
-
每个 Broker 都有可能同时属于不同的 partition,同时充当不同 partition 中的 leader 和 follower
Process 生命周期
Process 的生命周期主要由 Instance 体现每个 Process 的工作流中每一步都会划分为 Sub-Process
-
基本内容
-
process 每次执行会生成 Instance 实例
-
支持版本控制
-
子进程实例生命周期,传递 json kv 数据 Sub-process 生命周期如下
![](https://img-blog.csdnimg.cn/img_convert/ccb0ccd9a7e90d68343ec6b080bdbb47.png)
-
下图是一个 process 例子
![](https://img-blog.csdnimg.cn/img_convert/ecce025e78455e56c22dad91bd102d2d.png)
-
包含 Order Placed, Collect Money, Fetch Items, ShipParcel, Order Delivered 子进程
rter
Zeebe 中每个 Job 的执行都会产生一串有序的记录流,clients 无法直接检测记录流,通过 Exporter,Zeebe 能够配置和加载用户代码处理导出这些记录
Exporter 提供单点入口来处理写入流中的每条记录,并导入 ES 等外部数据仓库并通过可视化工具进行查看
-
基本功能
-
提供状态变更 event stream
-
监控当前 process instances 状态
-
分析历史进程数据
-
追踪错误事件
-
数据导入 ES
Zeebe Example
-
支持通过 MQ 消息进行数据同步
-
下图展示了 Zeebe 在处理 client 时能够采用 Kafka 等消息队列传递信息
-
也可以直接调用 Client 进行处理
-
下图展示了支持 Spring Boot Worker
-
Zeebe 本身由 Java 写成,对 Spring boot 支持很好
![](https://img-blog.csdnimg.cn/img_convert/64ce843a0beac9ce06f3e469f7f2ad61.png)
-
下图展示了官方 web 应用 Operate 可视化操作目前实例 retry 等动作
-
提供了可视化的操作工具,能够快速查看当前进行中的工作流,实例个数,失败重试等
![](https://img-blog.csdnimg.cn/img_convert/0f1b242f6c2348e9a808237a4b418ac5.png)