zeebe 为微服务架构的工作流引擎

zeebe 是灵活、轻量的基于微服务架构的工作流引擎

包含以下特性：

  • 可视化的额工作流
  • 审计日志以及历史
  • 水平缩放
  • 持久化&&容错
  • 消息驱动
  • 操作容器
  • 语言无关
  • 工作流基于标准bpmn 2.0 协议

参考架构

来自官方的额一个简单workflow demo

参考资料

https://zeebe.io/
https://docs.zeebe.io/basics/client-server.html

原文地址：https://www.cnblogs.com/rongfengliang/p/10347024.html

时间： 2024-11-11 16:41:38

zeebe 为微服务架构的工作流引擎的相关文章

微服务架构

互联网保险O2O平台微服务架构设计 关于架构,笔者认为并不是越复杂越好,而是相反,简单就是硬道理也提现在这里.这也是微服务能够流行的原因,看看市场上曾经出现的服务架构:EJB.SCA.Dubbo等等,都比微服务先进,都比微服务功能完善,但它们都没有微服务这么深入民心,就是因为他们过于复杂.简单就是高科技,苹果手机据说专门有个团队研究如何能让用户更加简单的操作.大公司都是由小公司发展起来的,如果小公司在开始技术选型时感觉某个框架费时费力就不会选择,而小公司发展到大公司的过程,一般也伴随着系统不断优

微服务架构的进程间通信（IPC）

先抛出几个问题: 微服务架构的交互模式有哪些? 微服务常用的进程间通信技术有哪些? 如何处理部分请求失败? API的定义需要注意的事项有哪些 微服务的通信机制与SOA的通信机制之间的关系与区别 微服务架构的交互模式 一对一还是一对多? 一对一:每个客户端请求有一个服务实例来响应 一对多:每个客户端请求有多个服务实例来响应 同步还是异步? 同步模式:客户端请求需要服务端即时响应,甚至可能由于等待而阻塞 异步模式:客户端请求不会阻塞进程,服务端的响应可以是非即时的 一对一的交互模式有以下几种方式:

微服务架构(Microservices)

说在前面 好久没写博文了,心里痒痒(也许是换工作后,有点时间了吧).最近好像谈论微服务的人比较多,也开始学习一下,但是都有E文,看起来半懂不懂的. Martinfowler的<微服务>,也算是入门必读了.有人翻译过,但是只有一半.还是自己练练手吧. 微服务 "微服务架构"一词在过去几年里广泛的传播,它用于描述一种独立部署的软件应用设计方式.这种架构方式并没有非常准确的定义,但是在业务能力.自动部署.端对端的整合.对语言及数据的分散控制上,却有着显著特征. "微服务

微服务架构-模块迁移

对于遗留的单体应用,要进行微服务架构的改造往往比一个全新应用基于微服务架构实现更加困难.对于单体应用的微服务架构改造,最常见的方式仍然是将低耦合的模块逐步迁出.下面以一个采购系统中招投标模块迁出为例进一步思考单体应用的微服务架构改造步骤. 在整个模型中我们将模型进行简化,当迁出一个功能模块进行微服务化的时候,首先要考虑的就是对该模块进行集成架构分析,考虑该模块和外围的集成情况,其次才是考虑该模块内部的私有数据.对于招投标模块我们将模型简化来看,主要涉及到上游,下游和底层共享数据几个方面的集成,初

软件架构设计学习总结（22）：软件架构——分层架构、事件驱动架构、微内核架构、微服务架构、基于空间的架构

分层架构 (Layered Architecture) 分层架构是最常见的架构,也被称为n层架构.多年以来,许多企业和公司都在他们的项目中使用这种架构,它已经几乎成为事实标准,因此被大多数架构师.开发者和软件设计者所熟知.比如MVC. 分层架构的一个特性就是 关注分离(separation of concerns) .在层中的组件只负责本层的逻辑.组件的划分很容易让它们实现自己的角色和职责,也比较容易地开发,测试管理和维护. 我们需要这样的冗余,即使业务层没有处理业务规则,也要通过业务层来调用数

微服务架构的两大解耦利器与最佳实践

这几年,微服务架构这个术语渐成热门词汇,但它不是一个全新架构,更不是一个包治百病的架构.那么,微服务架构究竟能够解决什么问题,又带来哪些痛点? 本文将与大家谈谈这个问题,以及微服务架构的两大解耦利器配置中心和消息总线的最佳实践. 微服务架构解决的问题与带来的痛点 一 互联网高可用架构为什么要服务化? 上图是互联网典型的高可用架构,大部分公司如果没有使用微服务,正在使用这样的架构: 用户端是浏览器 browser,APP 客户端 后端入口是高可用的 nginx 集群,用于做反向代理 中间核心是高可

SOA和微服务架构的区别？

知乎用户 289 人赞同了该回答 谢多人邀请,其实前面几位的回答已经差不多了,在这里仅谈下自己的简单总结. 微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用.这些小应用之间通过服务完成交互和集成.每个小应用从前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套.在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身

（转）微服务架构 互联网保险O2O平台微服务架构设计

http://www.cnblogs.com/Leo_wl/p/5049722.html 微服务架构 互联网保险O2O平台微服务架构设计 关于架构,笔者认为并不是越复杂越好,而是相反,简单就是硬道理也提现在这里.这也是微服务能够流行的原因,看看市场上曾经出现的服务架构:EJB.SCA.Dubbo等等,都比微服务先进,都比微服务功能完善,但它们都没有微服务这么深入民心,就是因为他们过于复杂.简单就是高科技,苹果手机据说专门有个团队研究如何能让用户更加简单的操作.大公司都是由小公司发展起来的,如果小

微服务架构的核心要点和实现原理

微服务架构中职能团队的划分 传统单体架构将系统分成具有不同职责的层次,对应的项目管理也倾向于将大的团队分成不同的职能团队,主要包括:用户交互UI团队.后台业务逻辑处理团队与数据存取ORM团队.DBA团队等.每个团队只对自己分层的职责负责,并对使用方提供组件服务质量保证.如果其中一个模块化组件需要升级.更新,那么这个变更会涉及不同的分层团队,即使升级和变更的改变很小,也需要进行跨团队沟通:需求阶段需要跨团队沟通产品功能,设计阶段需要跨团队沟通设计方案,开发阶段需要跨团队沟通具体的接口定义,测试阶段