Distributed micro-service decision method, device, equipment and computer storage medium

Abstract

The present application relates to the field of financial technology, and discloses a distributed micro-service decision-making method, comprising the following steps: receiving a micro-service request, obtaining input parameter information associated with a rule engine when the micro-service request needs to call the rule engine; grouping target input parameters required by the rule engine according to the input parameter information; calling a predefined data acquisition component to perform a parameter acquisition task according to the grouping, and obtaining target input parameters corresponding to the grouping; inputting the obtained target input parameters into the rule engine to obtain a processing result corresponding to the micro-service request. The present application also discloses a distributed micro-service decision-making device, equipment and computer storage medium. The present application improves the throughput of the distributed system and improves the reuse rate of parameter acquisition code in micro-service decision-making.

Description

Technical Field

[0001] The present invention relates to the technical field of financial technology (Fintech), and in particular to a distributed microservice decision-making method, apparatus, device, and computer storage medium. Background Art

[0002] In recent years, with the rapid development of Internet financial technology (Fintech), more and more technologies (big data, distributed, blockchain, artificial intelligence, etc.) have been applied in the financial field.

[0003] The amount of data and business volume of financial services are growing exponentially. In this case, higher requirements are placed on the system performance of financial services that process financial services. Currently, distributed architecture and microservice architecture are usually used to execute financial services. Microservices involve rule engines, which need to obtain relevant parameters when executing. Currently, parameters are obtained through RPC (Remote Procedure Call). Each RPC is called through a separate thread. The acquisition of microservice-related parameters requires a large number of threads, while the number of threads provided by a single distributed node is limited. In addition, the consumption of thread destruction and creation is relatively large, and the system throughput cannot be improved. In addition, microservice requests involve many parameters, and the code for a large number of parameters is relatively large, which is very difficult to read and has a low code reuse rate. Summary of the Invention

[0004] The main purpose of the present invention is to propose a distributed microservice decision-making method, device, equipment and computer storage medium, aiming to address the low throughput of current microservice systems and the difficulty of code reuse.

[0005] To achieve the above object, the present invention provides a distributed microservice decision-making method, which includes the following steps:

[0006] Receive a microservice request, and when the microservice request needs to call a rule engine, obtain input parameter information associated with the rule engine;

[0007] When the microservice request needs to call the rule engine, obtain the input parameter information associated with the rule engine;

[0008] Grouping the target input parameters required by the rule engine according to the input parameter information, calling a predefined data acquisition component to execute a parameter acquisition task according to the grouping, and acquiring the target input parameters corresponding to the grouping;

[0009] The obtained target input parameter is input into the rule engine to obtain the processing result corresponding to the microservice request.

[0010] Optionally, the step of grouping target input parameters required by the rule engine according to the input parameter information includes:

[0011] Obtaining parameter source information and / or parameter acquisition rules of the input parameter information;

[0012] The target input parameters required by the rule engine are grouped according to the parameter source information and / or the parameter acquisition rules.

[0013] Optionally, the step of calling a predefined data acquisition component to execute a parameter acquisition task according to the grouping to acquire a target input parameter corresponding to the grouping includes:

[0014] Call a predefined data acquisition component for each group;

[0015] Obtaining the execution time of each of the data acquisition components, and combining the data acquisition components according to their respective execution times to form a data acquisition component class;

[0016] Execute the parameter acquisition task corresponding to each data acquisition component class to obtain the target input parameter.

[0017] Optionally, the step of obtaining the execution time of each of the data acquisition components and combining the data acquisition components according to their respective execution times to form a data acquisition component class includes:

[0018] Obtaining the execution time of each of the data acquisition components, and taking the longest execution time as the target execution time;

[0019] Combining each data acquisition component with one or more other data acquisition components to obtain a subset of data acquisition components;

[0020] Counting the sum of execution time of each data acquisition component in the data acquisition component subset, and obtaining a preset number of target data acquisition component subsets whose sum of execution time is close to the target execution time;

[0021] Taking a union of the target data acquisition component subsets, and determining whether the union contains all non-repeated data acquisition components;

[0022] If the union contains all non-repeated data acquisition components, each of the target data acquisition component subsets is regarded as a data acquisition component class.

[0023] Optionally, the step of obtaining the execution time of each of the data acquisition components and combining the data acquisition components according to their respective execution times to form a data acquisition component class includes:

[0024] Obtain the execution time of each of the data acquisition components, count the execution time of each of the data acquisition components, obtain the total execution time, and obtain the service response time of the microservice request;

[0025] If the total execution time is less than or equal to the service response time, all the data acquisition components are combined to form a data acquisition component class;

