CN114020368A - 基于状态机的信息处理方法、装置和存储介质 - Google Patents

Abstract

本申请公开了一种基于状态机的信息处理方法、装置和存储介质，包括以下步骤：状态机根据接收到的信息和配置文件，对信息中的状态参数进行处理，其中，所述状态参数包括稳定态、进行态和完成态中的一种；当所述信息中的状态参数为稳定态时，所述状态机根据配置文件对信息进行调用处理服务。本申请实施例利用状态机原理实现分布式体系下多服务的自动化调用和信息流转，能够有效自动化处理订单的各种状态变化和服务调用。

Description

基于状态机的信息处理方法、装置和存储介质

技术领域

本发明涉及基于状态机的信息处理方法、装置和存储介质，属于计算机技术领域。

背景技术

目前，原始工作流一般基于服务节点对于信息状态的定义，例如：

(1)某服务前态：

对某服务定义信息的某服务前态，例如：待审批；

(2)某服务中间态：

对某服务定义信息的某服务中间态，例如：审批中；

(3)某服务完成态：

对某服务定义信息的某服务完成态，例如：审批完成。

不难看出，原始工作流的状态定义非常麻烦，必须为每一个服务定义三种状态，且前态与完成态重叠，因为前一服务的完成态与后一服务的前态是一致的状态，这就导致了状态无法稳定，不同服务修改状态，导致状态跳跃的情况。

现有技术中的工作流基于服务，对于状态的控制与保存归属于各个服务。在分布式和多服务体系下，由于其严重依赖于服务节点本身，当服务分布式部署于不同的***时，其他***会丢失对信息的最新状态描述，从而必须对于该服务进行查询或者随时通过订阅消息获取最新的信息状态。当信息量非常大的时候，这种信息状态的获取和更新就会变得异常频繁进而消耗大量的网络资源。而每一个服务所在的***都需要进行几乎相同的信息保存和更新操作，无论该信息处于什么样的状态，即便这种状态不需要本服务进行处理，也必须进行更新，这又会浪费大量的服务器资源和数据库资源。

此外，工作流引擎更符合单体应用的规则，或各服务统一使用共同的数据源，信息的内容和状态统一保存。但在分布式***中，由于各服务控制状态的变更，状态分布存储于不同的服务器之中，因此不得不广泛同步信息的状态，甚至冗余存储大量信息，且这些信息不具备实时性，对任意服务的访问都不能确认某一信息状态的实时真实性，因为可能在访问的过程中其他服务更新了状态，但是还未来得及同步到本地。

发明内容

本发明的目的在于提供一种基于状态机的信息处理方法、装置和存储介质，用于解决现有技术中存在的问题。

为达到上述目的，本发明提供如下技术方案：

一种基于状态机的信息处理方法，包括以下步骤：

状态机根据接收到的信息和配置文件，对信息中的状态参数进行处理，其中，所述状态参数包括稳定态、进行态和完成态中的一种；

当所述信息中的状态参数为稳定态时，所述状态机根据配置文件对信息进行调用处理服务。

优选地，步骤“当所述信息中的状态参数为稳定态时，所述状态机根据配置文件对信息进行调用处理服务”还包括：

在信息被调用服务后，所述状态机将信息中的状态参数修改为进行态。

优选地，在步骤“状态机根据接收到的信息和配置文件，确定该信息中的状态参数，其中状态参数包括稳定态、进行态和完成态”中，当该信息中的状态参数为进行态且该信息进行调用服务时，所述信息中的状态参数始终为进行态。

优选地，在步骤“状态机根据接收到的信息和配置文件，确定该信息中的状态参数，其中状态参数包括稳定态、进行态和完成态”中，当该信息中的状态参数为进行态且该信息完成调用服务后，所述状态机将所述信息中的状态参数修改为稳定态。

优选地，所述调用处理服务包括同步调用、异步调用、消息调用、定时调用、中断、等待人工处理中的至少一种。

优选地，包括根据工艺流程，对配置文件进行设置。

优选地，所述状态机对信息进行标记得到标记服务参数，所述标记服务参数包括前服务信息和后服务信息，其中，前服务信息包括至此稳定态之前最近一次执行的服务，所述后服务包括根据配置文件和条件指定的后继服务。

本申请实施例公开了一种基于状态机的信息处理装置，所述装置包括存储器和处理器，所述存储器中存储有至少一条程序指令，所述处理器通过加载并执行所述至少一条程序指令以实现如上述的方法。

