基于微服务的过程感知信息系统CBPs改进设计

李红卫,周 盛,郑 玮

(中航西安飞机工业集团股份有限公司,陕西 西安 710089)

1 技术发展背景

由于采用了新的互联网技术,如云计算和新兴的商业模式,组织能够建立协作网络,以灵活的方式执行协作业务流程(CBPs)。协作网络由自治的、地理分布的和异构的组织组成,这些组织协作以实现共同目标。在协作网络中组织之间的整合和协作是通过CBP建立和执行的。CBP指定了组织为实现共同业务目标而执行的角色之间交互的全局视图,它作为所涉及的组织间协作的合同基础[1-4]。协作网络的实施要求组织可以执行业务流程管理(BPM)生命周期到商定CBP的各个阶段。CBP管理的这些阶段需要进行以下处理,包含组织自主权;去中心化执行;消息交换的全局视图;点对点交互;充分表达通信。

当前基于互联网技术的CBP解决方案要求每个组织开发、实施和维护流程感知信息系统(PAIS)。PAIS是执行组织的集成业务流程所必需的,无论是使用自身的资源和基础设施如硬件、软件、网络等,还是吸引任何业务流程即服务(BPaaS)云解决方案,都需要依靠PAIS得以实现。其中,IBP定义了组织必须执行的公共和私人活动,以完成CBP中约定的消息交换,然而依赖自身的PAIS增加了组织的复杂性和成本,因为必须在本地配置和实施订阅云服务,以此相互交互。其中。最为重要的是使用可以使组织能够在协作网络中应用CBP管理的技术,从而能够以合理的成本访问易于集成的PAIS[5-7]。其在应用中流程如下:

第一步是提供一个合适的解决方案,允许组织根据指令同意执行的CBP按需生成的内容,并运用云计算技术部署和制定PAISs。现有研究也发现,实施基于的云解决方案基础设施即服务(IaaS)模型可以带来更敏捷的协作,其可以允许在任何时候建立协作,并更流畅地制定相关流程。这也使得提供平台即服务和软件即服务(SaaS)组织更加方便[8-11]。其在应用中所达成的解决方案解决了实施Pais所需的IT基础设施的高成本和复杂性的不足,同时改变了Pais平台过于僵化的问题。然而,其在应用中仍然存在额外的挑战,必须在CBPs平台和执行中将由每个组织的IBPs执行的活动的第三方或遗留系统之间完成重要的集成工作。此外,如消息交换的全局视图需要高级的全局监控服务,这即使在云中也难以实现。

值得注意的是,面向CBP的云解决方案必须处理与此范式相关的典型问题,例如便携性、弹性和隐私。为了构思一个独立于云提供商的平台,必须考虑可移植性。当制定几个IBP和PAISs时,弹性对于提高性能非常重要,因此使用适当的弹性控制器、定义正确的指标以及选择哪些组件应该具有弹性或不具有弹性是必要的[12-16]。这导致了面向用户提供适当的服务质量(QoS)级别需要具有适当程度的灵活性。一方面,微服务可以改善云平台和外部系统之间的集成,将微服务定义为IBP的流程活动和执行它的外部系统之间的接口,这使得平台的核心微服务能够在不考虑与外界连接的情况下完成工作。只需要将核心微服务与外部系统的微服务连接起来的适当且设计良好的接口和轻量级协议[17]。另一方面,容器化允许在不使用任何标准的情况下处理云计算环境中的可移植性问题,因为容器本身是可移植的,编排系统在容器级别可以实现适当的缩放机制,如果微服务使用容器来实现它们,可以从这种方法中受益。随着IBPs的每个活动被实现为微服务,所有业务流程本质上都可以在活动粒度上进行扩展。最后,可以在微服务级别应用跨所有剩余服务的身份服务,确保每个组织所需的隐私。

2 CBPs相关方法

