A Routing Method, Device, Equipment and Storage Medium Based on Microservices

Abstract

The present application provides a routing method, device, equipment and storage medium based on microservices. The method includes: obtaining the processor utilization rate, memory utilization rate, queue depth and connection number of the node device n under the microservice system m, where m and n are positive integers greater than or equal to 2, the queue depth represents the processing performance of the preset node device n for processing requests, and the connection number represents the number of external connections supported by the port of the node device n; determining the system performance parameter of the node device n based on the processor utilization rate, memory utilization rate, queue depth and connection number; predicting the routing performance parameters of the selected node devices under multiple microservice systems during the routing process based on the system performance parameter and the statistically recorded service request duration; and determining the routing paths corresponding to multiple service requests based on the routing performance parameters if multiple service requests are received.

Description

Technical Field

[0001] The embodiments of the present application relate to the technical field of data processing in financial technology (Fintech), and relate to, but are not limited to, a routing method, device, equipment, and storage medium based on microservices. Background Art

[0002] With the development of computer computing, more and more technologies are applied in the financial field, and the traditional financial industry is gradually transforming into financial technology (Fintech). However, due to the security and real-time requirements of the financial industry, higher requirements are also put forward for technologies.

[0003] In the field of financial technology, for the message middleware system in the industry, since most of the processed messages are asynchronous, the key point that the system cares about is the transmission time of the messages in the link. When the messages between systems are sent to the next multi-node system, a random algorithm of hash modulo is often used to achieve load balancing. At the same time, in order to prevent too many messages from being randomly sent to a certain machine, the maximum queue depth of the machine is restricted. When the maximum depth is reached, the node will no longer receive the sent messages, and the random algorithm will send the messages to other machines except those that have reached the maximum queue depth.

[0004] The routing methods of the microservice systems in the related technologies only achieve random calls, or find the nodes with relatively fewer calls and increase the calls on the basis of randomness, or reduce the calls on the nodes with lower processing capabilities. Most of them are local call adjustments between nodes and between a system and its adjacent systems. This routing method is relatively simple and cannot accurately achieve dynamic routing. Summary of the Invention

[0005] The embodiments of the present application provide a routing method, device, equipment, and storage medium based on microservices to solve the problem that the routing methods of the microservice systems in the related technologies are simple and cannot achieve dynamic adjustment of the routing path.

[0006] The technical solution of the embodiments of the present application is implemented as follows:

[0007] The embodiments of the present application provide a routing method based on microservices, including:

[0008] Obtain the processor usage rate, memory usage rate, queue depth, and connection number of the node device n under the microservice system m, where m and n are positive integers greater than or equal to 2, the queue depth represents the processing performance of the preset node device n for processing requests, and the connection number represents the number of external connections supported by the port of the node device n;

[0009] Based on the processor usage rate, memory usage rate, queue depth, and connection number, determine the system performance parameter of the node device n;

[0010] Based on the system performance parameters and the elapsed time of the statistically served requests, predict the routing performance parameters of the selected node devices under the multiple microservice systems when passing through the multiple microservice systems during the routing process;

[0011] If multiple service requests are received, determine the routing paths corresponding to the multiple service requests based on the routing performance parameters.

[0012] An embodiment of the present application provides a routing device based on microservices, including:

[0013] An acquisition module, configured to acquire the processor usage rate, memory usage rate, queue depth, and number of connections of the node device n under the microservice system m, where m and n are positive integers greater than or equal to 2, the queue depth represents the processing performance of the preset node device n for processing requests, and the number of connections represents the number of external connections supported by the port of the node device n;

[0014] A processing module, configured to determine the system performance parameters of the node device n based on the processor usage rate, memory usage rate, queue depth, and number of connections;

[0015] The processing module is configured to predict the routing performance parameters of the selected node devices under the multiple microservice systems when passing through the multiple microservice systems during the routing process based on the system performance parameters and the elapsed time of the statistically served requests;

[0016] The processing module is configured to, if multiple service requests are received, determine the routing paths corresponding to the multiple service requests based on the routing performance parameters.

[0017] An embodiment of the present application provides a routing device based on microservices, including:

[0018] A memory, configured to store executable instructions; a processor, configured to implement the above method when executing the executable instructions stored in the memory.

[0019] An embodiment of the present application provides a storage medium, storing executable instructions, for causing a processor to implement the above method when executed.

[0020] The embodiments of the present application have the following beneficial effects:

[0021] By obtaining the processor utilization rate, memory utilization rate, queue depth, and number of connections of the node device n under the microservice system m, where m and n are positive integers greater than or equal to 2, the queue depth represents the processing performance of the preset node device n for processing requests, and the number of connections represents the number of external connections supported by the port of the node device n; based on the processor utilization rate, memory utilization rate, queue depth, and number of connections, determine the system performance parameters of the node device n; based on the system performance parameters and the statistically recorded service request latency, predict the routing performance parameters of the selected node devices under multiple microservice systems when passing through multiple microservice systems during the routing process; if multiple service requests are received, based on the routing performance parameters, determine the routing paths corresponding to the multiple service requests; that is to say, this application collects and analyzes the following parameters affecting performance in the actual routing: processor utilization rate, memory utilization rate, queue depth, number of connections, and the statistically recorded service request latency, to achieve the collection and analysis of the relevant information of the node devices under each microservice system in the request path. Furthermore, when subsequent service requests arrive, the analysis results are input into the routing scheduling to dynamically adjust the routing paths and optimize the overall service call time. Description of the Drawings

[0022] Figure 1 is an optional architecture diagram of the server provided by an embodiment of the present application;

[0023] Figure 2 is a flowchart of the microservice-based routing method provided by an embodiment of the present application Figure 1 ;

[0024] Figure 3 is a flowchart of the microservice-based routing method provided by an embodiment of the present application Figure 2 ;

[0025] Figure 4 is a flowchart of the microservice-based routing method provided by an embodiment of the present application Figure 3 ;

[0026] Figure 5 is a schematic diagram of the microservice system passed by the microservice process provided by an embodiment of the present application;

[0027] Figure 6 is a schematic diagram of the microservice adjustment process under the microservice architecture provided by an embodiment of the present application. Detailed Embodiments

[0028] In order to make the purpose, technical solutions, and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations of the present application. All other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present application.