[0026] If the total execution time is greater than the service response time, the data acquisition components are combined according to the service response time to form at least two data acquisition component classes.

[0027] Optionally, the step of executing the parameter acquisition task corresponding to each data acquisition component class to acquire target input parameters includes:

[0028] If only one data acquisition component class is formed, each data acquisition component contained in the data acquisition component class is executed serially to obtain the target input parameter;

[0029] If more than two data acquisition component classes are formed, the data acquisition component classes are executed in parallel to obtain target input parameters. In the process of executing each data acquisition component class, the various data acquisition components contained in the data acquisition component class are executed serially.

[0030] Optionally, after the step of calling a predefined data acquisition component according to the grouping to execute a parameter acquisition task and acquiring a target input parameter corresponding to the grouping, the method includes:

[0031] If the target input parameter is not obtained within the preset time interval, the data acquisition component is closed.

[0032] Optionally, after the step of inputting the acquired target input parameter into the rule engine to obtain a processing result corresponding to the microservice request, the method includes:

[0033] If the processing result is abnormal, the target input parameter in the rule engine is downgraded or set to empty, and the rule engine is executed to obtain the processing result corresponding to the microservice request.

[0034] In addition, to achieve the above-mentioned purpose, the present invention further provides a distributed microservice decision-making device, which includes:

[0035] A request receiving module is used to receive microservice requests and, when the microservice request needs to call a rule engine, obtain input parameter information associated with the rule engine;

[0036] An information acquisition module is used to obtain input parameter information associated with the rule engine when the microservice request needs to call the rule engine;

[0037] An input parameter acquisition module is used to group the target input parameters required by the rule engine according to the input parameter information, call the predefined data acquisition component to perform the parameter acquisition task according to the grouping, and obtain the target input parameters corresponding to the group;

[0038] The input acquisition module is used to input the acquired target input parameters into the rule engine to obtain the processing result corresponding to the microservice request.

[0039] In addition, to achieve the above-mentioned purpose, the present invention also provides a distributed microservice decision-making device, which includes: a memory, a processor, and a computer program corresponding to the distributed microservice decision stored in the memory and runnable on the processor. When the computer program corresponding to the distributed microservice decision is executed by the processor, the steps of the distributed microservice decision-making method described above are implemented.

[0040] In addition, to achieve the above-mentioned purpose, the present invention also provides a computer-readable storage medium, on which a computer program corresponding to a distributed microservice decision is stored. When the computer program corresponding to the distributed microservice decision is executed by a processor, the steps of the distributed microservice decision method as described above are implemented.

[0041] The present invention provides a distributed microservice decision method, apparatus, device and computer storage medium. In this embodiment of the present invention, a microservice request is received. When the microservice request needs to call a rule engine, input parameter information associated with the rule engine is obtained; when the microservice request needs to call a rule engine, input parameter information associated with the rule engine is obtained; target input parameters required by the rule engine are grouped according to the input parameter information, and a predefined data acquisition component is called according to the group to perform a parameter acquisition task to obtain target input parameters corresponding to the group; the obtained target input parameters are input into the rule engine to obtain a processing result corresponding to the microservice request. In this embodiment of the present invention, the target input parameters required by the rule engine are grouped according to the input parameter information, and the target input parameters corresponding to the group are obtained by a predefined data acquisition component. In this way, each target input parameter does not need to be obtained through a thread, which reduces the thread occupancy rate and improves the throughput rate of the distributed system. In addition, since a type of input parameter is obtained through the data acquisition component, it is not necessary to set corresponding code for each target input parameter, which improves the code reuse rate. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 Schematic diagram of the device structure of the hardware operating environment involved in the embodiment of the present invention;

[0043] Figure 2This is a flow chart of the first embodiment of the distributed microservice decision-making method of the present invention;

[0044] Figure 3 This is a flow chart of the second embodiment of the distributed microservice decision-making method of the present invention;

[0045] Figure 4 Schematic diagram of the functional modules of an embodiment of a distributed microservice decision-making device of the present invention.

[0046] The purpose, features and advantages of the present invention will be further described with reference to the accompanying drawings and in conjunction with the embodiments. DETAILED DESCRIPTION

[0047] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0048] like Figure 1 As shown, Figure 1 It is a schematic diagram of the device structure of the hardware operating environment involved in the embodiment of the present invention.

[0049] The distributed microservice decision-making device of the embodiment of the present invention can be a PC or a server device, on which a Java virtual machine is running. Figure 1 As shown, the distributed microservice decision-making device may include: a processor 1001, such as a CPU, a network interface 1004, a user interface 1003, a memory 1005, and a communication bus 1002. Among them, the communication bus 1002 is used to realize the connection and communication between these components. The user interface 1003 may include a display screen (Display), an input unit such as a keyboard (Keyboard), and the user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory or a stable memory (non-volatile memory), such as a disk memory. The memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0050] Those skilled in the art will understand that Figure 1 The device structure shown in the figure does not constitute a limitation of the device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0051] like Figure 1 As shown, the memory 1005 as a computer storage medium may include computer programs corresponding to the operation network communication module, the user interface module, and the distributed microservice decision.