云计算是创建基于互联网的分布式系统的新范例。从商业角度来看,云计算可以被视为提供按需服务的一种模式,允许组织仅在使用资源或应用程序时为其付费按使用量付费,而不是面对硬件和软件基础设施的采购和维护成本。云计算主要有三种服务模式:SaaS、PaaS和IaaS。其中,在SaaS模型中,应用程序作为服务提供,用户通过互联网按需访问。PaaS模型为构建云应用程序提供开发服务,而IaaS模型意味着通过虚拟化来提供硬件资源。云计算还提供了不同的部署模式,例如私有云、社区云、公共云和混合云[18-23]。在私有云中,基础设施仅由一个组织运营,并由该组织或第三方管理;在社区云中,多个组织共同构建和共享相同的云基础架构,该基础架构可以由第三方或其中一个组织托管;在公共云中,服务提供商拥有云架构的全部所有权,拥有自己的策略、价值、利润、成本计算和收费模式;混合云则是私有云、社区云或公共云的组合。除此之外,云联合一词包括来自不同提供商的服务,这些服务聚合在一个池中,支持基本的互操作性特性。云计算为需要更复杂编排的其他模型提供了基础,为数据计算、存储和交付功能提供API。

2.1 微服务和容器

微服务软件架构范例作为一种灵活执行和独立部署面向服务的软件系统的方法受到了广泛关注。这种架构风格的特点是一组小的独立服务,在自身进程中运行并通过轻量级机制进行交互,它们共同符合单个应用程序。

微服务架构通常与面向服务的架构(SOA)进行比较。SOA通常与Web服务协议、工具和格式相关联,例如SOAP、WSDL(Web服务描述语言)和WS-*系列标准,而微服务需要使用简单且轻量级的通信协议,该协议增强了服务之间的解耦,例如REST over HTTP,可以依赖多种格式(XML、JSON)。

将应用程序实现为一组像微服务这样的自治组件的缺点是它们形成了一个分布式系统,这也导致在应用中处理难度明显提升。面对这些困难,需要一个功能齐全的微服务架构,以满足系统架构的处理需求,并解决面临的主要问题。在应用中需要完成以下任务:(1)服务发现组件;(2)一个配置服务器将源代码与其配置解耦,无需重新部署代码即可更改应用程序配置;(3)负载均衡器组件,为了使应用程序具有可扩展性,能够将单个服务上的负载分布到多个实例中;(4)断路器组件,用于为协同工作的服务之间的依赖关系的链故障产品提供容错;(5)边缘服务器,API网关模式的实现,用于将外部API作为接口暴露给外界;(6)集中式日志服务,能够检测新的微服务实例并从中收集日志事件;(7)一个监控服务能够分析每个微服务的硬件资源消耗,当响应时间和/或硬件资源的使用变得不可接受时,帮助发现问题的根本原因[24-26]。

2.2 协作业务流程

为了执行协作,组织通过定义和执行协作业务流程(CBP)来集成业务流程,就共同的业务目标达成一致,协调行动并交换信息。协作的实现意味着组织可以贯穿业务流程管理(BPM)生命周期考虑到CBP的介入。期间分析和设计在BPM生命周期的各个阶段,组织不仅必须定义自身的CBP,还必须定义内部业务流程(IBP),这些流程对组织的公共和私有行为进行建模,并支持其在协作中执行的交互和角色。为了处理组织自治问题,CBP被定义为抽象过程,因此,其不能被一个集中的过程感知信息系统直接执行。相反,它们是通过各组织的综合业务计划以分散的方式执行的,并由各自的工作地点差价调整数指数执行。

履行BPM生命周期的阶段包括开发、配置和部署PAISs,这是每个组织执行其IBP和互操作管理CBP所需的,组织间的协作依赖于组织实施Pais的能力,以便能够执行自身的IBPs,并与其他Pais进行交互,以实现CBPs中商定的消息交换。最后,执行阶段包括通过每个组织的PAISs实际颁布IBP实例来“颁布”CBP,以执行组织需要执行的私人活动,以及与它们之间的消息交换相关的公共活动[27]。

因此,协作可以从两个不同的角度来定义:(1)考虑交互的控制流的全局视角。(2)考虑每个组织的公共和/或私人活动以及它们之间的交互点,即为本地视角。这些视角和所涉及的流程类型之间的对应关系,如图1所示。

