Zeebe入门系列:1、背景与介绍

1. Zeebe背景 



是一家成立于2008年的咨询公司,总部位于德国柏林,从2010年8月就开始参与Activiti5.0的开源社区建设与共享,是当时除了Alfresco公司之外的第二大开源贡献者,提供基于Activiti5的Camunda  fox BPM产品,为其客户提供企业级的BPM实现与支持,由于理念分歧,于2012年12月宣布分裂,2013年8月29日发布Camunda 7.0.0-Final版本,产品命名为Camunda  BPM (现为Camunda  Platform 7),保留了PVM,并作了大量优化,截至2022年4月12日 Camunda Platform v7.17.0发布,每年稳定保持2个版本的迭代优化。

如前所述,Zeebe 是由Camunda公司开源的适用于人工任务、系统、设备及微服务编排的云原生工作流引擎,Camunda Platform 8于2022年4月12日发布,其核心引擎就是Zeebe,Camunda公司还有传统的开源工作流引擎Camunda Platform 7,是唯一一家同时开源2种工作流引擎的公司。

由于Activiti的宣传和中文资料较多,接触Activiti的自然就多些,实际上在国外,自从Camunda BPM 7.0.0推出后,很多客户陆续从Activit迁移到Camunda BPM了,详细资料可见QQ交流群。

                                                               

Camunda产品路线

  Camunda Platform 7与8的相同与不同

        Camunda Platform 8 产品

Camunda Platform 8 绿色部分为开源可用,其他为商业授权可用

 

一.  Zeebe是什么? 

2. Zeebe介绍

Zeebe是一个用于微服务编排的开源工作流引擎。它基于BPMN2.0可定义图形化工作流 ,可使用Docker和Kubernetes进行部署,可构建来自Apache Kafka和其他消息传递平台的事件的工作流,可水平扩展处理非常高的吞吐量,可以导出用于监视和分析的工作流数据,具有很好容错能力,可无缝伸缩以处理不断增长的事务量。

Zeebe旨在解决大规模微服务编排问题,并且为实现这一目标,它提供了:

  1. 横向可扩展性:  不依赖外部数据库;相反,Zeebe将数据直接写入同一服务器上的文件 系统中,并且可以轻松地在计算机集群之间分布处理以提供高吞吐量。
  2. 容错机制:  通过易于配置的复制机制实现容错,确保Zeebe可以从机器或软件故障中恢      复,而不会造成数据丢失和最小的停机时间。
  3. 消息驱动架构:  所有与工作流相关的事件都被写入仅用于追加的日志。这些事件可以导 出到外部系统进行长期存储,以提供一个完整的工作流审计日志。
  4. 发布-订阅交互模型:  该模型使连接到Zeebe的微服务可以保持高度的控制权,同时提 供处理背压机制。
  5. 可视化工作流:基于标准BPMN 2.0,使技术和非技术利益相关者可以使用通用语言进 行工作流程设计协作。
  6. 与语言无关的客户端模型:几乎可以使用构建微服务的任何编程语言来构建Zeebe客 户端。

Zeebe架构图 

3. Zeebe的特性

  1. Zeebe的设计考虑了大型工作流程(每秒及以后启动多达数万个新工作流程实例)。Zeebe不依赖外部数据库,而是将数据以不可变日志的形式直接存储在部署Zeebe的服务器上。这种架构是Zeebe处理高吞吐量和水平扩展能力的关键。

  2. 当前,Zeebe代理与外部服务之间的所有通信均由Zeebe的客户处理。Zeebe的客户端协议与编程语言无关,这意味着可以使用许多常见的编程语言轻松生成客户端。

  3. 与更成熟的工作流引擎(例如Camunda BPM)相比,Zeebe当前涵盖的BPMN符号更少。但是,Zeebe会定期添加对新符号的支持,最终,Zeebe将提供对工作流程自动化有意义的BPMN符号的完整介绍。

二. Zeebe解决问题及其重要性

1. Zeebe解决了什么问题

微服务架构近年来越来越受欢迎,但是微服务的松耦合,独立的部署周期却带来了巨大挑战。

