Rule engine hot updating method and device based on version binding

Abstract

The application provides a bidirectional collaborative enhancement method for tax knowledge ontology and large language models, which comprises determining and binding a corresponding target rule version when a service request is created; and in the execution process, according to the version binding relationship, a specific rule engine instance is obtained from a version engine pool coexisting with multiple version engine instances to execute decision logic. Through the application, the influence range of rule hot updating can be accurately limited to newly created service requests, thereby ensuring the consistency of decision logic before and after long-period running tasks, and truly realizing zero-downtime non-susceptible upgrading. Meanwhile, combined with fine-grained gray version allocation and task granularity rollback mechanism, the risk of new rule online is significantly reduced and the flexibility of fault recovery is improved. The application can reduce the error rate of automatic tax tasks caused by rule updating to near zero, and shorten the rollback recovery time from hours to minutes.

Description

Technical Field

[0001] This invention belongs to the field of computer software technology, and specifically relates to a method and apparatus for hot updating a rule engine based on version binding. Background Technology

[0002] Rule engines are widely used in the field of business decision automation, such as financial and tax accounting and risk control auditing. Because business rules need to be adjusted frequently, rule engines need to have hot update capabilities, that is, to switch rules without stopping the system.

[0003] Currently, mainstream rule hot update solutions typically employ a version switching mechanism. Upon detecting a new rule version, the system loads it and sets it as the globally effective version. All subsequent decision requests are executed using the new rule version. Some solutions also support multiple versions coexisting, allowing manual reverting to a previous version when necessary.

[0004] However, the above solution has significant drawbacks when handling service requests with long execution cycles. A complex business task typically involves multiple sequential decision-making steps, and the entire execution process can last for a considerable time. During task execution, if the system triggers a version switch, subsequent steps that have not yet been completed will be forced to use the new version's rules for decision-making. The new version's rules may differ from the old version in terms of parameter values ​​and judgment conditions. This results in the same task being calculated using different versions of rules, producing inconsistent decision results and easily leading to calculation errors. In scenarios such as finance and taxation, where consistency of results is strictly required, such errors can cause tax accounting deviations and even compliance risks.

[0005] Furthermore, the existing solution has a coarse-grained version switching mechanism, only supporting global activation or global rollback. When the new version rules have flaws, the scope of the failure cannot be narrowed, and the risk is uncontrollable. At the same time, the existing solution also lacks the ability to accurately roll back and repair individual or batch affected tasks, resulting in low efficiency in post-failure handling.

[0006] Therefore, existing technologies have certain limitations. Summary of the Invention

[0007] This invention is made to solve the above-mentioned problems, and aims to provide a method and apparatus for hot updating a rule engine based on version binding.

[0008] This invention provides a method for hot updating a rule engine based on version binding, characterized by the following steps: S1. In response to the creation of a service request, determine the target rule version corresponding to the service request; S2. Bind the identifier of the target rule version to the service request to generate a version binding relationship; S3. During the execution of the service request, based on the version binding relationship, obtain the rule engine instance corresponding to the target rule version from the pre-built version engine pool; S4. Execute decision logic through the rule engine instance to process service requests.

[0009] Further, in step S1, the target rule version corresponding to the service request is determined, including obtaining business attribute information related to the service request; and the target rule version is determined from multiple available rule versions based on the preset canary release strategy and business attribute information.

[0010] Furthermore, the canary release strategy includes at least one of the following: allocation based on business traffic ratio and matching based on business attributes; Among them, the matching strategy based on business attributes includes at least one of the following dimensions: the industry category of the request initiator, identifier, regional affiliation, or task type of the service request.

[0011] Furthermore, it also includes S5, which receives a rollback instruction when a service request fails to execute due to an anomaly in the target rule version; S6. According to the rollback instruction, remove the original version binding relationship of the service request and rebind the service request to another specified rule version; S7. Based on the re-bound version binding relationship, obtain another rule engine instance corresponding to another specified rule version, so as to re-execute the service request through the other rule engine instance.

[0012] The present invention also provides a version-bound rule engine hot update device, characterized by: The version determination module is used to determine the target rule version corresponding to the service request in response to the creation of the service request; The version binding module is used to bind the identifier of the target rule version to the service request, thereby generating a version binding relationship; The instance acquisition module is used to obtain a rule engine instance corresponding to the target rule version from a pre-built version engine pool based on the version binding relationship during the execution of a service request. The execution module is used to execute decision logic through the rule engine instance to process service requests.