[0029] In the following description, reference is made to "some embodiments", which describe a subset of all possible embodiments. It can be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments, and can be combined with each other without conflict. Unless otherwise defined, all technical and scientific terms used in the embodiments of the present application have the same meaning as those commonly understood by those skilled in the technical field to which the embodiments of the present application belong. The terms used in the embodiments of the present application are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.

[0030] The following describes an exemplary application of the microservice-based routing device provided by the embodiments of the present application. The microservice-based routing device provided by the embodiments of the present application can be implemented as a notebook computer, a tablet computer, a desktop computer, a mobile device (for example, a mobile phone, a portable music player, a personal digital assistant, a dedicated messaging device, a portable game device), an intelligent robot, or any other terminal with a screen display function, or can also be implemented as a server. Hereinafter, an exemplary application will be described when the microservice-based routing device is implemented as a server.

[0031] See Figure 1 , Figure 1 is a schematic structural diagram of server 100 provided by the embodiments of the present application. Figure 1 The server 100 shown includes: at least one processor 110, at least one network interface 120, a user interface 130, and a memory 150. Each component in the server 100 is coupled together through a bus system 140. It can be understood that the bus system 140 is used to implement the connection and communication between these components. In addition to the data bus, the bus system 140 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clear illustration, in Figure 1 all kinds of buses are labeled as the bus system 140.

[0032] The processor 110 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP, Digital Signal Processor), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0033] The user interface 130 includes one or more output devices 131 that enable the presentation of media content, including one or more speakers and / or one or more visual display screens. The user interface 130 also includes one or more input devices 132, including user interface components that facilitate user input, such as a keyboard, a mouse, a microphone, a touch screen display, a camera, other input buttons, and controls.

[0034] The memory 150 can be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disc drives, etc. Optionally, the memory 150 includes one or more storage devices that are physically remote from the processor 110. The memory 150 includes volatile memory, non-volatile memory, or both volatile and non-volatile memory. The non-volatile memory can be Read Only Memory (ROM), and the volatile memory can be Random Access Memory (RAM). The memory 150 described in the embodiments of the present application is intended to include any suitable type of memory. In some embodiments, the memory 150 is capable of storing data to support various operations. Examples of such data include programs, modules, and data structures, or subsets or supersets thereof, which will be described exemplarily below.

[0035] The operating system 151 includes system programs for processing various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic services and processing hardware-based tasks;

[0036] The network communication module 152 is used to reach other computing devices via one or more (wired or wireless) network interfaces 120. Exemplarily, the network interfaces 120 include: Bluetooth, Wi-Fi (Wireless Fidelity), and Universal Serial Bus (USB), etc.;

[0037] The input processing module 153 is used to detect and translate one or more user inputs or interactions from one of one or more input devices 132.

[0038] In some embodiments, the device provided by the embodiments of the present application can be implemented in software. Figure 1 Shown is a microservice-based routing device 154 stored in the memory 150. The microservice-based routing device 154 can be the microservice-based routing device in the server 100, and it can be software in the form of programs and plugins, etc., including the following software modules: an acquisition module 1541, a processing module 1542. These modules are logical, so they can be combined arbitrarily or further split according to the functions to be implemented. The functions of each module will be described below.

[0039] In some other embodiments, the device provided by the embodiments of the present application may be implemented in a hardware manner. As an example, the device provided by the embodiments of the present application may be a processor in the form of a hardware decoding processor, which is programmed to execute the microservice-based routing method provided by the embodiments of the present application. For example, the processor in the form of a hardware decoding processor may employ one or more application specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0040] Next, the microservice-based routing method provided by the embodiments of the present application will be described in conjunction with the exemplary applications and implementations of the server 100 provided by the embodiments of the present application. Refer to Figure 2 , Figure 2 which is an optional flowchart of the microservice-based routing method provided by the embodiments of the present application, and will be described in conjunction with the steps shown in Figure 2 .

[0041] Step S201: Obtain the processor utilization rate, memory utilization rate, queue depth, and number of connections of the node device n under the microservice system m.

[0042] Where m and n are positive integers greater than or equal to 2, the queue depth represents the processing performance of the preset node device n for processing requests, and the number of connections represents the number of external connections supported by the ports of the node device n.

[0043] The node device provided by the embodiments of the present application may be implemented as a laptop computer, a tablet computer, a desktop computer, a mobile device (such as a mobile phone, a portable music player, a personal digital assistant, a dedicated messaging device, a portable gaming device), a smart robot, or any other terminal with a screen display function, or may also be implemented as a server. In the embodiments of the present application, the node device is implemented as a server as an example for description.

[0044] Exemplarily, the queue depth reflects the processing performance of the node device n when providing corresponding functions. When different node devices provide the same function, there are generally differences in processing performance. In the present application, the queue depth can be set in advance for any node device. In some exemplary scenarios, assuming that different node devices all have storage functions, due to the influence of their respective hardware conditions and the like, the storage speed and / or the storage space size are different. Further, in the actual application scenario, the queue depth of any node device can be set manually; of course, other methods can also be used to set the queue depth. For example, the node device combines the influence of hardware conditions and the like to select a matching queue depth. Assuming that the queue depth refers to the messages that the node device n needs to process, when the queue depth of the node device n is relatively large, it means that the time for queuing and waiting for processing is longer; when the queue depth of the node device n is relatively small, it means that the time for queuing and waiting for processing is relatively short.

[0045] Exemplarily, regarding the number of connections, for example, when a client sends an http request to a node device such as a server, it needs to first establish a TCP connection, and then send a data packet to the http service. The connection request will occupy the port of the node device. After receiving the request reply, it is determined whether to close the connection according to whether the header is kept. The number of ports is limited, so the number of connections is also limited. In the process of determining the routing path in the present application, relevant information of the node device n such as the processor utilization rate, memory utilization rate, queue depth, and number of connections is fully collected to ensure that the routing performance ranking between different subsequent paths is more accurate and comprehensive.

[0046] In the embodiment of the present application, in an implementable microservice architecture, the server serves as the configuration center in the microservice architecture, including but not limited to realizing the display and management of configurations and services. Exemplarily, the microservice architecture includes a server serving as the configuration center, a registration center, and multiple microservice systems. The registration center is involved in the management of registered services after starting the overall system. In some maintenance scenarios of microservice systems, a random algorithm can be adopted at the beginning of system operation, and then on the basis of maintaining system operation, the node device provides various relevant information for the configuration center to analyze.