[0052] exist Figure 1 In the device shown, the network interface 1004 is mainly used to connect to the backend server and communicate data with the backend server; the user interface 1003 is mainly used to connect to the client (user end) and communicate data with the client; and the processor 1001 can be used to call the computer program corresponding to the distributed microservice decision stored in the memory 1005 and perform the operations in the following distributed microservice decision method.

[0053] With the dramatic changes in the financial environment and evolving consumer habits, the financial industry is experiencing increasingly frequent and drastic changes. Consequently, rule engines have emerged. These engines decouple complex and ever-changing business rules from application code, storing them in files or specialized storage media as rule scripts. This allows changes to business rules to take effect in online environments without requiring application changes or server restarts. Consequently, rule engines are widely used in the financial industry. Execution within a rule engine typically involves the following steps: 1. Obtaining the input parameters required by the rule engine; 2. Entering these input parameters into the rule engine; and 3. Returning the output parameters from the rule engine to the caller.

[0054] To illustrate the steps of the embodiment of the distributed microservice decision-making method of the present invention, several concepts are first explained, specifically:

[0055] 1. Rule Engine: Evolved from the inference engine, the rule engine is a component embedded in applications that separates business decisions from application code and uses predefined semantic modules to author business decisions. Using a rule engine can separate complex and redundant business rules from the entire supporting system, enabling reusable and portable architectures. Rule engines typically allow rules to be modified without restarting the system or deploying new executable code.

[0056] 2. System Performance: System performance can be expressed in terms of response time and throughput. Response time is the time between submitting a request and returning a response to that request; throughput is a measure of the amount completed per unit time. The relationship between response time and throughput is complex. Sometimes, higher throughput can be achieved at the expense of response time, while other times, better response time can be achieved at the expense of throughput. Sometimes, a single change can improve both.

[0057] 3. Distributed systems: A distributed system is a software system built on a network. It is a loosely coupled system consisting of multiple processors interconnected by communication lines. From the perspective of a single processor in the system, the other processors and their corresponding resources are remote; only its own resources are local. Because distributed systems are built on a network, network overload can degrade system performance and increase response time.

[0058] 4. Microservices. The concept of microservices is similar to distributed systems. Microservices are an architectural style. Simply put, microservices are small services that focus on completing a single task and performing it well. These services can be deployed and run independently. Each microservice is loosely coupled and can interact with each other via RPC. The subtle difference between microservices and distributed systems is that microservice applications do not necessarily need to be distributed across multiple servers; they can also be hosted on the same server.

[0059] 5. RPC (Remote Procedure Call): RPC allows a program to call a procedure or function in another address space (usually on another machine on a shared network) without the programmer having to explicitly code the details of the remote call. That is, the calling code written by the programmer is essentially the same, whether the call is local or remote. However, RPC calls generally take an order of magnitude longer than local calls because network transmission efficiency is lower than memory transmission.

[0060] Based on the above hardware structure and the above concept description, an embodiment of the distributed microservice decision-making method of the present invention is proposed.

[0061] Reference Figure 2 , Figure 2 This is a flow chart of a first embodiment of a distributed microservice decision-making method according to the present invention. The distributed microservice decision-making method includes:

[0062] Step S10: receiving a microservice request, and when the microservice request needs to call a rule engine, obtaining input parameter information associated with the rule engine.

[0063] In this embodiment, the distributed microservice decision-making method is applied to the distributed system of financial institutions (banks, insurance institutions, securities institutions, etc.) in the financial industry. The distributed system includes a microservice decision-making device. The microservice decision-making device refers to a hardware platform equipped with a computer program corresponding to the distributed microservice decision-making method. A JVM (Java Virtual Machine) runs on the microservice decision-making device. The microservice decision-making device needs to have high system performance to meet the concurrency and access speed requirements of financial services.

[0064] The microservice decision device receives the microservice request, and the triggering method of the microservice request is not specifically limited. That is, the microservice request can be actively triggered by the user, for example, the user clicks the "microservice" button on the microservice decision device to trigger the microservice request; or the microservice request can also be automatically triggered by the microservice decision device, for example, the microservice decision device automatically triggers the microservice request when it detects that the preset trigger conditions are met.

