Rule package loading method, rule package execution method and terminal device

Abstract

This application is applicable to the field of computer technology, and provides a rule package loading method, a rule package execution method and a terminal device based on a microservices architecture. The rule package loading method includes: obtaining a rule package and storing the rule package in a rule repository, where the rule package carries identification information of the rule package; according to a preset correspondence between the identification information and microservices, preloading the rule package into a target JVM memory, where the target JVM memory is the JVM memory of the microservice corresponding to the identification information of the rule package; writing the preloading result of the rule package in the target JVM memory into a preset database. By storing the rule package in the rule repository and preloading the rule package in the rule repository into the target JVM memory, it is convenient to uniformly manage and monitor the rule package, and solve the problem that the rule package is not convenient to manage and monitor. At the same time, this application also relates to blockchain technology.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and particularly relates to a method for loading rule packages in a microservices architecture, a method for executing rule packages, and a terminal device. Background Art

[0002] A rule engine is a component embedded in an application program that can separate business decisions from the application program code, reduce the complexity of components with complex business logic, and reduce the maintenance and scalability costs of the application program. However, existing rule engines are monolithic applications and are mainly applicable to small-scale application scenarios. With the development of big data and multiple services in Internet projects, traditional rule engines are difficult to apply to current Internet projects. Even if a rule engine adopting a microservices architecture can be applied to Internet projects, the rule packages of each rule engine are directly encapsulated in the corresponding microservices project, which is not conducive to the unified management and monitoring of rule packages. Summary of the Invention

[0003] Embodiments of this application provide a method for loading rule packages, a method for executing rule packages, and a terminal device based on a microservices architecture, which can solve the problem that rule packages are not convenient to manage and monitor.

[0004] In a first aspect, an embodiment of this application provides a method for loading rule packages based on a microservices architecture, including:

[0005] Obtain a rule package and store the rule package in a rule repository, where the rule package carries identification information of the rule package;

[0006] According to a preset correspondence between the identification information and microservices, preload the rule package into a target JVM memory, where the target JVM memory is the JVM memory of the microservice corresponding to the identification information of the rule package;

[0007] Write the preloading result of the rule package in the target JVM memory into a preset database.

[0008] In the embodiment of this application, by storing all rule packages in a rule repository and then automatically preloading the rule packages into the virtual environment memory of the corresponding microservices according to the identification information corresponding to the rule packages, compared with the existing method that when updating the rule packages of microservices, the rule packages need to be republished to the project files of each server corresponding to the microservices, the existing method requires multiple publishing operations for the rule packages, while this embodiment does not require multiple publishing of the rule packages. Only by publishing them to the rule repository, each server corresponding to the microservices can automatically load the rule packages from the rule repository, which is more convenient for the unified management of all rule packages of microservices; and writing the preloading result into a preset database is convenient for subsequent monitoring of the preloading result, solving the problem that rule packages are not convenient to manage and monitor.

[0009] Second aspect, an embodiment of the present application provides a method for executing a rule package based on a microservice architecture, including:

[0010] Obtain a rule execution request carrying service data, and determine the service type of the service data;

[0011] In response to the rule execution request, call the rule package pre-loaded from the rule repository by the microservice corresponding to the service type;

[0012] Based on the rule functions in the rule package, perform rule processing on the service data to obtain a processing result.

[0013] Third aspect, an embodiment of the present application provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the rule package loading method according to any one of the above first aspects or the rule package execution method according to any one of the above second aspects.

[0014] Fourth aspect, an embodiment of the present application provides a computer-readable storage medium. The computer-readable storage medium stores a computer program. When the computer program is executed by a processor, it implements the rule package loading method according to any one of the above first aspects or the rule package execution method according to any one of the above second aspects.

[0015] Fifth aspect, an embodiment of the present application provides a computer program product. When the computer program product runs on a terminal device, it causes the terminal device to execute the rule package loading method according to any one of the above first aspects or the rule package execution method according to any one of the above second aspects.