本申请实施公开了一种计算机存储介质，所述计算机存储介质中存储有至少一条程序指令，所述至少一条程序指令被处理器加载并执行以实现如上述的方法。

本申请实施例利用状态机原理实现分布式体系下多服务的自动化调用和信息流转，从而可以处理公司订单的状态流转与处理。由于公司的订单不是单纯的网络应用，订单来源于多种不同的第三方平台，甚至可能来自于客户的线下交易，不同的订单汇总与订单中心，订单根据状态的不同进行自动化处理，并在需要时发送消息等待人工处理流程。本***能够有效自动化处理订单的各种状态变化和服务调用。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，并可依照说明书的内容予以实施，以下以本发明的较佳实施例并配合附图详细说明如后。

附图说明

图1示出了以信息为核心建立信息中心的示意图。

图2为本申请一个实施例的流程示意图。

图3为本申请另一个实施例的流程示意图。

具体实施方式

下面将结合附图对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。

在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

此外，下面所描述的本发明不同实施方式中所涉及的技术特征只要彼此之间未构成冲突就可以相互结合。

本申请实施例提供的基于状态机的信息处理方法，包括以下步骤：

状态机根据接收到的信息和配置文件，对信息中的状态参数进行处理，其中，所述状态参数包括稳定态、进行态和完成态中的一种；

当所述信息中的状态参数为稳定态时，所述状态机根据配置文件对信息进行调用处理服务。

其中，所述状态参数包括稳定态、进行态和完成态。信息状态定义，包括稳定态和完成态，但是不需要定义进行态。需要定义默认的失败状态，初始状态，错误状态。

(1)稳定态：

稳定态处于服务间的状态，可能是初始，也可能是某一服务执行结束后的状态。稳定态具有不同的编号，用以内部区分。但是展示时一般不显示编号，仅根据配置条件确定前后服务名称并加上状态词并拼接形成完整状态描述。例如：稳定态(初审结束，待审批)。

稳定态的信息处于等待服务过程中，对于不同类型的服务，信息处于稳定态的时间是不确定的，例如对于同步，异步调用，稳定态的存在可能只有毫秒级。而对于定时任务，等待人工干预等状态则可能会很长。

对任意稳定态，可以定义该状态下的以下信息：

(1)名称

(2)编号

(3)描述

(4)类型(稳定态)

(5)服务，服务需要定义以下内容

①服务URL

②服务名称

③服务参数

④服务配置(包括调用方式，重试机制，失败处理等内容)

⑤后续状态列表，状态列表中的后续状态需定义

1)状态编号

2)达成此后续状态所需的条件，条件由标准EL语言进行描述，例如：$address.isValid，参数可以取自“流转信息”中的全部内容

3)后续状态列表中所有条件集合必须达成完整性约束，也就是条件覆盖所有的可能性。

4)后续状态可以是稳定态，也可以是完成态，用状态编号进行标识。

(2)进行态：

进行态是指信息在进行某一服务处理的过程中。当所述信息中的状态参数为稳定态时，状态机可以在明确执行对服务的调用操作前进行更改并固化(稳定态至进行态)。

当该信息中的状态参数为进行态且调用服务回调后，状态机进行第二次修改(进行态至稳定态)。

(3)完成态：

完成态是整个流程的终结，完成态不具备后继服务，因此处于完成态的信息可以认为跳出了整个流程。信息的属性展示由状态加所有途经服务的结果组合而成。例如：完成态(预审结束，初审结束，审批结束)或完成态(预审结束，初审驳回，修改完成，初审结束，审批驳回)。对于完成态，需定义编号，名称，简称，说明等内容信息。

服务调用的方式可以包括如下：

(1)同步调用：

***根据配置条件同步调用服务，并等待服务结果的返回。配置中应配置重试和超时等数据信息，以确定服务调用失败的处理方案。当调用服务失败时具备重试和手工恢复能力。当服务确定失败且达至服务调用失败的阈值，***按照失败处理方案执行。

(2)异步调用：

***根据配置条件异步调用服务，调用成功后，将信息状态调整至执行态。配置中应配置重试和超时等数据信息，以确定服务调用失败的处理方案，同时应配置异步调用最长等待时间等参数，当长期未收到异步调用的回调时，***通过定期任务将超时的信息执行失败处理方案。

(3)消息调用：