图1 协作的本地视角与全局视角执行模式

全局视角描述了协作的全局和公共行为以及参与者的责任。这种行为由CBP表示,作为定义参与者之间交互发生顺序的单个控制流。这个视角可以通过使用编排图(BPMN)和交互协议(UP-ColBPIP)来定义和描述。本地视角描述了基于每个参与者活动的协作行为。从这个角度来看,协作被描述为业务流程的组合,这些业务流程定义了每个参与者的独立行为以及它们之间的交互。每个参与者都有自己的控制流和交互点。根据这个观点,可以为每个参与者定义两种业务流程:接口流程和整合流程。接口流程根据支持相互接收和发送消息的活动来描述参与者的公共和外部可见的操作。相反,集成过程描述了支持参与者在协作中所扮演的角色所需的公共和私人行为。私有行为添加了参与者内部业务逻辑所必需的内部活动和事件。

3 基于微服务的CBPs的架构原理

3.1 微服务平台提供的主要服务

在开始使用所提供的云服务之前,组织必须在云平台中注册并加入协作网络,并准备好就新的合作达成一致,宣布CBP将被执行。一旦所有组织都同意CBP模型,该平台将提供云服务,从CBP模型中为每个组织生成IBP模型。每个IBP模型都包含从相应组织的角度来看执行协作所需的活动,但它仍然是一个不完整的模型,必须用附加信息来实现,如私人行为、数据和资源。在完整的概念IBP模型中,有一些服务允许用特定PAIS支持的执行细节来配置它们,以便实现IBPs的可执行实现。最后,该平台为PAISs的按需生成提供服务,PAISs将执行已配置的IBP。一旦所有Pais生成并配置了各自的可执行IBP模型,组织就可以利用云服务,通过Pais分布式执行IBP实例来支持CBP的执行。所有的IBP都已经实例化和生效,消息传递和监控服务就开始了,这些服务使组织能够了解协作的全局状态。

3.2 微服务平台架构

由于组织无法通过公开或管理敏感信息的公共服务参与协作,因此在以前的架构中,建议此类组织使用私有云与公共服务所在的公共云进行交互。这使得组织有了更多的自主权,并且满足了其中一些组织想要维护和保存其IBP的私有信息和活动的要求。公共云包括支持平台所有功能的组件,包括管理与建立协作相关的方面的组件,以及必须对所有组织都具有全球性的其他功能;相反,私有云只有实现所有者组织的流程所必需的组件,以及提供与公共云和其全球服务的连接的存根。使用微服务可以部署在不同的云提供商上,甚至在私有基础设施上。用于访问协作和CBPs存储库等的服务需要对所有组织都是全局的,需要部署在公共云上。每个组织需要以私有方式访问的其余服务也可以部署在公共云中。但是也允许其他配置,因此任何组织都可以在私有云中部署他们所需的私有服务。部署在不同云中的服务通过通信服务相互通信。这意味着平台的最终实现可以在云联盟或混合云模型上完成,不会有任何不便。该平台的架构基本上分为五类组件/服务:基本组件/服务、共同事务、CBPs服务、BPs服务和PAISs服务。

基本组件和服务组包括提供功能齐全的微服务平台所需的典型组件和服务,即允许解决这种架构范式所暗示的挑战的众所周知的组件或服务,其中一些是微服务的典型模式的实现。

(1)服务发现:允许注册所有微服务,以及通过URL或IP地址将所需服务映射到实例的端点。

(2)配置服务器:为每个服务提供独立于其实现的配置设置。

(3)负载平衡器:将单个服务的负载分布到其多个实例中。

(4)服务自动缩放器:根据观察到的指标(如CPU利用率或其他与应用程序相关的指标)自动扩展服务实例的数量。

(5)日志服务:从每个微服务收集日志事件,并以结构化和可搜索的方式解释和存储这些日志事件。

(6)监控服务:当响应时间和/或硬件资源使用率变得过高时,收集监控服务故障所需的数据。

(7)对等通信服务:在不同云提供商/私有基础架构中部署的平台服务之间提供异步和可扩展的通信。

