CN111694638A

CN111694638A - Rule package loading method, rule package executing method and terminal equipment

Info

Publication number: CN111694638A
Application number: CN202010469385.1A
Authority: CN
Inventors: 张强
Original assignee: Ping An Life Insurance Company of China Ltd
Current assignee: Ping An Life Insurance Company of China Ltd
Priority date: 2020-05-28
Filing date: 2020-05-28
Publication date: 2020-09-22

Abstract

The application is applicable to the technical field of computers, and provides a rule package loading method, a rule package executing method and terminal equipment based on a micro-service architecture, wherein the rule package loading method comprises the following steps: acquiring a rule package, and storing the rule package to a rule warehouse, wherein the rule package carries identification information of the rule package; preloading the rule package into a target JVM memory according to a preset corresponding relation between the identification information and the micro service, wherein the target JVM memory is the JVM memory of the micro service corresponding to the identification information of the rule package; and writing the preloading result of the rule packet in the memory of the target JVM into a preset database. The rule packages are stored in the rule warehouse, and the rule packages in the rule warehouse are preloaded to the target JVM memory, so that unified management and monitoring of the rule packages are facilitated, and the problem that the rule packages are inconvenient to manage and monitor is solved. Meanwhile, the application also relates to a block chain technology.

Description

Rule package loading method, rule package executing method and terminal equipment

Technical Field

The application belongs to the technical field of computers, and particularly relates to a rule package loading method, a rule package executing method and terminal equipment of a micro service architecture.

Background

The rules engine enables components embedded in the application to separate business decisions from the application code, reducing the complexity of components of complex business logic, and reducing maintenance and extensibility costs of the application. However, the existing rule engine is a single application and is mainly suitable for small-scale application scenarios. With the development of big data and multiple services of internet projects, the traditional rule engine is difficult to be applied to the current internet projects. Even if the rule engines adopting the micro-service architecture can be applied to internet projects, the rule packet of each rule engine is directly encapsulated in the corresponding micro-service project, which is not beneficial to uniformly managing and monitoring the rule packet.

Disclosure of Invention

The embodiment of the application provides a rule packet loading method, a rule packet executing method and terminal equipment based on a micro service architecture, and can solve the problem that a rule packet is inconvenient to manage and monitor.

In a first aspect, an embodiment of the present application provides a rule package loading method based on a micro service architecture, including:

acquiring a rule package, and storing the rule package to a rule warehouse, wherein the rule package carries identification information of the rule package;

preloading the rule package into a target JVM memory according to a preset corresponding relation between the identification information and the micro service, wherein the target JVM memory is the JVM memory of the micro service corresponding to the identification information of the rule package;

and writing the preloading result of the rule packet in the memory of the target JVM into a preset database.

In the embodiment of the application, all the rule packages are stored in the rule warehouse, and then the rule packages are automatically preloaded into the corresponding virtual environment memory of the micro-service according to the identification information corresponding to the rule packages, compared with the existing method that the rule packages are required to be re-issued into the project file of each server corresponding to the micro-service when the rule packages of the micro-service are updated, the existing method needs to issue the rule packages for multiple times, but the embodiment does not need to issue the rule packages for multiple times, only needs to issue the rule packages to the rule warehouse, and each server corresponding to the micro-service can automatically load the rule packages into the rule warehouse, so that all the rule packages of the micro-service can be managed more conveniently and uniformly; and the preloading result is written into a preset database, so that the preloading result can be monitored subsequently, and the problem that the rule packet is inconvenient to manage and monitor is solved.

In a second aspect, an embodiment of the present application provides a rule package execution method based on a microservice architecture, including:

acquiring a rule execution request carrying business data, and determining the business type of the business data;

responding to the rule execution request, and calling a rule package pre-loaded from a rule warehouse by the micro service corresponding to the service type;

and performing rule processing on the service data based on the rule function in the rule packet to obtain a processing result.

In a third aspect, an embodiment of the present application provides a terminal device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor implements the rule package loading method of any one of the first aspects or the rule package executing method of any one of the second aspects when executing the computer program.

In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, where a computer program is stored, and when being executed by a processor, the computer program implements the rule package loading method of any one of the above first aspects or the rule package executing method of any one of the above second aspects.