[0065] When the microservice decision device receives a microservice request, it determines whether the microservice request needs to call the rule engine. When the microservice request needs to call the rule engine, the microservice decision device obtains the input parameter information associated with the rule engine. The input parameter information includes but is not limited to: parameter name, parameter type, parameter source information, parameter acquisition rules, etc.

[0066] Step S20: grouping target input parameters required by the rule engine according to the input parameter information.

[0067] The microservice decision device determines the target input parameters required by the rule engine based on the input parameter information. The microservice decision device groups the target input parameters required by the rule engine based on the input parameter information. Specifically:

[0068] Step a1, obtaining parameter source information and / or parameter acquisition rules of the input parameter information;

[0069] Step a2: grouping the target input parameters required by the rule engine according to the parameter source information and / or the parameter acquisition rule.

[0070] Specifically, the microservice decision-making device obtains parameter source information and / or parameter acquisition rules for the input parameters. It then groups the target input parameters required by the rule engine according to this parameter source information and / or parameter acquisition rules. Grouping in this embodiment does not carry a specific business meaning; it simply indicates that a group of input parameters is acquired through the same data acquisition component. The principles of grouping are: 1. Input data originates from the response of a microservice request, forming a group; 2. Input parameters are acquired in the same manner and applied to different rules, ensuring essentially consistent implementation logic.

[0071] For example, there is a blacklist database table inside the rule engine system. Both the transfer-in rules and the transfer-out rules need to query the database to see whether the corresponding card number (payee or payer) in the operation is on the blacklist. The microservice decision device treats the "whether the payee's card number hits the blacklist" parameter or the "whether the payer's card number hits the blacklist" parameter in the two scenarios as a group, and obtains the target input parameters in the group through a general data acquisition component that checks whether the card number hits the blacklist to achieve the purpose of code reuse.

[0072] As shown in Table 1, Table 1 shows a payment scenario. Before making a payment, the payment platform calls the anti-fraud system for security checks. The anti-fraud system executes the corresponding rule engine. The target input parameters required by the rule engine are grouped. The groups set by the microservice decision device include:

[0073] The parameters in Group 1 come from the original payment request from the payment platform. This scenario is typical: the request message is directly or slightly transformed before being transparently passed to the rule input parameters. Setting these parameters eliminates the need to query data storage or make microservice RPC requests; the conversion is done directly in memory, ensuring consistent implementation logic.

[0074] The parameters in Group 2 all set the Champion Challenge random variables. The basic logic of the Champion Challenge random variables for each rule is consistent.

[0075] The parameters in group 3 all come from the same database.

[0076] The parameters of group 4 come from the blacklist system, and the return value is processed and set to the corresponding rule input parameter.

[0077]

[0078]

[0079] Table 1

[0080] Step S30: Call a predefined data acquisition component according to the group to execute a parameter acquisition task, and obtain target input parameters corresponding to the group.

[0081] The microservice decision-making device receives the input parameter information data interface corresponding to the group, executes the parameter acquisition task through the predefined data acquisition component in the data interface, and obtains the target input parameter corresponding to the group.

[0082] Step S40: input the acquired target input parameter into the rule engine to obtain the processing result corresponding to the microservice request.

[0083] The microservice decision-making device inputs the acquired target input parameters into the rule engine, which then runs the rule engine to obtain the processing result corresponding to the microservice request. In this embodiment, the target input parameters required by the rule engine are grouped according to the input parameter information. The target input parameters corresponding to the group are acquired through a predefined data acquisition component. This eliminates the need to acquire each target input parameter through a separate thread, reducing thread occupancy and improving the throughput of the distributed system. Furthermore, since the data acquisition component acquires a single type of input parameter, it eliminates the need to set up corresponding code for each target input parameter, thereby increasing code reuse.

[0084] Further, refer to Figure 3Based on the first embodiment of the distributed microservice decision-making method of the present invention, a second embodiment of the distributed microservice decision-making method of the present invention is proposed.

[0085] This embodiment is a refinement of step S30 in the first embodiment. The difference between this embodiment and the above embodiment is that it includes:

[0086] Step S31: assign a predefined data acquisition component to each group.

[0087] The microservice decision device assigns a predefined data acquisition component to each group. The data acquisition component is a code predefined in the data interface for performing data acquisition operations.

[0088] Step S32: Obtain the execution time of each of the data acquisition components, and combine the data acquisition components according to their respective execution times to form a data acquisition component class.

[0089] The microservice decision-making device obtains the execution time of each data acquisition component (the execution time of the data acquisition component is the average execution time obtained from multiple executions during the writing, testing, or daily use of the data acquisition component). The microservice decision-making device combines the data acquisition components according to their respective execution times to form a data acquisition component class. There are different ways to implement this:

[0090] Implementation method 1:

[0091] Step b1, obtaining the execution time of each data acquisition component, counting the execution time of each data acquisition component, obtaining the total execution time, and obtaining the service response time of the microservice request;

[0092] Step b2: If the total execution time is less than or equal to the service response time, all the data acquisition components are combined to form a data acquisition component class;

[0093] Step b3: If the total execution time is greater than the service response time, the data acquisition components are combined according to the service response time to form at least two data acquisition component classes.

[0094] That is, the microservice decision device obtains the execution time of each data acquisition component, counts the execution time of each data acquisition component, obtains the total execution time, and the microservice decision device obtains the business response time of the microservice request, wherein the business response time refers to the longest response time of the microservice. For example, the business response time is 100ms, and the microservice decision device compares the total execution time and the business response time; if the total execution time is less than or equal to the business response time, the microservice decision device combines all the data acquisition components to form a data acquisition component class; if the total execution time is greater than the business response time, the microservice decision device combines the data acquisition components according to the business response time to form at least two data acquisition component classes.

[0095] Specifically, in this embodiment, when the total execution time is greater than the business response time, the microservice decision device first determines whether there is a sequence between the parameter acquisition tasks corresponding to each data acquisition component. If there is a sequence between the parameter acquisition tasks corresponding to each data acquisition component, the data acquisition components are arranged according to the sequence between the data acquisition components, and the data acquisition components after sorting are divided to form several data acquisition component classes, wherein the sum of the execution time of each data acquisition component in each data acquisition component class is less than or equal to the business response time; if there is no sequence between the parameter acquisition tasks corresponding to each data acquisition component, the data acquisition components are combined according to the execution time to form several data acquisition component classes. The specific method of combining data acquisition components according to execution time is not limited, and it is only necessary to ensure that the sum of the execution time of each data acquisition component in the formed data acquisition component class is less than or equal to the business response time. In addition, the microservice decision device can be flexibly combined based on the number of idle threads, so that both response time and throughput can be achieved.

[0096] For example, there are data acquisition components a, b, c, d, and e. The sum of their average execution times is greater than the service response time (100ms). The average execution times of data acquisition components a, b, c, d, and e are 10ms, 20ms, 30ms, 40ms, and 50ms, respectively. If all data acquisition components are executed serially as a single data acquisition component class, the total execution time is 150ms = 10ms + 20ms + 30ms + 40ms + 50ms. It takes 150ms to acquire all the data, which is significantly greater than the service response time. To improve response efficiency and reduce waiting time, the microservice decision-making device combines a+d and b+c into two data acquisition component classes: c1 and c2. The microservice decision-making device then executes c1, c2, and e as three combined data acquisition component classes in parallel. This way, the time to acquire all the data will be the maximum of c1, c2, and e, which is 50ms. This reduces the response time for acquiring all the data from 150ms to 50ms, a two-fold reduction, or 1 / 3 of the original time.

[0097] Implementation method 2:

[0098] Step c1, obtaining the execution time of each data acquisition component, and taking the longest execution time as the target execution time;

[0099] Step c2: combining each data acquisition component with one or more other data acquisition components to obtain a data acquisition component subset;

[0100] Step c3, counting the sum of execution time of each data acquisition component in the data acquisition component subset, and obtaining a preset number of target data acquisition component subsets whose sum of execution time is close to the target execution time;

[0101] Step c4, taking a union of the target data acquisition component subsets, and determining whether the union contains all non-repeated data acquisition components;

[0102] Step c5: If the union contains all non-repeated data acquisition components, each of the target data acquisition component subsets is regarded as a data acquisition component class.

[0103] That is, the microservice decision device obtains the execution time of each data acquisition component and takes the longest execution time as the target execution time; the microservice decision device combines each data acquisition component with one or more other data acquisition components to obtain a data acquisition component subset; the microservice decision device calculates the sum of the execution time of each data acquisition component in the data acquisition component subset, and obtains a preset number of target data acquisition component subsets whose sum of execution time is close to the target execution time (the preset number can be flexibly set based on the number of data acquisition components or the number of free threads); the microservice decision device takes a union of the target data acquisition component subsets and determines whether the union contains all non-duplicate data acquisition components; if the union contains all non-duplicate data acquisition components, each target data acquisition component subset is regarded as a data acquisition component class. If the union contains duplicate data acquisition components, the preset number is reduced; if the union does not contain all data acquisition components, the preset number is increased; if the union contains duplicate data acquisition components but does not contain all data acquisition components, the duplicate first data acquisition component is replaced with the second data acquisition component that is not included, so that the union contains all non-duplicate data acquisition components, and finally forms a data acquisition component class.

