基于微服务架构的任务管理方法、系统、设备和存储介质

摘要

本发明提供一种基于微服务架构的任务管理方法、系统、设备和存储介质，所述任务管理方法包括：S10，接收并保存操作单；S20，按照业务逻辑通过多个微服务对所述操作单进行处理；S30，监控每一个微服务对所述操作单的处理结果：S31，当处理结果出现异常时，将所述操作单加入任务队列，并按照顺序重新处理所述操作单；S32，当所述操作单最终的处理结果未出现异常时，释放所述操作单。本发明技术方案中的微服务架构能够在操作过程中出现异常时，将操作单重新加入任务队列，且在出现异常的状态值达到预设的状态阈值时发出告警以提示后台人员进行检查，只有在所有微服务处理过程中没有异常时将操作单释放，从而有效的管理了整个操作单的处理流程。

说明书

技术领域

本发明涉及计算机技术领域，特别是涉及一种基于微服务架构的任务管理方法、系统、设备和存储介质。

背景技术

近年来，随着产品功能逐渐的增多，微服务架构越来越火爆，相应的，市场对其的要求也越来越高，微服务架构的运作原理是将单一的服务任务操作单划分成一个或一组微服务，并按照业务逻辑的顺序进行服务任务操作单的处理，各个微服务之间互相协调、互相配合，为用户提供最终价值。每个微服务运行在其独立的进程中，微服务间采用轻量级的通信机制互相沟通，每个微服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。

然而，在现有技术中，微服务架构中的业务逻辑和服务任务操作单的分割在微服务架构建立时就已经通过编码设置完成，业务逻辑基本无法进行变更，且在服务任务操作单的处理过程中，微服务架构无法对每个微服务的处理过程实现有效的管理和监控，此时一旦出现异常，微服务架构完全没有对应的跟进处理措施，从而引起的系统停摆，将严重影响企业的正常运营。

发明内容

鉴于以上现有技术的缺点，本发明的目的在于提供一种基于微服务架构的任务管理方法、系统、设备和存储介质，能够全程监控各个微服务对操作单进行处理的过程，并在处理过程中出现异常时，提供一套完整的操作处理方案。

本发明提供一种基于微服务架构的任务管理方法，其中，所述微服务架构包括多个微服务；所述任务管理方法包括：

S10，接收并保存操作单；

S20，按照业务逻辑通过多个微服务对所述操作单进行处理；

S30，监控每一个微服务对所述操作单的处理结果：

S31，当处理结果出现异常时，将所述操作单加入任务队列，并按照顺序重新处理所述操作单；

S32，当所述操作单最终的处理结果未出现异常时，释放所述操作单。

于本发明的一实施方式中，所述操作单保存在所述微服务架构的缓存中。

于本发明的一实施方式中，所述S31包括：

记录并更新处理结果出现异常的状态值；

判断所述状态值：

当所述状态值大于等于预设状态阈值时，停止处理所述操作单，并发出告警；

当所述状态值小于预设状态阈值时，将所述操作单加入任务队列，按照任务队列的重新处理所述操作单。

于本发明的一实施方式中，所述S31还包括：

保存出现异常的处理结果；

当所述状态值大于等于预设状态阈值时，将保存的处理结果作为告警信息进行反馈。

于本发明的一实施方式中，所述S32还包括：

当处理结果不是最终处理结果时，那么继续按照业务逻辑通过多个微服务对所述操作单继续进行处理。

于本发明的一实施方式中，所述任务管理方法还包括：根据所述操作单的处理状态更新并显示所述操作单的消息状态。

于本发明的一实施方式中，所述根据所述操作单的处理状态更新并显示所述操作单的消息状态的步骤包括：

所述操作单的处理状态为微服务处理中时，所述操作单的消息状态为“处理中”；

所述操作单的处理状态为出现异常并停止处理时，所述操作单的消息状态为“异常”；

所述操作单的处理状态为操作单被释放时，所述操作单的消息状态为“完成”。

本发明还公开了一种基于微服务架构的任务管理系统，其中，所述微服务架构包括多个微服务；所述任务管理方法包括：

