一. Zeebe是什么?
1. Zeebe介绍
Zeebe是一个用于微服务编排的开源工作流引擎。它基于BPMN2.0可定义图形化工作流 ,可使用Docker和Kubernetes进行部署,可构建来自Apache Kafka和其他消息传递平台的事件的工作流,可水平扩展处理非常高的吞吐量,可以导出用于监视和分析的工作流数据,具有很好容错能力,可无缝伸缩以处理不断增长的事务量。
Zeebe旨在解决大规模微服务编排问题,并且为实现这一目标,它提供了:
- 横向可扩展性: 不依赖外部数据库;相反,Zeebe将数据直接写入同一服务器上的文件 系统中,并且可以轻松地在计算机集群之间分布处理以提供高吞吐量。
- 容错机制: 通过易于配置的复制机制实现容错,确保Zeebe可以从机器或软件故障中恢 复,而不会造成数据丢失和最小的停机时间。
- 消息驱动架构: 所有与工作流相关的事件都被写入仅用于追加的日志。这些事件可以导 出到外部系统进行长期存储,以提供一个完整的工作流审计日志。
- 发布-订阅交互模型: 该模型使连接到Zeebe的微服务可以保持高度的控制权,同时提 供处理背压机制。
- 可视化工作流:基于标准BPMN 2.0,使技术和非技术利益相关者可以使用通用语言进 行工作流程设计协作。
- 与语言无关的客户端模型:几乎可以使用构建微服务的任何编程语言来构建Zeebe客 户端。
2. Zeebe的特性
-
Zeebe的设计考虑了大型工作流程(每秒及以后启动多达数万个新工作流程实例)。Zeebe不依赖外部数据库,而是将数据以不可变日志的形式直接存储在部署Zeebe的服务器上。这种架构是Zeebe处理高吞吐量和水平扩展能力的关键。
-
当前,Zeebe代理与外部服务之间的所有通信均由Zeebe的客户处理。Zeebe的客户端协议与编程语言无关,这意味着可以使用许多常见的编程语言轻松生成客户端。
-
与更成熟的工作流引擎(例如Camunda BPM)相比,Zeebe当前涵盖的BPMN符号更少。但是,Zeebe会定期添加对新符号的支持,最终,Zeebe将提供对工作流程自动化有意义的BPMN符号的完整介绍。
二. Zeebe解决问题及其重要性
1. Zeebe解决了什么问题
微服务架构近年来越来越受欢迎,但是微服务的松耦合,独立的部署周期却带来了巨大挑战。
微服务体系结构的核心原则是每个微服务仅负责一个业务功能。在微服务体系结构中,每个微服务仅负责仔细监视的业务功能,默认情况下却没人负责端到端工作流程。
许多微服务架构都依赖纯编排模式进行通信,在这种模式下,微服务通过在没有中央控制器的情况下将事件发布到消息传递平台并从消息传递平台使用事件来进行协作(该模型也称为“发布-订阅”或“发布-订阅”)。编排确实确实为微服务开发人员提供了一定程度的灵活性。但是,在其典型实现中,编排不提供:
1. 对业务当前状态的可见性:正在进行多少个端到端工作流实例,它们的状态是什么?在过去的24小时内,有多少个工作流实例未成功完成?为什么这些工作流程实例未成功完成?完成工作流程实例或工作流程中的特定步骤平均需要多少时间?
2.故障处理:如果作为工作流一部分的服务发生故障,谁负责处理故障?工作流的重试逻辑是什么?如果需要人工干预,我们的及时解决问题的规则是什么?
因此,微服务架构面临生产出了好的软件(在微服务级别上)但产生不良业务成果的风险。
开发团队如何在确保健壮的端到端工作流的同时获得微服务架构的好处?
这就是为什么要使用Zeebe.
2. Zeebe如何解决端到端的工作流问题
Zeebe使用户能够:
- 明确定义和建模跨多个微服务的工作流
- 详细了解工作流程的执行情况并了解存在问题的地方
- 编排微服务,以实现已定义的工作流,以确保所有工作流实例均按计划完成,即使 过程中存在问题。
使用Zeebe解决工作流程问题,第1步:了解工作流程的事件监视
回顾一下:平时我们的微服务架构
- 您的业务依赖于成功完成一个或多个长期运行的工作流程
- 这些工作流由独立开发和独立部署的微服务执行,这些微服务通过pub-sub进行通信而没有中央控制机制
- 尽管您可能了解给定微服务的性能,但对工作流的端到端运行状况以及业务的当前状态了解甚少。
Zeebe针对单个微服务的运行状况的范围,可提供了以下方面的可见性:
1.业务的当前状态:目前有多少个跨微服务工作流正在运行,它们的状态如何?
2.是否有由于错误或其他问题而“卡死”了运行中的流程?
3.我们平均的端到端流程持续时间是多少?我们在哪里遇到流程中的问题?
使用Zeebe解决工作流程问题,第2步:微服务编排
通过以下图,显示了Zeebe如何用于微服务编排
通过途中可以看到Zeebe与参与工作流的微服务直接通信。
您可以将Zeebe的工作流程编排方法视为状态机。当工作流实例执行某项任务时,Zeebe发送一条消息以通知负责的工作人员服务,然后等待工作人员完成任务。
任务完成后,工作人员服务会通知Zeebe,然后流程继续进行下一步。如果工作人员未能完成任务,则工作流将保留在当前步骤,可能会重试该任务,直到最终成功为止;如果需要人工干预,则升级为其他团队。
Zeebe将任务通知消息的创建与实际工作分离开来,这意味着Zeebe可以以最大可能的速率发送任务通知消息,而不管是否有可用于工作的工人服务。
Zeebe将任务通知排队,直到可以将其推送给工作人员为止。如果当前没有可用的工作程序服务,则工作消息将保持排队状态。如果订阅了工作者服务,则Zeebe的反压协议可确保工作者可以控制他们接收任务的速率。
这种微服务编排方法仍可提供对工作流和工作流实例的完整可见性,同时还可以确保工作流根据其定义完成,即使在途中出现故障时也是如此。
3. 为什么选择Zeebe
1. Zeebe水平缩放
Zeebe在微服务编排中需要提高吞吐量,为了处理大量的工作流实例,可能需要 跨计算机集群分发Zeebe,以满足吞吐量需求。
2. Zeebe具有容错能力并且高度可用
Zeebe允许用户在创建主题时配置复制因子。复制因子确定在其他代理上存储多 少个分区的“热备份”副本。如果一个代理宕机,另一个代理可以替换它而不 会丢失数据。由于数据是在集群中的代理之间分布的,因此Zeebe 无需外部数据 库即可提供容错能力和高可用性,直接将数据存储在部署它的服务器中的文件系统 上。Zeebe也不需要外部集群协调器,例如ZooKeeper。Zeebe完全独立且自给 自足。
3. Zeebe允许可视化地定义工作流程
Zeebe定义工作流的默认建模语言是基于BPMN 2.0的。工作流程是在视觉上定 义的,技术和非技术利益相关者都可以充分参与。尽管Zeebe对BPMN 符号的 涵盖范围不像Camunda BPM这样的更成熟的BPM平台涵盖的范围广泛,但 Zeebe路线图中包括定期添加对新符号的支持。
4. Zeebe与语言无关
当前,Zeebe用Java和Go提供了两个开箱即用的客户端。Zeebe客户端基于 gRPC,这意味着可以使用构建微服务的许多编程语言轻松生成 Zeebe客户端。
5. Zeebe是完全由消息驱动的
Zeebe代理和客户端完全通过发布-订阅进行通信,遵守松散耦合的原理,可以 实现Zeebe与参与工作流的微服务之间的异步通信。Zeebe的订阅协议包括背压 机制,以确保客户端不会因Zeebe的工作而过载。
6. Zeebe可以方便地存储用于审计事件的完整历史
Zeebe导出器使将工作流事件数据传输到存储系统变得很容易,因此可以无限 期地使用这些数据。这对于报告和可见性很重要,并且由于您所在的行业,出于监 管原因,也可能有必要。