[0016] It can be understood that the beneficial effects of the above second aspect to the fifth aspect can refer to the relevant descriptions in the above first aspect, and will not be elaborated here. Description of the Drawings

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for use in the embodiments or the description of the prior art. Obviously, the following drawings are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0018] Figure 1 is a flowchart of a rule package loading method provided by an embodiment of the present application;

[0019] Figure 2 is a flowchart of a rule package loading method provided by another embodiment of the present application;

[0020] Figure 3It is a schematic flowchart of a rule package loading method provided by another embodiment of the present application;

[0021] Figure 4 It is a schematic flowchart of a rule package execution method provided by an embodiment of the present application;

[0022] Figure 5 It is a schematic flowchart of a rule package execution method provided by another embodiment of the present application;

[0023] Figure 6 It is a schematic flowchart of the working process of a rule cloud platform based on a microservice architecture provided by an embodiment of the present application;

[0024] Figure 7 It is a schematic structural diagram of a terminal device provided by an embodiment of the present application. Detailed implementation manners

[0025] In the following description, for the purpose of illustration rather than limitation, specific details such as specific system architectures and technologies are presented to thoroughly understand the embodiments of the present application. However, those skilled in the art should clearly understand that the present application can also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid unnecessary details from interfering with the description of the present application.

[0026] It should be understood that when used in the specification and appended claims of the present application, the term "comprising" indicates the presence of the described features, wholes, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or their combinations.

[0027] It should also be understood that the term "and / or" as used in the specification and appended claims of the present application refers to any combination and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0028] As used in the specification and appended claims of the present application, the term "if" can be interpreted as "when...", "once", "in response to determining", or "in response to detecting" according to the context. Similarly, the phrase "if determined" or "if detecting [the described condition or event]" can be interpreted as meaning "once determined", "in response to determining", "once detecting [the described condition or event]", or "in response to detecting [the described condition or event]" according to the context.

[0029] In addition, in the description of the specification and appended claims of the present application, the terms "first", "second", "third", etc. are only used for distinguishing descriptions and cannot be understood as indicating or implying relative importance.

[0030] As described in the specification of this application, references to "one embodiment" or "some embodiments" etc. mean that in one or more embodiments of this application, specific features, structures or characteristics described in connection with that embodiment are included. Thus, statements such as "in one embodiment", "in some embodiments", "in other some embodiments", "in still other embodiments" etc. that appear in different places in this specification do not necessarily all refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized. The terms "comprising", "including", "having" and their variants all mean "including but not limited to", unless otherwise specifically emphasized.

[0031] As introduced in the related background art, the existing rule engine is a monolithic application and is mainly applicable to small-scale application scenarios. With the development of big data and multiple services in Internet projects, it is very difficult for traditional rule engines to be applied to current Internet projects. Even if a rule engine adopting a microservices architecture can be applied to Internet projects, the rule packages of each rule engine are directly encapsulated in the corresponding microservices project. When the rule package of this microservice needs to be updated, the rule package needs to be republished to the project files of each server corresponding to this microservice, which requires multiple publishing operations for the rule package and is very unfavorable for unified management and monitoring of the rule package.

[0032] Therefore, the embodiments of this application provide a method for loading rule packages based on a microservices architecture, which realizes storing all rule packages in a rule repository, and then automatically preloading the rule packages into the virtual environment memory of the corresponding microservices according to the identification information corresponding to the rule packages, so that it is not necessary to publish the rule packages multiple times. It only needs to be published to the rule repository, and each server corresponding to the microservice can automatically load the rule package from the rule repository, which is more convenient for unified management of the rule packages of all microservices; and writing the preloading result into a preset database is convenient for subsequent monitoring of the preloading result, solving the problem that the rule packages are not convenient to manage and monitor.

[0033] The method for loading rule packages based on a microservices architecture in the embodiments of this application can be applied to a terminal device. Exemplarily, the terminal device can be an independent server, a server cluster, a cloud server, etc. The embodiments of this application do not impose any restrictions on the specific type of the terminal device.

[0034] Figure 1 The schematic flowchart of the method for loading rule packages based on a microservices structure provided by this application is shown. As an example but not a limitation, this method can be applied to the above-mentioned cluster server.

[0035] S101, obtain a rule package and store the rule package in a rule repository, and the rule package carries the identification information of the rule package;