存储模块，用于在接收到操作单后将操作单进行保存；

处理模块，用于依据任务队列按照业务逻辑通过多个微服务对所述操作单进行处理；

监控模块，用于监控每一个微服务对所述操作单的处理结果，并根据监控结果控制所述操作单的处理：

当处理结果出现异常时，将所述操作单加入任务队列，所述处理模块重新按照任务队列顺序处理所述操作单；

当所述操作单最终的处理结果未出现异常时，释放所述操作单，并输出处理结果；

当中间的处理结果未出现异常时，将该监控结果反馈给所述处理模块，所述处理模块继续按照业务逻辑对所述操作单进行处理。本发明还公开了一种基于微服务架构的任务管理设备，包括处理器，所述处理器和存储器耦合，所述存储器存储有程序指令，当所述存储器存储的程序指令被所述处理器执行时实现所述基于微服务架构的任务管理方法。

本发明还公开了一种计算机可读的存储介质，包括程序，当其在计算机上运行时，使得计算机执行所述基于微服务架构的任务管理方法。

如上所述，本发明提供的一种基于微服务架构的任务管理方法、系统、设备和存储介质，具有以下有益效果：

本发明技术方案中的微服务架构在接收到操作单时，先将该操作单挂起，随后监控按照业务逻辑对操作单进行处理的多个微服务，在操作过程中，若出现异常，则按照重试策略将操作单重新加入任务队列，且在出现异常的次数达到预设的次数阈值时发出告警以提示后台人员进行检查，只有多个微服务的处理过程中没有出现异常时，操作单才会被解锁。本发明对操作单不仅从处理流程上进行管控，而且会从每一个微服务的处理结果进行管控，实现了真正意义上的操作单的处理流程上的管控。另一方面，由于本发明对操作单处理流程上的管控是基于业务逻辑的，其可以根据不同的操作单的需要，对应编写业务逻辑，相对于现有业务逻辑固定的微服务架构，本发明的任务管理方法使得微服务架构的适用性更加广泛。

附图说明

通过参考附图会更加清楚的理解本发明的特征和优点，附图是示意性的而不应理解为对本发明进行任何限制，在附图中：

图1显示为本发明的微服务架构的框架示意图。

图2显示为本发明的基于微服务架构的任务管理方法的系统流程图。

图3显示为本发明的基于微服务架构的任务管理系统的原理结构示意图。

图4显示为本发明的基于微服务架构的任务管理设备的原理结构示意图。

附图标记：

存储模块100；

处理模块200；

监控模块300；

显示模块400；

记录单元310；

判断单元320；

任务管理设备500；

处理器510；

存储器520。

具体实施方式

以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其它优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，同时，本说明书中所引用的如“上”、“下”、“左”、“右”、“中间”及“一”等的用语，亦仅为便于叙述的明了，而非用以限定本发明可实施的范围，其相对关系的改变或调整，在无实质变更技术内容下，当亦视为本发明可实施的范畴。

需要说明的是，本实施例中所提供的图示仅以示意方式说明本发明的基本构想，虽图示中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的形态、数量及比例可为一种随意的改变，且其组件布局形态也可能更为复杂。

在日常生活中，微服务架构作为一种为了适应当前互联网服务而产生的软件架构，将整个服务划分成各种小的、互相连接的微服务，相比于将所有功能都打包在一个单体中，具有简单灵活、高效可靠、能够自由选择语言工具的特点。

本发明的任务管理方法是基于微服务架构的，其在微服务架构从运维页面处接收到操作单后，对操作单按照业务逻辑进行处理流程管理和监控，以保证操作单在无异常的情况下的正常处理。