[0104] Step S33: execute the parameter acquisition task corresponding to each data acquisition component class to obtain the target input parameter.

[0105] The microservice decision device adds the data acquisition component class to the thread, runs the thread to execute the parameter acquisition task, and obtains the target input parameter. Specifically:

[0106] Step d1: If only one data acquisition component class is formed, then the data acquisition components contained in the data acquisition component class are executed serially to obtain the target input parameter;

[0107] Step d2: If more than two data acquisition component classes are formed, the data acquisition component classes are executed in parallel to obtain target input parameters. In the process of executing each data acquisition component class, the various data acquisition components contained in the data acquisition component class are executed serially.

[0108] That is, if only one data acquisition component class is formed, the microservice decision device executes the various data acquisition components contained in the data acquisition component class in series to obtain the target input parameters; if more than two data acquisition component classes are formed, the microservice decision device executes the data acquisition component classes in parallel to obtain the target input parameters, wherein, in the process of executing each data acquisition component class, the various data acquisition component microservice decision devices contained in the data acquisition component class are executed serially, that is, the microservice decision device adds each data acquisition component class to a thread, and the microservice decision device adds the data acquisition component class to the thread; if the number of threads is one, the microservice decision device obtains the target input parameters by serially executing the various data acquisition components contained in the data acquisition component class; if the number of threads is greater than or equal to two, the data acquisition component classes are executed in parallel to obtain the target input parameters, wherein, in the process of executing each data acquisition component class, the various data acquisition components contained in the data acquisition component class are executed serially. In this embodiment, the data acquisition component classes are executed in parallel to improve computing efficiency, while the data acquisition components contained in each data acquisition component class are executed serially to improve throughput. Therefore, through our mechanism, a balance can be found between computing efficiency and throughput, taking both performance into account at the same time.

[0109] In this embodiment, the microservice decision device groups the target input parameters required by the rule engine, and the target parameters of the same group can be quickly obtained. In this way, each target input parameter does not need to be obtained through a thread, which reduces the thread occupancy rate. At the same time, the microservice decision device combines the data acquisition components according to their respective execution times to form a data acquisition component class. The microservice decision device adds each data acquisition component class to a corresponding thread. In this way, one thread executes a data acquisition component class, which reduces time waste and takes into account both the response time and throughput of the system performance.

[0110] Furthermore, based on the above-mentioned embodiment of the distributed microservice decision-making method of the present invention, a third embodiment of the distributed microservice decision-making method of the present invention is proposed.

[0111] This embodiment is the step after step S30 in the first embodiment. The distributed microservice decision-making method in this embodiment further includes the following steps:

[0112] If the target input parameter is not obtained within the preset time interval, the data acquisition component is closed.

[0113] If the target input parameter is not obtained within the preset time interval (the preset time interval can be set according to the specific scenario, for example, the preset time interval is set to 200ms), the microservice decision device shuts down the data acquisition component; in this embodiment, when the target input parameter is not obtained through the data acquisition component, the data acquisition component is shut down, reducing the waiting time of the rule engine and improving the efficiency of microservice decision-making.

[0114] Furthermore, based on the above-mentioned embodiment of the distributed microservice decision-making method of the present invention, a fourth embodiment of the distributed microservice decision-making method of the present invention is proposed.

[0115] This embodiment is the step after step S40 in the first embodiment. The difference between this embodiment and the above embodiment is that:

[0116] If the processing result is abnormal, the target input parameter in the rule engine is downgraded or set to empty, and the rule engine is executed to obtain the processing result corresponding to the microservice request.

[0117] The microservice decision device determines whether the processing result is abnormal. If so, it downgrades or sets the target input parameter in the rule engine to null, executes the rule engine, and obtains the processing result corresponding to the microservice request. If the microservice decision device determines that the processing result is abnormal, it disables the corresponding parameter access or sets the target input parameter to a downgraded value or null. This configuration reduces the acquisition of invalid parameters and improves the efficiency of preparing the entire rule input parameter data.

[0118] Reference Figure 4 The present invention further provides a distributed microservice decision-making device, the distributed microservice decision-making device comprising:

[0119] The request receiving module 10 is used to receive a microservice request and obtain input parameter information associated with the rule engine when the microservice request needs to call the rule engine;

[0120] The information acquisition module 20 is used to obtain the input parameter information associated with the rule engine when the microservice request needs to call the rule engine;

[0121] An input parameter acquisition module 30 is configured to group target input parameters required by the rule engine according to the input parameter information, and call a predefined data acquisition component to perform a parameter acquisition task according to the grouping to obtain the target input parameters corresponding to the grouping;

[0122] The input acquisition module 40 is used to input the acquired target input parameter into the rule engine to obtain the processing result corresponding to the microservice request.

