Multi-scene-based orchestrable unified preprocessing rule method and system

Abstract

The invention relates to the technical field of multi-scene dynamic orchestration, in particular to a multi-scene-based orchestrable unified preprocessing rule method and system, and the method comprises the steps: carrying out the dynamic matching of a rule according to scene information, employing a visual rule orchestration engine, and employing a micro-service architecture design; the method has the beneficial effects that different service scenes can be covered through the modular rule base and the dynamic configuration capability, repeated development of a traditional single scene preprocessing system is avoided, and the technology reuse rate is improved. Visual flow arrangement is adopted, a user is allowed to customize a rule execution sequence, conditional branches and combinatorial logic, complex business demand changes are flexibly dealt with, and the technology coupling degree is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of multi-scene dynamic arrangement, in particular to a method and system for unified preprocessing rules based on multi-scene and programmable arrangement. BACKGROUND

[0002] With the development of information technology, the demand for rule verification in different application scenarios is increasingly diversified. Existing rule preprocessing methods are usually designed for specific scenarios, lacking flexibility and universality, and are difficult to quickly adapt to new business needs.

[0003] 1. Repeated development: similar preprocessing logic is repeatedly implemented in different scenarios, with low development efficiency.

[0004] 2. Poor flexibility: traditional rule engines are difficult to dynamically adjust the process and cannot quickly respond to business changes.

[0005] 3. High maintenance cost: scattered preprocessing logic leads to difficulties in version management and updating.

[0006] 4. Insufficient multi-scene adaptation: lack of unified rule description language and arrangement mechanism, making it difficult to cross-scene reuse.

[0007] Therefore, there is an urgent need for a unified preprocessing solution that supports multi-scene dynamic arrangement and rule reuse. SUMMARY

[0008] The purpose of the present application is to provide a method and system for unified preprocessing rules based on multi-scene and programmable arrangement to solve the problems raised in the background.

[0009] To achieve the above purpose, the present application provides the following technical solution: a method for unified preprocessing rules based on multi-scene and programmable arrangement, comprising:

[0010] According to the scene information, the rule is dynamically matched, the scene information includes scene IDs, business operation IDs, and subscription entity IDs, which are combined and matched to the rule template through scene IDs, business operation IDs, and subscription entity IDs. Scene IDs are used to identify one or more predefined business scenarios, combined with input operation IDs and subscription entity IDs for dynamic combination, dynamically matched to rules that meet the adaptation conditions, and the same rule is reused in different scenarios;

[0011] A visual rule arrangement engine is used, which adopts a four-layer architecture model, divided into rule management layer, rule storage layer, rule engine core layer, and data access layer, provides a graphical interface, generates preprocessing flow through dragging rule nodes, supports branching, parallel and conditional jump logic, builds global context objects, executes rule chains, and outputs processing results to the calling system;

[0012] It adopts microservice architecture design, decouples from the business system, and achieves independent deployment and elastic expansion.

[0013] Preferably, the rule management layer integrates LogicFlow to implement a visual canvas, supports dragging nodes, connections, and multi-level nested logic arrangement, provides a rule parameter configuration panel and real-time preview function, and supports configuration testing and release.

[0014] Preferably, the rule storage layer is used to configure the persistence of rules and cache common and commonly used rules and parameters to reduce database disk IO and improve data query efficiency.

[0015] Preferably, the core layer of the rule engine parses the matched rules, converts the stored rules into an internal data structure recognizable by the engine, integrates the Drools rule engine, and Drools loads the rule library through KieModule to build a Rete pattern network; compiles and caches the parsed rules, precompiles the rule conditions into memory, and reduces the runtime parsing overhead; encapsulates the business data into "fact" objects recognizable by the engine, inserts them into the working memory, quickly matches the rule conditions through the pattern network, and shares the repeated calculation logic; at the same time, the Drools rule engine frees complex and changeable business rules from hard coding, and stores them in files or specific storage media in the form of rule scripts, so that changes to business rules can take effect immediately in the online environment without modifying the project code or restarting the server, and achieves millisecond-level response based on Rete algorithm optimization and hot loading mechanism.