[0047] The service requests involved in the present application include but are not limited to service requests in the process of real-time online transaction processing (On-Line Transaction Processing, OLTP), also known as transaction-oriented processing. The characteristic of the above service requests is that the user data received by the front end can be immediately transmitted to the computing center for processing, and the processing result can be given in a very short time.

[0048] Furthermore, the routing method based on microservices provided by this application is an intelligent routing method. This method analyzes the existing routing paths, and the analysis results are used by the configuration center to dynamically adjust the paths. Here, when the configuration center collects the relevant parameters that affect performance in the actual routing, a reasonable period can be set. For example, for a microservices system including multi-node devices, based on the heartbeat mechanism in network communication, in the form of a heartbeat, after one heartbeat period, the relevant parameters of all node devices are synchronized. The intelligent routing algorithm can use the heartbeat period as a reference, and according to the total number of messages within one heartbeat period and the minimum number of messages required by the algorithm to collect, determine the most reasonable number of heartbeat periods as a message collection period. Periods with fewer than the minimum number of messages and fewer samples can be excluded. All routing information of the existing requests is collected in each period, and the analysis results are waited to be input into the specific routing scheduling in the next period. This cycle is repeated to achieve the purpose of relatively real-time and dynamic routing adjustment.

[0049] Step S202: Determine the system performance parameters of node device n based on the processor utilization rate, memory utilization rate, queue depth, and number of connections.

[0050] In the embodiments of this application, the processor utilization rate includes, but is not limited to, the utilization rate of the central processing unit (CPU). The system performance parameters of node device n determined in this application are used as important reference factors for selecting which node devices under multiple microservices systems to form a route that meets the reasonable route length condition during the prediction of the routing process through multiple microservices systems.

[0051] Combining step S201 and step S202, for example, taking one heartbeat period as a message collection period, obtain the processor utilization rate, memory utilization rate, queue depth, and number of connections of node device n under microservices system m, and then determine the system performance parameters of node device n based on the processor utilization rate, memory utilization rate, queue depth, and number of connections; further, using the system performance parameters determined in one heartbeat period as a reference factor, during the subsequent collection and statistics of the service request latency, perform the prediction of the routing path in the next heartbeat period, and finally wait until the next heartbeat period arrives, and then input the analysis results into the specific routing scheduling.

[0052] Step S203: Predict the routing performance parameters of the selected node devices under multiple microservices systems during the routing process through multiple microservices systems based on the system performance parameters and the statistically collected service request latency.

[0053] In the embodiments of the present application, the service request time consumed for statistics refers to the value that accounts for x% in the statistical sequence within a message collection period, where x is a positive number. Exemplarily, x is 95. Of course, in the embodiments of the present application, x can also take other parameters, such as 98, and the present application does not make specific limitations thereto.

[0054] Exemplarily, taking the value that accounts for 95% in the statistical sequence as an example, assuming there are 100 service requests, arranged in ascending order of response time, the value at the 95th position, which is the value accounting for 95% and is also called the P95 value. Assuming this value is 180ms, it means that the response time for 95% of the users is within 180ms, and only 5% of the users have a response time greater than 180ms. Based on this, the present application can determine more accurate service response time consumption information.

[0055] In the embodiments of the present application, the configuration center can collect the processor utilization rates of all node devices in each microservice system, such as CPU utilization rate, memory utilization rate, queue depth, and connection count, and add these system performance parameters in the actual routing process to the statistically consumed service request time to estimate the future request transfer time of the selected node devices in different routing paths.

[0056] It should be noted that the collection of messages such as the statistically consumed service request time, CPU utilization rate, memory utilization rate, queue depth, and connection count also has certain significance for circuit breaking and flow limiting. When the calculation results of the routing performance parameters of the selected node devices under multiple microservice systems exceed a reasonable threshold, the corresponding node devices can be temporarily isolated and then re-included in the routable paths after recovery.

[0057] Step S204, if multiple service requests are received, determine the routing paths corresponding to the multiple service requests based on the routing performance parameters.

[0058] In the embodiments of the present application, when multiple service requests are received, the configuration center determines that the next heartbeat period arrives, puts the analyzed results into specific routing scheduling, and determines the routing paths corresponding to the multiple service requests based on the routing performance parameters, so as to achieve the purpose of dynamically adjusting the routing paths and optimizing the overall service call time.

[0059] The routing method based on microservices provided by this application obtains the processor utilization rate, memory utilization rate, queue depth, and number of connections of the node device n under the microservice system m, where m and n are positive integers greater than or equal to 2, the queue depth represents the processing performance of the preset node device n for processing requests, and the number of connections represents the number of external connections supported by the port of the node device n; based on the processor utilization rate, memory utilization rate, queue depth, and number of connections, determine the system performance parameters of the node device n; based on the system performance parameters and the statistically recorded service request time consumption, predict the routing performance parameters of the selected node devices under multiple microservice systems when passing through multiple microservice systems during the routing process; if multiple service requests are received, based on the routing performance parameters, determine the routing paths corresponding to the multiple service requests; that is to say, this application collects the following parameters that affect performance in actual routing: processor utilization rate, memory utilization rate, queue depth, number of connections, and the statistically recorded service request time consumption for analysis, realizes the collection and analysis of the relevant information of the node devices under each microservice system in the request path, and then, when subsequent service requests arrive, inputs the analysis results into the routing scheduling to realize dynamic adjustment of the routing path and optimize the overall service call time.

[0060] In other embodiments of this application, step S202 determines the system performance parameters of the node device n based on the processor utilization rate, memory utilization rate, queue depth, and number of connections, which can be implemented through the steps as Figure 3 shown:

[0061] A11, configure weight parameters for the processor utilization rate, memory utilization rate, queue depth, and number of connections respectively;

[0062] A12, substitute the processor utilization rate, memory utilization rate, queue depth, number of connections, each weight parameter, the threshold depth of the node device n, and the threshold number of connections into the following calculation formula to calculate the system performance parameters of the node device n, and the system performance parameters of the node device n are characterized as PS:

[0063]

[0064] Among them, the processor utilization rate is characterized as pct cpu 、pct cpu The corresponding weight parameter is W cpu , the memory utilization rate is characterized as pct 内存 、pct 内存 The corresponding weight parameter is W 内存 , the weight parameter corresponding to the queue depth is W 队列深度 , the weight parameter corresponding to the number of connections is W 连接数 . Here, the threshold depth is also called the node device limited maximum depth, and the threshold number of connections is also called the node device limited maximum number of connections.

[0065] It should be noted that for each microservice system, due to different functionality, there may be different settings for the maximum number of connections and the maximum depth of the node device, and the requirements for CPU and memory may not be exactly the same. Therefore, each node device can customize the allocation ratio of weights according to the functional requirements of the node device using the above formula to make the results more accurate.

[0066] In other embodiments of the present application, step S203 is based on system performance parameters and the statistically recorded service request time consumption to predict the routing performance parameters of the selected node devices under multiple microservice systems when passing through multiple microservice systems during the routing process, which can be achieved through steps as Figure 4 shown below:

[0067] B11 are respectively the sum of the system performance parameters of the selected node devices under multiple microservice systems and the weight parameters configured for the statistically recorded service request time consumption; here, the selected node devices include each node device selected under each microservice system among multiple microservice systems.

[0068] B12, substitute the sum of the system performance parameters, the statistically recorded service request time consumption, and each weight parameter into the following calculation formula to predict the routing performance parameters, where the routing performance parameters are characterized as R:

[0069] R = W T ×T + W ps ×(PS1 + PS2 + PS3 +......PS i +......+ PS N );

[0070] Among them, the statistically recorded service request time consumption is characterized as T, the corresponding weight parameter is W T , the total number of multiple microservice systems is N, the system performance parameter of the selected node device under any microservice system is characterized as PS i , the weight parameter corresponding to the sum of the system performance parameters is W ps , and the value range of i is a positive integer greater than 0 and less than or equal to N. Here, based on the foregoing explanation of the statistically recorded service request time consumption, T includes but is not limited to T p95 .

[0071] It should be noted that in the calculation formula of the routing performance parameter R, it is also worth noting the respective weights of the P95 average request time and the sum of the system performance parameters. Here, the statistical service request time is a summary of the current request time, and the sum of the system performance parameters is an estimate of future performance. When the sum of the system performance parameters in each cycle grows slowly, the weight coefficient before the sum of the system performance parameters can be appropriately reduced. When the sum of the system performance parameters is large or grows rapidly, it means that the sum of the system performance parameters is likely to become a bottleneck for the overall performance. At this time, the corresponding weight can be increased in a timely manner.

[0072] In the embodiment of the present application, the statistical service request time T is T p95 For example, in the calculation formula of the routing performance parameter R, the weight change curve is similar to an exponential curve, such as from T p95 Judging from the previous weight coefficients, the average request time is short in the initial stage, and it is difficult to see the performance of the path from the perspective of request time. When designing a system, this application often makes a preliminary estimate of the request time based on experience and the specific requirements and implementation of the program. This application takes into account two time points of concern. One is the acceptable request duration set by this application. If the response is within this duration, the performance is considered good. If it exceeds this time, you need to pay a little attention to whether it can be optimized; the other time point is the confirmation timeout. If it exceeds this time, the request times out by default. During the period between these two time points, the request time has an increasingly strong ability to reflect performance, so the previous weight W T Will rise rapidly. In some embodiments, for example, the confirmation timeout is determined by the microservice system according to the type of service provided. For example, the timeouts of different service types may be different. Different service types correspond to different confirmation timeouts, so that the confirmation timeouts are adaptively different, thereby achieving dynamic adaptive changes in the weights of microservice systems of different service types; the acceptable request duration is determined by the microservice system and the initiator of the service request through negotiation. Of course, the confirmation timeout and the acceptable request duration can also be manually set in combination with the services provided by the microservice system. In summary, W T The growth curve of is similar to an exponential function. Before reaching the acceptable request time point, it is basically a straight horizontal line. There may be a small increase, but the speed is very slow and has little impact on the overall result. When this time point comes, an inflection point appears. T The growth is accelerating, and the growth rate per unit time is getting larger and larger until the time is exceeded and the peak value is reached.

[0073] Not just W T, other weight coefficients also increase in a similar exponential curve. During stress testing of this application, there is usually an expected range for factors such as processor usage, memory usage, queue depth, and the number of connections. For example, in terms of CPU usage, under normal circumstances, this application believes that as long as the usage does not exceed 50% for a long time, the impact of CPU usage on performance is very small. Once it exceeds 50%, attention should be paid. Similarly, for each additional unit increase, the limitation on performance becomes greater and greater.

[0074] That is to say, in the calculation formula of the routing performance parameter R of this application, W ps is a variable, and W ps changes with the change of the sum of system performance parameters. If the sum of system performance parameters increases rapidly, then W is increased ps , if the sum of system performance parameters increases slowly, then W is decreased ps . In this way, the request volume of the request path corresponding to the selected node device is flexibly adjusted in combination with the sum of system performance parameters. When the sum of system performance parameters is larger, the request volume of this request path is reduced. When the sum of system performance parameters is smaller, the request volume of this request path is increased to ensure the overall optimal performance.

[0075] In an implementable intelligent routing scenario based on microservices, referring to Figure 5 as shown, assume that the overall microservice process is divided into the following 4 necessary microservice systems: microservice system A, microservice system B, microservice system C, and microservice system D. Each microservice system has 3 node devices with different Internet Protocol Address (IP). Then, there are a total of routes to complete a full message routing. Based on the method provided by this application, the routing route with the best performance can be dynamically found among 81 routes.

[0076] First, it is to confirm the respective weights of the performance impact factors in a single microservice system, namely processor usage, memory usage, queue depth, and the number of connections, which can be set according to the actual needs of the microservice system.

[0077] Secondly, still calculated according to 3 IP node devices in a system. Referring to Figure 5 as shown, system A has a total of 3 node devices, a1, a2, and a3. The performance impact factors of each node device in system A are as follows: CPU usage, memory usage, queue depth, and the number of connections. The calculation formula of the system performance parameters including these 4 factors is as follows:

[0078]

