基于关系依赖模型的微服务流程演化分析

doi:10.13232/j.cnki.jnju.2022.02.014

基于关系依赖模型的微服务流程演化分析

郑伟波¹^,², 李志超^,², 刘纪遵¹, 刘士军¹

1.山东大学软件学院，济南，250101

2.浪潮通用软件有限公司，济南，250101

Business process and service evolution analysis based on relationship dependency model

Zheng Weibo¹^,², Li Zhichao^,², Liu Jizun¹, Liu Shijun¹

1.School of Software, Shandong University, Ji'nan, 250101, China

2.Inspur Genersoft Co. , Ltd. , Ji'nan, 250101, China

通讯作者: E⁃mail：lizhichao@inspur.com

收稿日期: 2021-12-22

基金资助:

国家重点研发计划. 2017YFA0700601

Received: 2021-12-22

摘要

微服务技术的快速发展为企业系统集成和网络化业务协同提供了技术支持，软件服务系统中的流程需要不断演化以适应业务变化的需求，而现有的研究多从单一维度评估服务流程演化的影响.提出包括流程层和服务层在内的服务系统双层依赖关系模型DoubleDM，从服务演化和流程演化两个方面分析服务系统演化问题.针对服务层演化，基于服务间的依赖关系分析服务变更的影响范围，给出了服务依赖关系表达、依赖关系演化影响范围及求解和相应算法；针对流程演化的不同类型，给出了流程依赖基础上的流程化简处理步骤和算法.最后给出了微服务系统中流程演化的实现逻辑，并以微服务系统处理供应链销售流程为例进行了分析.

关键词： 流程 ; 服务 ; 依赖模型 ; 业务流程演化

Abstract

The rapid development of microservice technology provides technical support for enterprise system integration and network business collaboration. The process in software service system needs to evolve continuously to adapt to the needs of business changes. Existing researches mostly assess the impact of service process evolution from a single dimension. This paper proposes a two⁃layer dependency model，DoubleDM，for the service system including the process layer and the service layer to analyze service system evolution from two aspects: service evolution and process evolution. Regarding to the evolution of the service layer and the analysis of impact range of service modification based on the dependency between services，the expression of service dependency，the influence scope of dependency evolution and the solution with corresponding algorithm are given. For process layer evolution with various types，the process simplification algorithms on the foundation of process dependency is given. Finally，the implementation logic of the process evolution in the microservice system is proved，and the analysis is carried out by taking the example of microservice system to deal with the supply chain process.

Keywords： process ; service ; dependency model ; business process evolution

PDF (1336KB) 元数据多维度评价相关文章导出 EndNote| Ris| Bibtex 收藏本文

本文引用格式

郑伟波, 李志超, 刘纪遵, 刘士军. 基于关系依赖模型的微服务流程演化分析. 南京大学学报（自然科学）[J], 2022, 58(2): 309-319 doi:10.13232/j.cnki.jnju.2022.02.014

Zheng Weibo, Li Zhichao, Liu Jizun, Liu Shijun. Business process and service evolution analysis based on relationship dependency model. Journal of nanjing University[J], 2022, 58(2): 309-319 doi:10.13232/j.cnki.jnju.2022.02.014

以大规模、协作化、网络型组织为特征的大型集团企业在实现全球供应链、市场、服务资源整合的过程中极大地推进了企业与社会组织联合的系统创新，而支撑这一系统运行的软件系统则得益于微服务技术的发展与开发运营一体化（Deve⁃lopment+Operation，DevOps）等新型开发模式的广泛应用，企业通过微服务连接内外部的不同系统、人员和设备，并将其进行动态整合集成.在这种应用场景下，受各种因素动态变化的影响，软件服务系统的流程、服务实例需要不断地演化以适应新的需求.虽然微服务、BPM（Business Process Management）和SaaS（Software⁃as⁃a⁃Service）等技术为服务整合、编排和发布提供了良好的支持，但服务系统内部错综复杂的关系使确定演化的影响范围和程度并对其进行有效的管理变得非常困难.对服务系统的服务与流程演化进行有效描述、确定演化影响范围并对影响程度进行评估成为该领域的重要研究问题.

由于整个服务网络中可能包含众多业务流程和服务等实体，且实体间存在复杂的依赖关系，所以当某个流程或服务发生演化之后，如何确定演化类型、影响范围并评估它带来的影响是一项代价很高的工作.虽然研究人员对演化影响分析与求解做了大量工作，但这些研究很少从服务系统的角度展开，忽略了服务系统的层次结构、流程与服务之间的密切关系以及数据在演化影响中的重要作用，从而对演化分析准确性产生不利影响.