公共服务提供的功能被其余微服务提供的其余功能广泛使用。

(1)身份服务:管理在平台中注册的所有用户和组织的身份,确保他们可以访问所有公共数据(如CBPs存储库中的信息),保留每个组织的私有数据。

(2)前端服务:提供支持用户交互的接口,并将其请求委托给相应的微服务。

其余三组服务提供平台提供的业务核心服务。CBP服务允许访问CBP存储库、建立协作和监控CBP执行。

(1)CBPs知识库服务:管理对CBP模型库的访问,该库存储协作网络、组织间协作及其CBP模型。这些服务只能从公共云中获得,所有组织都可以访问。

(2)CBP到IBPs转换服务:提供实现以前工作中提出的基于MDA方法的操作从CBP模型生成特定组织的IBP模型。此方法意味着模型到模型的转换过程,该过程将CBP模型和目标组织角色作为输入,并自动生成IBP模板模型作为输出,该模型包含组织为在CBP中履行目标角色而必须实施的公共和私有活动以及控制流。

(3)CBPs管理服务:管理与建立协作关系相关的方面,协商选择他们参与的协作网络中所有组织同意的CBP模式。这项服务也只能从公共云中获得,所有组织都可以访问。

(4)CBPs舞蹈服务:允许在不同的独立IBP实例之间进行协调,这些实例被制定来执行CBP的实际执行,协调这些IBP之间的异步消息交换,以实现协作。这项服务需要在公共云上实施。

(5)CBPs监控服务:负责监控当前的CBPs执行状态,服务也必须在公共云上实现。

IBPs服务基本上是对访问IBPs存储库的服务进行分组,并根据CBP到IBPs转换服务。

(1)IBPs存储库服务:管理对IBP模型存储库的访问,该存储库存储每个组织拥有的IBP模型,以及组织可以定义在从CBP到IBP的转换发生时使用的模板。

(2)IBPs管理服务:管理每个组织的IBP模型,从IBPs存储库中保存/检索它们,并允许添加组织所需的私有活动,以完成从它们参与的CBP生成的模板。

最后,PAIS服务包括用于访问PAIS存储库、配置和部署每个组织的可执行IBP模型、编排它们的执行以及提供与外部服务和/或以前存在的遗留系统交互的接口的服务。

(1)PAISs知识库服务:存储已配置的每个组织的可执行IBP模型,链接到执行活动所需的所有外部服务和/或遗留系统。

(2)IBPs配置服务:根据将制定可执行IBP模型的PAISs,从完全完整的IBP生成可执行模型的规范,定义所有公共和私有行为以完成每个组织执行这些模型所需的活动,包括执行CBP编排所需的所有活动。

(3)PAISs管理处:按需管理每个组织的Pais,创建它们,加载和部署从Pais存储库中检索的可执行IBP模型,并充当IBPs编排服务,它将负责制定法律。

(4)IBPs编排服务:一旦制定了PAIS,该服务将管理IBP的执行,在执行IBP时需要调用的活动和服务之间进行编排。

(5)活动接口服务:充当与执行IBPs活动的外部程序或遗留系统交互的边缘服务器。

然后,考虑到它必须提供的服务,平台架构足够灵活,在云计算和微服务方面也必须考虑灵活性。必须为所有服务提供弹性,因此需要与服务自动缩放器和负载均衡器一起计算基本组的组成部分。考虑到平台被设想为独立于云提供商或私有云基础设施,可移植性是另一个重要问题;利用微服务架构可以通过容器基础设施轻松部署这一事实,这有助于建立平台的过程,无需任何标准即可实现可移植性。关于隐私,提供了两种处理敏感信息的方法:横向身份服务仅允许访问与特定组织相对应的服务和数据;组织可以在私有环境中部署平台,与公共云通信,但仅共享交互所需的信息在CBP中,保留其自己的敏感数据和流程。一般来说,基本组的组件/服务允许处理基于微服务的平台将面临的所有困难。

3.3 平台的实施