[0036] In the above S101, the above rule package is a set of rule functions called when microservices process business data. Each rule package has its corresponding version information and identification information corresponding to the microservice. The identification information can be the ID number of the rule package. Optionally, it is written through an Integrated Development Environment (IDE), and the version of the rule package is managed through an SVN (Subversion) server. This management includes but is not limited to rule package version update and rule package version release.

[0037] The above rule repository is a database that stores all rule packages. It can be understood that this rule repository can also store other data besides rule packages. Optionally, the permission management of the rule repository is implemented through a lightweight permission framework such as shiro, that is, only users with permissions can upload rule packages to the rule repository.

[0038] S102, according to the preset correspondence between the identification information and the microservice, preload the rule package into the target JVM memory, where the target JVM memory is the JVM memory of the microservice corresponding to the identification information of the rule package;

[0039] In the above S102, the above microservice is a rule execution microservice that processes specific business. For example, according to the life cycle of an insurance policy, specific businesses can be divided into underwriting business, policy maintenance business, claims business, etc. Each business corresponds to a microservice. It should be noted that a microservice can be deployed on multiple servers, that is, each server has the ability to handle the specific business of this microservice. Specifically, the specific business of this microservice is distributed to one of the multiple servers through a task dispatcher.

[0040] The above JVM memory is the memory of the virtual environment of the microservice. When the microservice is started, the rule package is preloaded into the JVM memory of the microservice, so that the microservice can more quickly call the rule package to perform rule processing on business data.

[0041] In the embodiment of the present application, microservices uniformly preload rule packages from the rule repository. Compared with the existing method of encapsulating rule packages in the project files of microservices, in the present application, the rule packages are preloaded into the JVM memory of microservices. In this way, only the rule packages in the rule repository need to be uniformly managed to manage the rule packages of each microservice, and there is no need to separately manage the project files of microservices, which is more conducive to the management and monitoring of rule packages.

[0042] S103, write the preloading result of the rule package in the target JVM memory into a preset database.

[0043] In the above S103, the preset database may be databases such as MySql, Redis, and Mongodb, preferably Mongodb. Mongodb is a non-relational database, and the stored fields may not be fixed. For example, one piece of data only stores two fields, and another piece of data only stores three fields. The preloading result belongs to the data with unfixed field lengths, so Mongodb is more conducive to storing the preloading result.

[0044] The above preloading result includes, but is not limited to, that the rule package is successfully preloaded into the JVM memory of the corresponding microservice, or the preloading of the rule package fails.

[0045] The embodiment of the present application writes the preloading result into the preset database, so as to realize the storage of the preloading result and the subsequent query of the preloading result, and further facilitate the management and monitoring of the preloading result of the rule package.

[0046] On the basis of Figure 1 the shown embodiment, Figure 2 a schematic flowchart of another rule package loading method based on a microservice architecture provided by the embodiment of the present application is shown. As Figure 2 shown, obtaining the rule package in the above step S101 specifically includes S201 to S202. It should be noted that the same steps as Figure 1 the shown embodiment are not described herein again, please refer to the foregoing.

[0047] S201, obtain a rule package release request, and the rule package release request carries permission level information and link information of the rule package;

[0048] In the above S201, the link information of the above rule package is the transmission address information for obtaining the rule package. Specifically, when a user logs in to the system account through a terminal device such as a computer and publishes the written rule package to the rule repository, the computer sends a rule package release request to the rule repository and carries the permission level information of the system account and the link information of the rule package.

[0049] S202, if the permission level information conforms to the preset permission level information, obtain the rule package according to the link information of the rule package.

[0050] In the above S202, in order to improve the security of the rule package and avoid malicious tampering of the rule package in the rule repository, therefore, only when the user of the release request has the preset permission level can the rule package be published to the rule repository, and the rule repository downloads the rule package through the link information of the rule package. The embodiment of the present application sends the rule package to the rule repository in the form of link information along with the rule package release request, rather than directly sending the rule package to the rule repository along with the rule package release request, thereby reducing the occupation of a large amount of transmission channels when sending the rule package release request and improving the transmission efficiency.