In a fifth aspect, an embodiment of the present application provides a computer program product, which, when run on a terminal device, causes the terminal device to execute the rule package loading method of any one of the above first aspects or the rule package executing method of any one of the above second aspects.

It is understood that the beneficial effects of the second aspect to the fifth aspect can be referred to the related description of the first aspect, and are not described herein again.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive exercise.

Fig. 1 is a schematic flowchart of a rule package loading method according to an embodiment of the present application;

fig. 2 is a schematic flowchart of a rule package loading method according to another embodiment of the present application;

fig. 3 is a schematic flowchart of a rule package loading method according to another embodiment of the present application;

FIG. 4 is a flowchart illustrating a method for executing a rule package according to an embodiment of the present application;

FIG. 5 is a flow chart illustrating a method for executing a rule package according to another embodiment of the present application;

FIG. 6 is a schematic workflow diagram of a rule cloud platform based on a micro service architecture according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a terminal device according to an embodiment of the present application.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system structures, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

It will be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should also be understood that the term "and/or" as used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

As used in this specification and the appended claims, the term "if" may be interpreted contextually as "when", "upon" or "in response to" determining "or" in response to detecting ". Similarly, the phrase "if it is determined" or "if a [ described condition or event ] is detected" may be interpreted contextually to mean "upon determining" or "in response to determining" or "upon detecting [ described condition or event ]" or "in response to detecting [ described condition or event ]".

Furthermore, in the description of the present application and the appended claims, the terms "first," "second," "third," and the like are used for distinguishing between descriptions and not necessarily for describing or implying relative importance.

Reference throughout this specification to "one embodiment" or "some embodiments," or the like, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the present application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," or the like, in various places throughout this specification are not necessarily all referring to the same embodiment, but rather "one or more but not all embodiments" unless specifically stated otherwise. The terms "comprising," "including," "having," and variations thereof mean "including, but not limited to," unless expressly specified otherwise.

As introduced in the background, 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 of internet projects, the traditional rule engine is difficult to be applied to the current internet projects. Even if the rule engine adopting the micro-service architecture can be applied to internet projects, the rule packet of each rule engine is directly encapsulated in the corresponding micro-service project, and when the rule packet of the micro-service needs to be updated, the rule packet needs to be re-issued to the project file of each server corresponding to the micro-service, so that the rule packet needs to be issued for multiple times, and the rule packet is not beneficial to being uniformly managed and monitored.

Therefore, the embodiment of the application provides a rule package loading method based on a micro-service architecture, which is used for storing all rule packages to a rule warehouse and automatically preloading the rule packages to a virtual environment memory of a corresponding micro-service according to identification information corresponding to the rule packages, so that the rule packages do not need to be issued for multiple times, and each server corresponding to the micro-service can automatically load the rule packages to the rule warehouse only by issuing the rule packages to the rule warehouse, thereby being more convenient for uniformly managing all the rule packages of the micro-service; and the preloading result is written into a preset database, so that the preloading result can be monitored subsequently, and the problem that the rule packet is inconvenient to manage and monitor is solved.

The rule packet loading method based on the micro service architecture in the embodiment of the present application can be applied to a terminal device, and exemplarily, the terminal device may be an independent server, a server cluster, a cloud server, and the like.

Fig. 1 shows a schematic flow chart of a rule package loading method based on a microservice structure provided in the present application, and the method can be applied to the cluster server described above by way of example and not limitation.

S101, acquiring a rule package, and storing the rule package to a rule warehouse, wherein the rule package carries identification information of the rule package;

in S101, the rule packet is a set including a rule function called when the micro service processes the service data, each rule packet has version information corresponding to the rule packet and identification information corresponding to the micro service, and the identification information may be an ID number of the rule packet. Optionally, the version of the rule package is managed by an svn (subversion) server, written by an Integrated Development Environment (IDE), including but not limited to rule package version update and rule package version release.

The rule repository is a database storing all rule packages, and it is understood that the rule repository may store other data besides rule packages. Optionally, the authority management of the rule repository is implemented by a lightweight authority framework such as shiro, that is, only users with authority can upload the rule package to the rule repository.

S102, preloading the rule package into a target JVM memory according to the preset corresponding relation between the identification information and the micro service, wherein the target JVM memory is the JVM memory of the micro service corresponding to the identification information of the rule package;

