一种基于微服务架构的工作流管理系统及信息管理方法

技术领域

本申请涉及信息管理领域，特别地，涉及一种基于微服务架构的工作流管理系统及信息管理方法。

背景技术

微服务架构(Microservice Architecture)是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。微服务架构的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

现有系统根据微服务架构高内聚、低耦合的原则，通常垂直划分为多个业务应用服务和应用支撑服务。比如预算编制服务、预算执行服务、核算报表服务等应用服务，和工作流服务、用户认证等应用支撑服务。根据各个微服务的数据规模、访问量、并发要求，对微服务进行分布式部署，工作流服务作为一个重要的应用支撑服务需要为其他业务应用服务提供工作流管理、工作流设计、工作流执行、工作流状态日志等应用支撑，数据规模、访问量、并发量大，对系统资源要求较高。

在应用系统中，工作流服务作为服务提供方，业务系统作为服务消费方，由业务系统请求工作流服务获取对应的待办/已办业务数据，当需要查询相关数据服务时，由于一个工作流由不同工作流服务完成，因此需要业务系统分别到调用不同的微服务进行查询，造成工作流服务压力大，业务查询效率不高。

发明内容

为了克服现有技术的不足，本申请提供一种基于微服务架构的工作流管理系统及信息管理方法，以解决当需要查询相关数据服务时，由于一个工作流由不同工作流服务完成，因此需要业务系统分别到调用不同的微服务进行查询，造成工作流服务压力大，业务查询效率不高的问题。

本申请解决其技术问题所采用的技术方案是：

一方面，提供一种基于微服务架构的工作流管理系统，包括业务系统和用于支撑所述业务系统的多个工作流服务，所述业务系统包括业务系统前端和业务服务，用户通过所述业务系统前端调用所述工作流服务，执行当前节点流程任务；所述业务服务中内嵌有工作流状态前置装置；

任一所述工作流服务执行完当前节点流程任务后，触发业务回调，将流程状态日志更新到所述工作流状态前置装置中，以便用户通过所述业务系统前端查询相应流程的待办信息和已办信息。

进一步地，所述工作流状态前置装置通过业务系统后台回调接口与所述工作流服务连接。

进一步地，所述工作流状态前置装置包括工作流状态前置装置访问器、工作流状态前置装置存储器和工作流状态前置装置更新器；

所述工作流状态前置装置更新器与所述业务系统后台回调接口连接，用于获取用户待办信息和已办信息；

所述工作流状态前置装置更新器与所述工作流状态前置装置存储器连接，用于更新存储在所述工作流状态前置装置存储器内的用户待办信息和已办信息；

所述业务系统前端通过所述工作流状态前置装置访问器与所述工作流状态前置装置存储器连接，用于在用户查询时，获取存储在所述工作流状态前置装置存储器内的用户待办信息和已办信息。

进一步地，所述工作流状态前置装置为独立组件，内部实现细节封装，通过预留的访问接口与业务系统前端以及业务系统后台回调接口连接。

进一步地，还包括：权限组件；

所述权限组件用于用户通过所述业务系统前端查询时，根据用户角色权限对工作流状态前置装置的待办信息和已办信息进行过滤。

另一方面，提供一种信息管理方法，应用于上述的工作流管理系统，所述方法包括：

当调用任一工作流服务执行当前节点流程任务后，通过业务系统后台回调接口获取所述流程状态日志；

根据所述流程状态日志更新工作流状态前置装置中所述流程的信息。

进一步地，所述根据所述流程状态日志更新工作流状态前置装置中所述流程的信息，包括：

获取所述流程状态日志所属业务；

根据所属业务获取对应的数据模型，根据所述数据模型从所述流程状态日志中获取流程信息；所述数据模型包括字段和所述字段对应的值域，所述字段包括：对象ID、业务单据ID、工作流实例ID，当前流程任务节点、下一流程任务节点、流程任务状态、用户、用户角色、操作类型、操作时间；

将所述流程信息更新到所述工作流状态前置装置中所述流程的信息。

进一步地，还包括：

接收用户通过业务系统前端发送的查询请求，所述查询请求包括用户角色和查询事项；

根据所述查询事项获取回复信息；

根据所述用户角色获取用户权限，从所述回复信息中筛选符合所述用户权限的信息作为目标回复信息；

将所述目标回复信息发送到所述业务系统前端。

进一步地，所述根据所述流程状态日志更新工作流状态前置装置中所述流程的信息，包括：

根据所述流程状态日志更新工作流状态前置装置中第一数据库中的所述流程的信息；

将第一数据库中的流程的信息同步到第二数据库中，所述第二数据库用于接收到访问请求时，从中读取数据。

进一步地，还包括：

当接收到目标流程的预设的结束指令时，对所述工作流状态前置装置中所述目标流程的信息进行移除操作，所述移除操作包括删除和/或移动到第三方存储。

有益效果：