[0051] Based on Figure 1 the embodiment shown, Figure 3 a schematic flowchart of another rule package loading method provided by an embodiment of the present application based on a microservice architecture is shown. As Figure 3 shown, storing the rule package in the rule repository in step S101 above includes S301. It should be noted that, for Figure 1 the same steps as the embodiment shown, they will not be elaborated here. Please refer to the foregoing.

[0052] S301. Store the rule package in several first servers equipped with the rule repository in sequence. When storing the rule package in any one of the first servers, pause the business logic of this first server.

[0053] In S301 above, since originally updating the rule package required stopping the operation of the entire rule engine, it affected the rule processing of business data. In this embodiment, by performing gray release on the rule package, gray release is a process of updating the rule package without downtime. Specifically, when storing the rule package in any one of the first servers, pause the business logic of this first server, and the other first servers operate normally.

[0054] For example, microservices are generally deployed on more than two servers. When performing gray release, one of the servers first sets the service (business logic) to an unavailable state, and then this server updates the rule package. At this time, the incoming rule package call commands will be assigned to another server; after the server that updates the rule package finishes the update, restore the available state of this server, change the other server to an unavailable state, and this other server updates the rule package. When there are 3 or more servers, update the rule package for each server in sequence. By gray release, the version number of the rule package can be dynamically switched without causing any adverse effects on the microservices.

[0055] It should be understood that multiple microservices can be deployed on one server. Then, multiple microservices can be deployed on multiple servers. Then, stopping any one server will not cause the rule microservice to stop running. For example, for microservices A and B and servers a and b, deploy both microservices A and B on servers a and b. That is, stopping either server a or b does not affect the operation of the other server, thus ensuring that the microservices operate normally without being affected by the rule package update.

[0056] Based on Figure 1 , Figure 2 or Figure 3 the embodiment shown, an embodiment of another rule package loading method provided by an embodiment of the present application based on a microservice architecture. The identification information includes the rule package ID number. Step S102 specifically includes S1021 to S1022. It should be noted that, forFigure 1 , Figure 2 or Figure 3 The same steps as those in the embodiments shown are not described herein again. Please refer to the foregoing.

[0057] S1021. Monitor the rule package ID numbers of each rule package in the rule repository.

[0058] S1022. If it is detected that the rule package ID number of a rule package is the ID number of the latest version of the rule package, preload the rule package corresponding to the ID number of the latest version of the rule package into the JVM memory of the microservice corresponding to the rule package ID number.

[0059] In the above S1021 and S1022, the above rule package ID number includes the version information of the rule package and the specific identifier of the rule package. For example, if the ID number of the rule package is GZ01V001, GZ001 is used as the specific identifier of the rule package, and V001 is used as the version information of the rule package. Further, according to the preset version number sequence, it is determined whether the version in the rule package ID number is the latest version. For example, if the version numbers are numbered in ascending order, among V001 and V002, V002 is the latest version.

[0060] Optionally, a rule package management platform can be built to monitor the version update situation of the rule repository. The rule package management platform is built based on Spring Boot and adopts a front-end and back-end separation architecture. Among them, the front end sends HTTP requests to the back end in the form of AJAX to obtain data, and the data is displayed on the front end to achieve visualization.

[0061] In Figure 1 , Figure 2 or Figure 3 On the basis of the embodiments shown, another embodiment of the rule package loading method based on the microservice architecture provided by the embodiments of the present application is provided. The identification information includes the rule package ID number. After the above step S103, S1031 is further included. It should be noted that, the same steps as those in Figure 1 , Figure 2 or Figure 3 The embodiments shown are not described herein again. Please refer to the foregoing.

[0062] S1031. If the preloading result is that the rule package preloading fails, reload the rule package into the target JVM memory again.

[0063] In the above S1021, since uncertain factors may occur during the rule package preloading process, resulting in preloading failure, the rule package is reloaded into the target JVM memory again. Further, if the number of times the same rule package fails to be preloaded into the same microservice reaches the preset number of times, an error is reported, that is, the preloading result is fed back to the front end to notify the user to perform relevant processing.