***根据配置条件发送消息至特定消息队列，并订阅特定的回复消息。配置中应配置消息发送重试和消息超时等数据信息，以确定消息发送失败的处理方案。同时应配置本消息的最长处理时间等参数，当长期未收到异步调用的回调时，***通过定期任务将超时的信息执行失败处理方案。

(4)定时调用：

***定期执行任务，将裴志伟定时调用服务的信息打包处理，通过代码插件模式执行批处理操作，这种操作一般由代码控制执行，配置服务提供必要的参数。

(5)中断：

这是一种特殊的状态，一般用于需要人工干预，运维干预，网络故障，***故障等异常情况，此类服务调用谨慎使用

(6)等待人工处理：

类似中断方式，一般为需要人工处理的服务，正常人工处理服务，应采用消息调用模式，人工处理服务外置。此处等待人工处理类型的服务调用，主要用于配置不完善，等待完善等情况，一般在调试和测试阶段使用。

参照图1所示，信息中心可以由状态机，配置管理模块，固化保存模块，条件判断模块，对外服务模块，数据库，缓存，内部消息队列，外部消息队列等部分构成，可根据具体实例增加或减少。

1.状态机

用于调整信息状态的主核心模块，负责居中统合所有其他模块的运作，根据状态，配置，条件的不同调取不同的外部服务。

2.配置管理模块

用于管理所有配置信息，并对配置信息进行识别判断，提供给状态机作为运行依据

3.固化保存模块

用于配置，数据，信息，状态的保存和缓存通用模块，为信息中心提供基础数据保存能力

4.条件判断模块

用于对配置中的条件和参数进行解读，并形成最终的判断结果的功能性模块。

5.对外服务模块

对外提供各种信息查询，检索，状态罗列等信息服务的模块，是信息中心的对外窗口。

6.数据库

信息的核心存储位置，用于永久性固化保存信息

7.缓存

为提高性能使用的数据临时性存储位置

8.内部消息队列

用于信息中心内部服务使用的消息队列，主要用于信息状态变化的推送与订阅

9.外部消息队列

对消息状态变化同样提供对外服务的接口，允许外部应用或服务订阅使用消息的变化。

具体的，信息可以为原始信息和版本迭代信息。

原始信息可以从各个***以及各种复杂来源中到来的信息。原始信息中存储了核心内容的第一次进入信息处理装置的信息，核心内容可以为订单，工单，报销单等。

状态机可以根据到来的原始信息通过配置仓选取符合该原始信息流程文件的配置文件。状态机将原始信息的状态参数修改为稳定态，并且根据配置文件调用处理服务。

在原始信息被调用服务后，所述状态机将所述信息中的状态参数修改为进行态，此时原始信息经过调整变成迭代信息。在迭代信息被调用服务过程中，且调用服务并未结束的情况下，所述迭代信息中的状态参数始终为进行态。在调用服务结束后，所述状态机将所述迭代信息中的状态参数修改为稳定态。然后状态机根据配置文件和迭代信息继续下一个调用服务，直至迭代信息中的状态参数变为完成态。

当然的，迭代信息还可以用于保存原始信息的变更，迭代信息经过不同的服务***进行加工后，除原信息可能发生变化，还可能迭代存在其他的信息增补，修改，删除等情况，此类信息变更在***中会按照副本的方式多版本存储，每次服务后形成新的版本，最新版本为经最后一次服务处理的原始信息，下一次服务则总是在最新版本上进行修改。有些类型的原始信息不允许修改，则可忽略此类信息。

当然的，信息中还可以附有一些附属信息。附属信息可以包括各服务的签名，附加的附件，服务完成情况，错误信息，例外信息，这些信息采用约定的标准方式存放，此处不讨论具体的信息格式，但此格式必须满足各服务及信息中心通用，一般采用事先约定的方式形成标准格式，如XML，JSON等。状态机记录的信息状态变更也会于此处保留副本，以附属信息的一部分的方式存在，一般用于显示和校对。

图1示出了以信息为核心建立信息中心的示意图。该信息中心主要包括状态机、信息库、状态库、配置仓、状态服务配置管理器、配置服务等。配置服务可以根据各种实际工艺流程设置相应的配置文件，并且通过状态服务配置管理器将多个配置文件存储在配置仓中。状态机可以通过状态服务配置管理器调用出与信息适配的配置文件。