依赖关系分析作为一个成熟且有效的方法在演化影响分析中扮演非常重要的角色.比如，路由依赖关系确定了流程中各活动的执行次序；数据依赖定义了与每个活动相关的输入输出数据，并描述了数据的来源和去向.因此，根据服务间的依赖关系建立高效的关系模型成为演化分析与求解的基础.通过服务关系模型，不但可以减少演化影响分析的成本，而且可以避免分析过程中错误的发生.

本文以微服务系统中的服务依赖关系为基础，结合流程层的定义，提出了由流程层和服务层组成的服务系统双层依赖关系模型DoubleDM，对微服务系统中服务演化和流程演化进行了探讨.首先针对服务层的依赖关系，分析服务变更的影响范围，给出了服务间依赖关系表达、依赖关系演化影响范围及求解和相应的算法；然后针对流程演化类型，给出了流程演化描述语言和影响程度的量化评价，从流程路由依赖和服务依赖两方面给出了完整的处理步骤和算法；基于演化影响评估算法，以量化的方式对演化的影响范围和程度进行了计算.

1 相关工作

流程演化传播与分析一直吸引着研究者的目光，对演化的管理涉及计算机领域的诸多方面.微服务架构的一个重要关注点就是对基于服务的业务流程管理系统进行维护与演化，云原生、微服务等新技术给服务演化分析带来了新问题，业务人员需要采用新的工具和技术来应对服务系统中的演化影响.按层次划分，服务系统的演化研究集中于两个层面：一是基于业务操作和流程模型的业务层，另一个是基于部署架构的服务层^［1］.考虑到流程与服务间的依存关系，又可把演化分为自上而下从流程到服务的演化和自下而上从服务到流程的演化两方面^［2］.前者指由业务流程的改变引起的调用服务实例的演化，后者则表示由底层服务引起的业务流程的改变.

Krishna et al^［3］提出从BPMN （Business Process Modeling Notation）标准符号到LNT过程代数和LTS （Labelled Transition System）形式模型的模型转换，并提出在模型层级比较业务流程的一组关系，进而检查流程是否演化及如何演化.

胡强等^［4］采用逻辑Petri网作为形式化建模工具，通过分析几类不同的演化需求场景构建基于逻辑Petri网的服务流程结构演化运算，提供了一种在流程模型层面描述流程结构演化的形式化方法，探讨了所建立的结构演化运算对流程结构范式的保持问题.

Wang et al^［5］在流程层建模的基础上提出一种时间复杂度为 $O (n^{3} + n^{2})$ 的流程演化影响分析方法，但其模型忽略了数据在流程中的重要作用，并且算法只能求解受影响的活动集合，没有对影响进行量化的度量.

Dai et al^［6］介绍了一种案例学习方法，对流程演化从路由、数据和角色三个方面进行分析.先定义若干依赖影响规则，然后分析工具根据这些规则建立三种依赖关系的知识库，通过在分析工具中输入演化的元素和类型，获得受演化影响的前序和后续元素.虽然对流程演化进行了细致分析，但流程发生演化时必须重新构建知识库，对流程的动态性支持较差.

Kherbouche et al^［7］提出一种以依赖为核心的变更分析方法，检测和分析各种流程与相关服务中的交叉依赖来支持业务流程演化.使用一组指标计算变更影响传播的深度，通过影响度区别受影响实体，而变更影响传播基于图的可达性实现.

当前对服务层的演化研究包括服务接口和协议演化等方面^［8］.顾庆和陈道蓄^［9］通过软件网络图的方法描述软件系统，进而基于复杂网络理论采用不同的研究方法分析软件演化的规律.杨启亮等^［10］从基于控制理论的软件自适应方法的视角来综述软件自适应相关的原理、模型、方法、技术、工具等.卢成炳^［11］提出一种需求驱动的微服务应用自适应演化框架.该框架面向需求驱动，基于微服务架构，借助DYNAMICO （Dynamic Adaptive， Monitoring and Control Objectives Model）参考模型中的CO⁃FL，A⁃FL和M⁃FL反馈回路，映射到路由委派、微服务调度和监控执行过程中，进而满足变更的用户需求.何俊^［12］对经典π演算进行扩展，形式化表示和描述SaaS服务流程并建立服务流程演化模型，对服务流程演化前后的互模拟和模型簇膨胀问题进行了研究.

尤殿龙等^［13］运用互模拟理论，从单个状态节点、单个服务和服务组合三个层面进行深入分析，给出了业务流程演化类型判定规则.指出业务流程演化影响范围的判定与服务组合演化类型密切相关，提出依据发起演化服务内部业务流程演化前后的变化来判定波及服务，再将变化以初始服务编排协议的形式发送给伙伴服务，由各伙伴服务判定自身的服务组合业务流程演化影响范围，并给出单个内部业务流程演化影响范围、参与演化的单个服务内部业务流程演化影响范围和服务组合演化影响范围的判定规则和算法^［14］.