如图1所示，在本发明的一优选实施例中，将任务管理方法进行程序编码，编码后进行压缩，优选地，以JAR包的形式；压缩后置于微服务架构中。具体地，位于微服务架构的接口处，直接接收来自于运维页面的操作单以便对操作单进行管理。优选地，JAR包可以根据操作单具体的业务逻辑进行编写，从而使得微服务架构可以处理不同业务逻辑的操作单。JAR包从运维页面接收并保存操作单，并控制微服务A，微服务B，微服务C按照业务逻辑对操作单进行处理；处理过程中，任意一个微服务处理结果出现异常，JAR包将保存的操作单重新加入任务队列MQ中，按照任务队列MQ的顺序重新处理操作单；若最后一个微服务，即微服务C，最终的处理结果表示无异常，则JAR包控制该操作单释放，并将该操作单输出至下一个微服务架构，即服务B。

如图2所示，本实施例提供一种基于微服务架构的任务管理方法，其中，在微服务架构中包括有多个微服务，则所述任务管理方法包括：

步骤S10、接收并保存操作单。

本实施例中的微服务架构优选采用了spring boot的自动配置技术，将该任务管理方法引入微服务架构，对多个微服务按照操作单的流程进行管理。

如图1所示，当从外界的运维页面接收到操作单的数据后，为了防止操作单处理过程出现异常后，无法找到原始操作单，所以首先将该操作单挂起，并进行保存。优选地，将该操作单保存至微服务架构的缓存中。在本发明的其它优选实施例中，还可将操作单保存至微服务架构的存储介质中，JAR包的缓存中等等。本发明对操作单的保存位置不做限制，只要任务管理方法中首先将接收到的操作单挂起并保存，均在本发明的保护范围内。

步骤S20、按照业务逻辑通过多个微服务对所述操作单进行处理。

操作单的处理，需要按照对应的业务逻辑控制微服务架构中的各个微服务来进行。其中，业务逻辑是根据操作单进行预先编写的。

在本发明的优选实施例中，JAR包的程序编码会根据具体的操作单的业务逻辑来编写，不同类型的操作单，对应不同的业务逻辑，因此也会编写对应的JAR包。相较于现有的微服务架构仅适用于一种业务逻辑，且不能更改，本发明的任务管理方法可以针对相同的微服务，按照不同的业务逻辑进行适应性的JAR包的编写。例如，如图1所示，处理操作单的业务逻辑为微服务A先对操作单进行处理，然后是微服务B进行处理，最后是微服务C进行处理，则本实施例中的微服务架构在接收到该操作单时，先将操作单挂起保存，然后按照业务逻辑，分别发送给微服务A，微服务B和微服务C进行操作单的处理。

步骤S30、监控每一个微服务对所述操作单的处理结果。

进一步地，本实施例的任务管理方法除了根据业务逻辑对各个微服务进行处理顺序管控之外，还对每一个微服务的处理结果进行监控，以保证操作单的正常处理。

在本发明的一优选实施例中，对微服务的处理结果的监控是通过数据一致性注解的方式来实现的。在处理过程中，一旦微服务所输出的处理结果发生异常，就可以被及时发现，使得整个服务任务能够正常执行。

优选地，本实施例的JAR包里的注解是根据AOP(Aspect Oriented Programming，面向切面编程)拦截机制。所谓AOP是通过预编译方式和运行期间动态代理实现程序功能的统一维护的一种技术。通过AOP拦截机制，可以对业务逻辑的各个部分进行隔离，从而使得业务逻辑各部分之间的耦合度降低，提高程序的可重用性，同时提高开发的效率。

在本发明的一优选实施例中，配置注解的时候，需要自行编码提供操作单的锁定方法和释放方法，然后在注解的参数里指定锁定方法，释放方法和重试次数以及重试的延迟时间。例如，注解类名为：name＝“业务场景名称”，needRetryFor＝“异常类名”beforeInvoke＝“锁定方法名(参数)”，afterInvoke＝“释放方法名(参数)”，maxRetryTimes＝最大重试次数，retryInterval＝重试间隔时间等等。最后，在该注解中，捕获处理结果异常情况并予以显示。进一步地，本实施例是通过开源工具包AspectJ的@Before，@AfterThrowing等注解去拦截配置有以上自定义注解的接口，Spring框架在微服务架构启动时会自动去扫描这些注解，从而达到监控的目的。

步骤S31、当处理结果出现异常时，将所述操作单加入任务队列，并按照顺序重新处理所述操作单。