[0123] In one embodiment, the information acquisition module 20 is configured to:

[0124] An acquisition unit, configured to acquire parameter source information and / or parameter acquisition rules of the input parameter information;

[0125] A combining unit is used to group the target input parameters required by the rule engine according to the parameter source information and / or the parameter acquisition rule.

[0126] In one embodiment, the input parameter acquisition module 30 is further configured to:

[0127] A calling submodule is used to call a predefined data acquisition component for each group;

[0128] Combining to form a submodule, for obtaining the execution time of each of the data acquisition components, and combining the data acquisition components according to their respective execution times to form a data acquisition component class;

[0129] The task execution submodule is used to execute the parameter acquisition task corresponding to each data acquisition component class and obtain the target input parameter.

[0130] In one embodiment, the combination forms a submodule, including:

[0131] A time acquisition unit, configured to acquire the execution time of each of the data acquisition components, and take the longest execution time as the target execution time;

[0132] A component combining unit, configured to combine each data acquisition component with one or more other data acquisition components to obtain a data acquisition component subset;

[0133] a time statistics unit, configured to count the sum of execution times of the data acquisition components in the data acquisition component subset, and obtain a preset number of target data acquisition component subsets whose sum of execution times is close to the target execution time;

[0134] A first judging unit is configured to obtain a union of the target data acquisition component subsets and judge whether the union contains all non-repeated data acquisition components;

[0135] The component class determining unit is configured to treat each of the target data acquisition component subsets as a data acquisition component class if the union contains all non-repeated data acquisition components.

[0136] In one embodiment, the combination forms a submodule, including:

[0137] A time acquisition unit is used to obtain the execution time of each of the data acquisition components, count the execution time of each of the data acquisition components, obtain the total execution time, and obtain the service response time of the microservice request;

[0138] A first combining unit, configured to combine all the data acquisition components into a data acquisition component class if the total execution time is less than or equal to the service response time;

[0139] The second combining unit is configured to combine the data acquisition components according to the business response time to form at least two data acquisition component classes if the total execution time is greater than the business response time.

[0140] In one embodiment, the task execution submodule includes:

[0141] A serial execution unit, configured to serially execute the data acquisition components contained in the data acquisition component class to obtain target input parameters if only one data acquisition component class is formed;

[0142] A parallel execution unit is used to execute the data acquisition component classes in parallel if more than two data acquisition component classes are formed to obtain target input parameters. In the process of executing each data acquisition component class, each data acquisition component contained in the data acquisition component class is executed serially.

[0143] In one embodiment, the distributed microservice decision-making device includes:

[0144] The closing module is used to close the data acquisition component if the target input parameter is not obtained within a preset time interval.

[0145] In one embodiment, the distributed microservice decision-making device includes:

[0146] An execution module is set to downgrade or set the target input parameter in the rule engine to empty if the processing result is abnormal, and execute the rule engine to obtain the processing result corresponding to the microservice request.

[0147] In this embodiment, the target input parameters required by the rule engine are grouped according to the input parameter information, and the target input parameters corresponding to the group are obtained through a pre-defined data acquisition component. In this way, there is no need to obtain each target input parameter through a thread, which reduces the thread occupancy rate and improves the throughput rate of the distributed system. In addition, since one type of input parameter is obtained through the data acquisition component, there is no need to set the corresponding code for each target input parameter, which improves the code reuse rate.

[0148] The present invention also provides a computer-readable storage medium.

[0149] The computer-readable storage medium of the present invention stores a computer program corresponding to the distributed microservice decision-making. When the computer program corresponding to the distributed microservice decision-making is executed by a processor, the steps of the distributed microservice decision-making method described above are implemented.

[0150] Among them, the method implemented when the computer program corresponding to the distributed microservice decision running on the processor is executed can refer to the various embodiments of the distributed microservice decision method of the present invention, and will not be repeated here.

[0151] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or system comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or system. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or system comprising the element.

[0152] The serial numbers of the above embodiments of the present invention are for description only and do not represent the advantages or disadvantages of the embodiments.

[0153] Through the description of the above embodiments, those skilled in the art can clearly understand that the above embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better embodiment. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in each embodiment of the present invention.

[0154] The above are only preferred embodiments of the present invention and are not intended to limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made using the contents of the present invention description and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A distributed microservice decision-making method, characterized in that: The distributed microservice decision-making method includes the following steps: Receive a microservice request, and when the microservice request needs to call a rule engine, obtain input parameter information associated with the rule engine; Grouping target input parameters required by the rule engine according to the input parameter information; Calling a predefined data acquisition component according to the group to execute a parameter acquisition task and obtain the target input parameter corresponding to the group; Input the obtained target input parameter into the rule engine to obtain the processing result corresponding to the microservice request; The step of calling a predefined data acquisition component according to the group to execute a parameter acquisition task and acquiring a target input parameter corresponding to the group includes: Call a predefined data acquisition component for each group; Obtaining the execution time of each of the data acquisition components, and combining the data acquisition components according to their respective execution times to form a data acquisition component class; Execute the parameter acquisition task corresponding to each data acquisition component class to obtain the target input parameter.