[0064] The rule package execution method based on the microservice architecture in an embodiment of the present application can be applied to a terminal device. Exemplarily, the terminal device can be an independent server, a server cluster, a cloud server, etc. The specific type of the terminal device is not limited in the embodiments of the present application.

[0065] Figure 4 The schematic flowchart of the rule package execution method based on the microservice architecture provided by the present application is shown. As an example but not a limitation, this method can be applied to the above cluster server.

[0066] S401, obtain a rule execution request carrying service data, and determine the service type of the service data;

[0067] In the above S401, the rule execution request is a call command for the service system to call the microservice to perform rule processing on the service data. Specifically, the service system receives an external request, generates a call command carrying service data based on the external request, serializes the call command and sends it to the rule microservice. The microservice obtains the serialized call command and deserializes the call command to obtain the instruction information and service data in the call command.

[0068] The above service type is the service type of the service data for which the microservice performs rule processing, such as underwriting service, maintenance service, claims service, etc. divided according to the life cycle of the insurance policy. In one embodiment, a correspondence table between keywords and service types can be established, keywords in the service data are extracted, and according to the correspondence table between the keywords and service types, the service type corresponding to the service data is determined. In another embodiment, the service system can be divided into multiple subsystems, such as an underwriting subsystem, a maintenance subsystem, and a claims subsystem. If the underwriting subsystem sends a call command carrying service data to the microservice, the service type of the service data can be determined according to the service type processed by the service subsystem at the sending end of the service data. It can be understood that a correspondence can also be established between each subsystem and the rule microservice, and then the call command of the corresponding subsystem is only sent to the microservice that processes the corresponding service type.

[0069] S402, in response to the rule execution request, call the rule package pre-loaded from the rule repository by the microservice corresponding to the service type;

[0070] In the above S402, the microservice is a rule execution platform with an independent rule package, and its rule package is stored in its JVM memory. It runs through a jar package written according to the spi mechanism of Spring Boot, that is, the software installation package. Among them, spi (Service Provider Interface) is a service discovery mechanism built into the Jdk, which is conducive to the dynamic replacement of rule packages by microservices and provides an interface for adding an implementation class when the rule microservice runs, so as to customize the logic of rule execution.

[0071] The above rule package is a rule package written by IDE (Eclipse, Idea), and it is stored in the memory of the microservice. When the microservice processes business data, it calls the rule functions in the rule package to perform rule processing on the business data. Among them, the rule processing of the rule function can be implemented through the rete algorithm.

[0072] By making the rule engine of the original monolithic application into multiple microservices based on the microservice architecture, only the corresponding microservice needs to be called when processing business data. Each microservice does not interfere with each other, and rule processing of multiple business types can be carried out simultaneously, realizing the rule processing of big data and multiple businesses of Internet projects.

[0073] S403, based on the rule functions in the rule package, perform rule processing on the business data to obtain a processing result.

[0074] In the above S403, in the rule package of the microservice, the received business requirement data can be processed according to a preset rule table. The rule table includes a rule executable domain, and the rule executable domain represents the condition for starting the execution of business rules. Inside a rule engine, the business requirement data received from the outside can be disassembled into fact objects and rule files, that is, divided into two parts: data and logic, and then the fact objects are logically processed using the business rule files. Among them, the rule file is a collection of a series of logical processes, and the fact object is the data. Whether to perform such logical processing is determined by the executable domain in the rule table. Those that meet the executable domain are started for execution, and those that do not meet the executable domain are not started for execution.

[0075] Furthermore, write the processing result into a preset database to facilitate subsequent verification of the rationality of the rule functions of the rule package for processing business data.

[0076] In Figure 4 Based on the shown embodiment, Figure 5 The flowchart of another rule package execution method provided by the embodiment of the present application based on the microservice architecture is shown. As Figure 5As shown, the above step S402 specifically includes S501 to S502. It should be noted that, for the same steps as those in the Figure 4 illustrated embodiment, they will not be elaborated here. Please refer to the foregoing.

[0077] S501, in response to a rule execution request, monitor the running status of several second servers carrying microservices;

[0078] S502, when it is monitored that the running status of the second server is the running status of preloading and updating the rule package, call the rule package preloaded by any one of the other second servers except this second server.