[0079] From the above formula, we can see that the smaller the calculated PS value, the better the performance of the node device. Due to different functionality, each node device may have different settings for the maximum number of connections and maximum queue depth, and the requirements for CPU and memory may not be exactly the same. Therefore, each system can use the above formula to customize the weight distribution ratio according to the functional requirements of the system to make the result more accurate.

[0080] Then, all PS values of all 12 nodes are calculated in turn. The overall routing performance calculation formula is calculated by combining the P95 average request time and the sum of the PS of each node device in all systems passed through during the route. The formula is as follows:

[0081] R=W T ×T p95 +W ps ×(PS A +PS B +PS C +PS D );

[0082] Among them, PS A Characterize the system performance parameters of the selected node equipment in system A, PS B Characterize the system performance parameters of the selected node equipment in the B system, PS C Characterize the system performance parameters of the selected node equipment in the C system, PS D Characterize the system performance parameters of the selected node equipment in the D system.

[0083] Finally, after all the parameters of the above formula are determined, the configuration center can calculate the R values of the above 81 paths.

[0084] In other embodiments of the present application, in a scenario of implementing load balancing, if multiple service requests are received in step S204, determining the routing paths corresponding to the multiple service requests based on the routing performance parameters can be implemented by the following steps:

[0085] C11, for the routing performance parameters of the selected node devices corresponding to different paths in multiple microservice systems, sets the request quantity weight parameter;

[0086] C12, if multiple service requests are received, determine routing paths corresponding to the multiple service requests based on the request quantity weight parameter and the request quantities of the multiple service requests.

[0087] Based on the aforementioned achievable microservice-based intelligent routing scenario, after obtaining the R value corresponding to each path, it can also be sorted from small to large, so that the configuration center can reasonably allocate the number of requests when service requests arrive according to the pre-set request number weights.

[0088] For example, the path R value of A1 - B1 - C1 - D1 is the smallest, and the system can set the request quantity weight to 0.4. The path R value of A2 - B2 - C2 - D2 ranks second, and the request quantity weight is set to 0.3. The path R value of A3 - B3 - C3 - D3 ranks third, and the request quantity weight can be set to 0.2. The path R value of A4 - B4 - C4 - D4 ranks fourth, and the request quantity weight is set to 0.1. Further, when a service request is initiated, the request routing can be allocated accordingly according to the weight.

[0089] Exemplarily, when the configuration center receives 1000 service requests, based on the aforementioned set request quantity weight parameters and the request quantity 1000 of multiple service requests, it is determined that a total of 400 requests are routed through A1 - B1 - C1 - D1, a total of 300 requests are routed through A2 - B2 - C2 - D2, a total of 200 requests are routed through A3 - B3 - C3 - D3, and a total of 100 requests are routed through A4 - B4 - C4 - D4. In the next cycle, the request routing weights of the top four ranked paths are re - allocated according to the R value calculated in this cycle, and the request routing path of the next cycle is dynamically adjusted in real - time based on the relevant parameters of the previous cycle. Of course, the top five paths can also be selected, and the present application does not make specific limitations on this.

[0090] It should be noted that in actual allocation, except for unreasonable paths where the R value is particularly large and has exceeded the reasonable value range and should be isolated, in the case of a relatively large request call volume, while having a certain focus, it should be relatively dispersed as much as possible to achieve the purpose of load balancing. In the present application, regarding the representation of node devices under system A, when there are 3 node devices under system A, a1, a2, and a3 are used to represent each node device. When there are 4 node devices under system A, the above - mentioned A1, A2, A3, and A4 are used to represent each node device. Different reference identifiers are only for convenience of description.

[0091] As can be seen from the above embodiments, the intelligent routing method based on microservices provided by the present application can intelligently and dynamically provide request paths according to the actual deployment situation of the system. According to the request quantity of the service and the probability that each system may be called, the corresponding weights can be modified in a timely manner, and in the next cycle, it can be applied to the collection and calculation of paths, which is very convenient and fast.

[0092] In other embodiments of the present application, in a scenario where load balancing and high timeliness requirements are achieved, if multiple service requests are received in step S204, based on the routing performance parameters, determining the routing paths corresponding to the multiple service requests can be achieved through the following steps:

[0093] D11. If multiple service requests are received, determine the Internet Data Center (IDC) identifiers to which the selected node devices corresponding to different paths belong. Here, the IDC identifier is used to determine whether the selected node devices in each path belong to the same IDC, such as the same computer room.

[0094] D12. From the routing performance parameters of the selected node devices corresponding to different paths, filter out the target routing performance parameters of the selected node devices corresponding to at least one target path, where at least two of the selected node devices corresponding to the target path have the same IDC identifier.

[0095] That is to say, in this embodiment, when predicting the routing performance parameters of the selected node devices under multiple microservice systems during the routing process based on the system performance parameters and the statistically measured service request time consumption in step S203, based on the condition of whether the node devices are deployed in the same IDC, filter out the target routing performance parameters of the selected node devices corresponding to at least one target path, that is, at least two of the selected node devices in the selected routing path have the same IDC identifier. In this way, the routing time can be saved.

[0096] D13. Based on the target routing performance parameters, determine the routing paths corresponding to multiple service requests.

[0097] As can be seen from the above embodiment, it is possible to determine whether the node devices are deployed in the same IDC when making calls between microservice systems. That is to say, during the process of determining the routing path, the configuration center can preferentially select the node devices deployed within the same IDC and then select services according to the intelligent routing method based on microservices of the present application.

[0098] In other embodiments of the present application, if the configurations such as CPU and memory are high enough, and after evaluation by the configuration center, it is considered that this factor can be temporarily ignored at the beginning of system operation. Of course, at the beginning of system operation, the configuration center can also first remove the influencing factor of the same IDC. After the system has been running for a period of time and memory begins to become a factor restricting performance, then add the factor of the same IDC as a reference factor with a higher priority, and jointly adjust the real-time routing path in combination with the routing performance parameters of the filtered paths.

