Disclosure of Invention
The application provides a method for realizing the distributed business rules, which can be expanded to a distributed rule engine technical framework for implementation, thereby being suitable for the development trend of big data and multiple services.
The method for realizing the distributed business rule provided by the application specifically comprises the following steps:
when business requirement data is received, distributing the business requirement data to a distributed server according to a preset rule service table, wherein the rule service table contains a rule service ID number, and the rule service ID number has an association relation with the distributed server executing business rules;
in the distributed server, distributing the service demand data to a rule engine packaged by the micro service according to a preset rule scheme group table, wherein the rule scheme group table comprises a rule group ID number which represents a rule engine serial number packaged by the micro service executing the service rule;
and processing the received business requirement data in the rule engine of the microservice package according to a preset rule table, wherein the rule table comprises a rule executable domain which represents a condition for starting business rule execution.
Further, before receiving the service requirement data, the method further comprises:
generating a rule engine for processing the service requirement data and generating the rule table;
performing micro service encapsulation on the rule engine to generate a rule engine encapsulated by the micro service and generate the rule scheme grouping table;
and deploying the rule engine packaged by the micro-service to the distributed server by a Remote Procedure Call (RPC) method, and generating the rule service table.
Further, the method for distributing the service demand data to the distributed servers according to the preset rule service table includes:
and inquiring the rule service table, acquiring all distributed servers in the rule service table, and distributing the service demand data to all the distributed servers.
Further, the method for distributing the business requirement data to the rule engine encapsulated by the microservice according to the preset rule scheme grouping table comprises the following steps:
and inquiring the rule scheme grouping table, acquiring all rule engines packaged by the micro-services in the rule scheme grouping table, and distributing the service demand data to all rule engines packaged by the micro-services.
Further, the method for processing the received service demand data according to the preset rule table includes:
according to a rule engine execution method, disassembling received service demand data into a fact object and a service rule file;
judging whether the fact object belongs to the executable domain, if so, executing the business logic of the fact object according to the business rule file, and returning an execution result; otherwise, an empty result is returned.
Further, before receiving the service requirement data, the method further comprises:
setting a rule grouping mapping table, wherein the rule grouping mapping table comprises the corresponding relation between the ID number of the rule grouping and the executable domain of the rule;
and setting a rule service mapping table, wherein the rule service mapping table comprises the corresponding relation between the ID number of the rule service and the executable domain of the rule.
Further, the method for distributing the service demand data to the distributed servers according to the preset rule service table includes:
acquiring the rule executable domain from the service requirement data;
inquiring the rule service mapping table according to the rule executable domain, and determining a rule service ID number corresponding to the rule executable domain;
and sending the service requirement data to the distributed server corresponding to the determined rule service ID number.
Further, the method for distributing the business requirement data to the rule engine encapsulated by the microservice according to the preset rule scheme grouping table comprises the following steps:
acquiring the rule executable domain from the service requirement data;
inquiring the rule grouping mapping table according to the rule executable domain, and determining a rule grouping ID number corresponding to the rule executable domain;
and sending the service requirement data to a rule engine packaged by the micro service corresponding to the determined rule group ID number.
Further, the method for processing the received service demand data according to the preset rule table includes:
according to a rule engine execution method, disassembling received service demand data into a fact object and a service rule file;
and executing the business logic of the fact object according to the business rule file, and returning an execution result.
Further, when the mapping table maintenance opportunity is reached, the method further comprises:
and maintaining the rule grouping mapping table and the rule service mapping table by monitoring a rule database, wherein the rule database is used for storing the service rules.
Further, the mapping table maintenance opportunity includes:
before the distributed service rule is realized, the rule database is required to be called in the initialization process to establish the rule grouping mapping table and the rule service mapping table; or,
when a new business rule is added in the rule database; or,
the rule table also comprises a rule effective state and a rule updating time, and when the existing business rules are abolished or modified in the rule database to cause the rule effective state and the rule updating time to be updated.
The application also provides a system for realizing the distributed business rules, which specifically comprises the following steps: the system comprises an interface server and at least one distributed server;
the interface server distributes the business demand data to the distributed servers according to a preset rule service table when receiving the business demand data, wherein the rule service table contains a rule service ID number, and the rule service ID number has an association relation with the distributed servers executing business rules;
the distributed server distributes the service demand data to a rule engine packaged by the micro service according to a preset rule scheme group table, wherein the rule scheme group table comprises a rule group ID number which represents a rule engine serial number of the micro service package for executing the service rule; and processing the received business requirement data in the rule engine of the microservice package according to a preset rule table, wherein the rule table comprises a rule executable domain which represents a condition for starting business rule execution.
The application also provides a server for realizing the distributed business rules, which specifically comprises the following steps: the server acts as an interface server, comprising:
the first interface transceiver module is used for distributing the service demand data to the distributed servers according to a preset rule service table when receiving the service demand data, wherein the rule service table contains a rule service ID number, and the rule service ID number has an association relation with the distributed servers executing the service rules;
and the first storage module is used for storing the rule service table.
Further, the server further includes:
the first mapping module is used for acquiring the rule executable domain from the service demand data; inquiring the rule service mapping table according to the rule executable domain, and determining a rule service ID number corresponding to the rule executable domain; sending the service requirement data to a distributed server corresponding to the determined rule service ID number;
the first list updating module is used for maintaining the rule service mapping table by monitoring a rule database when the time for maintaining the mapping table is reached, wherein the rule database is used for storing the business rules;
and the first list storage module is used for storing a rule service mapping table, and the rule service mapping table comprises the corresponding relation between the rule service ID number and the rule executable domain.
The application also provides a server for realizing the distributed business rules, which specifically comprises the following steps: the server acts as a distributed server, comprising:
the second interface transceiver module is used for distributing the service demand data to a rule engine packaged by the micro service according to a preset rule scheme group table, wherein the rule scheme group table comprises a rule group ID number which indicates a rule engine serial number packaged by the micro service executing the service rule;
the rule engine is used for processing the received business requirement data according to a preset rule table, the rule table comprises a rule executable domain, and the rule executable domain represents conditions for starting business rule execution;
and the second storage module is used for storing the rule scheme grouping table and the rule table.
Further, the server further includes:
the second mapping module is used for acquiring the rule executable domain from the service demand data; inquiring the rule grouping mapping table according to the rule executable domain, and determining a rule grouping ID number corresponding to the rule executable domain; sending the service requirement data to a rule engine of micro-service encapsulation corresponding to the determined rule group ID number;
a second list updating module, configured to maintain the rule packet mapping table by monitoring a rule database when a mapping table maintenance opportunity is reached, where the rule database is used to store the service rule;
and the second list storage module is used for storing a rule grouping mapping table, and the rule grouping mapping table comprises the corresponding relation between the rule grouping ID number and the rule executable domain.
According to the technical scheme, a novel distributed rule engine technical framework is established in the embodiment of the application. Under the framework of the embodiment of the application, the business rules are no longer executed by a single machine, but the business rules are dispersed on distributed servers for implementation. The service requirement data is issued layer by layer through the set rule service table, the rule scheme grouping table and the rule table, and the service requirement data is not limited to a single machine any more, so that the method can adapt to the situation of large data and multiple services at present.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is further described in detail below by referring to the accompanying drawings and examples.
The embodiment of the application expands the rule engine technical framework of a single machine version to the distributed rule engine technical framework and is realized by a plurality of distributed servers, thereby being suitable for the development trend of big data and multiple services at present.
Fig. 1 is a flowchart of a first embodiment of the method of the present application. As shown in fig. 1, a method for implementing a distributed business rule in this embodiment includes:
step 101: when business requirement data is received, the business requirement data is distributed to a distributed server according to a preset rule service table, the rule service table contains a rule service ID number, and the rule service ID has an association relation with the distributed server executing business rules.
The embodiment of the application establishes a distributed rule engine technical framework, and the service rules are realized by a plurality of servers instead of a single server, so that when the service demand data is received, the server is firstly known through a rule service table, and the service demand data is sent to the server.
Step 102: in the distributed server, the service demand data is distributed to a rule engine packaged by the micro service according to a preset rule scheme group table, the rule scheme group table comprises a rule group ID number, and the rule group ID number represents a rule engine serial number packaged by the micro service executing the service rule.
The micro service encapsulation in this step is a method of combining complex large-scale application programs in a modular manner based on small functional blocks with single responsibility and function. The rule engine is packaged by micro-service, so that API calling service is provided to the outside, and one server can comprise a plurality of micro-service packages.
Step 103: and processing the received business requirement data in the rule engine of the microservice package according to a preset rule table, wherein the rule table comprises a rule executable domain which represents a condition for starting business rule execution.
Those skilled in the art know that, in a rule engine, the business requirement data received from the outside can be disassembled into a factual object and a rule file, that is, the factual object is divided into two parts, namely data and logic, and then the factual object is logically processed by using the business rule file. The rule file is a set of a series of logical processes, and the fact object is data. Whether the logic processing is carried out or not is determined by the executable domain in the rule table, and the execution is started if the logic processing is in accordance with the executable domain and is not started if the logic processing is not in accordance with the executable domain.
The first embodiment of the application realizes the business rules by dispersing the business rules on the distributed server, and the business requirement data is issued layer by layer through the set rule service table, the rule scheme grouping table and the rule table, so that the business requirement data is not limited to a single machine any more, and the business requirement data distribution method can adapt to the situation of large data and multiple services at present.
Before the distributed business rules are realized, a distributed business rule engine framework needs to be established in practical application. FIG. 2 is a flowchart of establishing a distributed business rules engine framework according to an embodiment of the present application. As shown in fig. 2, the method includes:
step 201: and generating a rule engine for processing the business requirement data and generating a rule table.
As mentioned above, the rule is a logic process, and the rule engine is a module for performing business data according to the logic. FIG. 3 is a schematic diagram of the operation of the rules engine technology framework described in this step. As shown in fig. 3, when the Rule engine receives the business requirement data, it is disassembled into a factual object (Fact) and a Rule file (Rule), and matching is performed inside. And when the matching is successful, performing logic processing on the fact object according to the rule file to generate a processing result. The matching is actually to judge whether the fact object belongs to the executable condition domain, if so, the matching is successful, otherwise, the matching is failed. The rule file usually includes two parts, namely "condition" and "execution", the "condition" is the executable domain described herein, and the "execution" is the specific logic processing.
Since the first embodiment of the present application is a distributed business engine framework, in order to distribute the business requirement data to each rule engine for processing, a rule table may be established for each rule engine. The rule table may be implemented in the manner shown in table one:
watch head |
ruleId |
ruleContent |
nameSpace |
ruleGroupId |
Explanation of the invention |
Rule ID |
Rule content |
Executable domain |
Regular packet ID |
Watch 1
In the actual application, one rule engine can process a plurality of rules, the rule ID represents the serial numbers of the different rules, the rule content represents the logic content to be processed by a certain rule, and the executable domain represents the condition for starting the execution of a certain business rule. In addition, since one server can establish a plurality of micro services, one micro service is also a rule group in the embodiment of the present application, and the rule group ID indicates the serial number of these different rule groups.
Step 202: and performing micro service encapsulation on the rule engine to generate a rule engine encapsulated by the micro service and generate the rule scheme grouping table.
As shown above, the microservice rules engine is a modular functional block that can provide language independent API calls to the outside. Since one server in this embodiment may establish a plurality of microservice rule engines, in order to facilitate the distribution of the service requirement data to each microservice rule engine for processing, a rule scheme grouping table may be established for each microservice rule engine. The rule scheme grouping table can be in a manner shown in table two:
watch head |
ruleGroupId |
ruleGroupName |
ruleServiceId |
Explanation of the invention |
Regular packet ID |
Rule group name |
Rule service ID |
Watch two
The rule group ID represents different micro service rule engines, and the rule group name represents the name of the function realized by the different micro service rule engines. In addition, there are several distributed servers, one distributed server may have one or several rule groups, and the rule service ID distinguishes these different sets and has correlation relation with the distributed servers. Thus, the corresponding distributed server can be determined by the rule service ID. Of course, how to determine the distributed servers is determined by big data framework technology, such as master-slave architecture, etc.
FIG. 4 is a schematic diagram of the operation of the microservice framework according to the embodiment of the present application. As shown in FIG. 4, the internal working principle of the microservice framework is the same as that of the rule engine, except that the microservice framework is packaged.
Step 203: deploying the microservice-encapsulated rule engine into the distributed server by a Remote Procedure Call (RPC) method, and generating the rule service table.
As known to those skilled in the art, an RPC is a computer communication protocol that allows a program running on one computer to call a subroutine on another computer. The RPC framework supports service governance functions including automatic discovery and removal of service nodes, high availability, load balancing and the like besides conventional point-to-point calling. Generally, three roles of a service provider (RPC Server), a service caller (RPC Client), and a service Registry (Registry) may be set. The service provider is used for providing services, can register own services with the service registry in advance, and periodically sends heartbeat report states to the registry. The service caller needs to subscribe RPC service to the service registration center, obtain a returned service list, establish connection with a certain service provider and call RPC.
In this embodiment, the rule engine encapsulated by the micro service can be deployed to each server by the RPC method, and how to implement the rule engine is not the focus of the description of the embodiment of the present application. In addition, since there are multiple distributed servers, a rule service table may be set, as shown in table three:
watch head |
ruleServiceId |
ruleServiceName |
Explanation of the invention |
Rule service ID |
Rule service name |
Watch III
Wherein the rule service ID may be associated with a distributed server, and the rule service name represents a name of a certain server. The rule table, the rule scheme table and the rule service table are respectively established and are respectively positioned at different levels of the distributed service framework. Determining the highest-level server through the rule service ID of the third table; finding out a corresponding rule group ID through the rule service ID of the table II so as to determine a micro-service encapsulation rule engine of a second level; and finding out the rule ID corresponding to the bottom layer rule engine through the rule group ID of the table I, and executing the corresponding rule by utilizing the bottom layer rule engine.
The embodiment of the application combines a rule engine technical framework, a micro service technical framework and an RPC technical framework to establish a novel distributed rule engine technical framework. Under the framework of the embodiment of the application, the business rules are not executed by a single machine any more, but the rule engines are deployed on a plurality of servers on the basis of considering the advantages of single machine versions, and can be grouped according to the business to realize the concurrent execution of multiple businesses and multiple rules, thereby well adapting to the development trend of the current big data and multiple businesses.
After the distributed rule engine technical framework is established, the distributed business rules can be realized according to the method of the first embodiment of the application. In practical applications, there may be multiple schemes for implementing the distributed business rule, and at least two schemes are described in detail below. The first scheme is to realize the distributed business rules by a traversal method, and the second scheme is to realize the distributed business rules by a quick positioning method.
The first scheme is as follows: and realizing the distributed business rules by adopting a traversal method.
The scheme is that the business requirement data is distributed in a traversing layer by layer, each rule engine at the bottom layer judges whether a fact object in the business requirement data belongs to an executable domain by utilizing a rule table of the rule engine, and whether the execution of the business rule is started or not is determined according to the fact object. FIG. 5 is a flowchart of a method of implementing a distributed business rule according to a second embodiment using a traversal method. As shown in fig. 5, the method includes:
step 501: and when the business demand data is received, inquiring a rule service table to obtain all distributed servers in the rule service table.
Step 502: and distributing the service requirement data to all the distributed servers.
Assuming that the rule service table in step 501 is in the form of table three, the third embodiment of the method is specifically shown in table four below:
watch four
Then, the server list, i.e. all distributed servers such as ServiceId-1, ServiceId-2, etc., can be obtained according to the fourth lookup table, and the service requirement data is sent to these servers.
Step 503: and in each distributed server, inquiring the rule scheme grouping table to obtain all rule engines encapsulated by the micro-services in the rule scheme grouping table.
Step 504: and distributing the business requirement data to all the rule engines encapsulated by the microservices.
Assuming that the rule scheme grouping table in step 503 takes the form of table two, the rule scheme grouping table in this server of ServiceId-1 in the third embodiment of the method is specifically shown in table five below:
watch five
Then, the rule scheme grouping list in the server ServiceId-1, that is, all the rule scheme groupings of GroupId-1, GroupId-2, etc., can be obtained according to the lookup table five. Here, each rule scheme grouping is a rule engine encapsulated by the microservices.
Step 505: in each rule engine packaged by the microservice, the received business requirement data is disassembled into a factual object and a business rule file according to a rule engine execution method.
Step 506: judging whether the fact object belongs to the executable domain, if so, executing step 507; otherwise, step 508 is performed.
Assuming that the rule table is in the form of table one, the rule table in this microservice rule engine of group id-1 in embodiment two of the method is specifically shown in table six below:
watch six
For a certain rule RuleId-1, it is assumed that the fact object received for parsing the service requirement data is some numerical values, and the parsed rule file needs to add the numerical values (service logic), and then it is first necessary to judge whether the received numerical values are positive integers according to the rule table, and if the received numerical values are positive integers, it is indicated that the fact object belongs to the executable domain, and then the execution of the rule RuleId-1 is started. For another rule, RuleId-2, it is assumed that the factual objects received from the parsing of the business requirement data are some values, and the parsed rule file is the value minus 100 (business logic). Similarly, it is first necessary to determine whether the received value is greater than 100 according to the rule table, and if so, it indicates that the fact object belongs to the executable domain, and then the execution of rule RuleId-2 is started.
Step 507: and executing the business logic of the fact object according to the business rule file, and returning an execution result.
Step 508: an empty result is returned.
The above steps 505 to 508 are the working mechanism inside the rule engine of the second embodiment. It can be seen that, in the third embodiment of the method of the present application, the rule service table, the rule scheme grouping table and the rule table are used to distribute the data demand data layer by layer to all servers and micro service rule engines, and all rule engines at the bottom layer use the executable domain in their own rule table to determine whether they need to be executed. That is, the method embodiment sends the service requirement data to all the rule engines in a traversal manner, and finally the rule engines perform filtering.
The second scheme is as follows: and realizing the distributed service rule by adopting a quick positioning method.
The scheme is that the business requirement data is accurately distributed to the related rule engines, and only the related rule engines start the execution of the business rules. In order to enable fast positioning, the embodiment adds two mapping tables, one is a rule packet mapping table, which includes a correspondence relationship between a rule packet ID number and a rule executable domain. The other is a rule service mapping table, which includes the correspondence of the rule service ID number and the rule executable domain.
Wherein, the rule grouping mapping table is shown as table seven:
watch seven
Wherein the rule executable domain and the rule group ID represent a pair of correspondences.
Similarly, the rule service mapping table is shown in table eight:
table eight
Wherein the rule executable domain and the rule service ID represent a pair of correspondences.
Fig. 6 is a flowchart of a method of implementing a distributed business rule by using a fast positioning method according to a third embodiment. As shown in fig. 6, the method includes:
step 601: and when the business requirement data is received, acquiring the rule executable domain from the business requirement data.
Those skilled in the art will appreciate that the business requirement data itself contains the contents of the rule file executable domain and can therefore be obtained therefrom.
Step 602: and inquiring a rule service mapping table according to the rule executable domain, and determining a rule service ID number corresponding to the rule executable domain.
Assuming that the rule service mapping table takes the form of table eight, a specific rule service mapping table in this embodiment three is shown in table nine:
watch nine
According to the query rule service mapping table, it can be known that the two servers, ServiceId-1 and ServiceId-5, are related to the rule which needs to be executed currently.
Step 603: and sending the service requirement data to the distributed server corresponding to the determined rule service ID number.
This step will send the service requirement data to both servers, ServiceId-1 and ServiceId-5.
Step 604: in the server, a rule executable domain is obtained from the business requirement data.
At this time, assuming that the service demand data has already been distributed to two servers, ServiceId-1 and ServiceId-5, the two servers, ServiceId-1 and ServiceId-5, can also obtain the contents of the rule file executable domain therefrom.
Step 605: the server queries the rule packet mapping table according to the rule executable domain and determines a rule packet ID number corresponding to the rule executable domain.
Assuming that the rule group mapping table takes the form of table seven, a specific rule group mapping table in the server ServiceId-1 of the third embodiment is shown in table ten, and a specific rule group mapping table in the server ServiceId-5 is shown in table eleven:
watch ten
Watch eleven
Step 606: and the server sends the service requirement data to the rule engine encapsulated by the micro-service corresponding to the determined rule group ID number.
That is, the server ServiceId-1 will send the service requirement data to the micro service encapsulation rule engine corresponding to the GroupId-1, and the server ServiceId-5 will send the service requirement data to the micro service encapsulation rule engine corresponding to the GroupId-3.
Step 607: and according to the rule engine execution method, the received business requirement data is disassembled into the fact object and the business rule file.
Step 608: and executing the business logic of the fact object according to the business rule file, and returning an execution result.
Here, step 607 is the process of processing the service requirement data by the group id-1 rule engine in the server ServiceId-1, and step 608 is the process of processing the service requirement data by the group id-3 rule engine in the server ServiceId-5. Since the business requirement data is only sent to the related rule engine after being screened by the rule executable domain, the step of re-verification can be omitted, and the logic processing can be directly carried out.
In the third embodiment of the application, the service requirement data is intercepted by using the set rule service mapping table and the set rule packet mapping table, and only the service requirement data is sent to the rule engine meeting the conditions without traversing all the servers and the rule engines, so that the rapid positioning can be realized. In addition, other servers and rule engines are not needed to receive and process the service requirement data, so that resources can be greatly saved. Of course, in practical application, the conditions of the rule executable domain can be further refined, and more accurate positioning can be performed. How to implement the method can be determined by the user applying the scheme of the application.
In practical applications, the information related to the rule may be stored in the rule database in advance, and the information obtained from the database constitutes the rule packet mapping table and the rule service mapping table. In the whole system operation process, the rule packet mapping table and the rule service mapping table can be adjusted to a memory for use. When the time for maintaining the mapping table is reached, the rule packet mapping table and the rule service mapping table are maintained by a method of monitoring a rule database.
The mapping table maintenance opportunity can be selected from the following links:
1. before the embodiment of the application realizes the distributed business rules, the system carries out initialization when a rule database is required to be called to establish a rule grouping mapping table and the rule service mapping table. At this time, the maintenance of the mapping table is equivalent to the construction from scratch.
2. In the process of implementing the distributed business rules in the embodiment of the application, if a new business rule needs to be added in the rule database. At this time, the mapping table needs to be updated in time in order to match the new business rule.
3. A rule effective state (ruleStatus) and a rule update time (updateTime) are set in advance for the rule and added in the rule table. In the process of implementing the distributed business rules in the embodiment of the application, if some existing business rules need to be modified or deleted in the database. To match this situation, the mapping table needs to be updated in time. For example, a certain business rule in the rule database is revoked, the rule effective state (ruleStatus) is set to "revocation" in the rule table, and the system time at the time of revocation is filled in the rule update time (updateTime). At this time, the mapping table needs to be updated.
The above lists only a few mapping table maintenance opportunities, and other opportunities may also exist in the opportunity application as long as the opportunities can be adapted to the database updating situation in time.
The scheme of the embodiment of the application can be applied to various scenes as long as the fact object serving as business data and the rule file serving as business logic can be disassembled in software engineering. Such as: data mining, machine-learned data cleansing, deep-learned feature transformation, and the like.
The following is a brief illustration of example four. The data set needing data cleaning is assumed to be login data of certain social software, and the final step of cleaning respectively enters two models, namely a Recurrent Neural Networks (RNN) model and a Deep Neural Networks (DNN) model. Fig. 7 is a schematic diagram of the flow direction of the traffic demand data in the fourth embodiment. As shown in fig. 7, it is assumed that the service requirement data is processed according to the third embodiment of the method, where the distributed service rule system includes three servers, which are server a, server B, and server C. A rule engine packaged by micro-service is established in the server A and respectively executes a logic-RNN scheme A, login-RNN scheme B and an order data scheme A; the rule engines with micro-service encapsulation established in the server B respectively execute a logic-DNN scheme A, an order data scheme B, an order data scheme C and the rule engines with micro-service encapsulation established in the server C respectively execute a browsing data scheme A and an order data scheme D.
The fourth embodiment of the method takes processing logic-RNN and logic-DNN data as an example. Assume that the system receives business requirement data that includes both the data related to the login-RNN business input and the data related to the login-DNN business input, and possibly business data related to browsing or ordering. Therefore, when the service demand data is received, the rule service mapping table and the rule packet mapping table can be used for intercepting, so that the related data of the logic-RNN service accurately enters the rule engine of the server A for executing the logic-RNN scheme A and the logic-RNN scheme B, and the related data of the logic-DNN service accurately enters the rule engine of the server B for executing the logic-DNN scheme A.
Therefore, in the fourth embodiment, when the service rule of data cleaning is implemented, a distributed rule engine technical framework is adopted, so that the requirement of big data and multiple services can be met, and the rule service mapping table and the rule packet mapping table are adopted to accurately and quickly distribute the service data to the related rule engines only, so that all the rule engines are not required to be called, and resources are greatly saved.
The application also provides a system for realizing the distributed business rules. Fig. 8 is a schematic structural diagram of a first embodiment of the system of the present application. As shown in fig. 8, the system includes at least one distributed server 802 and an interface server 801. Wherein,
when receiving the service requirement data, the interface server 801 distributes the service requirement data to the distributed servers 802 according to a preset rule service table, where the rule service table includes a rule service ID number, and the rule service ID number has an association relationship with the distributed servers executing the service rule.
The distributed server 802 distributes the service demand data to the rule engines encapsulated by the micro services according to a preset rule scheme group table, wherein the rule scheme group table comprises a rule group ID number which represents the sequence number of the rule engine encapsulated by the micro services for executing the service rules; and processing the received business requirement data in the rule engine of the microservice package according to a preset rule table, wherein the rule table comprises a rule executable domain which represents a condition for starting business rule execution.
Fig. 9 is a schematic diagram of the internal structure of the interface server 801. As shown in fig. 8, the server includes: a first interface transceiver module 901 and a first storage module 902. Wherein,
the first interface transceiver module 901, when receiving the service requirement data, distributes the service requirement data to the distributed servers according to a preset rule service table, where the rule service table includes a rule service ID number, and the rule service ID number has an association relationship with the distributed servers executing the service rule.
A first storage module 902, configured to store the rule service table.
The interface server may further include a first mapping module 903, a first list updating module 904, and a first list storing module 905. Wherein,
a first mapping module 903, configured to obtain the rule executable domain from the service requirement data; inquiring the rule service mapping table according to the rule executable domain, and determining a rule service ID number corresponding to the rule executable domain; sending the service requirement data to the distributed server corresponding to the determined rule service ID number through the first interface transceiver module 901;
a first list updating module 904, configured to maintain the rule service mapping table by monitoring a rule database when a mapping table maintenance opportunity is reached, where the rule database is used to store the service rule;
a first list storage module 905, configured to store a rule service mapping table, where the rule service mapping table includes a correspondence between the rule service ID number and the rule executable domain.
Fig. 10 is a schematic diagram of the internal structure of the distributed server 802. As shown in fig. 10, the server includes: a second interface transceiver module 1001, a rule engine 1002 for micro service encapsulation, and a second storage module 1003. Wherein,
a second interface transceiver module 1001, configured to distribute the service requirement data to a rule engine encapsulated by a micro service according to a preset rule scheme group table, where the rule scheme group table includes a rule group ID number indicating a rule engine serial number of a micro service encapsulation that executes a service rule;
a rule engine 1002 for microservice encapsulation, configured to process received service requirement data according to a preset rule table, where the rule table includes a rule executable domain, and the rule executable domain represents a condition for starting service rule execution;
a second storage module 1003, configured to store the rule scheme grouping table and the rule table.
The server may further include: a second mapping module 1004, a second list updating module 1005, a second list storing module, wherein,
a second mapping module 1004, configured to obtain the rule executable domain from the service requirement data; inquiring the rule grouping mapping table according to the rule executable domain, and determining a rule grouping ID number corresponding to the rule executable domain; sending the service requirement data to a rule engine of micro-service encapsulation corresponding to the determined rule group ID number;
a second list updating module 1005, configured to maintain the rule packet mapping table by monitoring a rule database when a mapping table maintenance opportunity is reached, where the rule database is used to store the service rule;
a second list storage module 1006, configured to store a rule grouping mapping table, where the rule grouping mapping table includes a correspondence between the rule grouping ID number and the rule executable domain.
That is to say, when the interface server 801 receives the service requirement data, the first interface transceiver module 901 distributes the service requirement data to the distributed server 802 according to a preset rule service table; a second interface transceiver module 1001 of the distributed server 802 distributes the service demand data to a rule engine 1002 packaged by the microservice according to a preset rule scheme grouping table; the rule engine 1002 for microservice encapsulation processes the received business requirement data according to a preset rule table. Meanwhile, when the mapping table maintenance opportunity is reached, the first list updating module 904 and the second list updating module 1005 also maintain the rule service mapping table and the rule packet mapping table in a listening manner.
By utilizing the method, the system and the device provided by the application, a new distributed rule engine technical framework can be established by combining the rule engine technical framework, the micro service technical framework and the RPC technical framework. On the basis of a distributed rule engine technical framework, grouping can be performed according to services, and multi-service and multi-rule concurrent execution is realized, so that the development trend of big data and multi-service at present is well adapted.
The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the scope of protection of the present application.