[0016] Preferably, the microservice architecture uses Hystrix circuit breakers to count failure rates, automatically breaking service calls when the threshold is reached to prevent an avalanche effect. Sentinel is combined to implement business-level circuit breaking, for example, maintaining the availability of high-priority order interfaces and automatically downgrading ordinary requests. Based on Prometheus monitoring indicators, the number of service instances is dynamically adjusted through the Kubernetes Operator and automatically synchronized to the Spring Cloud Gateway routing table. Through the decoupling characteristics of microservices, the dependencies between modules are reduced, and the maintainability and flexibility of the system are improved.

[0017] A system for a method based on multi-scenario, programmable, unified pre-processing rules, comprising:

[0018] A rule dynamic matching module is used to dynamically match rules based on scenario information, wherein the scenario information includes scenario IDs, business operation ID, and ordering entity ID;

[0019] The visual rule orchestration engine adopts a four-layer architecture model, divided into a rule management layer, a rule storage layer, a rule engine core layer, and a data access layer. It provides a graphical interface, generates pre-processing flows by dragging and dropping rule nodes, supports branching, parallelization, and conditional jump logic, builds global context objects, executes rule chains, and outputs processing results to the calling system.

[0020] The microservice architecture module is used to decouple from the business system to achieve independent deployment and elastic expansion of the system.

[0021] Preferably, the rule dynamic matching module combines and matches the scenario IDs, business operation IDs, and ordering entity IDs to the rule template, where the scenario IDs are used to identify one or more predefined business scenarios, and are dynamically combined with the input operation ID and ordering entity ID to dynamically match the rules that meet the adaptation conditions to achieve reuse of the same rule in different scenarios.

[0022] Preferably, the rule management layer integrates LogicFlow to implement a visual canvas, supports dragging nodes, connections, and multi-level nested logic arrangement, provides a rule parameter configuration panel and real-time preview function, and supports configuration testing and release.

[0023] Preferably, the rule storage layer is used to configure the persistence of rules and cache common and commonly used rules and parameters to reduce database disk IO and improve data query efficiency.

[0024] Preferably, the core layer of the rule engine parses the matched rules, converts the stored rules into an internal data structure that the engine can recognize, integrates the Drools rule engine, and Drools loads the rule library through KieModule to build a Rete pattern network; compiles and caches the parsed rules, precompiles the rule conditions into memory, and reduces the runtime parsing overhead; encapsulates the business data into "fact" objects that the engine can recognize, inserts them into the working memory, quickly matches the rule conditions through the pattern network, and shares the repeated calculation logic;

[0025] The microservice architecture module uses Hystrix circuit breakers to count failure rates, automatically breaking service calls when the threshold is reached to prevent an avalanche effect. It also uses Sentinel to implement business-level circuit breaking, for example, maintaining the availability of high-priority order interfaces while automatically downgrading common requests. Based on Prometheus monitoring indicators, the number of service instances is dynamically adjusted through the Kubernetes Operator and automatically synchronized to the Spring Cloud Gateway routing table. The decoupling characteristics of microservices reduce dependencies between modules, improving the maintainability and flexibility of the system.

[0026] Compared with the prior art, the present invention has the following beneficial effects:

[0027] The method and system based on the multi-scene, programmable unified preprocessing rule provided by the application can cover different business scenarios through the modular rule library and dynamic configuration capability, avoid repeated development of the traditional single-scene preprocessing system, and improve the technical reuse rate. The visual process arrangement is adopted to allow the user to customize the rule execution sequence, condition branch, and combination logic, flexibly cope with the complex business demand change, and reduce the technical coupling degree. The micro-service architecture design supports distributed deployment and elastic resource scheduling, can cope with the sudden traffic, and guarantees the stability in the high-concurrency scenario. Through the standardized interface and programmable rule engine, the developer can reduce the code amount by 30%-60%, reduce the error rate, and reduce the operation and maintenance cost BRIEF DESCRIPTION OF DRAWINGS