[0099] Here, for the microservice architecture of the present application, in combination with Figure 6As shown in the figure, the microservice adjustment process is described. The microservice architecture includes a server serving as a configuration center, a registration center, and multiple microservice systems. The registration center contains all the services registered by the systems providing the services, and the services provided by each system may not be completely the same; the configuration center can read all the registered services from the registration center. For different microservice systems, the services they provide may need to call downstream microservice systems. For example, the services provided by microservice system A may need to call downstream microservice systems B, C, and D; the services provided by microservice system B may need to call downstream microservice systems C and D; the services provided by microservice system C may need to call downstream microservice system D. In the process of determining the routing path in this application, the configuration center fully collects relevant information of all node devices under each microservice system, such as processor utilization rate, memory utilization rate, queue depth, and connection count, to ensure that the routing performance sorting between subsequent different paths is more accurate and comprehensive. Further, based on the relevant information fed back by the node devices and the statistical service request latency, the configuration center calculates and statistics the routing path sorting, and feeds back the routing path to the downstream system. It should be noted that between each microservice system and the configuration center in this application, the configuration center collects all the routing information of the existing requests in each cycle, and waits for the next cycle to input the analysis results into the specific routing scheduling. By cycling in this way, the purpose of relatively real-time and dynamic routing adjustment is achieved. For example, referring to Figure 6 As shown in the figure, after microservice system A receives the routing path fed back by the configuration center, it executes the routing process, and microservice system A also feeds back the actual routing records to the configuration center. In this way, the configuration center can obtain the routing situation of the real microservice system as a reference for the next analysis.

[0100] In other embodiments of this application, in a scenario of implementing intelligent routing for the attributes of service requests, if multiple service requests are received in step S204, based on the routing performance parameters, the routing paths corresponding to the multiple service requests can be determined through the following steps E11 to step E12, or steps E11, E13 to step E15:

[0101] E11, if multiple service requests are received, obtain the timeliness information and / or the number of requests of the multiple service requests; here, the timeliness information is used to indicate the requirement of the service request for timeliness. For example, synchronous service requests and asynchronous service requests have different timeliness information, and the timeliness information of synchronous service requests has a higher requirement for timeliness than that of asynchronous service requests.

[0102] E12, if there are some service requests among the multiple service requests whose timeliness information meets the timeliness conditions, and / or the number of requests of the multiple service requests is greater than the threshold number, based on the routing performance parameters, determine the routing paths corresponding to the partial service requests.

[0103] That is to say, for service requests with high timeliness requirements, the present application determines the routing paths corresponding to some service requests, i.e., requests with high timeliness requirements, based on the microservice-based intelligent routing method provided by the present application and based on routing performance parameters; and / or in scenarios where the request volume reaches a threshold number, determines the routing paths corresponding to some service requests, i.e., a part of all service requests, based on routing performance parameters, so as to timely determine the routing scheme suitable for the current microservice architecture. Here, in the scenario where intelligent routing is performed based on the attributes of service requests such as the request volume, for scenarios where the request volume reaches a threshold number, the intelligent path determination scheme provided by the present application is triggered, and for scenarios where the request volume does not reach the threshold number, the random routing scheme can still be used, thereby reducing the amount of calculation and improving the overall processing efficiency of service requests.

[0104] E13, for the remaining service requests among the multiple service requests, performing hash calculation on the primary key field of each request in the remaining service requests to obtain a hash value;

[0105] Here, when some service requests are requests with higher timeliness requirements, the remaining service requests include requests with lower timeliness requirements. When some service requests are part of all service requests, the remaining service requests include the remaining requests of all service requests. It should be noted that this application uses a random algorithm to determine the routing path for the remaining service requests, thereby reducing the amount of calculation and improving the overall processing efficiency of all service requests.

[0106] E14, performing a modulo operation on the number of all node devices under the microservice system m through the hash value to obtain a modulo result;

[0107] E15, based on the modulo result, sends each request to the corresponding node device.

[0108] In the embodiment of the present application, in the process of using a random algorithm, the random algorithm includes a hash modulus algorithm, that is, taking the remainder hash() mod n of the hash result, by numbering the node devices from 0 to n-1, according to a custom hash() algorithm, taking the hash() value of each request modulo n, obtaining the remainder i, and then distributing the request to the node device numbered i.

[0109] It can be seen from the above embodiments that for service requests with timeliness requirements, the role of the intelligent routing algorithm is relatively more obvious. The optimal path and the path with a relatively high ranking can significantly reduce the time from the request to the receipt of the processing completion message. For synchronous requests, the microservice-based intelligent routing method provided by this application can also reflect the processing capacity of the service to a certain extent.

[0110] Next, the exemplary structure in which the microservice-based routing device 154 provided in the embodiments of the present application is implemented as a software module will be further described. In some embodiments, as Figure 1 shown, the software module in the microservice-based routing device 154 stored in the memory 150 can be the microservice-based routing device in the server 100, including:

[0111] An acquisition module 1541, configured to acquire the processor utilization rate, memory utilization rate, queue depth, and number of connections of a node device n in a microservice system m, where m and n are positive integers greater than or equal to 2, the queue depth represents the processing performance of the preset node device n for processing requests, and the number of connections represents the number of external connections supported by the port of the node device n;

[0112] A processing module 1542, configured to determine system performance parameters of the node device n based on the processor utilization rate, memory utilization rate, queue depth, and number of connections;

[0113] A processing module 1542, configured to predict routing performance parameters of selected node devices under multiple microservice systems during the routing process based on the system performance parameters and the statistically measured service request latency;

[0114] A processing module 1542, configured to determine a routing path corresponding to multiple service requests based on the routing performance parameters if multiple service requests are received.

[0115] In some embodiments, the processing module 1542 is configured to configure weight parameters for the processor utilization rate, memory utilization rate, queue depth, and number of connections respectively; substitute the processor utilization rate, memory utilization rate, queue depth, number of connections, each weight parameter, the threshold depth of the node device n, and the threshold number of connections into the following calculation formula to calculate the system performance parameters of the node device n, and the system performance parameters of the node device n are characterized as PS:

[0116]

[0117] where the processor utilization rate is characterized as pct cpu 、pct cpu the corresponding weight parameter is W cpu ,the memory utilization rate is characterized as pct 内存 、pct 内存 the corresponding weight parameter is W 内存 ,the weight parameter corresponding to the queue depth is W 队列深度 ,the weight parameter corresponding to the number of connections is W 连接数 .