本次研究中给出了基于微服务的CBPs平台的实现细节。如前所述,在基础设施层面,有几种方法可以用来实现它,试图在云和可移植性、弹性、隐私和微服务要求微服务问题之间取得良好的平衡。例如,该平台可以部署在IaaS基础设施上,以支持公共云,其中的服务将可供所有组织使用。私有云可以由同一个或另一个IaaS提供商处理,甚至可以求助于私有IaaS基础架构。接下来,需要在这些基础设施上配置对微服务更友好的适当部署环境,例如Kubernetes作为Docker的编排器容器。另一种方法是直接使用容器服务/基础设施,例如Amazon Elastic Container Service 8(Amazon ECS)、Amazon Elastic Kubernetes Service 9(Amazon EKS)、Azure Kubernetes Service 10(AKS)或Red Hat OpenShift Container Platform 11。这里选择用于实验的选项是Kubernetes,因为它具有适当的扩展和负载平衡机制,以及基本组中剩余微服务的良好实现。Amazon EKS用于公共云服务和Red Hat OpenShift Container Platform对于私有云,因为两者都基于Kubernetes并提供托管Kubernetes集群(在第一种情况下运行在Amazon Web Services —AWS上,在第二种情况下运行在Red Hat Enterprise Linux上,这是私有云实施的理想选择)。这种基础设施大大简化了底层管理、配置和维护的各个方面,对于轻松快速地创建不同环境以以原型方式测试CBP平台的组件非常有价值。

CBPs平台的相关设计考虑主要是微服务,特别是业务核心服务。为实现协同控制合作提出了一种编排方法。编排需要一个中央服务,它将请求发送到其他服务并通过接收响应来监督流程。相反,编排假设没有集中化,并使用事件和发布/订阅机制来建立协作。几乎所有服务都根据编排模式工作,除了CBP编排服务和CBP监控服务。依赖于数据库的服务,如那些涉及存储库(CBP、IBP和PAIS)的服务,需要一种机制来实现跨越多个服务实例的事务。此类服务的实例不能拥有不同的数据库,因为整个平台不能简单地为每个实例使用本地ACID事务。每个本地事务更新数据库并发布消息或事件以触发下一个本地事务。

关于具体技术,几乎所有微服务的实现都使用了Spring Boot 12。前端服务需要一个具体的框架来与用户进行适当的交互。Spring Boot的一个优点是它与内置的嵌入式Apache Tomcat集成,因此前端是使用JavaServer Pages (JSP)开发的。存储库用于CBP、IBP和PAIS需要数据库连接。Spring Boot很容易集成到MySQL数据库中。用于实施CBPs编排服务,需要一种允许异步发送/接收消息的技术来完成微服务编排模式,因为所有IBP都是自主和分散的。为此,Spring AMQP 13 API用于与RabbitMQ 14消息代理进行交互。IBPs编排服务还需要一种附加技术来制定整个IBP可执行模型,并执行与其他IBPs的交互(通过CBPs编排服务的消息交换)以及外部系统之间的交互。任何基于微服务的流程引擎都是合适的,但在这种情况下,用于微服务编排的工作流引擎称为Zeebe 15用来。在Zeebe编排的工作流中,每个任务通常由不同的微服务执行,发送/接收任务可以轻松地与CBP编排服务交互。

4 过程感知信息系统改进设计应用

在过程感知信息系统协同业务流程改进设计中描述了基于微服务的平台的组件和服务之间的功能、适用性和交互,用于执行CBP。该分销网络是一个协作网络,包括电子产品零售商Megatronic和组装商和供应商Philkaw、Grundrive和Sanx。供应商以单独的点对点方式与零售商合作。每个供应商都与零售商建立独立的跨组织协作执行具体的CBP模型。Megatronic同意与Philkaw和Grundrive执行供应商管理库存(VMI)模型,以及与Sanx执行协作计划、预测和补货(CPFR)模型。Megatronic和Philkaw共享一个公共云,Grundrive和Sanx独立实施私有云。