2 服务系统双层依赖关系模型

本文提出的服务系统双层依赖关系模型（DoubleDM）由流程层依赖模型（PDM）和服务层依赖模型（SDM）组成，它对服务系统进行建模描述，本节将对其进行分析.

2.1　流程层依赖模型

流程层依赖模型描述了流程的执行过程，它由活动集合、网关集合、顺序流集合、数据集合以及活动与数据的关系组成.定义如下：

定义1

流程层依赖模型PDM， $P D M = 〈A, G, E, D, R〉$ ，它是一个五元组，如图1所示，其中：

图1

新窗口打开| 下载原图ZIP| 生成PPT

图1 流程层示意图 (D₁)

Fig.1 The diagram of process model (D₁)

$A = \{a_{1}, a_{2}, \dots, a_{m}\}$ 是流程中的活动集合.

$G = \{g_{1}, g_{2}, \dots, g_{n}\}$ 是网关集合，用于流程拆分或者合并时的流向控制.网关分并行网关、包含网关和排他网关三类.

$E = \{e (a_{i}, a_{j}), e (a_{i}, g_{j}), \dots, e (g_{i}, a_{j})\}$ 是顺序流集合，用于连接两个流程元素（流程元素包括活动与网关），标识流程的走向.它可能拥有先决条件，当条件满足时才会执行.

$D = \{\{d_{1}\}, \{d_{2}\}, \dots, \{d_{p}\}\}$ 是数据对象集合，对应流程中的数据.对于流程中的每个活动，都有一组输入数据和输出数据与之对应.

R =

\{(a_{1}, I D_{1}, O D_{1}),

(a_{2}, I D_{2}, O D_{2}),

\dots,

$(a_{m}, I D_{m}, O D_{m})\}$ 是活动与数据的关系集合， $I D_{i} \in D$ 和 $O D_{i} \in D$ 表示活动 $a_{i}$ 的输入和输出数据集合.

2.2　服务层依赖模型

在微服务系统中，微服务以单一应用程序构成小服务，拥有自己的进程与轻量化处理，服务依照业务功能设计，服务实例以全自动的方式部署，与其他服务使用HTTP API通信.服务层依赖模型对各层次服务之间的依赖关系、服务版本和服务实例的对应关系进行了建模.

定义2

服务层依赖模型SDM， $S D M = 〈S, S I, V, S D, S V〉$ ，它是一个五元组，如图2所示，其中：

图2

新窗口打开| 下载原图ZIP| 生成PPT

图2 服务层示意图

Fig.2 The diagram of service model

$S = \{S_{1}, S_{2}, \dots, S_{m}\}$ 是系统中所有抽象服务的集合， $S_{i}$ 代表某个服务.

$S I = \{\{S_{1} I\}, \{S_{2} I\}, \dots, \{S_{m} I\}\}$ 是系统中所有服务实例的集合， $S_{i} I$ 代表某抽象服务 $S_{i}$ 的一个服务实例集合.

$V = \{V_{1}, V_{2}, \dots, V_{n}\}$ 是系统中所有服务宿主的集合， $V_{i}$ 为具有可表示访问主机地址服务宿主单元.

$S D = \{〈S_{i}, S_{j}〉, S_{i}, S_{j} \in S\}$ 是服务间依赖关系的集合， $〈S_{i}, S_{j}〉$ 表示服务 $S_{i}$ 依赖于服务 $S_{j}$ .

$S V = \{〈S_{i} I_{j}, V_{k}〉, S_{i} I \in S I, V_{k} \in V\}$ 是服务实例宿主关系，表示服务 $S_{i}$ 的某个实例 $S_{i} I_{j}$ 宿主于服务宿主单元 $V_{k}$ .

微服务应用系统往往由物理部署上分布的、不同粒度、不同所有域的服务实例间互相调用，彼此存在逻辑关系的服务实例之间、服务实例与部署的物理资源之间均存在相互依赖的联系.因此，依赖关系不仅仅指服务间的依赖关系，还包括服务与容器化服务实例间、服务实例与宿主机之间的依赖关系.将依赖关系做以下细分：

引用依赖：服务间逻辑上的相互引用关系，包括时序依赖、强制依赖等.

时序依赖：在服务 $S_{i}$ 执行之后才能执行 $S_{j}$ 服务.

强制依赖：在服务 $S_{i}$ 执行后，必须紧跟着执行 $S_{j}$ 服务.

实例依赖：不同服务之间、服务实例之间的依赖关系.在应用系统中，每个服务对应若干服务实例，这些服务实例实现相同的功能，但访问地址、QoS（Quality of Service）属性可能不同.