[0013] Furthermore, the version determination module is specifically used to obtain business attribute information related to the service request; and to determine the target rule version from multiple available rule versions based on the preset canary release strategy and business attribute information.

[0014] Furthermore, the canary release strategy includes at least one of the following: allocation based on business traffic ratio and matching based on business attributes; Among them, the matching strategy based on business attributes includes at least one of the following dimensions: the industry category of the request initiator, identifier, regional affiliation, or task type of the service request.

[0015] Furthermore, it also includes a rollback processing module, used to unbind the original version binding of the service request and rebind it to another specified rule version when the service request fails and a rollback instruction is received; and Based on the re-bound version binding relationship, the instance acquisition module obtains another rule engine instance corresponding to another specified rule version, and the execution module re-executes the service request.

[0016] Furthermore, it also includes a resource recycling module, which is used to remove a rule engine instance and release its resources when it is detected that all service requests corresponding to any rule engine instance in the version engine pool have been completed and the retention conditions are met.

[0017] The role and effect of invention This invention provides a version-bound rule engine hot update method and apparatus. By establishing a pre-bound relationship between service requests and specific rule versions, and strictly invoking the corresponding rule engine instance according to this binding relationship throughout the entire execution cycle of the service request, it fundamentally avoids the problem of inconsistent decision-making caused by rule version switching during long-cycle task execution. This mechanism ensures that rule hot update operations only affect newly created service requests and do not interfere with existing tasks already in the execution process, thus achieving truly zero-downtime, seamless hot updates and ensuring the logical consistency and calculation accuracy of every business decision result.

[0018] Meanwhile, by introducing a configurable canary release strategy in the version determination stage and supporting fine-grained version allocation based on business attribute information and traffic ratios, new version rules can be applied to specific categories of service requests in a controlled and gradual manner. This limits the risk exposure of potential defects in new rules to the expected range, significantly reducing the risk of large-scale deployment. In the event of anomalies, the version rollback mechanism based on service request granularity can accurately and independently revert and re-execute individual or batch tasks affected by erroneous rules, avoiding the widespread impact of global rollback and greatly improving the flexibility and efficiency of fault recovery.

[0019] In addition, by continuously monitoring the task binding status and retention conditions of each version of the rule engine instance, the system can automatically identify and reclaim outdated version engine resources that no longer have task dependencies, effectively preventing memory bloat caused by frequent updates during long-term operation and ensuring the overall service performance and stability of the system. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating a version-binding-based hot update method for a rule engine according to the present invention. Detailed Implementation

[0021] To make the technical means, creative features, objectives and effects of this invention easier to understand, the following embodiments are described in detail with reference to the accompanying drawings.

[0022] like Figure 1 As shown, this invention provides a version-bound hot update method for rule engines, which can be deployed and implemented in various software systems that require the execution of complex business rules and have long operation cycles. The method includes the following steps: S1. In response to the creation of a service request, determine the target rule version corresponding to the service request; S2. Bind the identifier of the target rule version to the service request to generate a version binding relationship; S3. During the execution of the service request, based on the version binding relationship, obtain the rule engine instance corresponding to the target rule version from the pre-built version engine pool; S4. Execute decision logic through the rule engine instance to process service requests.

[0023] In this embodiment, the method of the present invention is further illustrated using the actual application scenario of an enterprise financial reporting system as an example. However, those skilled in the art should understand that the application scope of the present invention is not limited thereto.

[0024] Specifically, financial reporting systems frequently need to adjust their internal rules regarding tax rate calculations, pre-tax deductions, and preferential treatment determinations based on national tax policies. To meet the requirements of uninterrupted service and high accuracy, the system adopts the solution of this invention for rule management.

[0025] When a new tax filing service request is triggered and created, the system proceeds to step S1, which determines the target rule version corresponding to the service request. In this step, the method for determining the target rule version is not by default using the latest or globally effective version currently in effect, but rather by the system calling a gray-scale strategy decision engine to perform dynamic decision-making. Specifically, the system first obtains business attribute information related to the service request. This information is extracted from the service request's creation context and system configuration, such as the industry category of the initiating enterprise, the enterprise's unique identifier, its regional affiliation code, and the specific task type of this service request.

[0026] Next, the system loads the currently effective canary release strategy from the strategy configuration library and matches it with the aforementioned business attribute information as input parameters. The canary release strategy predefines a series of matching conditions and corresponding target rule version numbers. For example, a strategy can be configured to allocate 10% of service requests with the industry category "High-tech Enterprise" and the task type "R&D Expense Deduction" to the new rule version "v20260501" used for canary verification, while the remaining requests continue to use the current stable rule version "v20260315". The system achieves precise control of this ratio by calculating the hash value of the service request identifier and performing modulo operations, ultimately determining a specific and unique target rule version number for this service request.