2. The distributed microservice decision-making method according to claim 1, wherein: The step of grouping target input parameters required by the rule engine according to the input parameter information includes: Obtaining parameter source information and / or parameter acquisition rules of the input parameter information; The target input parameters required by the rule engine are grouped according to the parameter source information and / or the parameter acquisition rules.

3. The distributed microservice decision-making method according to claim 1, wherein: The step of obtaining the execution time of each of the data acquisition components and combining the data acquisition components according to their respective execution times to form a data acquisition component class includes: Obtaining the execution time of each of the data acquisition components, and taking the longest execution time as the target execution time; Combining each data acquisition component with one or more other data acquisition components to obtain a subset of data acquisition components; Counting the sum of execution time of each data acquisition component in the data acquisition component subset, and obtaining a preset number of target data acquisition component subsets whose sum of execution time is close to the target execution time; Taking a union of the target data acquisition component subsets, and determining whether the union contains all non-repeated data acquisition components; If the union contains all non-repeated data acquisition components, each of the target data acquisition component subsets is regarded as a data acquisition component class.

4. The distributed microservice decision-making method according to claim 1, wherein: The step of obtaining the execution time of each of the data acquisition components and combining the data acquisition components according to their respective execution times to form a data acquisition component class includes: Obtain the execution time of each of the data acquisition components, count the execution time of each of the data acquisition components, obtain the total execution time, and obtain the service response time of the microservice request; If the total execution time is less than or equal to the service response time, all the data acquisition components are combined to form a data acquisition component class; If the total execution time is greater than the service response time, the data acquisition components are combined according to the service response time to form at least two data acquisition component classes.

5. The distributed microservice decision-making method according to claim 1, wherein: The step of executing the parameter acquisition task corresponding to each data acquisition component class to obtain the target input parameter includes: If only one data acquisition component class is formed, each data acquisition component contained in the data acquisition component class is executed serially to obtain the target input parameter; If more than two data acquisition component classes are formed, the data acquisition component classes are executed in parallel to obtain target input parameters. In the process of executing each data acquisition component class, the various data acquisition components contained in the data acquisition component class are executed serially.

6. The distributed microservice decision-making method according to claim 1, wherein: After the step of calling a predefined data acquisition component according to the group to execute a parameter acquisition task and acquiring a target input parameter corresponding to the group, the method includes: If the target input parameter is not obtained within the preset time interval, the data acquisition component is closed.

7. The distributed microservice decision-making method according to any one of claims 1 to 6, wherein: After the step of inputting the acquired target input parameter into the rule engine to obtain the processing result corresponding to the microservice request, the method includes: If the processing result is abnormal, the target input parameter in the rule engine is downgraded or set to empty, and the rule engine is executed to obtain the processing result corresponding to the microservice request.

8. A distributed microservice decision-making device, characterized in that: The distributed microservice decision-making device includes: A request receiving module is used to receive microservice requests and, when the microservice request needs to call a rule engine, obtain input parameter information associated with the rule engine; An information acquisition module is used to obtain input parameter information associated with the rule engine when the microservice request needs to call the rule engine; An input parameter acquisition module is used to group the target input parameters required by the rule engine according to the input parameter information, call the predefined data acquisition component to perform the parameter acquisition task according to the grouping, and obtain the target input parameters corresponding to the group; An input acquisition module is used to input the acquired target input parameters into the rule engine to obtain the processing result corresponding to the microservice request; The input parameter acquisition module is specifically used to call a predefined data acquisition component for each group; Obtaining the execution time of each of the data acquisition components, and combining the data acquisition components according to their respective execution times to form a data acquisition component class; Execute the parameter acquisition task corresponding to each data acquisition component class to obtain the target input parameter.

9. A distributed microservice decision-making device, characterized in that: The distributed microservice decision-making device includes: a memory, a processor, and a computer program corresponding to the distributed microservice decision stored in the memory and executable on the processor. When the computer program corresponding to the distributed microservice decision is executed by the processor, the steps of the distributed microservice decision-making method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program corresponding to the distributed microservice decision-making. When the computer program corresponding to the distributed microservice decision-making is executed by the processor, the steps of the distributed microservice decision-making method according to any one of claims 1 to 7 are implemented.

Images