部署依赖：容器化部署的服务实例与服务器资源之间的部署关系，一个服务器资源上会部署多个服务实例，部署在不同服务器上的服务实例的QoS不同.

一个抽象的业务流程由多个活动组成，在微服务系统中，这些活动对应服务和服务实例，可以对服务之间的引用依赖关系进行形式化的约束.定义服务依赖是在服务 $S_{i}$ 和 $S_{j}$ 间的一种有向依赖，记作 $S_{i} \to S_{j}$ ，称 $S_{i}$ 依赖 $S_{j}$ ，或称 $S_{j}$ 影响 $S_{i}$ ， $S_{i}$ 是依赖者， $S_{j}$ 是被依赖者.服务依赖是有向的、可传递和反对称的多元关系.

之前的研究^［15］提出基于知识交换格式（Knowledge Interchange Format，KIF）^［16］描述服务依赖关系的方法，服务依赖的KIF标记为（service_dependency？ $S_{i}$ ？ $S_{j}$ ？T），它的非正式语义是在子依赖图T中 $S_{i}$ 依赖 $S_{j}$ .

根据该定义可将服务依赖图划分为若干子依赖（sub⁃dependency）、依赖根（dependency⁃root）、依赖叶（dependency⁃leaf）、依赖后继（dependency⁃next）等组成部分.

服务依赖具有传播性，一个服务的演化将直接或间接影响多个具有依赖关系的服务，主要包括依赖传递、依赖链、依赖本影、依赖包络和热依赖，可以用依赖影响来界定服务结点的依赖影响范围.求解服务演化的影响范围的基本思想是以给定结点为依赖根，利用图的深度优先遍历算法，依次递归寻找每个服务结点的直接依赖结点，直到叶结点，最终得到依赖路径.在处理多个顶点的依赖关系时可以求解这些结点的多个服务依赖链的并集，即依赖包络；同时，通过提取共享依赖列表中共享的中间结点，可以求解出热依赖结点，这些服务是在服务演化中应该重点关注的结点.依赖本影的求解可以借助子依赖和依赖包络算法得出，用于裁剪不需要分析依赖影响的分支^［15］.

2.3　流程层演化模型

流程演化的多样性不但使描述演化变得困难，也加剧了演化分析的工作量.本节将流程演化划分为若干基本的演化类型，并用形式化的语义对其进行描述，从而简洁高效地描绘流程演化，为演化分析打下良好基础.

虽然流程演化类型繁多，但流程由活动、网关、顺序流和数据等组成，本文对流程演化的分析也从这四个方面展开，将复杂的流程演化拆解为若干简单的流程演化.图3列出了流程基本演化类型.D₁（图1）发生演化后转化为图4所示的D₂.