[0027] Subsequently, in step S2, the system binds the identifier (i.e., version number) of the determined target rule version to the current service request to generate a version binding relationship. The establishment and persistence of this binding relationship is the core of this invention's version isolation mechanism. Specifically, when a service request task is created, the system writes the task's globally unique identifier and the determined rule version number as an association record into a data table specifically used to maintain task state and context information (e.g., the aforementioned t_task_state table). This means that the rule version selection occurs at the source of task creation and is recorded as an inherent attribute of the task. From then on, the entire subsequent execution process of the service request will be strictly locked to this bound version number, completely unaffected by any subsequent hot update operations that may occur in the system.

[0028] When a service request enters the execution process and needs to call the rule engine to execute specific decision logic, step S3 is triggered. The system retrieves the rule version number bound to the service request from the task status record based on the service request's identifier. Based on this version number, the system does not directly call a single global rule service, but instead obtains an independent rule engine instance that strictly corresponds to that version number from a pre-built structure called the "version engine pool." The version engine pool is a key technical component of this invention for achieving runtime isolation between multiple versions. Its internal structure is a mapping table where the key is the string-type rule version number, and the value is a uniquely created and fully functional rule engine container instance that corresponds to that version number. This container instance can be a KieContainer object dynamically compiled and built based on rule engine frameworks such as Drools, which encapsulates all executable code and data for a complete rule version. When the system detects a change in a rule file in the configuration center or file system, it automatically parses the new rule content (such as a DMN definition file), dynamically compiles and generates a brand new KieContainer instance for the new version, and registers its version number and instance mapping relationship in the version engine pool. Throughout the process, the original KieContainer instance serving the old version requests remains unchanged, thus achieving safe coexistence and physical isolation of multiple old and new version engine instances in memory.

[0029] Finally, in step S4, the system calls the decision interface of the specific rule engine instance previously obtained from the version engine pool, passes in the factual data required for the current service request, executes the complete decision logic, and obtains the processing result. Since different service requests are routed to their respective version engine instances according to their binding relationships, the absolute consistency of the decision logic within long-cycle tasks is ensured by the mechanism.

[0030] Furthermore, to address anomalies after rule deployment, the method of this invention may further include the following steps: When a service request fails to execute due to a confirmed logical defect in the target rule version it is bound to, the operations or management system will issue a rollback instruction for the affected request. In step S5, the system receives this instruction. Subsequently, in step S6, the system automatically performs a version rollback according to the instruction. This operation is not a global version switch, but rather a precise modification of the rule version number field bound to the specific service request in the database task status table, changing it from the defective new version number to another specified, verified, and reliable old version number. Finally, in step S7, the system, based on the updated version binding relationship, re-triggers the execution flow of the task, causing it to obtain the specified old version rule engine instance from the version engine pool and recalculate the decision, thereby completing a refined repair of the erroneous task without affecting other normal service requests.

[0031] To achieve automatic optimization of system resources, the method of this invention also provides step S8: An asynchronously executed resource reclamation scheduling task periodically checks the task association status and retention time of each rule engine instance in the version engine pool. When the check determines that no active or pending service request is currently bound to a historical rule version (e.g., a gray-scale version that has been offline for several days), and the last time this version was used was more than the preset retention grace period (e.g., 24 hours), the system determines that the engine instance of this version is a reclaimable resource. Subsequently, the system will actively call the destruction method of this instance (e.g., the dispose method of the KieContainer object) to release all the memory resources it occupies and completely remove its corresponding mapping entry from the version engine pool, thereby completing the automatic cleanup of old version resources and effectively preventing memory bloat and performance degradation problems that may be caused by long-term version accumulation.

[0032] To implement the above method, the present invention also provides a hot update device for a rule engine based on version binding. This device, through the collaborative work of various software functional modules, constitutes a complete system, including: a version determination module, a version binding module, an instance acquisition module, and an execution module.

[0033] The version determination module is responsible for using a gray-scale strategy to determine the target rule version to be bound when a service request is created.

[0034] The version binding module is responsible for performing the specific binding operation, that is, establishing an association between the determined version number and the service request identifier in the task status storage area.

[0035] The instance acquisition module serves as the core routing component. When the service is executed, it retrieves the correct rule engine instance from the version engine pool that manages the coexistence of multiple version instances based on the binding relationships in the task status storage area.