in the above S102, the micro service is a rule for processing a specific service, for example, according to a life cycle of the policy, the specific service may be divided into an underwriting service, a security service, a claim settlement service, and the like, and each service corresponds to one micro service. It should be noted that one micro service may be installed on a plurality of servers, that is, each server has the capability of a specific service of the micro service, and specifically, the specific service of the micro service is distributed to one of the plurality of servers by the task distributor.

The JVM memory is a memory of a virtual environment of the microservice. When the micro service is started, the rule packet is preloaded into the JVM memory of the micro service, so that the micro service can more quickly call the rule packet to perform rule processing on the service data.

Compared with the prior art that the rule packages are packaged in the item files of the micro services, the rule packages are preloaded in the JVM memory of the micro services, so that the rule packages of each micro service can be managed only by uniformly managing the rule packages in the rule warehouse, the item files of the micro services do not need to be managed independently, and the rule packages are more favorably managed and monitored.

S103, writing the preloading result of the rule packet in the target JVM memory into a preset database.

In S103, the preset database may be a database such as MySql, Redis, and Mongodb, preferably, Mongodb, which is a non-relational database, and the stored field may not be fixed. For example, one piece of data only stores two fields, the other piece of data only stores 3 fields, and the preloading result belongs to data with variable field lengths, so that Mongoldb is more beneficial to storing the preloading result.

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

According to the embodiment of the application, the preloading result is written into the preset database, so that the preloading result is stored and subsequently inquired, and the preloading result of the rule package is managed and monitored.

Based on the embodiment shown in fig. 1, fig. 2 is a schematic flowchart illustrating another rule package loading method based on a micro service architecture according to the embodiment of the present application. As shown in fig. 2, the acquiring of the rule package in step S101 specifically includes S201 to S202. It should be noted that, the same steps as those in the embodiment shown in fig. 1 are not repeated herein, please refer to the foregoing description.

S201, acquiring a rule packet issuing request, wherein the rule packet issuing request carries authority level information and link information of a rule packet;

in S201, the link information of the rule packet is transmission address information for acquiring the rule packet. Specifically, when a user logs in a system account through a computer and other terminal equipment and issues a written rule package to a rule repository, the computer sends a rule package issuing request like the rule repository and carries authority level information of the system account and link information of the rule package.

S202, if the authority level information accords with the preset authority level information, the rule packet is obtained according to the link information of the rule packet.

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, the rule package can be issued to the rule repository only when the user issuing the request has a preset authority level, and the rule repository downloads the rule package through the link information of the rule package. The rule package is sent to the rule warehouse along with the rule package issuing request in a link information mode instead of directly sending the rule package to the rule warehouse along with the rule package issuing request, so that the occupation of a large number of transmission channels when the rule package is sent without the rule package issuing request is reduced, and the transmission efficiency is improved.

Based on the embodiment shown in fig. 1, fig. 3 is a schematic flowchart illustrating another rule package loading method based on a micro service architecture according to the embodiment of the present application. As shown in fig. 3, storing the rule package in the rule repository in step S101 includes S301. It should be noted that, the same steps as those in the embodiment shown in fig. 1 are not repeated herein, please refer to the foregoing description.

S301, the rule packages are sequentially stored in a plurality of first servers carrying rule warehouses, and when any first server stores the rule packages, the service logic of the first server is suspended.

In S301, since the original rule packet needs to stop the operation of the whole rule engine, the rule processing of the service data is affected. In this embodiment, the gray distribution is a process of updating the rule package without stopping by performing gray distribution on the rule package. Specifically, when any one of the first servers stores the rule packet, the service logic of the first server is suspended, and the other first servers operate normally.

For example, a micro service generally deploys more than two servers, when gray scale distribution is performed, one server first puts the service (service logic) in an unavailable state, then the server performs rule packet update, and at this time, an incoming rule packet call command is distributed to the other server; and when the server for updating the rule packet is updated, recovering the available state of the server, changing another server into an unavailable state, updating the rule packet by the other server, and when 3 or more servers exist, sequentially updating the rule packet for each server. The version number of the rule packet is dynamically switched by gray release, and no adverse effect is caused on the micro service.

It should be understood that if one server can deploy multiple micro-services, multiple micro-services can be deployed in multiple servers, and stopping any one server will not cause the regular micro-service to stop running. For example, the microservice A, B and the servers a and B deploy the microservices a and B in the servers a and B, that is, the stop of the operation of any one of the servers a and B does not affect the operation of the other server, thereby ensuring that the microservice is not affected by the update of the rule packet and operates normally.