[0118] In some embodiments, the processing module 1542 is configured to configure weight parameters for the sum of the system performance parameters of the selected node devices under multiple microservice systems and the statistical service request duration respectively; substitute the sum of the system performance parameters, the statistical service request duration, and each weight parameter into the following calculation formula to predict the routing performance parameter, where the routing performance parameter is characterized as R:

[0119] R = W T ×T + W ps ×(PS1 + PS2 + PS3 +......PS i +......+PS N );

[0120] wherein, the statistical service request duration is characterized as T, the corresponding weight parameter is W T , the total number of multiple microservice systems is N, the system performance parameter of the selected node device under any microservice system is characterized as PS i , the weight parameter corresponding to the sum of the system performance parameters is W ps , and the value range of i is a positive integer greater than 0 and less than or equal to N.

[0121] In some embodiments, the processing module 1542 is configured to set request quantity weight parameters for the routing performance parameters of the selected node devices corresponding to different paths under multiple microservice systems; if multiple service requests are received, determine the routing paths corresponding to the multiple service requests based on the request quantity weight parameters and the request quantities of the multiple service requests.

[0122] In some embodiments, the processing module 1542 is configured to, if multiple service requests are received, determine the Internet data center identifiers to which the selected node devices corresponding to different paths belong; screen out the target routing performance parameters of the selected node devices corresponding to at least one target path from the routing performance parameters of the selected node devices corresponding to different paths, wherein at least two devices among the selected node devices corresponding to the target path have the same Internet data center identifier; determine the routing paths corresponding to the multiple service requests based on the target routing performance parameters.

[0123] In some embodiments, the obtaining module 1541 is configured to, if multiple service requests are received, obtain the timeliness information and / or the request quantity of the multiple service requests; the processing module 1542 is configured to, if the timeliness information of some service requests among the multiple service requests meets the timeliness condition, and / or the request quantity of the multiple service requests is greater than the threshold quantity, determine the routing paths corresponding to the partial service requests based on the routing performance parameters.

[0124] In some embodiments, the processing module 1542 is configured to perform a hashing calculation on the primary key field of each of the remaining service requests among a plurality of service requests to obtain a hash value; perform a modulo operation on the number of all node devices in the microservice system m using the hash value to obtain a modulo result; and based on the modulo result, send each request to the corresponding node device.

[0125] The routing device for microservices provided in this application obtains the processor utilization rate, memory utilization rate, queue depth, and connection count of the node device n in the microservice system m, where m and n are positive integers greater than or equal to 2, the queue depth represents the processing performance of the preset node device n for processing requests, and the connection count represents the number of external connections supported by the port of the node device n; determines the system performance parameter of the node device n based on the processor utilization rate, memory utilization rate, queue depth, and connection count; predicts the routing performance parameter of the selected node device under multiple microservice systems when passing through multiple microservice systems during the routing process based on the system performance parameter and the statistically recorded service request latency; if multiple service requests are received, determines the routing paths corresponding to the multiple service requests based on the routing performance parameter; that is to say, this application collects and analyzes the following parameters that affect performance in actual routing: processor utilization rate, memory utilization rate, queue depth, connection count, and the statistically recorded service request latency, realizes the collection and analysis of the relevant information of the node devices under each microservice system in the request path, and then, when subsequent service requests arrive, inputs the analysis result into the routing scheduling to dynamically adjust the routing path and optimize the overall service call time.

[0126] It should be noted that the description of the device in the embodiments of this application is similar to the description of the above method embodiments and has similar beneficial effects as the method embodiments, so it will not be elaborated here. For the technical details not disclosed in the embodiments of this device, please refer to the description of the method embodiments of this application for understanding.

[0127] The embodiments of this application provide a storage medium storing executable instructions, where the executable instructions, when executed by a processor, cause the processor to execute the method provided in the embodiments of this application. For example, as Figure 2 shown in the method.

[0128] The storage medium provided by this application obtains the processor utilization rate, memory utilization rate, queue depth, and number of connections of the node device n in the microservices system m, where m and n are positive integers greater than or equal to 2, the queue depth represents the processing performance of the preset node device n for processing requests, and the number of connections represents the number of external connections supported by the port of the node device n; determines the system performance parameters of the node device n based on the processor utilization rate, memory utilization rate, queue depth, and number of connections; predicts the routing performance parameters of the selected node devices under multiple microservices systems when passing through multiple microservices systems during the routing process based on the system performance parameters and the statistically measured service request latency; if multiple service requests are received, determines the routing paths corresponding to the multiple service requests based on the routing performance parameters; that is to say, this application collects and analyzes the following parameters that affect performance in actual routing: processor utilization rate, memory utilization rate, queue depth, number of connections, and the statistically measured service request latency, realizes the collection and analysis of the relevant information of the node devices under each microservices system in the request path, and then, when subsequent service requests arrive, inputs the analysis results into the routing scheduling to dynamically adjust the routing paths and optimize the overall service call time.

[0129] In some embodiments, the storage medium may be a computer-readable storage medium, for example, a ferroelectric memory (FRAM, Ferromagnetic Random Access Memory), a read-only memory (ROM, Read Only Memory), a programmable read-only memory (PROM, Programmable Read Only Memory), an erasable programmable read-only memory (EPROM, Erasable Programmable Read Only Memory), an electrically erasable programmable read-only memory (EEPROM, Electrically Erasable Programmable Read Only Memory), a flash memory, a magnetic surface memory, an optical disc, or a compact disk-read only memory (CD-ROM, Compact Disk-Read Only Memory), etc.; it may also be various devices including one or any combination of the above memories.

[0130] In some embodiments, the executable instructions may be in the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including being deployed as an independent program or being deployed as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0131] By way of example, the executable instructions may or may not correspond to a file in a file system, and may be stored as part of a file that holds other programs or data. For example, they may be stored in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple cooperating files (such as files that store one or more modules, subroutines, or code portions). By way of example, the executable instructions may be deployed to execute on one computing device, or on multiple computing devices located at one site, or alternatively, on multiple computing devices distributed across multiple sites and interconnected by a communication network.

[0132] As described above, the foregoing are only embodiments of the present application and are not intended to limit the protection scope of the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and scope of the present application are all included within the protection scope of the present application.

Claims