[0036] The execution module is responsible for driving the final decision-making process of this instance.

[0037] In addition, to support more comprehensive system functions, the device also includes a rollback processing module and a resource recovery module, which correspond to the rollback step and resource recovery step in the aforementioned method, respectively. Through independent modular design, refined fault recovery capabilities and automated resource management capabilities can be more clearly integrated into the entire device system, ensuring the robustness and resource efficiency of the system under long-term operation.

[0038] The role and effect of the embodiments During the execution of the tax declaration task, regardless of whether the system loads a new version of the tax rules from the configuration center and builds a new rule engine container, the task always calls the old version container instance bound to it at the time of its creation for calculation. This ensures that the decision-making basis in the series of processes such as tax calculation, deduction, and declaration remains completely consistent, fundamentally eliminating calculation errors caused by concurrent version changes.

[0039] Meanwhile, operations and maintenance personnel can modify the canary deployment configuration to initially make the new version of the tax rules available to a small number of specific types of enterprises. Once the logic of the new rules is verified to be correct, it can then be rolled out to all enterprises, effectively limiting potential calculation risks to a controllable range. In the event of a miscalculation, only the version number associated with the affected enterprise's tax filing task can be modified to trigger an automatic recalculation, without requiring a global rollback for all business operations.

[0040] The above embodiments are preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A hot update method for a rule engine based on version binding, characterized in that, Includes the following steps: S1. In response to the creation of a service request, determine the target rule version corresponding to the service request; S2. Bind the identifier of the target rule version to the service request to generate a version binding relationship; S3. During the execution of the service request, according to the version binding relationship, obtain a rule engine instance corresponding to the target rule version from the pre-built version engine pool; S4. Execute decision logic through the rule engine instance to process the service request.

2. The method according to claim 1, characterized in that: In step S1, determining the target rule version corresponding to the service request includes obtaining business attribute information related to the service request; and determining the target rule version from multiple available rule versions based on a preset canary release strategy and the business attribute information.

3. The method according to claim 2, characterized in that: The canary release strategy includes at least one of the following: allocation based on business traffic ratio and matching based on business attributes; The matching strategy based on business attributes includes at least one of the following dimensions: the industry category of the request initiator, identifier, regional affiliation, or the task type of the service request.

4. The method according to claim 1, characterized in that, Also includes: S5. When the service request fails to execute due to an anomaly in the target rule version, a rollback instruction is received; S6. According to the rollback instruction, remove the original version binding relationship of the service request and rebind the service request to another specified rule version; S7. Based on the re-bound version binding relationship, obtain another rule engine instance corresponding to the other specified rule version, so as to re-execute the service request through the other rule engine instance.

5. The method according to claim 1, characterized in that, Also includes: S8. When it is determined that all service requests bound to any rule version in the version engine pool have been processed and the rule version meets the preset retention conditions, the rule engine instance corresponding to the rule version is removed from the version engine pool and the system resources it occupies are released.

6. A hot update device for a rule engine based on version binding, characterized in that, include: The version determination module is used to determine the target rule version corresponding to the service request in response to the creation of the service request; The version binding module is used to bind the identifier of the target rule version to the service request, thereby generating a version binding relationship; The instance acquisition module is used to, during the execution of the service request, acquire a rule engine instance corresponding to the target rule version from a pre-built version engine pool according to the version binding relationship; The execution module is used to execute decision logic through the rule engine instance to process the service request.

7. The apparatus according to claim 6, characterized in that: The version determination module is specifically used to obtain business attribute information related to the service request; and to determine the target rule version from multiple available rule versions based on the preset canary release strategy and the business attribute information.

8. The apparatus according to claim 7, characterized in that: The canary release strategy includes at least one of the following: allocation based on business traffic ratio and matching based on business attributes; The matching strategy based on business attributes includes at least one of the following dimensions: the industry category of the request initiator, identifier, regional affiliation, or the task type of the service request.

9. The method according to claim 6, characterized in that, Also includes: The rollback processing module is used to remove the original version binding relationship of the service request and rebind it to another specified rule version when the service request fails to execute and a rollback instruction is received. as well as Based on the re-bound version binding relationship, the instance acquisition module is controlled to obtain another rule engine instance corresponding to the other specified rule version, and the service request is re-executed through the execution module.

10. The apparatus according to claim 6, characterized in that, Also includes: The resource recycling module is used to remove a rule engine instance and release its resources when it is detected that all service requests corresponding to any rule engine instance in the version engine pool have been completed and the retention conditions are met.

Images