On the basis of the embodiments shown in fig. 1, fig. 2, or fig. 3, another embodiment of a rule package loading method based on a micro service architecture is provided in the embodiments of the present application. The identification information includes a rule package ID number, and the step S102 specifically includes steps S1021 to S1022. It should be noted that, the same steps as those in the embodiments shown in fig. 1, fig. 2, or fig. 3 are not repeated herein, please refer to the foregoing description.

S1021, monitoring the ID number of each rule packet in the rule warehouse;

and S1022, if the rule package ID number of the rule package is monitored to be the rule package ID number of the latest version, preloading the rule package corresponding to the rule package ID number of the latest version into the JVM memory of the micro-service corresponding to the rule package ID number.

In S1021 and S1022, the rule package ID number includes version information of the rule package and a specific identifier of the rule package, for example, 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, it is determined whether the version in the rule package ID number is the latest version according to a preset version number order, for example, if the version number is numbered in a positive order, V002 is the latest version in V001 and V002.

Optionally, a rule package management platform can be set up to monitor the version update condition of the rule warehouse, the rule package management platform is set up based on Spring Boot, a front-end and back-end separation architecture is adopted, the front end sends an HTTP request to the back end in an AJAX manner to acquire data, and the data is displayed on the front end to realize visualization.

On the basis of the embodiments shown in fig. 1, fig. 2, or fig. 3, another embodiment of a rule package loading method based on a micro service architecture is provided in the embodiments of the present application. The identification information includes a rule package ID number, and S1031 is further included after the above step S103. It should be noted that, the same steps as those in the embodiments shown in fig. 1, fig. 2, or fig. 3 are not repeated herein, please refer to the foregoing description.

And S1031, if the preloading result is that the rule package preloading fails, preloading the rule package into the target JVM memory again.

In S1021, since the rule package preloading procedure may have uncertainty that may cause preloading failure, the rule package is reloaded into the target JVM memory. Further, if the same rule package is preloaded until the failure frequency of the same micro service reaches a preset frequency, an error is reported, that is, the preloading result is fed back to the front end to inform the user of performing related processing.

The rule packet execution method based on the micro service architecture in the embodiment of the present application may be applied to a terminal device, and for example, the terminal device may be an independent server, a server cluster, a cloud server, and the like.

Fig. 4 is a schematic flow chart of a rule package execution method based on a microservice structure provided by the present application, which can be applied to the cluster server described above by way of example and not limitation.

S401, acquiring a rule execution request carrying business data, and determining the business type of the business data;

in S401, the rule execution request is a call command for the business system to call the microservice to perform rule processing on the business 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 the serialized call command to the rule micro-service, and the micro-service acquires the serialized call command and deserializes the call command to obtain instruction information and service data in the call command.

The service type is a service type of service data regularly processed by the microservice, such as an underwriting service, a security service, a claim settlement service, and the like divided according to a life cycle of the policy. In an embodiment, a correspondence table between keywords and service types may be established, keywords in service data may be extracted, and a service type corresponding to the service data may be determined according to the correspondence table between the keywords and the service types. In another embodiment, the service system may be divided into a plurality of subsystems, such as an underwriting subsystem, a security subsystem, and a claims subsystem, and if the underwriting subsystem sends a call command carrying service data to the microservice, the service type of the service data may 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 corresponding relationship may also be established between each subsystem and the rule microservice, and the call command of the corresponding subsystem is only sent to the microservice processing the corresponding service type.

S402, responding to the rule execution request, and calling a rule package pre-loaded from a rule warehouse by the micro service corresponding to the business type;

in the above S402, the microservice is a rule execution platform with an independent rule package, the rule package is stored in the JVM memory, and the microservice is implemented by a jar package written according to a spi mechanism of the Spring Boot, that is, a software installation package, where spi (service Provider interface) is a service provision discovery mechanism built in Jdk, which is beneficial to dynamically replacing the rule package by the microservice, and provides a logic for implementing that an implementation class interface needs to be added when the microservice is run, so as to customize rule execution.

The rule package is a rule package written in IDE (Eclipse, Idea), and is stored in the memory of the microservice. When the micro service processes the service data, the rule function in the rule packet is called to perform rule processing on the service data, wherein the rule processing of the rule function can be realized through a rete algorithm.