本申请技术方案提供一种基于微服务架构的业务系统及信息管理方法，通过在业务服务中内嵌工作流状态前置装置，能够在每个工作流服务执行完当前节点流程任务后，利用回调机制，将流程状态日志更新到工作流状态前置装置中。由于工作流状态前置装置内嵌在业务系统中，这样用户查询相应流程的待办信息或已办信息时，直接在业务系统中的工作流状态前置装置即可查询，无需另外调用工作流服务，大大降低了工作流服务压力，且在工作流状态前置装置查询为业务系统内部查询，提高了查询效率。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种基于微服务架构的工作流管理系统结构示意图；

图2是本申请实施例提供的一种工作流状态前置装置结构示意图；

图3是本申请实施例提供的一种信息管理方法流程图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面结合附图和实施例对本申请的技术方案进行详细的描述说明。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所得到的所有其它实施方式，都属于本申请所保护的范围。

首先对现有的工作流管理系统进行说明，其采用微服务架构(MicroserviceArchitecture)是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。微服务架构的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。

本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

分布式部署是将数据分散的存储于多台独立的机器设备上，采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息。

任何的服务器的性能都是有极限的，面对海量的互联网访问需求，是不可能单靠一台服务器或者一个CPU来承担的。所以我们一般都会在运行时架构设计之初，就考虑如何能利用多个CPU、多台服务器来分担负载，这就是所谓分布的策略。不但解决了传统集中式存储系统中单存储服务器的瓶颈问题，还提高了系统的可靠性、可用性和扩展性。

分布式部署，就是把因为数据量大无法使用一台机器完成的项目或者是由于企业安全问题或是特殊要求等而把一个项目分开部署到不同服务器上，而处理各个部分正常通信的技术解决方案。比如，我数据库数据量太大导致系统操作缓慢，这时就需要在数据库集群，冗余等。分布式的实质就是把本来一台机器完成的任务，分配给多个机器从而提高效率。

微服务架构与传统的单体式方案的最大不同是微服务将应用的核心功能拆分成多项服务。每项服务可以单独构建和部署。服务之间需要互相通信。假设服务间每次通信都需要在调用方编码操作，那么必定会增加很大的工作量，并且造成代码冗余并且无法维护。

集成是微服务相关技术中最重要的一个。做得好的话，你的微服务可以保持自治性，你也可以独立地修改和发布它们；但做得不好的话会带来灾难。

在微服务的诸多优势中，最重要的是高内聚、低耦合。然而，我们仍然需要创建一个对最终用户有意义的集成体验，集成是微服务相关技术中非常重要的一个。既要保持微服务自治性，可以独立地修改和发布它们；也要考虑微服务之间的交互，服务的编排与通信。

在企业或政务管理过程中，绝大多数属于流程类业务，比如业务的分级审批工作、各类申请表单、公文签审、业务处理等。通过现代的技术手段将诸多繁琐复杂的业务流程自动化，并对其进行有效地管理便是工作流需要解决的问题。

工作流程管理系统其主要目标是对业务过程中各活动发生的先后次序以及和活动相关的相应人力或信息资源的调用，进行管理而实现业务过程的自动化。

现有系统根据微服务架构高内聚、低耦合的原则，通常垂直划分为多个业务应用服务和应用支撑服务。比如预算编制服务、预算执行服务、核算报表服务等应用服务，和工作流服务、用户认证等应用支撑服务。根据各个微服务的数据规模、访问量、并发要求，对微服务进行分布式部署，工作流服务作为一个重要的应用支撑服务需要为其他业务应用服务提供工作流管理、工作流设计、工作流执行、工作流状态日志等应用支撑，数据规模、访问量、并发量大，对系统资源要求较高。

为解决上述技术问题，为了减少工作流服务压力，提高查询效率，本申请在业务系统嵌入工作流状态前置装置，业务系统通过工作流回调机制，将工作流流转状态日志记录到业务系统的工作流状态前置装置。待办信息查询直接在业务服务内进行，不需要跨微服务间调用，提高查询性能。

下面结合附图对本申请实施例进行详细说明：

图1示出了一种基于微服务架构的工作流管理系统结构示意图。参照图1，本申请实施例提供了一种基于微服务架构的工作流管理系统，包括业务系统和用于支撑业务系统的多个工作流服务，业务系统包括业务系统前端和业务服务，用户通过业务系统前端调用工作流服务，执行当前节点流程任务；多个工作流服务用于支撑业务系统，业务服务和工作流服务属于微服务架构中的两种不同服务。

业务服务中内嵌有工作流状态前置装置；工作流状态前置装置封装了工作流状态日志相关信息数据，以及访问工作流状态日志信息的标准接口。

任一工作流服务执行完当前节点流程任务后，触发业务回调，将流程状态日志更新到工作流状态前置装置中，以便用户通过业务系统前端查询相应流程的待办信息和已办信息。

一个实施例中，工作流状态前置装置通过业务系统后台回调接口与工作流服务连接。其中，业务系统后台回调接口设置在业务服务中，此外，业务服务中还存储有业务单据表。

在实际操作中，业务系统前端调用工作流服务，执行当前节点流程任务，同时生成下一节点流程待办任务，更新流程状态日志。工作流服务执行业务回调接口，将流程状态日志更新到业务服务工作流状态前置装置。用户登录系统，通过访问业务服务工作流状态前置装置，查询相应业务的待信息和已办信息。