微服务体系结构的核心原则是每个微服务仅负责一个业务功能。在微服务体系结构中,每个微服务仅负责仔细监视的业务功能,默认情况下却没人负责端到端工作流程。

许多微服务架构都依赖纯编排模式进行通信,在这种模式下,微服务通过在没有中央控制器的情况下将事件发布到消息传递平台并从消息传递平台使用事件来进行协作(该模型也称为“发布-订阅”或“发布-订阅”)。编排确实确实为微服务开发人员提供了一定程度的灵活性。但是,在其典型实现中,编排不提供:

1. 对业务当前状态的可见性:正在进行多少个端到端工作流实例,它们的状态是什么?在过去的24小时内,有多少个工作流实例未成功完成?为什么这些工作流程实例未成功完成?完成工作流程实例或工作流程中的特定步骤平均需要多少时间?

2.故障处理:如果作为工作流一部分的服务发生故障,谁负责处理故障?工作流的重试逻辑是什么?如果需要人工干预,我们的及时解决问题的规则是什么?

因此,微服务架构面临生产出了好的软件(在微服务级别上)但产生不良业务成果的风险。

开发团队如何在确保健壮的端到端工作流的同时获得微服务架构的好处?

这就是为什么要使用Zeebe.

2. Zeebe如何解决端到端的工作流问题

Zeebe使用户能够:

  1. 明确定义和建模跨多个微服务的工作流
  2. 详细了解工作流程的执行情况并了解存在问题的地方
  3. 编排微服务,以实现已定义的工作流,以确保所有工作流实例均按计划完成,即使 过程中存在问题。

使用Zeebe解决工作流程问题,第1步:了解工作流程的事件监视

回顾一下:平时我们的微服务架构

  1. 您的业务依赖于成功完成一个或多个长期运行的工作流程
  2. 这些工作流由独立开发和独立部署的微服务执行,这些微服务通过pub-sub进行通信而没有中央控制机制
  3. 尽管您可能了解给定微服务的性能,但对工作流的端到端运行状况以及业务的当前状态了解甚少。

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导出器使将工作流事件数据传输到存储系统变得很容易,因此可以无限 期地使用这些数据。这对于报告和可见性很重要,并且由于您所在的行业,出于监 管原因,也可能有必要。

 

 

附:参考链接

Zeebe官方仓库:https://github.com/camunda-cloud/zeebe

Zeebe官方文档:https://docs.camunda.io/docs/product-manuals/zeebe/zeebe-overview

Zeebe优秀集合:https://github.com/camunda-community-hub/awesome-camunda-platform-8

Zeebe问答社区:https://forum.camunda.io/

交流群:

 

  • 2
    点赞
  • 25
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Zeebe是一款基于流程引擎的分布式工作流引擎,而Spring Boot是一个用于创建独立的、生产级别的Spring应用程序的框架。将Zeebe与Spring Boot集成可以使我们更方便地在应用程序中使用工作流引擎。 要在Spring Boot应用程序中集成Zeebe,可以按照以下步骤进行操作: 1. 添加依赖:在项目的pom.xml文件中添加Zeebe和Spring Boot的相关依赖。例如,可以添加以下依赖: ```xml <dependency> <groupId>io.camunda.zeebe</g> <artifactId>zeebe-client-java</artifactId> <version>.2.0</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> ``` 2. 配置Zeebe连接:在Spring Boot应用程序的配置文件(如application.properties或application.yml)中配置Zeebe连接信息,包括Zeebe Broker的地址和端口等。例如: ```yaml zeebe.client.broker.contactPoint=127.0.0.1:26500 ``` 3. 创建Zeebe客户端:在Spring Boot应用程序中创建Zeebe客户端实例,以便与Zeebe Broker进行通信。可以使用@Autowired注解将Zeebe客户端注入到需要使用的类中。 4. 使用Zeebe工作流:通过Zeebe客户端,可以创建、部署和执行工作流实例。可以使用Zeebe提供的API来定义工作流模型、任务和流程变量等。 5. 处理工作流事件:在Spring Boot应用程序中,可以使用Zeebe提供的监听器来处理工作流事件,例如任务完成、工作流实例启动等。可以通过编写相应的处理逻辑来响应这些事件。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值