参照图2所示，当状态机通过监听消息队列监听到信息中的状态参数变化后，则根据配置文件调度外部服务(同步调用，异步调用，消息调用，定时调用，中断等待人工处理等)作用于本信息，各服务所在***完成处理后通过不同的手段(直接返回-对应同步调用，回调-对应异步调用，发送处理完成消息-对应于消息调用等其他调用方式)向信息中心提供调用结果。信息中心根据结果按照配置的方式调整信息状态参数，同时发送状态参数变更消息。循环进行此操作，直至信息的状态参数达至完成态。

举例说明：利用状态机实现订单流转操作。具体工作步骤为：

1.首先根据需求设计规划状态流转图(参看图3订单中心状态迁移图范例)。

2.形成根据1形成的流转图，生成配置文档(参看表1：节点配置信息)。

3.在配置文档中对个状态对应的服务进行配置，并约定各服务执行协议。

4.至此，状态机配置完成。

表1：节点配置信息

具体而言，信息中心是一个纯服务化应用，因此对外提供一系列的标准REST服务。后文统一用“信息服务”代称。

1.其他应用通过专用的信息服务将信息传输到信息中心

2.此时，信息中心调用状态机，并初始化该信息为初始稳定态。状态机默认配置文件中的第一个稳定态为初始稳定态，也可在配置文件中使用关键字“初始稳态”进行定义。

3.状态机发送“信息状态变更”消息至消息队列，该消息中包含信息的编号，原始信息，当前状态等内容。

4.状态机***获取到消息队列“信息状态变更”消息。

5.状态机根据消息中的“信息状态”和配置信息中对应此状态所完成服务的“后续状态列表”进行后续状态的判断，判断原则为配置信息中定义的达成后续状态的条件，条件中参数取值来源于此“流转信息”。

6.状态机根据5的结果调整当前流转信息的状态，重复执行3-6，直至流转信息的状态达至某一完成态，形成闭环，退出流程。

7.完成态可以是成功，也可以是失败，撤销等无需继续进行流程的状态，这些完成态同样在配置文件中进行配置。

本申请实施例与传统工作流的区别：

传统工作流以工作(work,job)为核心，以执行工作的服务为节点，任何信息在进入某一服务之前，信息标识为某服务前态，进入服务后则标注信息状态为服务中间态，完成服务后则标注信息状态为服务完成态。

这种以服务为节点的工作流机制在单体环境中运行良好，多个服务运行于同一环境中，每个服务对于信息的状态来源一致，因此不会出现信息误解。但是在分布式和多服务体系下，由于其严重依赖于服务节点本身，当服务分布式部署于不同的***时，其他***会丢失对信息的最新状态描述，从而必须对于该服务进行查询或者随时通过订阅消息获取最新的信息状态。当信息量非常大的时候，这种信息状态的获取和更新就会变得异常频繁进而消耗大量的网络资源。而每一个服务所在的***都需要进行几乎相同的信息保存和更新操作，无论该信息处于什么样的状态，即便这种状态不需要本服务进行处理，也必须进行更新，这又会浪费大量的服务器资源和数据库资源。

1.核心理念的差别

工作流基于服务，而本产品基于信息，服务是动词的概念化，而信息则是名词的概念化。比如，审批是服务，但是工单则是信息，原始工作流针对审批这一动作的概念化，对工单进行状态划分，待审批，审批中，审批完成。而本产品则对信息本身的状态进行描述稳定态(初审结束，审批前)，执行态(审批中)，完成态(审批完成)，无需独立命名每一状态，只需要加入其前后关联服务名称加上前、中、完成即可，当服务配置发生变化时，所有的状态会由于其配置变化而随之变化。

2.控制位置的差别。

传统工作流作用于不同的服务，因此对于状态的控制与保存归属于各个服务，而本产品则将状态的控制与保存归属于信息管理中心，由中心统一调配，服务仅仅处理信息并产生结果而已，不产生状态变化。这样的布局让信息本身得以控制自身的状态，增加服务节点，不会导致信息量的暴增，信息仅需要进行状态的变更。进而使信息状态的查询与检索都变得更加简单。

3.适配环境的差别