The original rule engine applied by the single body is constructed into a plurality of micro services based on the micro service rack, when the business data is processed, only the corresponding micro services are needed to be called, each micro service is not interfered with each other, the rule processing of various business types can be simultaneously carried out, and the rule processing of big data and multiple businesses of the Internet project is realized.

And S403, performing rule processing on the service data based on the rule function in the rule packet to obtain a processing result.

In the above S403, in the rule packet of the micro service, the received service requirement data may be processed according to a preset rule table, where the rule table includes a rule executable domain, and the rule executable domain indicates a condition for starting service rule execution. In a rule engine, the business requirement data received from the outside can be disassembled into a factual object and a rule file, namely, the factual object is divided into two parts of data and logic, and then the factual object is logically processed by using the business rule file. Where a rule file is a collection of a series of logical processes and the fact objects are 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.

Further, the processing result is written into a preset database, so that the reasonability of the rule function of the rule packet for processing the service data can be checked subsequently.

Based on the embodiment shown in fig. 4, fig. 5 is a flowchart illustrating another rule package execution method based on a microservice architecture according to the embodiment of the present application. As shown in fig. 5, the step S402 specifically includes steps S501 to S502. It should be noted that, the same steps as those in the embodiment shown in fig. 4 are not repeated herein, please refer to the foregoing description.

S501, responding to the rule execution request, and monitoring the running states of a plurality of second servers carrying the micro-services;

and S502, when the running state of the second server is monitored to be the running state of the rule package preloading updating, calling the rule package preloaded by any one second server in other second servers except the second server.

In the above S501 and S502, the rule package of the present embodiment employs gray scale distribution, and the micro service employs dynamic loading, so when one server of the micro service is preloading the rule package, the received rule execution request is not distributed to the server, but distributed to any server other than the server. Preferably, the rule execution request is distributed to the server which has completed the preloading of the rule package, so that the latest rule function is adopted to perform the rule processing on the service data.

On the basis of the embodiments shown in fig. 4 or fig. 5, another embodiment of a rule package execution method based on a microservice architecture is provided in the embodiments of the present application. Step S403 is followed by steps S4031 to S4032. It should be noted that, the same steps as those in the embodiment shown in fig. 4 or fig. 5 are not repeated herein, please refer to the foregoing description.

S4031, determining the rationality of the rule logic of the rule function according to the processing result;

s4032, if the reasonability of the rule logic of the rule function does not meet the preset reasonability requirement, rolling back the version of the rule packet corresponding to the rule function in the rule warehouse to the last version based on the transaction rollback mechanism, or updating the rule packet corresponding to the rule function in the rule warehouse into a new version.

In S4031 and S4032, the condition that the rationality of the rule logic of the rule function does not meet the preset rationality requirement belongs to an exception handling condition, and the exception handling condition may be a rollback operation based on transaction control. Since the execution exception of a certain rule function may be caused by the error of the execution result of the previous rule function, the rollback operation is performed on the rule function with the execution exception and the rule function which has been completed before the rule function based on the transaction compensation mechanism to find out the reason causing the execution exception.

Specifically, the rollback operation may include starting from the rule function with the execution exception as the first rule function to the first rule function in the execution flow, verifying whether the transaction of each rule function is successful, starting to execute the preset transaction if the transaction is successful, marking the rollback of the time as successful after the execution of the preset transaction is finished, and rolling back the version of the rule packet to the previous version or updating the version of the rule packet to the new version if the transaction is unsuccessful.

In order to facilitate clear understanding of the rule package loading method and the rule package executing method provided in the embodiment of the present application, fig. 6 shows a workflow diagram of a rule cloud platform based on a micro service architecture provided in the embodiment of the present application. It should be noted that the workflow shown in fig. 6 is only used as an example, and is not a specific limitation means of the present application.