当捕获到配置为异常情况的注解时，会将挂起的操作单重新加入任务队列，依据重试策略按照任务队列的顺序重新处理操作单。

具体的：

记录并更新处理结果出现异常的状态值；

判断所述状态值：当所述状态值大于等于预设状态阈值时，停止处理所述操作单，并发出告警；当所述状态值小于预设状态阈值时，将所述操作单加入任务队列，按照任务队列的重新处理所述操作单

在一优选实施例中，状态值为操作单处理过程中累积出现异常的次数。

则当监控到处理结果出现异常时，将次数加一，这里的次数表示该操作单在处理过程中重复不断重试后连续出现异常的次数。而在监控过程中，一旦监控到某个微服务的处理结果出现异常，本实施例中的微服务架构即将该操作单重新加入任务队列，任务队列中依次排有多个等待被处理的操作单，则该操作单按照顺序被重新处理。

判断出现异常的次数：

当所述次数大于等于预设阈值时，停止处理所述操作单，并发出告警；

当所述次数小于预设阈值时，将所述操作单加入任务队列，按照任务队列的重新处理所述操作单。

若不设置阈值，操作单如果一直重复处理反复出现异常，该操作单会一直重复进行处理。因此根据实际经验，预先设置一个阈值，当操作单累积重复处理后仍出现异常的次数达到该阈值时，则停止处理该操作单，同时发出告警，以提示进行检查。除了对操作单发生异常进行告警外，还会对异常的处理结果进行保存，以便操作人员进行纠错。

当所述次数大于等于预设阈值时，将保存的处理结果作为告警信息进行反馈。

当本实施例中的监控得到操作单出现异常的次数达到预设阈值时，将步骤S30中监控得到的处理结果作为告警信息，告警信息例如包括该操作单的方法参数，类名，方法签名和异常日志中的至少一种。

在另一种较优的实施例中，还可以通过监控操作单重试间隔时间的总时长来控制该操作单，在编码环节自定义注解类名：retryInterval＝重试间隔时间，拦截配置有包括retryInterval＝重试间隔时间在内的自定义注解的接口，Spring框架在微服务架构启动时自动去扫描这些注解，从而达到监控的目的。

通过预先设置时长阈值，并记录操作单重试间隔时间的总时长，当总时长达到时长阈值时，将停止处理所述操作单，并发出告警。

在本发明中，用于控制操作单的标准很多，如操作单重新执行的总时长、操作单在微服务架构中执行的总时长，在此不再一一列举，但均应包含在本技术方案的保护范围内。

步骤S32、当所述操作单最终的处理结果未出现异常时，释放所述操作单。

当操作单的整个处理过程，未监控到出现异常，则释放对该操作单的锁定。

步骤S32还包括：当处理结果不是最终处理结果时，那么继续按照业务逻辑通过多个微服务对所述操作单继续进行处理。

本实施例中的按照业务逻辑将操作单依次发送给多个微服务进行处理，业务逻辑中排最后的微服务输出的处理结果为最终处理结果。例如，当微服务A处理完操作单时，步骤S30未监控到处理结果出现异常，此时的处理结果不是最终处理结果，因此将操作单发送给微服务B，以此类推，直到在业务逻辑中排最后的微服务C处理完毕，此时微服务C的处理结果作为最终处理结果。

在本实施例中，任务管理方法还包括：

根据所述操作单的处理状态更新并显示所述操作单的消息状态。

本实施例中的操作单存在三种处理状态，分别为：

当微服务正在对操作单进行处理，则此时操作单的处理状态为微服务处理中，此处进行处理的过程包括了监控到微服务的处理结果出现异常，操作单重新进行处理的过程；

当本实施例中的微服务架构监控到微服务的处理结果出现异常，且停止对操作单进行处理时，此时操作单的处理状态为出现异常并停止处理；

当本实施例中的微服务架构未监控到微服务的最终处理结果出现异常时，操作单的处理状态为被释放。

则根据所述操作单的处理状态更新并显示所述操作单的消息状态的步骤包括：