[0079] In the above S501 and S502, the rule package in this embodiment adopts gray release, and the microservice adopts dynamic loading. Therefore, when a server of the microservice is preloading the rule package, the received rule execution request is not distributed to this server, but to any server other than this server. Preferably, the rule execution request is distributed to the server that has completed the preloading of the rule package, so as to perform rule processing on the service data using the latest rule function.

[0080] In Figure 4 or Figure 5 On the basis of the illustrated embodiment, another embodiment of the rule package execution method based on the microservice architecture provided by the embodiment of the present application is provided. After the above step S403, it further includes S4031 to S4032. It should be noted that, for the same steps as those in the Figure 4 or Figure 5 illustrated embodiment, they will not be elaborated here. Please refer to the foregoing.

[0081] S4031, determine the rationality of the rule logic of the rule function according to the processing result;

[0082] S4032, if the rationality of the rule logic of the rule function does not meet the preset rationality requirements, based on the transaction rollback mechanism, roll back the version of the rule package corresponding to the rule function in the rule warehouse to the previous version, or update the rule package corresponding to the rule function in the rule warehouse to a new version.

[0083] In the above S4031 and S4032, the situation where the rationality of the rule logic of the rule function does not meet the preset rationality requirements belongs to an exception handling situation. For the exception handling situation, a rollback operation can be performed based on transaction control. Since the abnormal execution of a certain rule function may be caused by the incorrect execution result of a previous rule function, a rollback operation is performed on the rule function with abnormal execution and the rule functions that have been completed before this rule function based on the transaction compensation mechanism to find out the reason for the abnormal execution.

[0084] Specifically, the rollback operation may include starting from the rule function where an execution exception occurs as the first rule function to the first rule function in the execution process, verifying whether the transaction of each rule function is successful. If all are successful, the preset transaction is started. After the preset transaction is executed, this rollback is marked as successful. If not, the version of the rule package is rolled back to the previous version or the version of the rule package is updated to a new version.

[0085] To facilitate a clear understanding of the rule package loading method and the rule package execution method provided by the embodiments of the present application, Figure 6 FIG. shows a schematic diagram of the working process of a rule cloud platform based on a microservices architecture provided by the embodiments of the present application. It should be noted that, Figure 6 The shown working process is only used as an example and is not a specific limitation means of the present application.

[0086] As shown in the figure, the working process of the rule cloud platform includes a rule preloading stage and a rule execution stage. Among them, the rule preloading stage includes: a rule package can be written through an IDE, and the version of the rule package can be managed through an SVN server; a rule package release request carrying permission level information and link information of the rule package is obtained through a rule repository. If the permission level information conforms to the preset permission level information, the rule package is obtained according to the link information of the rule package; the identification information of each rule package in the rule repository is monitored through a rule management platform. If the identification information of the rule package monitored is the identification information of the latest version, the rule package corresponding to the identification information of the latest version is preloaded into the JVM memory of a microservice (such as Figure 6 the rule execution platforms A, B, or C in); the loading result of the rule package is written into a preset database (such as Figure 6 MySql, Redis, or Mongdb in) through the microservice that preloads the rule package; the rule package loading result in the preset database is monitored through a rule management platform. If the loading result is that the rule package loading fails, the rule package is preloaded into the target JVM memory again. If the number of times the loading result fails reaches the preset number of times, an error is reported to the front end.

[0087] Through the steps of the above rule preloading stage, the rule package has been loaded into the JVM memory of the rule execution platforms A, B, or C. Then the rule execution stage includes: obtaining a rule execution request (such as Figure 6 the call request in) sent by the corresponding business systems a, b, or c through the rule execution platforms A, B, or C, and calling the rule package preloaded in the corresponding rule execution platform; based on the rule functions in the rule package, processing the business data in the rule execution request to obtain a processing result. Further, the processing result can be written into a preset database (such as Figure 6Among MySql, Redis or Mongdb), the rule management platform detects the rationality of the rule logic of the rule function according to the processing result. If the rationality of the rule logic of the rule function does not meet the preset rationality requirements, based on the transaction rollback mechanism, the version of the rule package corresponding to the rule function in the rule warehouse is rolled back to the previous version, or the rule package corresponding to the rule function in the rule warehouse is updated to a new version.