[0028] Figure 1 The figure is the system architecture diagram of the application;

[0029] Figure 2 The figure is the rule arrangement engine layered architecture model diagram of the application;

[0030] Figure 3 The figure is the rule engine execution flow diagram of the application. DETAILED DESCRIPTION

[0031] In order to make the purpose, technical scheme of the application clear, complete, and the advantages more clear and obvious, the embodiments of the application are further described in detail below in combination with the drawings. It should be understood that the specific embodiments described here are part of the embodiments of the application, not all the embodiments, only to explain the embodiments of the application, and not to limit the embodiments of the application, all other embodiments obtained by the person skilled in the art without creative labor are within the scope of protection of the application.

[0032] Embodiment one, the application provides a technical scheme: a method of unified preprocessing rule based on multi-scene and programmable, comprising: dynamically matching rules according to scene information, the scene information includes scene IDs, business operation ID, and subscription entity ID; the visual rule arrangement engine adopts a four-layer architecture model, which is divided into a rule management layer, a rule storage layer, a rule engine core layer, and a data access layer, provides a graphical interface, generates a preprocessing process through dragging rule nodes, supports branch, parallel, and condition jump logic, constructs a global context object, executes a rule chain, and outputs the processing result to the calling party system; the micro-service architecture design is decoupled with the business system, and can be independently deployed and elastically expanded.

[0033] By combining scenario IDs, business operation IDs, and ordering entity IDs to match rule templates, scenario IDs can identify one or more predefined business scenarios, dynamically combine them with the input operation ID and ordering entity ID, and dynamically match them to rules that meet the adaptation conditions, so that the same rule can be reused in different scenarios.

[0034] Integrate LogicFlow to implement a visual canvas, support dragging nodes, connections, and multi-level nested logic arrangement, provide a rule parameter configuration panel and real-time preview function, and support configuration testing and release.

[0035] It is used to persist configuration rules and cache common and frequently used rules and parameters, which can effectively reduce database disk IO and improve data query efficiency.

[0036] Matching rules are parsed, and stored rules are converted into internal data structures recognizable by the engine. The Drools rule engine is integrated, and Drools loads the rule library through KieModule to build a Rete pattern network. Parsed rules are compiled and cached, and rule conditions are precompiled into memory (e.g., generating Java bytecode) to reduce runtime parsing overhead. Business data is encapsulated as "fact" objects recognizable by the engine and inserted into working memory. Rule conditions are quickly matched through the pattern network, and repeated calculation logic is shared.

[0037] Complex and ever-changing business rules can be liberated from hard coding and stored in files or specific storage media (such as in a database) in the form of rule scripts. This allows changes to business rules to take effect immediately in the online environment without modifying the project code or restarting the server. Based on Rete algorithm optimization and hot loading mechanism, millisecond-level response is achieved.

[0038] Based on Hystrix circuit breaker statistics, service calls are automatically disconnected when the threshold is reached to prevent avalanche effects. In combination with Sentinel, business-level circuit breaking is implemented. For example, high-priority order interfaces are kept available while ordinary requests are automatically downgraded. Based on Prometheus monitoring indicators (such as QPS and CPU utilization), the number of service instances is dynamically adjusted through the Kubernetes Operator and automatically synchronized to the Spring Cloud Gateway routing table. The decoupling characteristics of microservices reduce dependencies between modules and improve the maintainability and flexibility of the system.

[0039] Example 2, based on Example 1, proposes a system for a method of unified pre-processing rules based on multiple scenarios and programmable rules, including:

[0040] A rule dynamic matching module is configured to dynamically match rules according to scene information, wherein the scene information comprises scene IDs, business operation IDs and subscription entity IDs; the rule dynamic matching module matches the rules to rule templates through combination of the scene IDs, the business operation IDs and the subscription entity IDs, wherein the scene IDs are used to identify one or more predefined business scenes, and the rule dynamic matching module dynamically matches to rules that meet the adaptation conditions through dynamic combination of the input operation IDs and the subscription entity IDs, so as to realize reuse of the same rule in different scenes.

[0041] A visual rule orchestration engine adopts a four-layer architecture model, which is divided into a rule management layer, a rule storage layer, a rule engine core layer and a data access layer. The visual rule orchestration engine provides a graphical interface, generates a preprocessing flow through dragging and dropping rule nodes, supports branch, parallel and conditional jump logic, constructs a global context object, executes a rule chain, and outputs a processing result to a calling system. The rule management layer integrates LogicFlow to realize a visual canvas, supports dragging and dropping nodes, lines and multi-level nested logic orchestration, provides a rule parameter configuration panel and a real-time preview function, and supports configuration testing and publishing. The rule storage layer is used for persisting configured rules, and caches public and common rules and parameters to reduce database disk IO and improve data query efficiency.

[0042] A microservice architecture module is configured to decouple with a business system, realize independent deployment and elastic expansion of the system. The rule engine core layer parses matched rules, converts stored rules into an internal data structure recognizable by the engine, integrates a Drools rule engine, and the Drools loads a rule library through KieModule to construct a Rete mode network. The rule engine core layer compiles and caches parsed rules, pre-compiles rule conditions to memory to reduce runtime parsing overhead, encapsulates business data into a “fact” object recognizable by the engine, inserts the “fact” object into working memory, quickly matches rule conditions through the mode network, and shares repeated computing logic. The microservice architecture module is based on a Hystrix fuse to count a failure rate, and automatically fuses service calls when the failure rate reaches a threshold to prevent an avalanche effect. The microservice architecture module is combined with Sentinel to realize business-level fusing, for example, to maintain availability of a high-priority order interface and automatically degrade normal requests. The microservice architecture module is based on Prometheus monitoring indicators to dynamically adjust a number of service instances through a Kubernetes Operator and automatically synchronizes to a Spring Cloud Gateway routing table. Through decoupling characteristics of the microservice, the microservice architecture module reduces dependencies between modules and improves maintainability and flexibility of the system.

[0043] While embodiments of the application have been shown and described, it is to be understood that the embodiments described are merely exemplary of the principles and application of the present application. Numerous modifications and adaptions can be effected without departing from the spirit and scope of the present application, which is not limited to the exact construction and arrangement described. It is intended, therefore, to cover all modifications and adaptions that fall within the scope of the claims and their equivalents.

Claims

1. A method based on multi-scenario, programmable unified pre-processing rules, characterized by: include: Dynamically match rules based on scenario information. The scenario information includes scenario IDs, business operation IDs, and ordering entity IDs. These are combined and matched to rule templates. Scenario IDs are used to identify one or more predefined business scenarios. Dynamically combine the input operation IDs and ordering entity IDs to dynamically match rules that meet the adaptation criteria, enabling the reuse of the same rule in different scenarios. It uses a visual rule orchestration engine with a four-layer architecture model, consisting of a rule management layer, a rule storage layer, a rule engine core layer, and a data access layer. It provides a graphical interface, allows users to generate pre-processing flows by dragging and dropping rule nodes, supports branching, parallelism, and conditional jump logic, builds global context objects, executes rule chains, and outputs processing results to the calling system. It adopts microservice architecture design, decouples from the business system, and achieves independent deployment and elastic expansion.

2. The method according to claim 1, wherein: The rule management layer integrates LogicFlow to implement a visual canvas, supports dragging nodes, connections, and multi-level nested logic arrangement, provides a rule parameter configuration panel and real-time preview function, and supports configuration testing and release.

3. The method according to claim 2, wherein: The rule storage layer is used to persist configuration rules and cache common and frequently used rules and parameters to reduce database disk IO and improve data query efficiency.