流 程 演 化 类 型 \{\begin{matrix} 活 动 演 化 \{\begin{matrix} 增 加 活 动 \\ 删 除 活 动 \end{matrix} \\ 数 据 演 化 \{\begin{matrix} 输 入 数 据 演 化 \{\begin{matrix} 增 加 输 入 数 据 \\ 删 除 输 入 数 据 \\ 输 入 数 据 类 型 改 变 \end{matrix} \\ 输 出 数 据 演 化 \{\begin{matrix} 增 加 输 出 数 据 \\ 删 除 输 出 数 据 \\ 输 出 数 据 类 型 改 变 \end{matrix} \end{matrix} \\ 网 关 演 化 \{\begin{matrix} 增 加 网 关 \\ 删 除 网 关 \\ 修 改 网 关 \end{matrix} \\ 顺 序 流 演 化 \{\begin{matrix} 增 加 数 据 流 \\ 删 除 数 据 流 \\ 修 改 顺 序 流 条 件 \end{matrix} \end{matrix}

图4

新窗口打开| 下载原图ZIP| 生成PPT

图4 流程图D₂

Fig.4 Flowchart D₂

图3　流程的基本演化类型

Fig.3　Basic evolution types of processes

该演化实际由12个基本演化组成，它们是：

（1）网关 $g_{1}$ 由排他节点改为并行节点；

（2）顺序流 $e (g_{1}, a_{2})$ 条件改为TRUE；

（3）顺序流 $e (g_{1}, a_{3})$ 条件改为TRUE；

（4）增加活动 $a_{5}$ ；

（5）增加顺序流 $e (g_{1}, a_{5})$ ；

（6）增加并行节点 $g_{2}$ ；

（7）删除顺序流 $e (a_{2}, a_{4})$ ；

（8）删除顺序流 $e (a_{3}, a_{4})$ ；

（9）增加顺序流 $e (a_{2}, g_{2})$ ；

（10）增加顺序流 $e (a_{3}, g_{2})$ ；

（11）增加顺序流 $e (a_{5}, g_{2})$ ；

（12）增加顺序流 $e (g_{2}, a_{4})$ .

2.4　流程路由依赖关系简化处理

对流程中路由演化的分析依赖于流程图实现，流程中存在路由依赖关系的活动通过x个网关和x+1条顺序流连接，这会使路由依赖分析变得更加复杂.通过依赖矩阵描述流程中各活动、网关和顺序流的关系，然后运用简化算法去除依赖矩阵中的网关，可以有效地简化依赖分析的时间复杂度与空间复杂度.

设某网关有m条以其为终点的顺序流和n条以其为起点的顺序流，对于它的每一条输入顺序流，分别将其连接到n条输出顺序流上，共形成 $m \times n$ 条新顺序流，如算法1所示.然后，将该网关及其连接的输入输出顺序流从流程图中删去，如算法2所示.其中算法1将与网关有关的顺序流转化为活动之间的顺序流得到中间矩阵 $M M_{h}$ ，算法2将中间矩阵 $M M_{h}$ 中的网关消除掉.

算法1

SimpDepeMidMatrix（）

输入：路由依赖矩阵 M_h，节点属性哈希表H_h，节点序号哈希表H_i

输出：中间矩阵 MM_h

1.Set $M M_{h} = M_{h}$ ；

2.FOR 流程图中的每一个节点V_i do

3. IF V_i 为网关 THEN

4. FOR 流程图中的任一非V_i 节点V_j_do

5. IF $M M_{h} [j] [i] = = 1$ do

6. $M M_{h} [j] [i] = - 1$ ；

7. FOR 流程中的任一节点V_k do

8. IF $M M_{h} [i] [k] = = 1$ THEN

9. $M M_{h} [i] [k] = - 1$ ；

10. $M M_{h} [j] [k] = 1$ ；

11. END IF

12. END FOR

13. END IF

14. END FOR

15. END IF

16.END FOR

17. Return MM_h.

算法2

SimpDepeMatrix（）

输入：路由依赖矩阵 M_h，节点属性哈希表H_h，节点序号哈希表H_i

输出：化简后的路由依赖矩阵 SM_h

1.Set $M M_{h} = S i m p D e p e M i d M a t r i x ()$ ；

2.Set $S M_{h} = N U L L$ ；

3.INT $r c N u m = 0$ ；

4.FOR 流程中每个节点V_i do

5. IF V_i 为网关 THEN

6. $r c N u m = r c N u m + 1$ ；

7. ELSE

8. int $c c N u m = 0$ ；

9. FOR 流程中每个节点V_j do

10. IF V_j 为网关 THEN

11. $c c N u m = c c N u m + 1$ ；

12. ELSE

13. $\begin{array}{l} S M_{h} [i - r c N u m] [j - c c N u m] = \\ M M_{h} [i] [j] \end{array}$ ；

14. END ELSE

15. END FOR

16. END ELSE

17.END FOR

18.Return SM_h .

图5为流程图p_h 的路由依赖矩阵 M_h，如表1所示.通过算法2可得到p_h 化简后的路由依赖矩阵 SM_h，如表2所示.

图5

新窗口打开| 下载原图ZIP| 生成PPT

图5 流程图p_h

Fig.5 Flowchart p_h

表1 流程图p_h 的路由依赖矩阵 M_h

Table 1 The routing dependency matrix M_h of the flowchart p_h

	g₁	a₂	a₃	g₂	a₄	a₅	g₃	a₆	g₄	a₇	g₅	a₈	a₉
a₁	1	0	0	0	0	0	0	0	0	0	0	0	0
g₁	0	1	1	0	0	0	0	0	0	0	0	0	0
a₂	0	0	0	1	0	0	0	0	0	0	0	0	0
a₃	0	0	0	0	0	0	1	0	0	0	0	0	0
g₂	0	0	0	0	1	1	0	0	0	0	0	0	0
a₄	0	0	0	0	0	0	0	0	1	0	0	0	0
a₅	0	0	0	0	0	0	1	0	1	0	0	0	0
g₃	0	0	0	0	0	0	0	1	0	1	0	0	0
a₆	0	0	0	0	0	0	0	0	0	0	0	0	1
g₄	0	0	0	0	0	0	0	0	0	0	1	0	0
a₇	0	0	0	0	0	0	0	0	0	0	1	0	0
g₅	0	0	0	0	0	0	0	0	0	0	0	1	0
a₈	0	0	0	0	0	0	0	0	0	0	0	0	0
a₉	0	0	0	0	0	0	0	0	0	0	0	0	0

新窗口打开| 下载CSV

表2 流程图p_h 化简后的依赖矩阵 SM_h

Table 2 Flowchart p_h simplified dependency matrix SM_h

	a₂	a₃	a₄	a₅	a₆	a₇	a₈	a₉
a₁	1	1	0	0	0	0	0	0
a₂	0	0	1	1	0	0	0	0
a₃	0	0	0	0	1	1	0	0
a₄	0	0	0	0	0	0	1	0
a₅	0	0	0	0	1	1	1	0
a₆	0	0	0	0	0	0	0	1
a₇	0	0	0	0	0	0	1	0
a₈	0	0	0	0	0	0	0	0
a₉	0	0	0	0	0	0	0	0

新窗口打开| 下载CSV

经化简，起点或终点为网关的顺序流被转化成起点或终点均为活动的顺序流，如 $e (a_{1}, g_{1})$ ， $e (g_{1}, a_{2})$ 和 $e (g_{1}, a_{3})$ 转化为 $e (a_{1}, a_{2})$ 和 $e (a_{1}, a_{3})$ .

3 微服务系统中流程演化实现逻辑

目前企业信息系统驱动业务与数据流转的方式主要是基于BPMN等流程标准的流程引擎驱动，这种方式通过预先配置好的有限流程活动节点以及分支规则驱动业务状态与相关数据的流转.但这类流程是碎片化的，难以适应制造企业网络化协同与智能制造的趋势.在微服务架构下，预配式流程与自由流程混合驱动的模式是化解这一难题的途径.

通过在流程引擎中置入发布/订阅事件集成活动节点，可以在流程引擎执行到特殊节点时触发自由流中的微服务活动，也可由自由流中的微服务活动触发预配流程中的节点.进一步，将自由流微服务活动抽象为流程模型中的扩展节点，可以实现预配流程与自由流程的融合建模.结合预配流程与自由流程的执行数据标准模型，实现统一的流程分析与优化.主体思路如图6所示.

图6

新窗口打开| 下载原图ZIP| 生成PPT

图6 预配流程与自由流程融合实现逻辑

Fig.6 The implementation logic of the integration of provisioning process and free process

3.1　预配流程与自由流程融合建模

预配流程主要面向企业中相对固化的流程，由业务流程分析师根据实际的运行流程基于BPMN规范通过图形化的流程建模工具在系统中进行定义.预配流程的建模包括以下几个基础元素：

事件，用来表明流程的生命周期中发生了什么事，总是画成一个圆圈.事件分为订阅事件、发布事件两大分类.订阅事件指当流程执行到该事件时它会中断执行，等待被其他流程活动或微服务触发；发布事件指流程执行到该事件时会抛出一个结果，也可以触发自由流中的微服务活动.

网关，用来控制流程的执行流向，在拆分路径时产生令牌，在合并路径时消费令牌.常用网关可分为排他网关（XOR）、并行网关（AND）和包含网关（OR）.

活动是业务流程定义的核心元素，一个活动可以是流程中一个基本处理单元（如人工任务、服务任务），也可以是一个组合单元（如外部子流程、嵌套子流程）.其中服务任务、外部子流程都可能触发其他流程，将当前流程与运行在其他微服务上的预配流程或基于事件的自由流程关联起来.

数据，在流程、活动之间进行传递，主要通过三种元素表示，即数据对象（Data Objects）、数据输入（Data Inputs）、数据输出（Data Outputs）.

顺序流，用于连接两个流程元素，标识流程的走向.它可能拥有先决条件，当条件满足时才会执行.

在微服务架构下，企业中的上、下游微服务活动分别部署在不同的微服务上，自由流程面向“微服务活动⁃微服务活动”的点对点交互，实现上下游业务活动的自动化对接，进而组装成无边界的网状流程，以满足传统制造企业难以应对网络组织间复杂多变的业务流程协同需求.

3.2　流程监控管理

在运行阶段需要不断关注整个执行过程，在必要时进行介入来把控整体业务的顺畅进行.流程服务系统为系统管理员提供了一组运行监控管理工具，运维管理员可以通过管理操作改变流程执行路线，处理日常技术服务响应.由管理员干预流程执行的操作将被记录到该流程的任务处理日志中，同时在审计日志中记录主客体的操作行为.具体支持以下功能特性：

（1）提供实例查询、统计.

（2）提供图形化的流程跟踪功能，支持查看运行日志、流转现状，支持后继路线预测、预判流程走向，及时发现并纠正流程设计缺陷.

（3）提供基于事件的可靠发布与处理机制的流程异常处理策略，并支持人工干预处理异常.

（4）提供流程实例的干预操作功能，支持流程实例的挂起、恢复、取消、复活、终止、删除等操作.

（5）提供任务实例的干预操作功能，支持任务实例的移交、委托、挂起、恢复、取消、分配、删除等操作.

（6）提供流程干预调整的处理日志、审计日志.

3.3　实时流程动态优化

为了持续优化流程，提升流程效率，需从“流程数量、流程环节、流程效率”等方面进行分析，为流程梳理、流程建模、运行维护提供决策依据，实现流程动态实时优化.主体思路如图7所示.

图7

新窗口打开| 下载原图ZIP| 生成PPT

图7 流程动态优化

Fig.7 Process dynamic optimization

通过采集企业流程过程数据（如流程实例日志、流程节点日志），通过内置的分析模型和算法，将原始数据加工成过程效率相关的KPI （Key Performance Indicator）维度分析结果，以图表的形式展现，能够为企业调整、优化业务流程提供量化的建议.

具体支持以下功能特性：

（1）支持过程数据的计算、处理和分析.

（2）内置流程KPI和算法模型，自动处理成流程、组织、时间的多维分析结果.

（3）支持图表展示灵活配置，支持折线图、柱状图、面积图、URL图和饼图，并提供钻取功能.

（4）支持以年、季、月、周、天、时为单位的分析区间，并提供数据同比、环比分析.

3.4　微服务共享数据一致性保证

智能制造场景中，端到端的流程集成跨越的边界较多，存在交互需求多样的特征，需要建立支持同步、异步不同传输模式，可跨越不同进程、设备、网关、企业的，安全、可靠的数据传动机制.

分布式系统的最大难点，就是各个节点的状态如何保持一致.为了解决分布式一致性问题，可以采用事件总线（Event Bus，EBS）实现分布式架构下微服务之间的数据一致性；通过事件的发布与订阅机制，实现不同业务逻辑之间的同步或异步调用，提升系统的并发性、扩展性和响应性.

事件总线采用事件驱动架构，如图8所示，提供基于业务事件触发服务并在微服务间通信的能力，主要功能包括事件注册与订阅管理、事件发布、事件处理和事件监控.

图8

新窗口打开| 下载原图ZIP| 生成PPT

图8 事件总线功能架构图

Fig.8 Event bus functional architecture diagram

具体支持以下功能特性：

（1）提供同步与异步调用机制，支持事件发布方与消费方的逻辑解耦.

（2）提供多维度的事件发布与订阅机制，支持跨系统、跨微服务、跨租户、跨业务的通信.

（3）提供事件分流机制，通过业务维度与事件的关系动态路由事件流通道，提升事件流传递效率.

（4）提供业务事件管理功能，支持业务事件的注册、订阅、状态控制与配置管理.

（5）提供事件的可靠发布与处理机制，提供事件异常处理策略，并支持人工干预处理事件异常.

（6）提供事件处理监控，支持跟踪事件的发布日志和事件的处理日志，便于及时诊断和处理业务逻辑中的调用异常.

在事件总线支持下，TCC（Try/Confirm/Cancel）框架实现了跨应用单元的同步服务调用的一种保持数据一致性的机制，其核心思想：即使无法做到强一致性，每个应用仍然可以根据自身业务特点，采用适当的方式来使系统达到最终一致性.分布式事务边界如图9所示.

图9

新窗口打开| 下载原图ZIP| 生成PPT

图9 分布式事务边界

Fig.9 Distributed transaction boundary

TCC核心分两个阶段：（1）尝试（Try）；（2）确认/取消（Confirm/Cancel）.先尝试操作数据，如果都成功则全部确认（Confirm）该修改；如果有任意一个尝试失败，则全部取消（Cancel）.简单说就是增加了中间态和可回改能力.

因环境问题等导致Confirm/Cancel方法执行失败时则通过间隔重试机制使Confirm和Cancel方法在环境恢复后及时执行，保证分布式事务的成功完成；如果多次重试后Confirm/Cancel方法仍然失败，则暂停执行以避免不断重试影响系统性能，并通过通知机制引入人工处理.即，允许损失部分响应时间和功能，但依然可用，系统数据状态允许在一段时间内不同步，系统要求数据的最终一致性而非实时一致性.具体操作如图10所示.

图10

新窗口打开| 下载原图ZIP| 生成PPT

图10 重试机制

Fig.10 Retry mechanism

4 案例分析

本文以微服务系统处理供应链销售流程为例进行分析.供应链销售流程如图11所示，客户下达采购订单后首先由部门经理审核，审核通过后由销售人员编制销售订单，然后提交经理审批，确认订单无误后传入会计主管进行单价核准.销售订单经审核后触发销售子流程，根据销售类型不同，如普通销售、跨公司销售、第三方销售，订单会触发不同的自由流，完成销售过程.

图11

新窗口打开| 下载原图ZIP| 生成PPT

图11 标准的销售流程

Fig.11 Standard sales process

打开流程监控系统，筛选标准销售流程，分析流程执行情况.发现大量流程停留在“经理审核”“会计主管核准”和“生成出库单”等节点，如图12所示.

图12

新窗口打开| 下载原图ZIP| 生成PPT

图12 流程统计

Fig.12 Process statistics

进一步分析各步骤耗时，如表3所示.

表3 流程步骤耗时表

Table 3 Time consumption of process steps

流程步骤	持续时间（min）	传递或等待时间（d）
订单制单	10	/
经理审核	5	0.5
会计主管核准	3	0.5
生成出库单	3	2
生成结算单	2	/

新窗口打开| 下载CSV

\begin{array}{l} \frac{增 值 时 间}{非 增 值 时 间} = \frac{23 m i n}{3 d \times 8 h \times 60 m i n} = \\ \frac{23 m i n}{1440 m i n} \times 100 % = 1.60 % \end{array}

由表可见，导致销售周期较长的主要环节是等待经理审核和会计主管核准以及生成出库单（库存经常不足，需临时调拨或采购）.要想对该流程进行优化，提升其运作效率，必须从以上几个环节进行压缩.

经分析公司标准销售流程发现，现行流程由销售管理部经理审核销售订单录入差错，销售管理部会计主管审核单价，两者均审核完毕之后才能通过.销售订单有一处错误，则需两者重新审核，影响审批效率.从流程优化的角度讲，应尽量压缩无效消耗.任何物品和文本的转移都要通过人员和设备来完成，不必要的转移将占用从事增值作业的时间.一份文件在不同人员之间进行转移，会造成大量的时间和人力浪费，而这些活动不会给客户带来任何直接或间接收益.因此，建议公司设置专岗对销售订单进行审核，简化流程审批步骤；同时，加强对流程执行人员的培养和教育，使销售员录入订单时尽量少出错，进一步减轻审批人员的工作量.

另一方面，现有流程设计是下达销售订单后，先去检查库存，若有货则直接出库，否则发起采购流程，等物品全部采购完成后再出库.由于客户购买的货物量可能较大，库存经常不满足出库条件，需等采购完成之后再出库，这无形中增加了流程的等待时间.

结合实际业务场景，可以配置销售订单生成交货单流程.此活动侦听销售订单的审核事件，销售订单审核通过后先查看库存量，对仓库中存有的货物立即生成提货单，而对缺货的物品发起采购流程.该流程执行完成后再调回预设流程，由提货单生成出库单，达到分批出库的目的，节省等待时间.

优化后的销售流程如图13所示.合并经理审核和会计主管核准为订单主管审核减少等待时间，同时在预设流程的基础上增加微服务架构下的自由流程，即销售订单生成交货单，减轻出库压力.

图13

新窗口打开| 下载原图ZIP| 生成PPT

图13 演化后的销售流程

Fig.13 Evolved sales process

流程优化后支持分批出库，这样即使仓库中的货品不能满足销售订单的所有需求数量，但可以根据客户的需求及库存量灵活配置发货方式.如图14所示，某客户需购买100台笔记本，分三次提货.经查询，仓库中12月剩余笔记本30台，可以先将这30台笔记本发货，同时仓库补货；1月和2月再分别发货30台和40台.这样既满足了客户的需求，也避免了等待采购物品的时间.

图14

新窗口打开| 下载原图ZIP| 生成PPT

图14 单据追踪

Fig.14 Document tracking

5 结论

在微服务系统的复杂体系下，如何对演化进行有效的描述、确定演化的影响范围并对影响程度进行评估是该领域中主要的研究问题.

本文的主要贡献在于提出包括流程层和服务层在内的服务系统双层依赖关系模型DDM，可以从服务演化、流程演化两方面分析服务系统演化问题.针对服务层演化，基于服务间的依赖关系，分析服务变更的影响范围，给出了服务依赖关系表达、依赖关系演化影响范围及求解和相应的算法；针对流程演化类型，给出了流程演化描述语言和影响程度的量化评价，从路由依赖和服务依赖两方面给出了完整的处理步骤和算法；基于流程演化影响评估算法，以量化的方式对演化的影响范围和程度进行了计算.但本文服务依赖关系的表述还比较单一，没有结合服务语义、输入输出、QoS等复杂依赖关系，需进一步深入研究以解决实际应用中的问题.

参考文献

原文顺序

文献年度倒序

文中引用次数倒序

被引期刊影响因子

[1]

Amjad Alam

， Ahmad

R B

， Akhtar

Change Impact analysis and propagation in service based business process management systems preliminary results from a systematic review

∥Proceedings of 2014 8th Malaysian Software Engineering Conference. Langkawi，Malaysia：IEEE，2014：7-12.