读书笔记:流程自动化实战, 系统架构和软件开发视角

前言

流程自动化工具与技术

不过流程自动化有其独特的特征和需求,有些软件专门为了解决这些问题而设计。分析师依此定义了与流程自动化相关的细分软件市场:数字流程自动化( DPA)、智能业务流程管理套件(iBPMS)、 低代码平台、机器人流程自动化(RPA)、微服务编排、流程编排、流程监控、流程挖掘、决策支持和自动化。

架构师总有实现方案

如果你无法展示具体的示例代码,只讨论概念,那乐趣会减少一半。可运行的代码迫使你变得精确,去思考那些概念层面可能忽略的细节——最重要的是,它通常能更好地解释概念。我个人很喜欢一个座右铭:“架构师总有实现方案。”

配套网站和示例代码

https://processautomationbook.com/
https://bpmn.io/

第1章 简介

  • 流程自动化是什么
  • 流程自动化的具体技术难点。
  • 工作流引擎的作用及其重要性。

1.1 流程自动化

本质上,流程(或工作流)仅指为实现预期结果而需要执行的一系列任务。
流程自动化有不同的级别。主要区别在于是人工控制流程还是计算机控制流程。
任务间控制流的自动化与任务本身的自动化,两者有重要的区别。

  • 控制流的自动化。假如由人来完成任务,则计算机控制流程,并且在必要时让人参与进来。
  • 任务的自动化。任务本身是自动化的。在前面的例子中,就是将烹饪的任务交由机器完成。

如果你结合使用控制流的自动化和任务的自动化,则可以实现完全流程自动化,也称为直通式流程(STP)。

推动自动化的具体原因如下:

  • 重复次数多。只有当潜在的收益超过了开发成本时,在自动化中投人的努力才是值得的。具有超高执行量的流程是进行自动化的候选者。
  • 标准化。流程需要结构化和可重复,以便于自动化。虽然在流程自动化中实现一定程度的变化和灵活性是可行的,但它增加了自动化的开销,并削弱了一些优势。
  • 合规的一致性。可审计性,甚至规定在授权时要以可重复和可修订的方式记录步骤。
  • 质量需求。你可以承诺为用户提供以特定的速度交货的订单。
  • 信息丰富。包含大量数字化信息的流程更适合自动化。

利用Microsoft Office、Slack或Zapier等工具来自动化某些基于事件触发的任务。

1.2 荒野大集成

下面是荒野大集成的一些特点:

  • 通过数据库集成。服务直接访问共他服务的数据库来进行通信,其他服务通常并不会被通知。
  • 简单的点对点集成。两个组件之间会直接通信,通常是基于REST、SOAP或消息协议,但没有充分描述远程通信的所有内容。
  • 数据库触发器。每当你向数据库写人内容时,数据库都会再调用其他逻辑。
  • 脆弱的工具链。

1.3 工作流引擎和可执行流程模型

蓝图是以特定建模语言描述的流程定义。
如果你下定决心要整理荒野大集成的项目,也许还能复用大部分代码,只需利用工作流引擎进行状态处理和调度即可。

1.4 一个业务场景

流程建模语言(BPMN)都是通用的。

1.5 长期运行的流程

从另一个视角看每当逻辑跨越边界,就需要长期运行的行为。边界有很多不同的含义。
如果你调用其他组件或资源,就跨越了技术事务的边界。如果你的流程包含了人,则跨越了可自动化任务与不可自动化任务之间的边界。

1.6 业务流程、集成流程和工作流

1.7 业务-IT协作

遗憾的是,不同的角色表达和理解事物的方式往往不同。
将业务流程作为讨论的中心是有益的。它使得大家在大背景下更容易理解需求,同时避
免了在单独讨论功能时可能产生的误解。

1.8 业务驱动及流程自动化的价值

组织通常将流程自动化应用于:

  • 构建更好的用户体验。
  • 快速跟进市场(使用已修改或全新的流程、产品或商业模式)。
  • 提高业务灵活性。
  • 降低运营成本。

一些商业模式甚至依赖于流程完全自动化的可能性,这对于公司的盈利、提供可预期的
快速反馈或者扩大业务规模至关重要。

1.9 当代流程自动化工具

1.9.1 流程自动化简史

当时的想法是将功能分解为服务,以或多或少标准化的方式提供给企业。

低代码的局限性

低代码(是什么?)方案需要非常重的工具,才能让非开发者通过拖放预置的元素来构建流程。

缺点:

  • 你无法使用行业中的最佳实践来开发软件,例如,实现自动化测试、集成你需要的框架、完善用户界面。
  • 开源或者社区提供的知识和工具改进,你通常是用不了的。
  • 这些工具常常很重,很难在现代的虚拟化或云原生架构上运行。

与其用低代码流程自动化取代软件开发,不如将软件开发和流程自动化结合起来!

1.9.2 Camunda的故事

也是在当时,我们合作开发了业务流程模型和标记法( Business
Process Model and Notation, BPMN)标准,该标准定义了一种可视化并且可直接执行的流程建模语言。
从技术上讲,Camunda 工作流引擎的工程实现是2013年的工程实现。它本质上是一个用Java构建的库,使用了关系数据库来存储状态。这个引擎可以嵌入你自己的Java服务中,也可以独立运行,对外提供REST API。当然了,我们还提供了一些额外的工具来建模或运维流程。

1.10 结论

第一部分 基础知识

第2章 工作流引擎和流程解决方案

2.1 工作流引擎

2.1.1 核心功能

工作流引擎技术层面的核心功能如下:

  • 持久状态/持久化。引擎会持续追踪所有正在运行的流程实例的当前状态和历史审计数据。
  • 调度。必须有一个调度机制,使引擎在需要执行某个任务时能够及时响应。
  • 版本化。大多数工作流引擎支持多个版本的流程定义并行存在。

2.1.2 工作流平台的其他功能

除了核心功能外,大多数工作流引擎还提供了些附加功能。 优秀的工具会将这些功能设计成可选的或者插件化的,让你既可以用上超精简的工作流引擎,也可以用上一些额外的工具。当你看到使用这些功能的需求时,也能逐步将其添加进来。