所述操作单的处理状态为微服务处理中时，所述操作单的消息状态为“处理中”；

所述操作单的处理状态为出现异常并停止处理时，所述操作单的消息状态为“异常”；

所述操作单的处理状态为操作单被释放时，所述操作单的消息状态为“完成”。

具体的，操作单的消息状态用于显示在后台，以便后台人员的查询和监控，也起到了告警的作用。

如图3所示，本实施例还提供了一种基于微服务架构的任务管理系统，该任务管理系统中包括多个微服务，包括：

存储模块100，用于在接收到操作单后将操作单进行保存；

处理模块200，用于依据任务队列顺序按照业务逻辑通过多个微服务对所述操作单进行处理；

监控模块300，用于监控每一个微服务对所述操作单的处理结果，并根据监控结果控制所述操作单的处理：

当处理结果异常时，则将操作单加入至任务队列，以便处理模块200重新按照任务队列顺序处理操作单；

当最终的处理结果无异常时，则释放该操作单，并输出处理结果；

当中间处理结果正常时，则反馈给处理模块200，继续按照业务逻辑对操作单进行处理。

所述监控模块300还包括：

记录单元310，用于记录并更新处理结果出现异常的状态值；

判断单元320，用于判断所述状态值：

当所述状态值大于等于预设状态阈值时，停止处理所述操作单，并发出告警；

当所述状态值小于预设状态阈值时，将操作单加入至任务队列，以便处理模块200重新按照任务队列顺序处理操作单。

在本实施例中，存储模块100还用于保存出现异常的处理结果。

在本实施例中，任务管理系统还包括：

显示模块400，用于根据所述操作单的处理状态更新并显示所述操作单的消息状态：

当所述操作单的处理状态为微服务处理中时，显示模块400则显示所述操作单的消息状态为“处理中”；

当所述操作单的处理状态为出现异常并停止处理时，显示模块400则显示所述操作单的消息状态为“异常”；

当所述操作单的处理状态为操作单被释放时，显示模块400则显示所述操作单的消息状态为“完成”。

如图4所示，本实施例还提出了一种基于微服务架构的任务管理设备500，该任务管理设备500包括处理器510和存储器520，处理器510和存储器520耦合，存储器520存储有程序指令，当存储器520存储的程序指令被处理器510执行时实现上述任务管理方法。处理器510可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(Digital SignalProcessing，简称DSP)、专用集成电路(Application Specific Integrated Circuit，简称ASIC)、现场可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件；所述存储器520可能包含随机存取存储器(Random Access Memory，简称RAM)，也可能还包括非易失性存储器(Non-VolatileMemory)，例如至少一个磁盘存储器。所述存储器520也可以为随机存取存储器(RandomAccess Memory，RAM)类型的内部存储器，所述处理器510、存储器520可以集成为一个或多个独立的电路或硬件，如：专用集成电路(Application Specific Integrated Circuit，ASIC)。需要说明的是，上述的存储器520中的计算机程序可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，电子设备，或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。

本实施例还提出一种计算机可读的存储介质，所述存储介质存储有计算机指令，所述计算机指令用于使计算机执行上述的任务管理方法。存储介质可以是电子介质、磁介质、光介质、电磁介质、红外介质或半导体系统或传播介质。存储介质还可以包括半导体或固态存储器、磁带、可移动计算机磁盘、随机存取存储器(RAM)、只读存储器(ROM)、硬磁盘和光盘。光盘可以包括光盘-只读存储器(CD-ROM)、光盘-读/写(CD-RW)和DVD。

如上所述，本发明提供的一种基于微服务架构的任务管理方法、系统、设备和存储介质，具有以下有益效果：

本发明技术方案中的微服务架构在接受到操作单时，先将该操作单挂起，随后监控按照业务逻辑对操作单进行处理的多个微服务，在操作过程中，若出现异常，则按照重试策略将操作单重新加入任务队列，且在出现异常的状态值达到预设的状态阈值时发出告警以提示后台人员进行检查，只有多个微服务的处理过程中没有出现异常时，操作单才会被解锁，从而有效的管理了整个操作单的处理流程。

上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。