[0088] To further ensure the privacy and security of all the data appearing above, all the above data can also be stored in a node of a blockchain, that is, the database in this solution can adopt the database on the blockchain node.

[0089] It should be noted that the blockchain referred to in the present invention is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. Blockchain, in essence, is a decentralized database, a string of data blocks generated by using cryptographic methods. Each data block contains information about a batch of network transactions, which is used to verify the validity of the information (anti-counterfeiting) and generate the next block. The blockchain can include a blockchain underlying platform, a platform product service layer, an application service layer, etc.

[0090] The embodiment of the present application provides a complete workflow and architecture composition of the rule cloud platform, which realizes storing all rule packages in the rule warehouse, automatically preloading the rule packages into the virtual environment memory of the corresponding microservices, so that it is not necessary to publish each rule package to each server of the microservices (i.e., rule execution platforms A, B, or C), thus avoiding multiple publications of the rule packages. Instead, only by publishing to the rule warehouse, each server corresponding to the microservices can automatically load the rule packages from the rule warehouse, which is more convenient for unified management of the rule packages of all microservices; and writing the preloading result into a preset database, which is convenient for subsequent monitoring of the preloading result, solving the problem that the rule packages are not easy to manage and monitor. Further, by transforming the rule engine of the original monolithic application into multiple microservices based on the microservice architecture, only the corresponding microservices need to be called when processing business data, and each microservice does not interfere with each other, and multiple types of business rules can be processed simultaneously, realizing the rule processing of big data and multiple services for Internet projects, and solving the problem that the traditional rule platform cannot be used for Internet projects.

[0091] It should be understood that the magnitudes of the sequence numbers of the steps in the above embodiments do not mean the order of execution. The execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

[0092] Figure 7 This is a schematic structural diagram of a terminal device provided by an embodiment of the present application. As Figure 7As shown, the terminal device 7 of this embodiment includes: at least one processor 70 ( Figure 7 only one is shown in the figure), a processor, a memory 71, and a computer program 72 stored in the memory 71 and executable on the at least one processor 70. When the processor 70 executes the computer program 72, it implements the steps in any of the above-described method embodiments for loading rule packages and executing rule packages.

[0093] The terminal device 7 may be a computing device such as a desktop computer, a notebook, a palm computer, or a cloud server. Specifically, it may be a virtual reality device as described above. The terminal device may include, but is not limited to, a processor 70 and a memory 71. Those skilled in the art can understand that Figure 7 this is only an example of the terminal device 7 and does not limit the terminal device 7. It may include more or fewer components than those shown in the figure, or combine some components, or have different components. For example, it may also include input / output devices, network access devices, etc.

[0094] The so-called processor 70 may be a central processing unit (CPU). The processor 70 may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0095] In some embodiments, the memory 71 may be an internal storage unit of the terminal device 7, such as the hard disk or memory of the terminal device 7. In other embodiments, the memory 71 may also be an external storage device of the terminal device 7, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the terminal device 7. Further, the memory 71 may include both the internal storage unit and the external storage device of the terminal device 7. The memory 71 is used to store an operating system, application programs, a boot loader, data, and other programs, such as the program code of the computer program. The memory 71 may also be used to temporarily store data that has been output or will be output.

[0096] An embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

[0097] An embodiment of the present application provides a computer program product. When the computer program product runs on a mobile terminal, the mobile terminal is enabled to implement the steps in the above-mentioned method embodiments when executed.

[0098] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, to implement all or part of the processes in the above method embodiments of the present application, a computer program can be used to instruct relevant hardware to complete. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in the form of source code, object code, executable file or some intermediate form, etc. The computer-readable medium can at least include: any entity or device that can carry the computer program code to the photographing device / terminal device, recording medium, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electrical carrier signal, telecommunication signal, and software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk or an optical disc, etc. In some jurisdictions, according to legislation and patent practice, the computer-readable medium may not be an electrical carrier signal and a telecommunication signal.