常见的附加功能如下。

  • 可视化。切实看到流程是如何实现的,既有利于沟通,也有利于不同角色的参与者理解当前流程,包括开发者( “我去年怎么做的这个?")、运维(“当时为什么要这么做?")和业务利益相关者(“现在这个流程是怎么实现的?能不能改?")
  • 审计数据。工作流引擎会记录大量关于当下事件的审计数据,包括时间戳(例如,流程实例何时启动和何时结束)。

2.1.3 架构

使用工作流引擎有两类基本的方法可供选择,

  • 将工作流引擎作为单独的服务来运行,也就是说你的业务应用程序与工作流引擎需要进行远程通信。
  • 将工作流引擎当作库嵌人服务,也就是作为你的业务应用程序的部分运行。

2.2 流程解决方案
2.3 一个可执行的示例

2.4 服务、流程和工作流引擎

服务、工作流引擎、流程定义和流程实例之间的关系是什么?
如果你以服务的形式启动工作流引擎,则可以在这个工作流引擎上:部署许多流程定义。对于每个流程定义,你可以启动任意个流程实例。你还可以让其他服务或微服务调用这个工作流引擎。

flowchart TD     A1[订单履约服务] --> R1     A2[订单取消服务] --> R1[为“订单履约”团队服务的工作流引擎(一个工作流引擎能对接多个服务)] --一个工作流引擎能处理多个流程定义--> Def     subgraph Def[流程定义:每个流程定义都有多个实例]     D1[订单履约流程]     D2[订单取消流程]     D3[订单查询流程]     end

2.5 项目生命周期中常用的工作流工具

2.5.2 协作工具

在协作工具实用的功能中有一个很好的例子,就是可以把图表分享给别人,让他们能够在上面评论。

2.5.4 任务清单应用

流程模型中是可以引入一些需要人工处理的任务的。当需要工作人员进行操作时,必须要有一些机制能够通知他们。

2.6 结论

第3章 开发流程解决方案

3.1 BPMN

对象管理组织(Object Management Group)的网站
formal-13-12-09

3.1.2 token:控制流的实现

你可以将每个流程实例当作在流程模型中运行的token。流程启动时,在开始事件处生成一个token。每完成一步, 它都会沿着流程路径流向下一个任务。当token到达结束事件时,流程实例的生命周期就到达了尾声。
你可以将token类比成路上行驶的汽车。在每个十字路口,司机必须决定要继续直行,还是左转右转。道路系统可以对应为流程模型,车辆所选的任意条具体的路径可以类比成流程实例。

3.1.3 顺序流:控制执行流

BPMN顺序流( sequence flow)定义了流程中每一个步骤发生的顺序。在BPMN的可视化定义中,顺序流是两个节点的连线,箭头的方向体现了它们的执行顺序。

3.1.4 任务:工作单元

在BPMN流程中,任务是一个原子的工作单元。每当token到达任务的位置时,token 都会停下,直到任务完成。之后,它才会沿着顺序流流出。
任务粒度如何选择取决于建模流程的人。例如,处理订单的动作可以建模为一个任务,也可以分为支付确认、提取货物和发出货物三个独立任务。
通常最困难的部分是定义你的任务及其顺序。一旦这些清晰了,你可能会先从人工任务开始制作原型(一个只能“点点点”的模型),也可能在生产环境中发布第一个迭代。

3.1.5 网关:流程方向盘

并行网关为了激活多个顺序流会生成新的token。
流程是与等待相关的,所以” 并行”的含义基本上是说,你可以在某条路径等待时在另一条路径上做些什么。

3.2 关联流程模型与代码实现

关于如何关联流程模型与代码实现,但添加这些逻辑有三种常见的思路:订阅流程、引用代码和使用预建的连接器。

3.2.1 发布/订阅流程

消息代理提供队列。消息发送方可以将消息发布到队列,接收方可以订阅队列,然后就可以接收到消息。接收方无须了解发送方。

3.2.4 模型还是代码

细节太多的模型不仅变得难以维护,而且图形化的价值也不复存在。
以下三个问题可以帮助你决定放在哪里。

你需要在哪里(隐式地)停下

参与者需要定期讨论什么

你需要定期与其他参与者讨论,过去的经验告诉了我一条重要的规则:所有讨论的内容都应该放在图形模型中。
你可能还想发掘不同的人群对哪些关键效能指标(KPI)感兴趣。

什么在跨越边界

如果你想调用两个软件或服务,而这两个软件又不能在一个技术事务中, 这时你应该将这两个调用分离到它们自己独立的任务中。

3.3 测试流程

3.4 流程解决方案的版本管理

系统中总是有正在运行的流程实例,如果你要更新流程模型,就必须直面这样的状况。
因此工作流引擎提供了版本管理功能:

  • 流程模型修改后一旦部署,就会创建一个新版本。
  • 活跃的流程实例将继续以它们启动时的版本运行。
  • 新创建的流程实例将使用新版本的流程模型运行(除非你明确指定启动旧版本)。

多版本并行运行

胶水代码和数据定义的版本化

或者,你可以修改代码,确认有新字段时才使用它。虽然这会让代码更复杂,但却有一个明显的优势:如果你将流程实例迁移到新版本,它什么都不需要做就能正常运行。缺点是,随着时间的推移会积累无效代码,为了避免这样,你应该定期检查是否有任何版本依然需要这些代码,如果不再需要,就进行清理。

3.5 结论

第4章 万物皆可编排

来看看流程自动化可以为你解决哪些问题。工作流引擎是可以编排任何事物的,

  • 软件组件
  • 决策
  • RPA机器人及物理设备

什么是编排(orchestration)。 在云原生社区中,编排通常指的是容器管理,是Kubernetes等工具所做的工作。在流程自动化领域,编排实际上是指协调配合(coordination) 。

4.1 编排软件

4.1.2 微服务

这样你就可以自行决定如何实现或修改服务(只要你不破坏API)。不必要求别人为你做任何事情,也不必踏上发布列车。团队能够快速交付修改,在事实上提高了行动力,团队成员会因为掌控着服务而真正感到被赋予了权利。

4.1.4 模块化的单体架构

工作流引擎可以作为依赖库嵌人你的单体架构中。流程定义只是所有源代码中的一个附加资源。

4.1.5 解构单体架构

4.2 编排决策

这个领域名为决策自动化。其核心组件是决策引擎,你可能发现这和工作流引擎有一些相似之处, 但不同的是决策不会长期运行,决策可以在一个原子步骤中进行。

4.2.1 DMN

决策也有一个全球通用的标准:决策模型和标记法(DMN)。
让我们简单看看DMN能做什么。我想在本书中重点阐述两个概念:

  • 决策表。表格(各种情况类别与决策结果的汇总表)非常适合表达决策逻辑和业务规则。
  • 表达式语言。所以DMN定义了FEEL (Friendly-Enough Expression Language)。

但使用FEEL也能创建更复杂的逻辑表达式。下面这些表达式都是可行的:

Party.Date < date( "2021-01-01")
Party.NumberOfGuests in [25..100]
not( Party.Cancelled )

在实际存储时,DMN决策表存储为XML文件,下面是伪代码实现的例子:

input = Map .putValue("paymentType", "invoice").putValue("customerRegionScore", 34) .putValue("monthlyPayment", 30);decisionDefinition = dmnEngine.parseDecision('automaticProcessing.dmn')
output = dmnEngine.evaluateDecision(decisionDefinition, input)output.get('manualCheckNecessary')

4.3 编排人

4.3.1 任务分配

一个重要的问题是某个任务应该由谁执行。
你可以对候选人和执行人进行区分。任何一个候选人都可以被分配任务。在工作开始的时候会声明第一一个候选人是执行人,之后任务才会进入个人清单中。

4.4 编排RPA机器人

RPA工具能自动控制现有的图形化用户界面。其核心主题是屏幕抓取、图像处理、OCR 和机器人操作GUI。

当然,机器人总是比真正的API调用更加脆弱,因此无论何时,你都应该优先使用API。但现实世界总是充满了阻碍。系统可能井不提供你需要的API。

4.5 编排物理设备和其他事物
4.6 结论

第5章 选择工作流引擎和BPMN

5.1 其他实现方式的局限性

5.1.2 批处理

在这个例子中,客户在线请求更新信用额度。此请求不会立即被处理(一般叫在线处理),而是在队列中等到下一次批处理时运行。触发后,这一批次中 正在等待的所有事项都会被立刻处理。
批处理在流程自动化方面的缺陷:

  • 批处理增加了每个独立工作单元的处理时间,拉长了流程周期。
  • 流程不可见,因为它隐藏在一个个批处理作业的交替中。

5.1.3 数据流水线和流式处理

流式数据(data streaming)背后的思想是从静态数
据转向动态数据。
市场上的一些工具指的是data pipeline (数据流水线)或data flow,而不是data stream,而另一些工具是指事件流也不是数据流。

缺陷:
流程实例并不真实存在,因为只有数据流经队列。你无法审视整个流程的真实运行方式。最近我听说了尼尔.福特发明的弹球机架构(pinball machine arhitcture)一词,我觉得他抓住了这个架构的精髓。
你修改流程的能力也有限,主要是因为修改你不理解的内容确实很难。

常见的工具只允许创建无环模型,也就是说你无法实现回环(loop back)。通常,在许多流程中你都会操作循环。例如,用户可能会修改订单,可能会撒销付款.叉车可能会略过漂亮的小包爽。现实世界可能会发生很多事情,令你不得不回到流程的开始阶段。

5.1.4 actor模型

actor 模型是处理并发计算的一种方法。 它基于消息传递:基本概念是有一个单一职责的软件组件,即所谓的actor。actor之间以及actor 和自己只能以消息的方式通信。由于并行处理通常被限制在单一一的actor中,因此你不仅可以使用队列,还可以让整个系统进行扩缩容。

缺陷:

  • 因为没有建模语言,所以无法支持长期运行所需的那种模式。
  • 流程逻辑隐藏在源代码中,不可见,这使得所有关心流程的人都难以理解流程。

5.1.5 有状态函数

缺陷:

  • 因为没有建模语言,所以无法表达长期运行所需的那种模式。
  • 流程逻辑没有图形化的形式,这让业务人员、开发人员和运维人员之间很难协作。
  • 调度和版本控制相关的支持非常有限。

5.2 流程建模语言

总的来说,反对XML的两个观点(它太古老,并且很难合井)经不起推敲。
不过让我们退后一步,谈谈在选择流程建模语言时审视真正重要的方面:

  • 这种语言支持什么样的行为?这个问题定义了语言整体的成熟度,决定了你选择的语言是否会遇到无法建模的情况。
  • 图形化展示给表格带来了什么价值?应该使用基于图形化的建模语言吗,还是说基于文本的语言就足够了?

5.2.1 工作流范式

为了判断流程建模语言是否提供了你所需的功能,可以参考Workflow Patterns主导定义的范式,他们主导的研究已经完成:
对于工作流语言或业务建模语言需要支持的各种方向(控制流、数据、资源和异常处理),这个网站都提供了全面的检查项,可用于检查某个工作流语下和工作流系统是否适合某一项目。

工作流范式及BPMN中的映射
http://www.workflowpatterns.com/patterns/

范式名称 BPMN元素 描述
顺序流(sequence) A->B 一个任务在流程中的另一个任务完成后启动
并行分支(parallel split) <+> 一个分支分为两个或多个并行的分支,
每个分支并发执行
同步(synchronization) <+> 两个或多个输入分支汇聚为一个后续
分支,当所有的输入分支都到达时,
线程才会将其传递给后续分支
排他选择(exclusive choice) <×> 分支分为两个或多个不同的分支,当
输入分支到达时,控制线程会根据某
种传出分支选择机制立刻选出一个分
支进行后续操作
简单汇聚(simple merge) <×> 将两个或多个分支汇聚到一个后续分
支中,输入分支中的任意一个到达都
会触发控制线程的向后传递

5.2.2 图形流程可视化的优势

图形流程可视化的好处很明显:模型的可见性和可理解性,以及和不同干
系人讨论时的易用性。
运营人员也能利用图形模型,例如可以在流程实例中标记遇到的问题。
图形模型能在开发者之间进行对齐。解释某个流程、算法或其他复杂软件实现。他们真的给你看了一堵写满代码的墙吗?他们带你浏览了一份长篇累牍的文档吗?还是说,他们在白板上画了一幅图来解释核心概念? 我打赌是后者。
BPMN等语言的核心元素是一些方框和箭头,大多数人都能直观地理解它
们。
实现图形流程可视化有两种方法。最简单的方法是像BPMN那样创建一个包含图形信息的流程模型。记住,专有的符号限制了可视化在与其他角色协作时的价值。
另一种方法是基于流程模型自动生成可视化内容,这种模型甚至只能以文本形式使用。

5.2.3 纯文本流程建模方案

最常见的方法是使用JSON或YAML来定义流程模型:

{"name": "sample-workflow","version": 1,"tasks": [{"name": "task_1","type": "SIMPLE"},{"name": "someDecision","type": "DECISION","decisionCases": {

5.2.4 关于图形化建模的常见问题

一些开发者不太喜欢图形化建模语言。下面是一些常见问题的概要:

  • 其中隐藏着魔法。由于图形化建模工具通常将某些逻辑和配置隐藏在属性面板或向导中,不知道这些工具存在的用户会感觉他们遗漏了关键的事物。另一个可行的策略是在开始时使用代码对流程进行建模,并在流程模型变得更加复杂后立刻切换到图形化建模方法。

另一个担忧是,一旦你拥有了可理解的图形模型,业务利益相关者能随时干预开发过程,并且希望加入与解决方案设计有关的所有对话。这主要与项目中的不同角色互相尊重有关。

5.2.5 图形化与文本化

请记住,只在流程模型中以图形方式表达任务本身的顺序,然后将其他逻辑的代码与它关联。这样在两个方向上,你都能获得最佳的体验。

5.3 区块链上的流程自动化

剧透警告:对于公司内部流程的自动化来说,它不会有太大影响。它只影响多方合作。
这是一个无解的情况,我不想在拿到汽车的产权凭证之前转账,经销商也不想在收到钱之前发送产权凭证。
与互不信任的合作伙伴做生意是区块链方案的最佳使用场景。在这种情况下,解决信任缺失问题的经典方法是引入值得信赖的第三方,如银行、公证人或一些专门服务。
智能合约能让汽车购买流程的公共部分自动化——只限于双方都达成一致的部分。

5.4 结论

第二部分 企业级流程自动化

如果你的组织非常成功,就会有规模化的需求。为了更快地开发出更多功能,企业需要增加开发团队。为了能顺利地扩张团队,就需要将服务拆分并分配给各个团队。
但所有的这些用户都不关心,用户只关心端到端的业务流程(比如,尽快发货的订单)。

第6章 解决方案架构

6.1 何时使用工作流引擎

quadrantCharttitle 工作流引擎带来的价值只要回报超过投入就是值得的x-axis "低可见性价值" --> "高可见性价值"y-axis "低长期运行能力价值" --> "高长期运行能力价值"quadrant-1 "流程编排,业务交易,saga"quadrant-2 "集成模式,解决远程通信的挑战"quadrant-3 " "quadrant-4 "图形化编程"

工作流引擎有两个主要的优势:它为你的应用程序或服务增加了长期运行的能力,井且使你的流程逻辑可视化。
一旦价值(回报)超过引人工作流引擎的努力(投人), 工作流引擎就会对你的架构产生积极影响。确切的阈值很大程度上取决于所选工具引入的难易。我推测,随着工具变得越来越轻量级或者直接作为托管服务提供,引人的难度将在未来几年进一步下降。
也有一些使用方法没什么意义。例如,使用BPMN进行图形化编程,也就是说,你只是简单地用图形模型表达代码逻辑,而不是控制状态或者与其他角色进行协作。

6.2 架构权衡

6.2.1 运行工作流引擎

第一个也是最重要的问题是:你如何运行工作流引擎本身?

  1. 确保你选择的引擎适合你的现状。
  2. 你还需要了解工具的灵活性程度。

6.3 评估工作流引擎

最重要的是工具要符合本书中使用的定义,即它们可以处理持久状态以实现长期运行的流程,我把它们分类为:

  • 开发者友好的工作流引擎或工作流自动化平台(例如 Camunda),本书对这类工具进行了非常详细的讨论。
  • 托管的编排工具或工作流引擎,例如AWS Step Functions或Camunda Cloud。
  • 提供开源代码的自研编排工具和工作流引擎(例如Netflix Conductor)。 这些开源项目接近轻量级工作流引擎,但它们通常很难修改,并且没有任何保障。
  • BPM套件(例如Pega)。
  • RPA工具(例如UiPath)。
  • 低代码平台(例如Zapier,其目标用户希望在不需要任何软件开发的情况下在类似Office的工作流内自动化任务。

其他工作流工具:

  • 数据流水线工具(例如Apache Airflow)能以图形化方式建模数据流水线。
  • 集成工具(例如Apache Camel)能很好地解决集成问题。

最后,有一些类别的工具属于流程自动化领域,但更侧重于可见性方向。例如:

  • 分布式追踪工具(例如Jaeger)能可视化请求如何在技术层面流过系统。
  • 流程挖掘工具(例如Celoni) 可以帮你了解遗留系统是如何实现的。

评估标准包括:

  • 集成的可能性。如何关联流程模型与代码?能使用自己选择的编程语言吗?
  • 部署选项和支持的环境。引擎本身如何运行?
  • 工具。它是否拥有你需要的所有工具?
  • 流程建模语言。支持BPMN吗?
  • 许可证和支持。你能访问源代码吗(以防万一)?
    6.4 结论

第7章 自治、边界和隔离

7.1 高内聚低耦合

正如Sam Newman在他的Monolith to Microservices (O'Reilly) 一书中所说,” 需要起修改的代码,就要放在一
起。”其理念就是,业务功能预期中的一个变更(理想情况下)仅应该更改一个组件。
Sam Newman定义的4种类型:

  • 实现耦合。如果有别的组件使用了你组件内部的实现知识你将遇到实现期合,一个非常常见的例子是,若另一个组件会查询你的数数据库表,那么之后你就很难修改这个表结构。
  • 时间耦合。在分布式系统中的同步通信中,你依赖于对端服务的可用性。这就是时间耦合。
  • 部署耦合。为了运行软件,你必须构建一个部署单元,其中可能会包含其他的库、资源或流程模型。即使大多数制品保持不变,部署单元也必须整体重新部署。部署耦合的另一个例子是发布列车(release train)。
  • 领城耦合。在为最终用户创建有意义的业务功能时,组件之间的一些耦合是不可避免的。

7.2 领域驱动设计、限界上下文和服务

基本概念是,你需要对任何模型界定清晰的边界,使其集中和统一。这使模型更有可能正确且有效。

DDD着重确保术语在单个限界上下文中是统一的,即使它们在不同上下文中可能表示不同的事物。
另一个例子是消费者。大多数上下文都与这个概念相关,但它们着重于不同的方面:在订单履约中只需要知道消费者的身份,在发货时只需要地址,在支付时只需要知道支付
的详细信息。因此,不同的上下文可能对消费者和订单有不同的定义,即使它们使用了相同的术语。

7.3 边界和业务流程

但我为什么要在流程自动化的书中写这些?好问题!上下文和边界极大地影响了你的业务流程设计,反过来说也是一样,原因如下:

  • 许多端到端的业务流程在其生命周期内会触及多个上下文。
  • 建模和讨论业务流程,特别是在端到端层级上,可以帮助你发现边界的踪迹。
  • 在上下文中使用工作流引擎,能让你看到许多问题其实具有长期运行的特性。

7.3.1 维护边界,避免单体架构流程

Real-Life BPMN
如何划分事物,其本质是如果出现问题应该归咎于谁。划分服务表达了责任和问责的本质。

7.3.2 加强对职责的理解

你必须思考组织中每个服务的业务职责。其中最重要的问题是:

  • 这个服务负责的业务产出是什么?
  • 它需要保证哪些SLA ?

7.4 流程间通信如何跨越边界

流程间通信有两个基本选项:

  • 调用活动。使用BPMN的结构以利用工作流引擎的功能调用其他流程。
  • API调用。向另一个服务发起普通的API调用,调用的服务在内部启动-个流程实例。

7.5 分散式工作流工具
7.6 结论

第8章 平衡编排与编制

微服务的兴起与事件驱动架构(event-driven architecture)相关。在这种架构中,每当有实质性的事情发生时,服务就会发出(emit) 事件,其他服务可能会对这些事件做出响应。这就是编制。

8.1 事件驱动系统

在事件驱动的替代方案中,库存服务将库存商品数量的任何变更都作为事件发布。结算服务可以监听这些事件,并使用这些信息计算和存储库存商品的剩余量。这避免了时间偶合,甚至还为库存服务分散了压力。

8.1.2 事件链

支付服务可以监听结算服务发出的下单事件,收到后处理每个订单的支付结果。处理完支付后会发出收到付款事件,而库存服务监听这个事件。
但这个场景有所不同,事件订阅之间存在某种关系,从而导致了事件链的产生。

缺乏可见性

事件散落在各个代码库中,因此你必须对所有的代码库进行推敲才能了解整个系统。

8.2 编排和编制的对比

8.2.1 命令简介

回顾一下:事件是已发生的事情,是事实。组件A发布事件来通知所有人,但它对这个事件产生的影响没有任何期望。组件B决定是否对这个事件做出反应。
与此相对地,组件A也可以向组件B发送命令。这表示A想让B做些什么,有一个明确的意图,B不能轻易忽略这个命令。

8.2.3 术语和定义

  • 命令驱动通信=编排
  • 事件驱动通信=编制

8.2.5 依赖的方向

两个服务之间每增加一次通信都会增加 定程度的期合。 但这里有一个很有趣的点,你可以选择依赖的方向,以此来决定哪些组件之间产生耦合。
当服务监听事件时,作为接收方与这事件“领城耦合"。或者说它知道要在哪个通道接受这个事件,知道这个事件的含义,以及可能会有的附加数据是什么结构。依赖的方向是从接收方到发送方。正如你在本章前面所看到的,并非在所有情况下都是好选择。
与事件相对的,一个服务还可以向另一个服务发送命令。为此,发送方必须知道命令的含义,要发送到哪个通道,以及可能会有的附加数据是什么。依赖的方向是从发送方到接收方,发送方与接收方“ 领域耦合”。

8.3 寻找恰当的平衡

8.3.1 选择使用命令还是事件

如果一个事件被忽略,导致组件遗漏了一件事,这种情况是可接受的吗?这个问题是个不错的试金石。如果回答是,那么它就真的是一个事件:如果回答不是,那你面对的可能是一条命令。

8.3.3 设计职责

在设计通信链路时,你需要充分考虑每个组件的职责。在发送方无须对接下来发生的事情负责的情况下,应该使用事件。在发送方需要确认某些事情会发生的时候,应该使用命令。
如果你忽视了职责的划分,最终会发现团队无法控制所要负责的范围。这会导致团队相互指责,情绪沮丧。
如果你没有正确设计职责,将构建出需要团队之间大量讨论和协作的系统,因为你通常不得不一起更改多个部分。 ^1b708a

8.4 澄清常见的误解

8.4.1 命令不需要同步通信

命令(及事件)独立于通信协议。
重要的是要理解,时间耦合是由同步通信本身产生的,而不是由选择使用命令产生的。

8.4.2 编排并不一定是集中式的

编排只是意味着指挥(或协调)另一个组件。 每个组件都可以做到这一点,这不需要拥有一个集中式的编排器。

8.5 工作流引擎的作用
8.6 结论

第9章 工作流引擎与集成挑战

9.1 服务间调用的通信模式

9.1.1 同步请求/响应

正如Peter Deutsch及Sun Microsystems公司的其他人提出的分布式计算谬误中所说的,远程通信本质上是不可靠的。

9.1.1 异步请求/响应

假设有这样一个业务需求,你的服务需要等待某些请求的答复才能真正继续。而这个响应过程可能需要一定的时间,并且是异步送达的。

--- title: BPMN处理异步通信并管理好超时 --- stateDiagram-v2发送请求 --> 消息系统消息系统 --> 等待响应NamedComposite: 工作流引擎state NamedComposite {[*] --> 发送请求发送请求 --> 等待响应等待响应 --> [*]等待响应 --> 执行B计划: 超时执行B计划 --> [*]}

为了支持异步通信,工作流引擎提供了一些机制来寻找处于等待中对应的流程实例。假设实例发出了一条消息来做支付确认,其中包含了一个事务ID。当响应到达时也会带有这个事务ID,工作流引擎就能够依靠ID识别正在等待这个响应的实例。

9.1.4 聚合消息

聚合器:
使用一个有状态的过滤器(聚合器)来收集和存储单条消息,直到收到完整的相关消息集。然后,聚合器会发布一条从单个消息中提炼出来的消息。

9.1.5 毒丸与死信

毒丸消息( poisoned message)。当前端出现错误,把一些破损的数据放入该消息,使消息“带毒”,你的服务在处理这条消息时就会抛出异常。
你无法将此异常交给任何客户端,因此消息系统必须处理它。默认的处理方式是给接收端重发消息,但这没什么帮助,只会增加负载。在设定的重试次数过后,消息系统一般
会将其放入死信队列(Dead Letter Queue, DLQ)。
使用工作流引擎,一个失败的流程实例会给你提供很多上下文数据,例如它从哪里开始、选择什么路径,以及附加什么数据。

9.1.6 隐藏在同步facade背后的异步通信

接收响应的方式有三种:

  • 订阅发送响应消息的通道。
  • 提供一个回调API。
  • 定期进行轮询,看看结果是否可用。

其共同点是,你必须考虑超时问题,因为你不能永远等待,永远阻塞。这意味着你需要考虑如果在限定时间内没有响应该怎么处理。
我经常看到的一种模式是, 当一切正常时同步返回,出现错误时退回到异步处理。

9.2 事务和一致性

9.2.2 处理不一致的业务策略

解决不一致问题

在实例层面上解决不一致问题, 无须等待任何批处理的运行:Saga模式和发件箱模式。

9.2.3 Saga模式和补偿

Saga模式描述了分布式系统中长期运行的事务。其主要思想很简单:当你无法回滚任务时,就撤销它们。
BPMN通过补偿事件来支持这个模式,补偿事件可以将任务与对应的撤销任务关联起来。

9.2.4 使用发件箱模式链接资源

另一个有趣的模式是发件箱模式(outbox pttern)。假设你构建了一个执行某些业务逻辑的服务,它会将结果持久化在一个关系型数据库中,然后在事件总线上发送一个事件。正如本章前面所解释的,你不能对两个使用不同资源(这里指数据库和事件总线)的任务使用ACID事务。(问题难点
在这种模式的典型实现中,服务将需要发布的事件写人领城数据所在的关系型数据库中,但需要写入另张单独的表。这个表就被称为发件箱。表在同一个数据库中,服务就可以使用数据库的ACID事务,持久化业务逻辑的结果以及写人事件可以是原子的。(解决办法
你还可以利用工作流引擎。这样的话,你根本不需要一个单独的发件箱表。
首先,业务逻辑将被执行并提交结果。只有当这一过程成功时,事件才会在第二个任务中被发布到事件总线上。

9.3 最终一致性适用于各种形式的远程通信

过去,有人试图将远程通信的实际内容隐藏在框架后面。例如,在你的源代码中,REST调用可能看起来像本地方法调用一样。 开发者得到的感受是他们执行完就能立刻得到结果。 ^166c1f

9.4 幂等性的重要性

幂等性操作定位为“可多次执行而不改变第一次执行结果的操作”。
一个好的工作流引擎也提供幂等操作,这样你就可以确保只为一个给定的key启动一个流程实例。

9.5 结论

第10章 业务-IT协作

10.1 一个典型的项目

10.2 所有人:BizDevOps

让我们透过业务、开发和运维(简称BizDevOps)之间的合作更细致地讨论一下流程自动化工具的价值。

10.2.1 开发

可执行流程模型是活文档,当流程发生变更时,它不会像其他没有与代码关联的架构图一样逐渐过时。即使是最规范化的开发流程,在程序需要紧急修复的情况下也无法避免遗忘更新文档。

10.2.2 业务

有一个奇怪的现象:使用流程模型的项目在最初分析阶段常常出现工作量激增的情况。流程模型不是应该帮助减少工作量吗?
事实上,由于图形模型很容易理解,项目组往往会在流程设计早期发现流程设计存在问题,比如设计缺乏清晰度。

10.2.3 运维

以往,运维人员需要根据数据库中的日志文件和数据开展工作。这限制了他们理解整个流程以及自己解决问题的能力。解决故障的唯一方法就是让那些对应用程序 了如指掌的开发人员参与进来。
使用可视化的图形流程能帮助运维人员在上下文中理解事件,其中包括流程模型、历史信息,附加到流程实例上的数据,以及有关错误或异常的详细信息。

10.3 一体化模型的力量

在观察过成功的项目后,我得出一个重要的结论,业务人员和开发人员之间的协作绝对不是一方迫使另一方接受定义好的模型。成功来自真正的合作。

从流程金字塔到房子

BPMN能让你在一个大图表中建模所有的流程,这个图表叫作协作模型。从技术上讲你还是单独创建流程,只不过将它们放在一个图上并表达通信关系。(房子
BPMN中,这三个矩形被称为泳道(pool)。每个泳道都是个完整的流程。 你可以将每个流程视为整个业务流程的一个具体视角。

10.4 谁来建模

业务分析师思考业务需求,专注于“是什么”和“为什么”,尽量忽略“怎么做””(为解决方案留下空间,让开发者决定如何进行选择)。业务分析师通常是创建流程模型初稿的人,当然, 这也会塑造可执行流程。
关注可执行模型,你需要避免让业务分析师覆盖或删除那些在他们的工具中不可见的技术属性。这就是为什么可执行模型的所有权必须归开发者所有

10.5 创建更好的流程模型

许多不同角色的人都需要理解你的流程模型(理想情况下应该无须进一步的解释), 这些模型是具有很长寿命的人工制品。
一个正在生产环境中的不完美模型比一个从未被执行过的完美模型更有价值。

10.5.1 将逻辑提取(集成)到子流程中

有些人更喜欢大模型,包含所有的细节,然后应用建模惯例来保持它们的可读性。

10.5.3 提高可读性

从左到右建模,遵循乐观路线

从左到右建模流程图(或者相反,如果你所处的文化是这样书写的话),特别注意不要从上到下。这考虑了阅读方向,还考虑了人类的视野,人们更喜欢宽屏。

10.6 结论

第11章 流程可见性

11.1 流程可见性的价值

可见性在两个方面实际影响流程的性能:

  • 流程改进(持续性的)
  • 流程运维

流程可见性对所有的运维人员都有帮助。其中一个有趣的内容是提供志势感知(situation awareness)。认知心理学在这一领城有很多研究, 证明态势感知对运维人员的决策结果至关重要。
有个案例很有趣,是在空中交通管制和核电站控制室的背景下的一项研究。研究报告“The Impact of Process Visibility on Process Performance"(https://oreil.ly/gPTjq)的作者发现,“运维人员必须能够随时了解当前的流程状态,并有能力充分利用这些知识来预测未来的流程状态以及控制流程达到运维目标”。

11.2 获取数据
11.3 状态查询

11.4 理解跨多个系统的流程

11.4.1 可观测性与分布式追踪工具

最常见的例子是分布式追踪,它致力于追踪不同系统和服务之间的调用栈。它的实现方式是创建一个用来追踪的唯一ID,将其添加到所有远程调用中(例如添加到HTTP Header或消息头)。
https://zipkin.io/

11.4.2 自定义集中式监控

与其收集技术踪迹,不如收集有意义的业务事件或领域事件。这样你能够获得恰当粒度的信息。
你还可以利用图形化流程模型将这些信息可视化。比如,bpmn.io这种轻量级的开源JavaScript框架就可以轻松创建HTML页面。 ^ce3eb9

11.4.4 流程挖掘

还有一类完全不同的工具:流程挖掘( process mining)工具。
流程挖掘工具可以发现流程模型,并以图形的方式将其可视化。
换句话说,这些工具擅长分析日志文件,但并不擅长分析实时的事件流。它们能够用于分析发现的流程模型,但不能用于监控或报告用例。而且它们通常使用DPG(Direct Follower Graph),而不是BPMN,这就很难向所有干系人展示这些内容。

11.5 设置流程报告和监控

11.5.1 常见的指标和报告

最重要的指标反而最简单。其中一些是基于流程持续时间的,包括:

  • 周期时间,指的是整个流程(包括工作流引擎中运行的流程以及端到端流程)的持续时间。这是判断流程性能的关键指标。进一步分析趋势和异常值是很有意义的,比如可以了解运行缓慢的流程实例背后的原因和影响。
  • 流程指定部分或指定阶段的持续时间。如果你想聚焦分析流程的某一小段,这个指标就很有用。
  • 单个任务的持续时间。比如,你可能希望验证SLA,或者分析单个步骤优化的可能性。

11.6 结论

第三部分 应用流程自动化

第12章 引入流程自动化的过程

本章将回答以下问题:如何将流程自动化引入你的组织?如何成功完成第一个项目?

12.1 了解采用过程

12.1.1 那些你想避免的失败

你可能从这个例子中观察到许多:

  • 不要过早地付诸战略行动,先从小项目开始。
  • 避免自上而下的大改造,创造允许自下面上发展的环境,最住平衡方案是,创造一个让一线员工的提议可以被收能起来的环境,然后接纳最含理的方案来讨论,进而推动改造。扩大使用范围的举措始终应该放在第二步。
  • 抵挡创建自己平台的诱感。
  • 第一步先选择合适的流程进行自动化。最重要的核心流程可能太庞大、有风险、太过复杂,不适合作为第一步尝试。
  • 不要同时启动太多项目。
  • 专注于交付业务价值。流程解决方案需要解决真正的业务痛点。
  • 不要从流程架构或流程景观开始。不要期望提前为流程自动化项目导出现成的流程模型。当你知道流程自动化的真正运作方式时,将能更好地描绘流程架构。
  • 让学习带给自己视野,这包括接受一种公开讨论失败的文化, 因为你可以从中学习到很多。厂商或咨询公司的最佳实践(或书籍)可以作为一个很好的起点,但不能取代你自己的探索。
  • 给子项目团队自由度,让他们可以自己做一些决定。

12.1.2 成功案例

这个故事的主要收获是:

  • 一步一步来,直到你准备好大规模使用。
  • 获得决策者的认可,这需要你的流程解决方案能解决真正的业务痛点,
  • 确保让有经验的人有机会在后续的项目中提供帮助。
  • 获取最佳实践,确保知识共享。
  • 如果可复用的组件能提高生产力,就提供这些组件,但要作为库让团队自行采用。
  • 建立内部咨询方法,也许可以组织成一个专家中心(COE)。 至少要在企业中确定并培养一名能够推动该主题的专家。
  • 为新人或团队确定学习路径。

12.1.2 成功采用过程的模式

xychart-beta     title "流程自动化项目采用过程"     x-axis "项目投入(时间、资金)" ["试点-初期", "试点-后期","灯塔-初期","灯塔-后期", "大规模采用-初期","大规模采用-后期","成熟期"]     y-axis "价值"     bar [1, 1.1, 2, 2.1, 3, 3.1, 4]     line [1, 1.1, 2, 2.1, 3, 3.1, 4]

评估工具栈时,你需要建立概念验证项目。该项目的目标是定义井验证架构和工具栈,具体的代码往往会被丢弃。
任概念验证之后,马上开始一个试点项目。你应该选择一个合适的场景, 在这个场景中至少可以展示流程自动化的一些好处(例如, 提高效率、有效性、合规性), 因为许多人(包括决策者)都对可量化的结果感兴趣。
在成功运行试点项目后,启动一个灯塔项目。
理想情况下,进行试点的团队也在灯塔项目中工作,因为这样可以充分利用他们所有的学习成果。这一点很重要,因为灯塔可能会成为后续项目的模板。也因此在灯塔项目完成上线后,你还应该规划一些时间来进行回顾。 请记住,投入些时间在修正上,远好于押注在第一版能做到完美。
只有这样,你才应该进入下一个阶段,即在整个企业中大规模使用流程自动化。你应该逐步推进这个阶段。在从少数项目中收集足够的经验之前,请确保不要走得太远。理想情况下,这种规模化是以“被动”的方式进行的,换句话说,是项目团队听说了流程自动化的优势,并决定要在他们的项目中采用它。

12.2 开始引入流程自动化

12.2.1 自下而上地引入与自上而下地引入

引人可以自下而上。这种情况经常发生在开源组件上。开发者可能在某个地方了解到一个工具,然后试着使用。
在这种情况下,公司基本上是在工具已经稳定下来的阶段开始采购流程,此时评估已经没有多大意义了。这未必是一件坏事,因为该工具已经证明了它的价值。

自上而下的引人方式与此形成鲜明对比,在这个过程中,工具一般是由高层决定并交给开发团队的。在极端情况下,企业要求每个项目都必须使用统的流程自动化工具栈。

12.3 从项目到工程:扩大使用规模

12.3.3 管理架构决策

当然,任由每个团队选择自己喜欢的东西是有风险的,因为这些决定可能会被趋势、炒作、个人喜好所左右,或者仅仅是人们要尝试某个“早就想试试”的技术。
这就是所谓的“谁构建,谁运维”(you build it, you run it)。这一重 要的基本原理会使团队识到他们将为自己的决定负责,从而做出 更明智的决定。

12.3.5 角色和技能培训

  • 明星开发者。他们积极进取,充满热情。你只需要给他们工作流引擎和入门指南,然后离开。他们大概会自己从网上搜索。这些人可能最适合早期项目,也许还可以成为COE的人选。他们面临的挑战是,总想用最新、最好的技术,有时往往会过度设计。他们并不总是善于指导别人。要注意,这样的人很容易分心。
  • 专业开发者。这些开发人员是训练有素的软件工程师。建议让工具的提供商进行一次培训,或许还要再加上一段时间的咨询服务,以便他们遇到任何问题时可以获得答复。这些人通常是很好的讲师,可以成为COE的一部分。

12.4 结论
第13章 临别赠言
13.1 当下架构趋势对流程自动化的影响
13.2 重新思考业务流程和用户体验
13.3 何去何从
关于作者
关于封面
推荐阅读
封底

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.hqwc.cn/news/877372.html

如若内容造成侵权/违法违规/事实不符,请联系编程知识网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

5.C++提高编程

C++提高编程。C++提高编程 本阶段主要针对C++泛型编程和STL技术做详细讲解,探讨C++更深层的使用 1 模板 1.1 模板的概念 模板就是建立通用的模具,大大提高复用性 例如生活中的模板 一寸照片模板:PPT模板:模板的特点: 模板不可以直接使用,它只是一个框架 模板的通用并不是…

又来新活了!AI电商搜索,或是下一个90亿美元独角兽?

全新体验,大模型驱动的对话式购物搜索。图源:https://www.shopencore.ai/ 全新体验,大模型驱动的对话式购物搜索。 Encore, 由2024年10月成立的美国初创公司开发。定位于二手商品对话式购物搜索,最终目标为个人购物助理。 2024年12月3日获得YC(Y combinator)的50万美元天使…

qq网页版下载音乐教程

点一首音乐开始播放,务必要播放界面内只有一首音乐,然后f12调试,找到audio标签;然后复制src=”” 双引号内的内容到新标签打开,然后在播放栏,右键,就可以保存音乐了,注意有的音乐是m4a格式,下载完成后还要转换成mp3。谢雨尘安-谢雨尘安的博客

gin: 校验参数时返回自定义错误信息

一,代码 1,global/validator.go package globalimport "github.com/go-playground/validator/v10"//存放GetMessages()方法 type Validator interface {GetMessages() ValidatorMessages }//校验信息 type ValidatorMessages map[string]string// GetErrorMsg方法,…

VM笔记_Modbus通信触发流程

1,通信触发流程 ①通信配置② 接收事件新建③全局触发-事件触发4, 通信心跳配置和启用5, 效果展示

[SWPUCTF 2021 新生赛]easyupload3.0 Writeup

题目来源:NSSCTF 题目方向:Web 题目类型:文件上传 2.0的做法和1.0相同,不过用.phtml绕过就行 1.这里去了解了一下.htaccess文件: htaccess文件是Apache服务中的一个配置文件,它负责相关目录下的网页配置。通过htaccess文件,可以帮助我们实现:网页301重定向、自定义404错…

数据库性能调优中的配置参数调整:提升系统效率的关键环节

title: 数据库性能调优中的配置参数调整:提升系统效率的关键环节 date: 2025/1/31 updated: 2025/1/31 author: cmdragon excerpt: 数据库的性能直接影响到应用程序的响应能力和用户体验,因此在日常运维中,管理员需要定期对数据库系统进行性能调优。配置参数调整是数据库性…

PID 温控设计(基于 STC51)

PID 温控设计(基于 STC51) 一、需求分析 开关型控制存在的问题:加热的过程是全功率加热,三极管发热量大,温度控制振荡幅度大,控制精度较低。而通过采用PID方法能够更加精确地控制加热片处于目标温度,并在一个较小范围内浮动。精度要求:0.2℃ 温控范围 目标温度:45℃ 温…

gin: 接收参数时校验

一,安装第三方库: $ go get -u github.com/go-playground/validator/v10 go: downloading github.com/go-playground/validator/v10 v10.24.0 go: downloading github.com/gabriel-vasile/mimetype v1.4.8 go: downloading golang.org/x/crypto v0.32.0 go: downloading golan…

Java异常分类及处理

Throwable 是 Java 语言中所有错误或异常的超类,在 Java 中只有 Throwable 类型的实例才可以被抛出(throw)或者捕获(catch),它是异常处理机制的基本组成类型。实例分为 Error 和 Exception 两种。 其中,AWTError GUI图形界面化编程相关异常。Error(错误)是程序无法处理…

Apple Safari 18.3 - macOS 专属浏览器 (独立安装包下载)

Apple Safari 18.3 - macOS 专属浏览器 (独立安装包下载)Apple Safari 18.3 - macOS 专属浏览器 (独立安装包下载) 适用于 macOS Sonoma 和 macOS Ventura 的 Safari 浏览器 18 请访问原文链接:https://sysin.org/blog/apple-safari-18/ 查看最新版。原创作品,转载请保留出处…

AppSpider Pro 7.5.015 for Windows - Web 应用程序安全测试

AppSpider Pro 7.5.015 for Windows - Web 应用程序安全测试AppSpider Pro 7.5.015 for Windows - Web 应用程序安全测试 Rapid7 Dynamic Application Security Testing (DAST) released Jan 30, 2025 请访问原文链接:https://sysin.org/blog/appspider/ 查看最新版。原创作品…