[发明专利]一种业务状态的调节装置及方法

说明书

技术领域

本发明涉及计算机技术领域，尤其涉及一种业务状态的调节装置及方法。

背景技术

在各类需要对业务状态进行调节的系统或平台中，现有技术中包括两种技术方案。一种是被动式方案，以当前的业务状态为中心，如图1a所示，包括状态监控、状态判断和触发调节动作三个部分；另一种是主动式方案，以任务为中心，如图1b所示，包括任务管理、任务分发和状态统计三个部分。被动式方案需要对当前的各种业务状态进行监控，并根据监控结果做出判断，最终触发调节动作。主动式方案需要在进行应用架构设计时，考虑如何使任务按规则分发执行。

在各种业务状态的调节技术方案中，均依赖于应用的架构以及特征，包括如下两种方案：

方案一、

在业务处理逻辑中加入调节函数，通过静态或者动态配置调节参数，使得调节函数发生作用，从而影响业务状态。此种方案在多数软件中都会采用，在程序设计开发过程中可根据应用的需求随时加入，及时完成调节，并且在使用过程中，调节函数运行表现状态较稳定，不易出现错误。此种方案中，加入的调节参数通常包括如下几种：程序休眠n秒、间隔t秒轮询一次、在某个时间点触发某种业务行为、在某种业务行为发生时执行某个操作、循环执行次数等。

方案二、

在业务处理逻辑中，如图2所示，实现业务的各个处理过程的业务处理模块间通过缓冲模块连接，通过控制缓冲模块实现对业务状态的影响。管理模块通过判断程序，主动控制业务处理模块完成业务行为。业务处理模块间和业务处理模块中均可植入缓冲模块，来调节节奏。此种方案要求对业务处理逻辑进行建模之初，就要考虑到业务状态迁移逻辑，并植入缓冲模块。此种方案在大型系统中使用较为普遍，特别是对于具有普遍控制和调节行为的业务处理逻辑，可以共享使用相同的缓冲模块。此种方案中，调节参数除包括方案一中列举的各参数外，还能调节多个处理过程之间的节奏和状态，能够定义更复杂的业务处理逻辑。

现有技术中提供的两种业务状态的调节方案，存在如下的缺点：

方案一中必须在开发前期明确应用的需求，并且代码维护较为复杂，特别是对于调节参数的管理维护代价很大，且缺乏一致性，给应用的部署带来困难。实际使用中，灵活性较差，很难处理多个业务状态的动态调节。不适用于复杂的业务处理逻辑，并且一但发生需求变更，很难修改。

方案二要求在应用的需求明确之后，程序设计开发过程中必须考虑各种可能，在保证业务处理逻辑完整性的前提下，适度加入缓冲模块。并且，缓冲模块不可避免与业务处理程序产生了固定的依赖关系。新增和变化调节机制，均需重新编译和测试应用。

现有技术中提供的两种业务状态的调节方案，不存在通用且独立的调节装置或调节程序，而是采用与业务处理逻辑相关的处理方式，并且均采用主动式方案调节业务状态，均存在实现复杂、灵活性差、不同应用间不具有通用性的问题，需要根据应用的需求设计开发相应架构，是不可分离的紧耦合方式。虽然在实际应用中较为广泛，但均限定了在程序设计开发前期和过程中全面考虑应用的需求，并且加入相应的调节机制，均需要与业务处理程序一起编译再使用。现有技术中提供的两种业务状态的调节方案均是以任务为中心，响应速度较慢，调节范围有限，很难构造复杂的随机状态。并且，随着业务处理程序复杂度日益提升，加入调节机制的情况下，复杂度更高，可靠性下降。

因此，在不增加程序设计开发复杂度的前提下，提供通用、稳定、且易于管理维护的业务状态的调节机制，特别是在对业务状态调节需求较高的多用户、多任务、多并发应用中实现，成为现有技术中亟待解决的技术问题之一。

发明内容

本发明提供一种业务状态的调节装置及方法，用以提升业务状态调节机制的通用性、稳定性和可管理维护性。

本发明实施例提供一种业务状态的调节装置，包括状态机控制引擎和资源池控制引擎，其中：

所述状态机控制引擎，用于接收业务处理程序在业务的每个需要调节的处理过程的入口发起的状态请求，根据所述业务的处理过程状态机描述的当前的处理过程获取启动当前的处理过程所需的状态信息，并返回给所述业务处理程序；

所述资源池控制引擎，用于接收业务处理程序在所述业务的每个需要调节的处理过程中发起的资源请求，根据当前的处理过程从行为资源池中获取完成当前的处理过程所需的处理资源，并返回给所述业务处理程序。

本发明实施例提供一种基于上述调节装置的业务状态的调节方法，包括：