4. The method of claim 3, wherein: The core layer of the rule engine parses the matching rules, converts the stored rules into an internal data structure that the engine can recognize, integrates the Drools rule engine, and Drools loads the rule library through KieModule to build a Rete pattern network; compiles and caches the parsed rules, precompiles the rule conditions into memory, and reduces the runtime parsing overhead; encapsulates the business data into "fact" objects that the engine can recognize, inserts them into the working memory, quickly matches the rule conditions through the pattern network, and shares the repeated calculation logic; at the same time, the Drools rule engine liberates complex and changeable business rules from hard coding, and stores them in files or specific storage media in the form of rule scripts, so that changes to business rules can take effect immediately in the online environment without modifying the project code or restarting the server. Based on the Rete algorithm optimization and hot loading mechanism, millisecond-level response is achieved.

5. The method of claim 4, wherein: The microservice architecture uses Hystrix circuit breakers to calculate failure rates. When the threshold is reached, service calls are automatically disconnected to prevent avalanche effects. This is combined with Sentinel to implement service-level circuit breaking. For example, high-priority order interfaces maintain availability while ordinary requests are automatically downgraded. Based on Prometheus monitoring indicators, the number of service instances is dynamically adjusted through Kubernetes Operator and automatically synchronized to the Spring Cloud Gateway routing table; through the decoupling characteristics of microservices, the dependencies between modules are reduced, and the maintainability and flexibility of the system are improved.

6. A system for the method of multi-scenario, programmable unified pre-processing rules according to claim 5, characterized in that: include: A rule dynamic matching module is used to dynamically match rules based on scenario information, wherein the scenario information includes scenario IDs, business operation ID, and ordering entity ID; The visual rule orchestration engine adopts a four-layer architecture model, divided into a rule management layer, a rule storage layer, a rule engine core layer, and a data access layer. It provides a graphical interface, generates pre-processing flows by dragging and dropping rule nodes, supports branching, parallelization, and conditional jump logic, builds global context objects, executes rule chains, and outputs processing results to the calling system. The microservice architecture module is used to decouple from the business system to achieve independent deployment and elastic expansion of the system.

7. A system according to claim 6, characterized in that: The rule dynamic matching module matches the rule template by combining scenario IDs, business operation IDs, and ordering entity IDs. Scenario IDs are used to identify one or more predefined business scenarios, and are dynamically combined with the input operation ID and ordering entity ID to dynamically match the rules that meet the adaptation conditions, so as to achieve the reuse of the same rule in different scenarios.

8. A system according to claim 7, characterized in that: The rule management layer integrates LogicFlow to implement a visual canvas, supports dragging nodes, connections, and multi-level nested logic arrangement, provides a rule parameter configuration panel and real-time preview function, and supports configuration testing and release.

9. A system according to claim 8, characterized in that: The rule storage layer is used to persist configuration rules and cache common and frequently used rules and parameters to reduce database disk IO and improve data query efficiency.

10. A system according to claim 9, characterized in that: The rule engine core layer parses matching rules, converts stored rules into internal data structures recognizable by the engine, integrates the Drools rule engine, and uses KieModule to load the rule library and build a Rete pattern network. It also compiles and caches parsed rules, precompiling rule conditions into memory to reduce runtime parsing overhead. It also encapsulates business data into "fact" objects recognizable by the engine, inserts them into working memory, and quickly matches rule conditions through the pattern network, sharing repeated calculation logic. The microservice architecture module uses Hystrix circuit breakers to calculate failure rates. When the threshold is reached, service calls are automatically disconnected to prevent avalanche effects. It also integrates Sentinel to implement business-level circuit breaking. For example, high-priority order interfaces maintain availability while ordinary requests are automatically downgraded. Based on Prometheus monitoring indicators, the number of service instances is dynamically adjusted through Kubernetes Operator and automatically synchronized to the Spring Cloud Gateway routing table; through the decoupling characteristics of microservices, the dependencies between modules are reduced, and the maintainability and flexibility of the system are improved.

Images