工作流状态前置装置封装了工作流状态日志相关信息数据，以及访问工作流状态日志信息的标准接口。业务系统待办信息查询不再需要跨微服务间调用，直接通过本地调用访问业务微服务内的工作流前置装置，提高查询性能。

为了保证系统的低耦合以及服务遍历，本申请实施例中对于工作流状态前置装置具有一定的设计原则，具体如下：

1、技术无关性

选择对具体实现技术没有限制的集成方式，便于服务的替换与移植。

2、服务易于消费方使用

业务消费方应该能很容易地使用工作流服务，获取相关工作流状态信息。

3、隐藏内部实现细节

工作流状态前置装置作为独立组件，封装内部实现细节，只暴露必要的访问接口，避免服务消费方与服务的内部实现细节绑定在一起，增加系统耦合。

图2示出了一种工作流状态前置装置结构示意图，如图2所示，工作流状态前置装置包括工作流状态前置装置访问器、工作流状态前置装置存储器和工作流状态前置装置更新器；

工作流状态前置装置更新器与业务系统后台回调接口连接，用于获取用户待办信息和已办信息；

工作流状态前置装置更新器与工作流状态前置装置存储器连接，用于更新存储在工作流状态前置装置存储器内的用户待办信息和已办信息；

业务系统前端通过工作流状态前置装置访问器与工作流状态前置装置存储器连接，用于在用户查询时，获取存储在工作流状态前置装置存储器内的用户待办信息和已办信息。

一个实施例中，还包括：权限组件；

权限组件用于用户通过业务系统前端查询时，根据用户角色权限对工作流状态前置装置的待办信息和已办信息进行过滤。具体地，接收用户通过业务系统前端发送的查询请求，查询请求包括用户角色和查询事项；根据查询事项获取回复信息；根据用户角色获取用户权限，从回复信息中筛选符合用户权限的信息作为目标回复信息；将目标回复信息发送到业务系统前端。

本申请实施例提供的工作流管理系统，通过在业务服务中内嵌工作流状态前置装置，能够在每个工作流服务执行完当前节点流程任务后，利用回调机制，将流程状态日志更新到工作流状态前置装置中。由于工作流状态前置装置内嵌在业务系统中，这样用户查询相应流程的待办信息或已办信息时，直接在业务系统中的工作流状态前置装置即可查询，无需另外调用工作流服务，大大降低了工作流服务压力，且在工作流状态前置装置查询为业务系统内部查询，提高了查询效率。

图3示出了一种信息管理方法流程图。如图3所示，本申请实施例提供一种信息管理方法，应用于上述实施例中的工作流管理系统，方法包括：

S11：当调用任一工作流服务执行当前节点流程任务后，通过业务系统后台回调接口获取流程状态日志；

S12：根据流程状态日志更新工作流状态前置装置中流程的信息。

具体地，获取流程状态日志所属业务；

根据所属业务获取对应的数据模型，根据数据模型从流程状态日志中获取流程信息；数据模型包括字段和字段对应的值域，字段包括：对象ID、业务单据ID、工作流实例ID，当前流程任务节点、下一流程任务节点、流程任务状态、用户、用户角色、操作类型、操作时间；

将流程信息更新到工作流状态前置装置中流程的信息。

其中，数据模型的字段和值域如表1所示：

一个实施例中，用户获取工作流待办/已办信息，通常还需要根据用户的角色权限对相关业务数据进行过滤，组件同时提供相关用户权限的处理逻辑；具体地：接收用户通过业务系统前端发送的查询请求，查询请求包括用户角色和查询事项；根据查询事项获取回复信息；根据用户角色获取用户权限，从回复信息中筛选符合用户权限的信息作为目标回复信息；将目标回复信息发送到业务系统前端。

由于业务应用广泛，数据规模大、访问频度高，为了进一步提升访问性能，可以通过读写分离，分离工作流状态前置装置读库和写库，提升业务交易能力。具体地，根据流程状态日志更新工作流状态前置装置中第一数据库(即写库)中的流程的信息；将第一数据库中的流程的信息同步到第二数据库(即读库)中，第二数据库用于接收到访问请求时，从中读取数据。

作为本申请一种具体实现方式，当接收到目标流程的预设的结束指令时，对工作流状态前置装置中目标流程的信息进行移除操作，移除操作包括删除和/或移动到第三方存储。用以避免工作流状态前置装置中存储数据过多。

本申请实施例提供的信息管理方法，通过在各个业务系统中嵌入工作流状态前置装置，业务系统访问工作流状态信息由跨服务的远程调用，转变为本服务内的本地调用。具有以下优点：降低工作流服务压力、提升业务查询效率以及提高待办信息查询准确度。

可以理解的是，上述各实施例中相同或相似部分可以相互参考，在一些实施例中未详细说明的内容可以参见其他实施例中相同或相似的内容。

需要说明的是，在本申请的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本申请的描述中，除非另有说明，“多个”的含义是指至少两个。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。