As shown, the workflow of the rule cloud platform includes a rule preloading phase and a rule executing phase. Wherein the rule preloading phase comprises: the rule package can be compiled through the IDE, and the version of the rule package is managed through the SVN server; acquiring a rule package issuing request carrying authority level information and link information of a rule package through a rule warehouse, and acquiring the rule package according to the link information of the rule package if the authority level information accords with preset authority level information; monitoring the identification information of each rule package in the rule repository through the rule management platform, and if the identification information of the rule package is monitored to be the identification information of the latest version, preloading the rule package corresponding to the identification information of the latest version into a JVM memory of a microserver (such as the rule execution platform A, B or C in fig. 6); writing the loading result of the rule package into a preset database (such as MySql, Redis or Mongdb in FIG. 6) through the micro-service of the pre-loading rule package; and monitoring a rule package loading result in a preset database through a rule management platform, if the loading result is that the rule package loading fails, reloading the rule package to a target JVM memory, and if the frequency of loading failure of the loading result reaches a preset frequency, reporting an error to the front end.

Through the steps of the rule preloading phase, the rule package is already loaded into the JVM memory of the rule execution platform A, B or C, and the rule execution phase includes: acquiring a rule execution request (such as a call request in fig. 6) sent by a corresponding service system a, b, or C through the rule execution platform A, B or C, and calling a rule package preloaded in the corresponding rule execution platform; and processing the service data in the rule execution request based on the rule function in the rule packet to obtain a processing result. Further, the processing result may be written into a preset database (e.g., MySql, Redis, or Mongdb in fig. 6), the rationality of the rule logic of the rule function is detected by the rule management platform according to the processing result, and if the rationality of the rule logic of the rule function does not meet the preset rationality requirement, the version of the rule packet corresponding to the rule function in the rule repository is rolled back to the previous version based on the transaction rollback mechanism, or the rule packet corresponding to the rule function in the rule repository is updated to the new version.

In order to further ensure the privacy and security of all the data appearing above, all the data may also be stored in a node of a block chain, that is, the database in this scheme may be a database on a block chain node.

It should be noted that the blockchain in the present invention is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. A block chain (Blockchain), which is essentially a decentralized database, is a series of data blocks associated by using a cryptographic method, and each data block contains information of a batch of network transactions, so as to verify the validity (anti-counterfeiting) of the information and generate a next block. The blockchain may include a blockchain underlying platform, a platform product service layer, an application service layer, and the like.

The embodiment of the application provides a complete workflow and architecture composition of a rule cloud platform, all rule packages are stored in a rule warehouse, the rule packages are automatically preloaded into a virtual environment memory of a corresponding micro service, and each rule package is not required to be issued to each server of the micro service (namely the rule execution platform A, B or C), so that the rule packages are prevented from being issued for multiple times, and only the rule packages are required to be issued to the rule warehouse, each server corresponding to the micro service can automatically load the rule packages into the rule warehouse, and thus the rule packages of all micro services can be more conveniently and uniformly managed; and the preloading result is written into a preset database, so that the preloading result can be monitored subsequently, and the problem that the rule packet is inconvenient to manage and monitor is solved. Furthermore, the original rule engine applied by the single body is constructed into a plurality of micro services based on the micro service rack, the corresponding micro services are only needed to be called when the business data are processed, each micro service is not interfered with each other, the rule processing of various business types can be carried out simultaneously, the rule processing of big data and multiple services of the internet project is realized, and the problem that the traditional rule platform cannot be used for the internet project is solved.

It should be understood that, the sequence numbers of the steps in the foregoing embodiments do not imply an execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

Fig. 7 is a schematic structural diagram of a terminal device according to an embodiment of the present application. As shown in fig. 7, the terminal device 7 of this embodiment includes: at least one processor 70 (only one shown in fig. 7), a memory 71, and a computer program 72 stored in the memory 71 and executable on the at least one processor 70, wherein the processor 70 executes the computer program 72 to implement the steps of any of the various rule package loading method and rule package executing method embodiments described above.

The terminal device 7 may be a computing device such as a desktop computer, a notebook, a palm computer, and a cloud server, and specifically, the above virtual reality device. The terminal device may include, but is not limited to, a processor 70, a memory 71. Those skilled in the art will appreciate that fig. 7 is only an example of the terminal device 7, and does not constitute a limitation to the terminal device 7, and may include more or less components than those shown, or combine some components, or different components, for example, and may further include input/output devices, network access devices, and the like.