工作流引擎更符合单体应用的规则，或各服务统一使用共同的数据源，信息的内容和状态统一保存。但在分布式***中，由于各服务控制状态的变更，状态分布存储于不同的服务器之中，因此不得不广泛同步信息的状态，甚至冗余存储大量信息，且这些信息不具备实时性，对任意服务的访问都不能确认某一信息状态的实时真实性，因为可能在访问的过程中其他服务更新了状态，但是还未来得及同步到本地。而本产品信息集中管理于信息中心，信息中心本身可根据数据量和访问压力的要求进行各种分布式部署，但访问信息中心意味着获得最权威的数据信息。服务仅用于加工信息，而不对信息状态进行变更，信息中心获取服务结果后，根据结果反馈更新信息状态。进而激发下一步的服务调用，通俗的例子类似于调度室，信息中心调度各种服务为信息进行加工，但是各个服务无需为信息状态和全工作流程进行负责，服务变得更加专业化，简单化。

本申请实施例与传统状态机的区别：

传统状态机使用简单的状态变更表来进行状态变化描述，没有服务的概念，更多的是针对单机内部的某一数据的状态变更，常见的实例为工厂中对电压变化的监控，超过不同的阈值状态激发不同的处理方案。

本产品对状态机的使用场景进行了放大，将状态机的功能进一步扩展，形成状态变更，固化，配置，服务调用，消息提醒一体的全面解决方案。并从单机领域，扩展到微服务器分布式领域，使状态机这一传统计算机概念在新的领域绽放光彩。

由于本公司订单来源于多个不同第三方平台，甚至包括用户的线下交易。汇总的订单需要进行统一的调度和处理。本***就可以适配于以下各种不同的业务，例如订单来源复杂、订单处理流程分散于多个不同的***之中；不同***都需要获取订单状态，并展示；订单状态需要做到全方位可追踪；订单需要复杂的重复处理过程；订单处理流程根据不同的情况可能出现复杂的变化；同一节点下订单可能出现多种不同的状态。

本申请还提供了一种基于状态机的信息处理装置，所述装置包括存储器和处理器，所述存储器中存储有至少一条程序指令，所述处理器通过加载并执行所述至少一条程序指令以实现如上所述的方法。

本申请还提供了一种计算机存储介质，所述计算机存储介质中存储有至少一条程序指令，所述至少一条程序指令被处理器加载并执行以实现如上所述的方法。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (9)

1.一种基于状态机的信息处理方法，其特征在于，包括以下步骤：

状态机根据接收到的信息和配置文件，对信息中的状态参数进行处理，其中，所述状态参数包括稳定态、进行态和完成态中的一种；

当所述信息中的状态参数为稳定态时，所述状态机根据配置文件对信息进行调用处理服务。

2.根据权利要求1所述的基于状态机的信息处理方法，其特征在于，步骤“当所述信息中的状态参数为稳定态时，所述状态机根据配置文件对信息进行调用处理服务”还包括：

在信息被调用服务后，所述状态机将信息中的状态参数修改为进行态。

3.根据权利要求1所述的基于状态机的信息处理方法，其特征在于，在步骤“状态机根据接收到的信息和配置文件，确定该信息中的状态参数，其中状态参数包括稳定态、进行态和完成态”中，当该信息中的状态参数为进行态且该信息进行调用服务时，所述信息中的状态参数始终为进行态。

4.根据权利要求1所述的基于状态机的信息处理方法，其特征在于，在步骤“状态机根据接收到的信息和配置文件，确定该信息中的状态参数，其中状态参数包括稳定态、进行态和完成态”中，当该信息中的状态参数为进行态且该信息完成调用服务后，所述状态机将所述信息中的状态参数修改为稳定态。

5.根据权利要求1所述的基于状态机的信息处理方法，其特征在于，所述调用处理服务包括同步调用、异步调用、消息调用、定时调用、中断、等待人工处理中的至少一种。

6.根据权利要求1所述的基于状态机的信息处理方法，其特征在于，包括根据工艺流程，对配置文件进行设置。

7.根据权利要求1所述的基于状态机的信息处理方法，其特征在于，所述状态机对信息进行标记得到标记服务参数，所述标记服务参数包括前服务信息和后服务信息，其中，前服务信息包括至此稳定态之前最近一次执行的服务，所述后服务包括根据配置文件和条件指定的后继服务。

8.一种基于状态机的信息处理装置，其特征在于，所述装置包括存储器和处理器，所述存储器中存储有至少一条程序指令，所述处理器通过加载并执行所述至少一条程序指令以实现如权利要求1至7任一所述的方法。

9.一种计算机存储介质，其特征在于，所述计算机存储介质中存储有至少一条程序指令，所述至少一条程序指令被处理器加载并执行以实现如权利要求1至7任一所述的方法。

Images