1. A routing method based on microservices, characterized in that, Including: Obtain the processor utilization rate, memory utilization rate, queue depth, and number of connections of the node device n under the microservice system m, where m and n are positive integers greater than or equal to 2, the queue depth represents the processing performance of the preset node device n for processing requests, and the number of connections represents the number of external connections supported by the port of the node device n; Based on the processor utilization rate, memory utilization rate, queue depth, and number of connections, determine the system performance parameters of the node device n; Based on the system performance parameters and the statistically recorded service request latency, predict the routing performance parameters of the selected node devices under the multiple microservice systems during the routing process; If multiple service requests are received, based on the routing performance parameters, determine the routing paths corresponding to the multiple service requests; The predicting the routing performance parameters of the selected node devices under the multiple microservice systems during the routing process based on the system performance parameters and the statistically recorded service request latency includes: Configure weight parameters for the sum of the system performance parameters of the selected node devices under the multiple microservice systems and the statistically recorded service request latency respectively; Substitute the sum of the system performance parameters, the statistically recorded service request latency, and each weight parameter into the following calculation formula to predict the routing performance parameter, where the routing performance parameter is represented as R: R = W T × T + W ps × (PS1 + PS2 + PS3 + …… PS i + …… + PS N ); Among them, the time consumption of the statistically service request is characterized as T, and the corresponding weight parameter is W T , the total number of the multiple microservice systems is N, and the system performance parameter of the selected node device under any microservice system is characterized as PS i , the weight parameter corresponding to the sum of the system performance parameters is W ps , where the value range of i is a positive integer greater than 0 and less than or equal to N.

2. The method according to claim 1, wherein The determining the system performance parameters of the node device n based on the processor utilization rate, memory utilization rate, queue depth, and number of connections includes: Configure weight parameters for the processor utilization rate, the memory utilization rate, the queue depth, and the number of connections respectively; Substitute the processor utilization rate, the memory utilization rate, the queue depth, the number of connections, each weight parameter, the threshold depth of the node device n, and the threshold number of connections into the following calculation formula to calculate the system performance parameters of the node device n, where the system performance parameters of the node device n are represented as PS: Among them, the processor utilization rate is characterized as pct cpu and the weight parameter corresponding to the pct cpu is W cpu , the memory utilization rate is characterized as pct 内存 and the weight parameter corresponding to the pct 内存 is W 内存 , the weight parameter corresponding to the queue depth is W 队列深度 , the weight parameter corresponding to the number of connections is W 连接数 .

3. According to the method described in any one of claims 1-2, characterized in that, The if multiple service requests are received, based on the routing performance parameters, determining the routing paths corresponding to the multiple service requests includes: Set request quantity weight parameters for the routing performance parameters of the selected node devices corresponding to different paths under the multiple microservice systems; If the multiple service requests are received, based on the request quantity weight parameters and the request quantities of the multiple service requests, determine the routing paths corresponding to the multiple service requests.

4. The method according to any one of claims 1-2, characterized in that, The if multiple service requests are received, based on the routing performance parameters, determining the routing paths corresponding to the multiple service requests includes: If multiple service requests are received, determine the Internet data center identifiers to which the selected node devices corresponding to different paths belong; From the routing performance parameters of the selected node devices corresponding to different paths, filter out the target routing performance parameters of the selected node devices corresponding to at least one target path, where at least two devices among the selected node devices corresponding to the target path have the same Internet data center identifier; Based on the target routing performance parameters, determine the routing paths corresponding to the multiple service requests.

5. The method according to any one of claims 1-2, characterized in that, If multiple service requests are received, determining a routing path corresponding to the multiple service requests based on the routing performance parameter includes: If the multiple service requests are received, obtaining timeliness information and / or the number of requests of the multiple service requests; If timeliness information of some service requests among the multiple service requests meets the timeliness condition, and / or the number of requests of the multiple service requests is greater than a threshold number, determining a routing path corresponding to the part of the service requests based on the routing performance parameter.

6. The method according to claim 5, wherein After obtaining the timeliness information of the multiple service requests when the multiple service requests are received, the method further includes: For the remaining service requests among the multiple service requests, calculating a hash value for a primary key field of each request in the remaining service requests; Performing a modulo operation on the number of all node devices under the microservice system m by the hash value to obtain a modulo result; Based on the modulo result, sending each request to a corresponding node device.

7. A routing device based on microservices, characterized in that, including: An obtaining module, configured to obtain the processor usage rate, memory usage rate, queue depth, and connection number of a node device n under the microservice system m, where m and n are positive integers greater than or equal to 2, the queue depth represents the processing performance of the preset node device n for processing requests, and the connection number represents the number of external connections supported by the port of the node device n; A processing module, configured to determine a system performance parameter of the node device n based on the processor usage rate, memory usage rate, queue depth, and connection number; The processing module is configured to predict a routing performance parameter of a selected node device under the multiple microservice systems when passing through the multiple microservice systems during the routing process based on the system performance parameter and the statistically recorded service request latency; The processing module is configured to determine a routing path corresponding to the multiple service requests based on the routing performance parameter if multiple service requests are received; Predicting a routing performance parameter of a selected node device under the multiple microservice systems when passing through the multiple microservice systems during the routing process based on the system performance parameter and the statistically recorded service request latency includes: Respectively configuring weight parameters for the sum of the system performance parameters of the selected node devices under the multiple microservice systems and the statistically recorded service request latency; substituting the sum of the system performance parameters, the statistically recorded service request latency, and each weight parameter into the following calculation formula to predict the routing performance parameter, where the routing performance parameter is characterized as R: R = W T × T + W ps × (PS1 + PS2 + PS3 + …… PS i + …… + PS N ); Among them, the statistical service request time consumption is characterized as T, and the corresponding weight parameter is W T , the total number of the multiple microservice systems is N, and the system performance parameter of the selected node device under any microservice system is characterized as PS i , the weight parameter corresponding to the sum of the system performance parameters is W ps , the value range of i is a positive integer greater than 0 and less than or equal to N.

8. A routing device based on microservices, characterized in that, including: A memory, configured to store executable instructions; A processor, configured to implement the method according to any one of claims 1 to 6 when executing the executable instructions stored in the memory.

9. A storage medium, characterized in that, Stored with executable instructions, configured to cause a processor to implement the method according to any one of claims 1 to 6 when executed.

Images