The Processor 70 may be a Central Processing Unit (CPU), and the Processor 70 may be other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic, discrete hardware components, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The memory 71 may in some embodiments be an internal storage unit of the terminal device 7, such as a hard disk or a 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 memory Card (Flash Card), and the like, which are provided on the terminal device 7. Further, the memory 71 may also include both an internal storage unit and an external storage device of the terminal device 7. The memory 71 is used for storing an operating system, an application program, a BootLoader (BootLoader), data, and other programs, such as program codes of the computer program. The memory 71 may also be used to temporarily store data that has been output or is to be output.

The embodiments of the present application further provide a computer-readable storage medium, where a computer program is stored, and when the computer program is executed by a processor, the computer program implements the steps in the above-mentioned method embodiments.

The embodiments of the present application provide a computer program product, which when running on a mobile terminal, enables the mobile terminal to implement the steps in the above method embodiments when executed.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer-readable storage medium and can implement the steps of the embodiments of the methods described above when the computer program is executed by a processor. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer readable medium may include at least: any entity or device capable of carrying computer program code to a photographing apparatus/terminal apparatus, a recording medium, computer Memory, Read-Only Memory (ROM), random-access Memory (RAM), an electrical carrier signal, a telecommunications signal, and a software distribution medium. Such as a usb-disk, a removable hard disk, a magnetic or optical disk, etc. In certain jurisdictions, computer-readable media may not be an electrical carrier signal or a telecommunications signal in accordance with legislative and patent practice.

In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and reference may be made to the related descriptions of other embodiments for parts that are not described or illustrated in a certain embodiment.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus/network device and method may be implemented in other ways. For example, the above-described apparatus/network device embodiments are merely illustrative, and for example, the division of the modules or units is only one logical division, and there may be other divisions when actually implementing, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not implemented. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

The above-mentioned embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present application and are intended to be included within the scope of the present application.

Claims

1. A rule package loading method based on a micro service architecture is characterized by comprising the following steps:

2. The microservice architecture-based rule package loading method of claim 1, wherein the obtaining the rule package comprises:

acquiring a rule packet issuing request, wherein the rule packet issuing request carries authority level information and link information of a rule packet;

and if the authority level information accords with the preset authority level information, acquiring the rule packet according to the link information of the rule packet.

3. The microservice architecture-based rule package loading method of claim 1, wherein the storing the rule package to a rule repository comprises:

and sequentially storing the rule packages to a plurality of first servers carrying the rule warehouse, and suspending the execution of the service logic of the first servers storing the rule packages when any one of the first servers stores the rule packages.

4. The microservice-architecture-based rule package loading method of any one of claims 1-3, wherein the identification information comprises a rule package ID number;

the preloading the rule package into the memory of the target JVM includes:

monitoring the ID number of each rule package in the rule warehouse;

and if the ID number of the rule packet is monitored to be the ID number of the latest version of the rule packet, preloading the rule packet corresponding to the ID number of the latest version of the rule packet into the JVM memory of the micro-service corresponding to the ID number of the rule packet.

5. The microservice-architecture-based rule package loading method of any one of claims 1 to 3, wherein after writing the pre-loaded result of the rule package in the target JVM memory into a preset database, further comprising:

and if the preloading result is that the rule package preloading fails, reloading the rule package into a target JVM memory.

6. A rule packet execution method based on a micro service architecture is characterized by comprising the following steps:

responding to the rule execution request, and calling a rule package pre-loaded from a rule warehouse by the micro service corresponding to the business type;

7. The microservice-architecture-based rule package execution method of claim 6, wherein the invoking of the rule package pre-loaded from the rule repository by the microservice corresponding to the business type in response to the rule execution request comprises:

responding to the rule execution request, and monitoring the running states of a plurality of second servers carrying the micro-service;

if the running state of the second server is monitored to be the running state of the rule package preloading updating, calling the rule package preloaded by any one of the second servers except the second server.

8. The method for executing rule package based on microservice architecture as claimed in claim 6 or 7, wherein after the rule processing is performed on the service data based on the rule function in the rule package and the processing result is obtained, the method further comprises:

determining the reasonability of rule logic of the rule function according to the processing result;

and if the reasonability of the rule logic of the rule function does not meet the preset reasonability requirement, rolling back the version of the rule packet corresponding to the rule function in the rule warehouse to the last version based on a transaction rollback mechanism, or updating the rule packet corresponding to the rule function in the rule warehouse into a new version.

9. A terminal device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the method of any one of claims 1 to 5, or 6 to 8 when executing the computer program.

10. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1 to 5, or 6 to 8.