为了使用该平台,零售商访问公共云的前端服务,利用身份服务进行身份验证,并使用CBPs管理服务创建协作网络电子产品协同分销,该服务通过CBPs存储存储库服务。接下来,零售商在平台中寻找供应商并向他们发送加入该网络的邀请。之后,供应商加入协作网络和零售商能够与它们中的每一个创建三个组织间协作,全部通过CBPs管理服务。每一次合作都表明了所采用的商业模式和组织所扮演的角色。组织可以使用CBPs管理服务来管理CBP模型,该服务与CBPs存储库服务交互以检索/存储模型。例如,零售商将几个CBP模型添加到CBP模型存储库中,作为与Sanx基于CPFR的协作的一部分,例如协作补货计划管理模型(CPFR流程)。图2显示了定义此CBP模型行为的BPMN中的编排图。

图2 Megatronic和Sanx之间的协同补货计划管理模型

在图3中,(a)从CBP模型中为每个组织生成IBP模型(使用模板)。(b)从具有所需私有活动的模板完成IBP模型以获得完整的IBP模型,一旦完成,获得可执行的IBP模型。(c)通过分散执行各个IBP来执行CBP。

该模型管理零售商和供应商之间的简单谈判过程,以就短期内几种产品的补货计划达成一致。从向零售商提出供应计划的供应商开始,零售商对其进行评估并决定拒绝、接受或提出反建议。决定发送给供应商。在拒绝或接受的情况下,该过程结束。相反,对于反建议,供应商对其进行评估并回复零售商接受或拒绝。在所有组织同意协作后,协作状态会自动设置为“活动”,并且可以通过CBP监控服务访问。CBPs管理服务调用CBPs存储服务以获取最终的CBP模型,然后调用CBP-to-IBPs转换服务从CBP生成每个组(Megatronic、Philkaw、Grundrive和Sanx)的IBPs的公共行为模型,作为不完整的IBP模型,最后使用IBPs存储库服务将它们保存在IBPs存储库中。CBP-to-IBPs转换服务采用提出的方法和工具来执行其操作。

从生成的不完整IBP模型中,通过前端服务和IBP管理服务,组织完成它们并添加他们考虑的所有私有活动以正确执行协作(图3(a)完整的IBP模型交互)。这在公共云和/或私有云中以相同的方式完成,并且仍然是根据与技术无关的语言来实现的。完成的IBP模型也通过IBPs存储库服务保存到IBPs存储库中。组织现在能够配置完整的IBP模型以生成可执行规范。再次,在前端服务的帮助下和IBPs管理服务,组织检索其相应的完整IBP模型并生成PAIS规范,以及与外部服务和/或遗留系统交互所需的所有信息和资源链接,吸引IBPs配置服务(图3(b)生成可执行的IBP模型交互)。可执行的IBP模型通过PAISs管理服务和PAISs存储库服务保存到PAISs存储库中。当可执行的IBP模型可用时,每个组织都可以制定自己的IBP并开始去中心化执行CBP(图3(c))。同样,这在公共云和/或私有云中以相同的方式完成。执行意味着访问PAIS存储库并检索可执行的IBP模型。这些可执行模型可供IBP编排服务使用,该服务最终将执行它们。在IBP执行期间,IBP编排服务使用CBP编排服务根据CBP,在IBP之间交换消息,并且还使用Activity接口服务将IBP模型的每个活动与适当的外部服务和/或遗留系统进行通信。协作状态现在设置为“执行中”。一旦执行所有IBP,每个组织都可以使用CBP监控服务跟踪协作状态。

(a)

5 结束语

本次研究为CBPs管理平台提出了一个基于微服务的架构。通过微服务及系统环境部署,基于微服务的云架构平台系统有效解决了执行CBPs的可移植性、弹性和隐私问题。该架构还为微服务的部署带来了更大的灵活性,支持IBP及其数据管理的微服务,可以部署在公有云上,也可以部署在私有云上。所提出的云架构满足了组织执行其IBP的自主性要求,同时也满足了CBP分散执行的要求,通过独立部署的服务满足了协同业务流程工作要求,并通过基于异步消息的微服务来支持CBP的执行,以及对这些进程的监控来提供CBP中消息交换的全局视图,发挥了微服务的技术价值,改善了过程感知信息系统协同业务流程。