[0099] In the above embodiments, the descriptions of the various embodiments have their own focuses. For parts not detailed or recorded in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0100] Those of ordinary skill in the art can realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0101] In the embodiments provided in the present application, it should be understood that the disclosed device / network device and method can be implemented in other ways. For example, the device / network device embodiments described above are merely illustrative. For example, the division of the modules or units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of the device or unit can be in an electrical, mechanical or other form.

[0102] The units described as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0103] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A rule package loading method based on a microservices architecture, characterized in that Including: Obtain a rule package and store the rule package in a rule repository. The rule package carries identification information of the rule package, and the rule repository is a database storing all rule packages; According to the preset correspondence between the identification information and the microservice, preload the rule package into the target JVM memory. The target JVM memory is the JVM memory of the microservice corresponding to the identification information of the rule package; The microservice is a rule execution platform with independent rule packages, and its rule packages are stored in its JVM memory. It is implemented and run through a jar package written based on the spi mechanism of Spring Boot; The JVM memory is the memory of the virtual environment of the microservice; Write the preloading result of the rule package in the target JVM memory into a preset database; The storing the rule package in the rule repository includes: Store the rule package in several first servers carrying the rule repository in sequence. When storing the rule package in any one of the first servers, pause the business logic of the first server storing the rule package; Among them, the rule package adopts gray release, and the microservice adopts dynamic loading. When a server of the microservice is preloading a rule package, the received rule execution requests are not distributed to this server, but to any server other than this server.

2. The rule package loading method based on the microservice architecture according to claim 1, characterized in that The obtaining the rule package includes: Obtain a rule package release request, and the rule package release request carries permission level information and link information of the rule package; If the permission level information conforms to the preset permission level information, obtain the rule package according to the link information of the rule package.

3. The rule package loading method based on a microservice architecture according to any one of claims 1-2, characterized in that, The identification information includes a rule package ID number; The preloading the rule package into the target JVM memory includes: Monitor the rule package ID numbers of each rule package in the rule repository; If it is detected that the rule package ID number of a rule package is the rule package ID number of the latest version, preload the rule package corresponding to the rule package ID number of the latest version into the JVM memory of the microservice corresponding to the rule package ID number.

4. The rule package loading method based on a microservice architecture according to any one of claims 1-2, characterized in that, After writing the preloading result of the rule package in the target JVM memory into a preset database, it further includes: If the preloading result is that the rule package preloading fails, preload the rule package into the target JVM memory again.

5. A method for executing a rule package based on a microservices architecture, characterized in that, Including: Obtain a rule execution request carrying business data and determine the business type of the business data; Respond to the rule execution request, and call the rule package preloaded from the rule repository by the microservice corresponding to the business type; The microservice is a rule execution platform with independent rule packages, and its rule packages are stored in its JVM memory. It is implemented and run through a jar package written based on the spi mechanism of Spring Boot; The JVM memory is the memory of the virtual environment of the microservice; The rule repository is a database storing all rule packages; Based on the rule functions in the rule package, perform rule processing on the business data to obtain a processing result; In response to the rule execution request, the rule package pre-loaded from the rule repository by invoking the microservice corresponding to the service type includes: in response to the rule execution request, monitoring the running status of several second servers on which the microservice is installed; if the running status of the second server is detected as the running status of pre-loading and updating the rule package, invoking the rule package pre-loaded on any one of the other second servers except this second server. Among them, the rule package adopts gray release, and the microservice adopts dynamic loading. When a server of the microservice is pre-loading the rule package, the received rule execution request is not distributed to this server, but to any one of the servers other than this server.

6. The rule package execution method based on a microservices architecture according to claim 5, wherein After performing rule processing on the service data based on the rule function in the rule package and obtaining the processing result, it further includes: Determining the rationality of the rule logic of the rule function according to the processing result; If the rationality of the rule logic of the rule function does not meet the preset rationality requirements, based on the transaction rollback mechanism, roll back the version of the rule package corresponding to the rule function in the rule repository to the previous version, or update the rule package corresponding to the rule function in the rule repository to a new version.

7. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 6.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the method according to any one of claims 1 to 6.

Images