WO2023087679A1 - Routing method and apparatus based on micro-service, and device and storage medium - Google Patents

Abstract

Provided in the present application are a routing method and apparatus based on a micro-service, and a device and a storage medium. The method comprises: acquiring a processor utilization rate, a memory utilization rate, a queue depth and the number of connections of a node device n under a micro-service system m, wherein m and n are positive integers greater than or equal to 2, the queue depth represents a preset processing performance of the node device n processing a request, and the number of connections represents the number of external connections that is supported by a port of the node device n; determining system performance parameters of the node device n on the basis of the processor utilization rate, the memory utilization rate, the queue depth and the number of connections; predicting, on the basis of the system performance parameters and a counted time that is consumed by a service request, routing performance parameters of selected node devices under a plurality of micro-service systems when the plurality of micro-service systems are passed by during a routing process; and if a plurality of service requests are received, determining, on the basis of the routing performance parameters, routing paths corresponding to the plurality of service requests.

Description

A microservice-based routing method, device, equipment, and storage medium

Cross References to Related Applications

This application claims the priority of the Chinese patent application submitted to the China Patent Office on November 22, 2021, with the application number 202111386475.5 and the application name "A routing method, device, equipment and storage medium based on microservices", all of which The contents are incorporated by reference in this application.

technical field

The present application relates to the technical field of data processing of financial technology (Fintech), involving but not limited to a routing method, device, device and storage medium based on microservices.

Background technique

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 Fintech. However, due to the security and real-time requirements of the financial industry, higher requirements are placed on technology. requirements.

In the field of financial technology, for the message middleware system in the industry, since most of the processing is asynchronous messages, the focus of the system is the transmission time of messages in the link. When 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 randomly sent to a certain machine, the maximum queue depth of the machine is limited. When the maximum depth is reached, the node will no longer receive the sent messages, and the random algorithm will send the messages to all but reached Other machines beyond the maximum queue depth.

The routing method of the microservice system in the related art is only to make random calls, or to find out nodes with relatively few calls on a random basis to increase calls, or to reduce calls to nodes with low processing capabilities. Most are local call adjustments between nodes and between one system and adjacent systems. This routing method is relatively simple and cannot accurately implement dynamic routing.

Contents of the invention

Embodiments of the present application provide a microservice-based routing method, device, device, and storage medium to solve the problem that the routing method of the microservice system in the related art is simple and cannot dynamically adjust the routing path.

The technical scheme of the embodiment of the application is realized in this way:

The embodiment of this application provides a routing method based on microservices, including:

Obtain the processor usage, memory usage, queue depth and number of connections of the node device n under the microservice system m, wherein, the m and the n are positive integers greater than or equal to 2, and the queue depth represents a preset The processing performance of the processing request of the node device n, the number of connections represents the number of external connections supported by the port of the node device n;

Determine system performance parameters of the node device n based on the processor usage, memory usage, queue depth, and number of connections;

Predicting the routing performance parameters of the selected node devices under the multiple micro-service systems when the routing process passes through multiple micro-service systems based on the system performance parameters and the statistical time-consuming service requests;

If multiple service requests are received, based on the routing performance parameters, route paths corresponding to the multiple service requests are determined.

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

The obtaining module is used to obtain the processor usage rate, memory usage rate, queue depth and connection number of the node device n under the microservice system m, wherein the m and the n are positive integers greater than or equal to 2, and the The queue depth represents the preset processing performance of the processing request of the node device n, and the number of connections represents the number of external connections supported by the port of the node device n;

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

The processing module is configured to predict the routing performance parameters of the selected node devices under the multiple micro-service systems when the routing process passes through multiple micro-service systems based on the system performance parameters and the statistical service request time-consuming ;

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

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

The memory is used to store executable instructions; the processor is used to implement the above microservice-based routing method when executing the executable instructions stored in the memory.

An embodiment of the present application provides a storage medium, which stores executable instructions, and is used to cause a processor to implement the above method when executed.

The embodiment of the present application has the following beneficial effects:

By obtaining the processor usage, memory usage, queue depth and connection number of 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 preset node device n processing Request processing performance, the number of connections represents the number of external connections supported by the port of node device n; based on processor usage, memory usage, queue depth and number of connections, determine the system performance parameters of node device n; based on system performance parameters and Statistical service request time-consuming, predict routing performance parameters of selected node devices under multiple micro-service systems when passing through multiple micro-service systems in the routing process; if multiple service requests are received, based on routing performance parameters, determine how many The routing path corresponding to each service request; that is to say, the embodiment of the present application collects the following parameters affecting performance in the actual routing: processor usage rate, memory usage rate, queue depth, number of connections, and service request time-consuming statistics for analysis, to achieve Collect and analyze the relevant information of node devices under each micro-service system in the request path, and then, when subsequent service requests arrive, put the analysis results into routing scheduling, realize dynamic adjustment of routing paths, and optimize the overall service call time.

Description of drawings

FIG. 1 is a schematic diagram of an optional architecture of a server provided in an embodiment of the present application;

FIG. 2 is a first schematic flow diagram of a microservice-based routing method provided by an embodiment of the present application;

FIG. 3 is a second schematic flow diagram of the microservice-based routing method provided by the embodiment of the present application;

FIG. 4 is a third schematic flow diagram of the microservice-based routing method provided by the embodiment of the present application;

Fig. 5 is a schematic diagram of the microservice system through which the microservice process provided by the embodiment of the present application passes;

FIG. 6 is a schematic diagram of a microservice adjustment process under the microservice architecture provided by the embodiment of the present application.

Detailed ways

In order to make the purpose, technical solutions and advantages of the application clearer, the application will be further described in detail below in conjunction with the accompanying drawings. All other embodiments obtained under the premise of creative labor belong to the scope of protection of this application.

In the following description, references to "some embodiments" describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or a different subset 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 commonly understood by those skilled in the technical field of the embodiments of the present application. 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.

The exemplary application of the microservice-based routing device provided by the embodiment of the present application is described below. The microservice-based routing device provided by the embodiment 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) , portable music player, personal digital assistant, dedicated message device, portable game device), intelligent robot and any terminal with screen display function can also be implemented as a server. Next, an exemplary application when the microservice-based routing device is implemented as a server will be described.

Referring to FIG. 1, FIG. 1 is a schematic structural diagram of a server 100 provided by an embodiment of the present application. The server 100 shown in FIG. Various components in the server 100 are coupled together through the bus system 140 . It can be understood that the bus system 140 is used to realize connection and communication between these components. The bus system 140 includes not only a data bus, but also a power bus, a control bus and a status signal bus. However, for clarity of illustration, the various buses are labeled as bus system 140 in FIG.

Processor 110 can be a kind of integrated circuit chip, has signal processing capability, such as general-purpose processor, digital signal processor (DSP, Digital Signal Processor), or other programmable logic device, discrete gate or transistor logic device, discrete hardware Components, etc., wherein the general-purpose processor can be a microprocessor or any conventional processor, etc.

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

Memory 150 may be removable, non-removable or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, and the like. Memory 150 optionally includes one or more storage devices located physically remote from processor 110 . Memory 150 includes volatile memory or nonvolatile memory, and may include both volatile and nonvolatile memory. The non-volatile memory can be read-only memory (Read Only Memory, ROM), and the volatile memory can be random access memory (Random Access Memory, RAM). The memory 150 described in the embodiment 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 which include programs, modules, and data structures, or subsets or supersets thereof, as exemplified below.

Operating system 151, including system programs for processing various basic system services and performing hardware-related tasks, such as framework layer, core library layer, driver layer, etc., for implementing various basic services and processing hardware-based tasks;

Network communication module 152 for reaching other computing devices via one or more (wired or wireless) network interfaces 120, exemplary network interfaces 120 include: Bluetooth, Wireless Compatibility Authentication (Wi-Fi), and Universal Serial Bus (Universal Serial Bus, USB), etc.;

The input processing module 153 is configured to detect one or more user inputs or interactions from one or more of the input devices 132 and translate the detected inputs or interactions.

In some embodiments, the device provided by the embodiment of the present application may be implemented in software. FIG. 1 shows a microservice-based routing device 154 stored in a memory 150. The microservice-based routing device 154 may be The microservice-based routing device in the server 100 can be software in the form of programs and plug-ins, and includes the following software modules: an acquisition module 1541 and a processing module 1542. These modules are logical, so they can be processed according to the functions implemented. Arbitrary combinations or further splits. The function of each module will be explained below.

In other embodiments, the device provided in the embodiment of the present application may be implemented in hardware. As an example, the device provided in the embodiment of the present application may be a processor in the form of a hardware decoding processor, which is programmed to execute the In the microservice-based routing method provided by the embodiment, for example, the processor in the form of a hardware decoding processor can adopt one or more application-specific integrated circuits (Application Specific Integrated Circuit, ASIC), DSP, Programmable Logic Device (Programmable Logic Device, PLD), Complex Programmable Logic Device (Complex Programmable Logic Device, CPLD), Field-Programmable Gate Array (Field-Programmable Gate Array, FPGA) or other electronic components.

The microservice-based routing method provided by the embodiment of the present application will be described below in conjunction with the exemplary application and implementation of the server 100 provided in the embodiment of the present application. Referring to FIG. 2, FIG. 2 is an optional flow chart of the microservice-based routing method provided by the embodiment of the present application, which will be described in conjunction with the steps shown in FIG. 2.

Step S201, acquiring processor usage, memory usage, queue depth and connection number of node device n under the microservice system m.

Among them, 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.

The node device provided by the embodiment of the present application can be implemented as any A terminal with screen display function can also be implemented as a server. In the embodiment of the present application, the node device is implemented as a server as an example for description.

Exemplarily, the queue depth reflects the processing performance when the node device n provides a corresponding function, and when different node devices provide the same function, there are generally differences in processing performance. This application can pre-set the queue depth for any node device. In some exemplary scenarios, assuming that different node devices have storage functions, due to the influence of respective hardware conditions, the storage speed and/or the size of the storage space are different. Furthermore, in a practical application scenario, the queue depth of any node device can be manually set; of course, other methods can also be used to set the queue depth, for example, the node device selects a matching queue depth based on the influence of hardware conditions. Assuming that the queue depth refers to the messages that node device n needs to process, when the queue depth of node device n is relatively large, it means that it takes longer to wait in line for processing; when the queue depth of node device n is relatively small, it means that it needs to wait in line for processing relatively short time.

Exemplarily, for the number of connections, for example, if a client initiates an http request to a node device such as a server, it needs to establish a TCP connection first, and then send a data packet to the http service. The connection request will occupy the port of the node device, and the request is received After the response, determine whether to close the connection according to whether the header is maintained. The number of ports is limited, so the number of connections is also limited. In the process of determining the routing path, this application fully collects relevant information of the node device n such as processor usage, memory usage, queue depth, and number of connections, so as to ensure more accurate and comprehensive routing performance ranking among subsequent different paths.

In the embodiment of the present application, in a realizable microservice architecture, the server serves as the configuration center in the microservice architecture, including but not limited to realizing the display and management of configuration and services. Exemplarily, the microservice architecture includes a server serving as a configuration center, a registration center, and multiple microservice systems. The registration center involves the management of registration services after starting the overall system. In the maintenance scenarios of some microservice systems, random algorithms can be used at the beginning of system operation, and then on the basis of maintaining system operation, node devices provide various relevant information for analysis by the configuration center.

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

In some embodiments, the microservice-based routing method provided by the present application is an intelligent routing method, which analyzes the existing routing paths, and the analysis results are used for the configuration center to dynamically adjust the paths. Here, the configuration center can set a reasonable cycle in the process of collecting relevant parameters that affect performance in actual routing. For example, for a microservice system including multi-node devices, based on the heartbeat mechanism in network communication, the heartbeat method is adopted. After a heartbeat cycle, the relevant parameters of all node devices are synchronized. The intelligent routing algorithm can take the heartbeat cycle as a reference, and according to the total number of messages in a heartbeat cycle, and the minimum number of messages that the algorithm needs to collect, it is most reasonable to use several heartbeat cycles as a message collection cycle, which is less than the minimum number of messages, samples Fewer cycles can be eliminated. Each cycle collects all routing information of existing requests, and waits for the next cycle before putting the analysis results into specific routing scheduling. This cycle is used to achieve the purpose of relatively real-time and dynamic routing adjustment.

Step S202: Determine system performance parameters of node device n based on processor usage, memory usage, queue depth, and number of connections.

In this embodiment of the present application, the processor usage rate includes, but is not limited to, a central processing unit (central processing unit, CPU) usage rate. The system performance parameters of the node device n determined in this application are used as an important reference factor to select which node devices under the multiple micro-service systems to form a route that satisfies the reasonable path length condition when the routing process passes through multiple micro-service systems .

Combining steps S201 and S202, for example, a heartbeat period is used as a message collection period to obtain the processor usage, memory usage, queue depth and connection number of the node device n under the microservice system m, and then based on Processor usage, memory usage, queue depth, and number of connections determine the system performance parameters of node device n; further, taking the system performance parameters determined as a heartbeat cycle as a reference factor, the time-consuming service requests in subsequent collection statistics , execute the prediction of the routing path of the next heartbeat cycle, and finally wait for the arrival of the next heartbeat cycle, and then put the analysis results into specific routing scheduling.

Step S203, based on the system performance parameters and the statistical time-consuming service requests, predict the routing performance parameters of the selected node devices under the multiple micro-service systems when the routing process passes through multiple micro-service systems.

In the embodiment of the present application, the statistical service request time consumption refers to the numerical value accounting for x% proportion in the statistical series within a message collection period, where x is a positive number. Exemplarily, x is 95. Of course, in the embodiment of the present application, x can also take other parameters, such as 98, which is not specifically limited in the present application.

As an example, take the value of 95% in the statistical series as an example, assuming that there are 100 service requests, arranged in ascending order of response time, and the value at position 95, that is, the value of 95% is also called the P95 value . Assuming that the value is 180ms, it means that the response time for 95% of the users is within 180ms, and only 5% of the users are longer than 180ms. Based on this, the application can determine more accurate service response time-consuming information.

In the embodiment of this application, the configuration center can collect the processor usage rate of all node devices of each microservice system, such as CPU usage rate, memory usage rate, queue depth and number of connections, and based on the time-consuming statistics of service requests Add these system performance parameters in the actual routing process to estimate the future request delivery time of selected node devices in different routing paths.

It should be noted that the collection of statistics such as service request time consumption, CPU usage, memory usage, queue depth, and number of connections is also meaningful for fusing and current limiting. When multiple microservice systems If the calculation result of the routing performance parameter of the selected node device exceeds a reasonable threshold, the corresponding node device can be temporarily isolated, and then re-included in the routable path after recovery.

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

In the embodiment of this application, when multiple service requests are received, the configuration center determines the arrival of the next heartbeat cycle, puts the analysis results into specific routing scheduling, and determines the routes corresponding to multiple service requests based on routing performance parameters Path, to achieve the purpose of dynamically adjusting the routing path and optimizing the overall service call time.

The microservice-based routing method provided by this application obtains the processor usage, memory usage, queue depth, and number of connections of 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 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 usage, memory usage, queue depth and the number of connections, determine the node device The system performance parameters of n; based on the system performance parameters and statistical service request time-consuming, predict the routing performance parameters of the selected node devices under the multiple micro-service systems when the routing process passes through multiple micro-service systems; if multiple micro-service systems are received A service request, based on routing performance parameters, determine the routing path corresponding to multiple service requests; that is, this application collects the following parameters that affect performance in the actual routing Processor usage rate, memory usage rate, queue depth, number of connections, and statistics time-consuming analysis of service requests, to realize the collection and analysis of relevant information of node devices under each micro-service system in the request path, and then, when subsequent service requests arrive, the analysis results are put into routing scheduling to realize dynamic adjustment of routing paths , optimize the overall service call time.

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

A11, configure weight parameters for processor usage, memory usage, queue depth and number of connections respectively;

A12. Substitute processor usage, memory usage, queue depth, number of connections, each weight parameter, threshold depth of node device n, and threshold number of connections into the following calculation formula to calculate the system performance parameters of node device n.

Here, the system performance parameter of node device n is characterized by PS:

Among them, the processor usage is characterized by pct _cpu , the weight parameter corresponding to pct _cpu is W _cpu , the memory usage is represented by pct _memory , the weight parameter corresponding to pct _memory is W _memory , and the weight parameter corresponding to the queue depth is W _{queue depth} , The weight parameter corresponding to the number of connections is _{the number of W connections} . Here, the threshold depth is also called the maximum depth limited by node devices, and the threshold number of connections is also called the maximum number of connections limited by node devices.

It should be noted that, due to the different functions of each microservice system, there may be different settings for the maximum number of connections and the maximum depth of node devices, and the requirements for CPU and memory may not be exactly the same, so Each node device can customize the distribution ratio of the weight according to the above formula and according to the functional requirements of the node device, so as to make the result more accurate.

In other embodiments of the present application, in step S203, based on the system performance parameters and statistical service request time-consuming, the routing performance parameters of the selected node devices under the multiple micro-service systems can be predicted when the routing process passes through multiple micro-service systems. Through the steps shown in Figure 4:

B11, the weight parameters are respectively configured for the sum of the system performance parameters of the selected node devices under the multiple microservice systems and the statistical service request time consumption.

Here, the selected node device includes each node device selected under each microservice system in the multiple microservice systems.

B12. Substituting the sum of system performance parameters, statistical service request time consumption and each weight parameter into the following calculation formula to predict routing performance parameters.

Here, the routing performance parameter is represented by R:

R＝W _T ×T+W _ps ×(PS ₁ +PS ₂ +PS ₃ +...PS _i +...+PS _N );

Among them, the statistical service request time consumption is represented by T, the corresponding weight parameter is W _T , the total number of multiple microservice systems is N, and the system performance parameters of selected node devices under any microservice system are represented by PS _i , the system The weight parameter corresponding to the sum of the 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, on the basis of the foregoing explanation about the statistical service request time consumption, T includes but is not limited to T _p95 .

It should be noted that in the calculation formula of the routing performance parameter R, it is also worth paying attention to the respective weights of the P95 average request time consumption and the sum of the system performance parameters. Here, the statistical service request time consumption is a summary of the existing request time consumption, and the sum of system performance parameters is an estimate of future performance. When the sum of system performance parameters in each cycle increases slowly, the system performance can be appropriately reduced The weight factor before the sum of parameters. When the sum of system performance parameters is large or grows rapidly, it means that the sum of system performance parameters is likely to become the bottleneck of the overall performance. At this time, the corresponding weight can be increased in due course.

In the embodiment of this application, taking the statistical service request time T as T _p95 as an example, in the calculation formula of the routing performance parameter R, the weight change curve is similar to an exponential curve. For example, from the weight coefficient before T _p95 , in the initial stage The average request time is short, and it is difficult to see the performance of this path from the perspective of request time. When designing a system, this application often has a preliminary estimate of the request time based on experience and the specific requirements and implementation of the program. The application takes into account two points of interest. One is the acceptable request duration set by this application. Responding within this duration is regarded as having better performance. 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. At this time, the default request timeout. During the period between these two time points, the ability to request time response performance is getting stronger and stronger, so the previous weight W _T will rise rapidly. In some embodiments, for example, the confirmation timeout period is determined by the microservice system according to the service type provided, for example, the timeout period of different service types can be different, and different service types correspond to different confirmation timeout periods , so that the overtime of the confirmation is adaptively different, so that the weight of the microservice system of different service types is also adaptively and dynamically changed; the acceptable request duration is determined through mutual negotiation between the microservice system and the initiator of the service request. Of course, the timeout period for confirmation and the acceptable request duration can also be manually set in combination with the services provided by the microservice system. To sum up, the growth curve of W _T is similar to an exponential function. Before reaching an acceptable request time point, it is basically a straight horizontal line. There may be a little growth, but the speed is very slow, which has little effect on the overall result. Large; at this point in time, there is an inflection point, and the growth of W _T is accelerating, and the growth rate per unit time is getting larger and larger, until the timeout reaches the peak value.

Not only W _T , other weight coefficients also grow similar to an exponential curve. When this application is stress testing, it often has an expected range for processor usage, memory usage, queue depth, number of connections, etc., such as CPU Utilization rate, under normal circumstances, this application believes that as long as the usage rate does not exceed 50% for a long time, the impact of CPU usage rate on performance is very small, and if it exceeds 50%, attention should be paid to it. Also, every increase of one unit will affect performance. Restrictions are also increasing.

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 the system performance parameters. If the sum of the system performance parameters increases quickly, then increase W _ps , the sum of system performance parameters increases slowly, then reduce W _ps , so, combined with the sum of system performance parameters, flexibly adjust the request amount of the request path corresponding to the selected node device, when the sum of system performance parameters is larger Next, reduce the request volume of this request path. When the sum of system performance parameters is smaller, increase the request volume of this request path to ensure the optimal overall performance.

种，基于本申请提供的方法，可以在81条路线中动态找到性能最佳的路由路线。 In a realizable microservice-based intelligent routing scenario, as shown in Figure 5, it is assumed that the overall microservice process is divided into the following four necessary microservice systems, microservice system A, microservice system B, and microservice system C And microservice system D, each microservice system has 3 node devices with different Internet Protocol Address (IP), then there can be a total of routes for completing a complete message routing

Based on the method provided by this application, the routing route with the best performance can be dynamically found among 81 routes.

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

Secondly, the calculation is still based on the fact that there are 3 IP node devices in a system. Referring to Figure 5, system A has a total of 3 node devices a1, a2, and a3. The performance influencing factors of each node device in system A are as follows: CPU usage, memory usage, queue depth, and number of connections, the calculation formula of system performance parameters including these four factors is as follows:

It can be seen from the above formula that the smaller the calculated PS value is, the better the performance of the node device is. Each node device, due to its different functionality, 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, so each system can use the above formula, according to the system According to the functional requirements, the distribution ratio of the custom setting weight makes the result more accurate.

Then, calculate all the PS values of all 12 nodes in turn. The overall routing performance calculation formula is calculated by combining the P95 average request time consumption and the sum of PS of each node device under all systems passing through the route. The formula is as follows:

R＝W _T ×T _p95 +W _ps ×(PS _A +PS _B +PS _C +PS _D );

Among them, PS _A represents the system performance parameters of the selected node devices in system A, PS _B represents the system performance parameters of selected node devices in system B, PS _C represents the system performance parameters of selected node devices in system C, and PS _D represents System performance parameters of the selected node devices under the D system.

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

In other embodiments of the present application, in a scenario where load balancing is implemented, if multiple service requests are received in step S204, based on routing performance parameters, the routing path corresponding to multiple service requests can be determined, which can be achieved through the following steps:

C11, set the request quantity weight parameter for the routing performance parameters of the selected node devices corresponding to different paths under multiple microservice systems;

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 quantity of the multiple service requests.

Based on the aforementioned achievable smart routing scenarios based on microservices, in the case of obtaining the R value corresponding to each path, it can also be sorted from small to large, and then the configuration center can weight the number of requests preset in advance. When service requests come, allocate the number of requests reasonably.

For example, the path R value of A1-B1-C1-D1 is the smallest, the system can set the weight of the number of requests to 0.4, the path R value of A2-B2-C2-D2 ranks second, set the weight of the number of requests to 0.3, and the weight of A3-B3-C3- If the R value of the D3 path ranks third, the weight of the number of requests can be set to 0.2, and the R value of the path A4-B4-C4-D4 ranks fourth, and the weight of the number of requests can be set to 0.1. Furthermore, when a service request is initiated, the request route can be allocated according to the weight.

Exemplarily, when the configuration center receives 1000 service requests, based on the previously set request quantity weight parameter and the request quantity of multiple service requests of 1000, it is determined that A1-B1-C1-D1 has a total of 400 routes, A2-B2- C2-D2 has a total of 300 routes, A3-B3-C3-D3 has a total of 200 routes, and A4-B4-C4-D4 has a total of 100 routes. Wait for the next cycle and redistribute the new top four request routing weights according to the R value calculated in this cycle, and dynamically adjust the request routing path for the next cycle in real time based on the relevant parameters of the previous cycle. Of course, the top five paths may also be selected, which is not specifically limited in this application.

It should be noted that in the actual allocation, except for the unreasonable paths whose R value is too large and exceeds the reasonable value range, they should be isolated. Distributed to achieve the purpose of load balancing. Regarding the representation of node devices under A system in this application, when there are 3 node devices under A system, use a1, a2, and a3 to represent each node device; when there are 4 node devices under A system, use the above-mentioned A1, A2 , A3, and A4 represent each node device, and the different designations are only for convenience of description.

It can be seen from the above embodiments that the microservice-based intelligent routing method provided by the present application can intelligently and dynamically provide request paths according to the actual deployment of the system. According to the number of service requests and the probability that each system may be called, modify the corresponding weight in time, and it can be applied to the collection and calculation of the path in the next cycle, which is very convenient and fast.

In other embodiments of the present application, in a scenario that implements load balancing and requires high timeliness, if multiple service requests are received in step S204, based on routing performance parameters, the routing path corresponding to multiple service requests can be determined through the following Steps to achieve:

D11, if multiple service requests are received, determine the ID of the Internet data center to which the selected node devices corresponding to different paths belong; here, the ID of the Internet data center is used to determine whether the node devices selected in each path belong to the same Internet data center (Internet Data Center, IDC) is like a computer room.

D12, from the routing performance parameters of the selected node devices corresponding to different paths, select the target routing performance parameters of the selected node devices corresponding to at least one target path, wherein at least two of the selected node devices corresponding to the target path have the same Internet data center logo;

That is to say, in this embodiment, in step S203, based on system performance parameters and statistical service request time consumption, the routing performance of selected node devices under multiple microservice systems is predicted when the routing process passes through multiple microservice systems In the case of parameters, 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 one of the selected node devices in the selected routing path Both devices have the same Internet data center identity, so to save routing time.

D13. Determine routing paths corresponding to multiple service requests based on the target routing performance parameters.

It can be seen from the above embodiments that it can be determined whether the node devices are deployed in the same IDC when calling between microservice systems. That is to say, in the process of determining the routing path, the configuration center can preferentially select node devices deployed in the IDC, and then select services according to the intelligent routing method based on microservices of this application.

In other embodiments of the present application, if the CPU and memory configurations are high enough, the configuration center evaluates that this factor may not be considered at the beginning of the system operation; of course, the configuration center may also remove the same The impact factor of an IDC, after waiting for the system to run for a period of time, the memory begins to become an aspect that limits performance, and then add the same IDC factor as a higher priority reference factor, combined with the routing performance parameters of the selected path, together Perform real-time routing path adjustments.

Here, for the microservice architecture of the present application, the microservice adjustment process is described in conjunction with the diagram shown in FIG. 6 . The microservice architecture includes a server as a configuration center, a registration center, and multiple microservice systems. The registration center contains all the services registered by the system provided to the service, and the services provided by each system may not be exactly the same; the configuration center can read all registered services from the registration center. For different microservice systems, the services they provide may need to call downstream microservice systems. For example, the service provided by microservice system A may need to call downstream microservice system B, microservice system C, and microservice system D; the service provided by microservice system B may need to call downstream microservice system C and microservice system D; The service provided by service system C may need to call the downstream microservice system D. In the process of determining the routing path in this application, the configuration center has fully collected the relevant information of all node devices under each microservice system, such as processor usage, memory usage, queue depth, and number of connections, to ensure the subsequent routing between different paths. Routing performance sorting is more accurate and comprehensive. Furthermore, based on the relevant information fed back by the node device and the statistical service request time-consuming, the configuration center statistically calculates the ranking of routing paths, and feeds back the routing paths to the downstream system. It should be noted that, between the various microservice systems and the configuration center in this application, the configuration center collects all routing information of existing requests every cycle, and waits for the next cycle to put the analysis results into specific routing scheduling. This cycle is used to achieve the purpose of relatively real-time and dynamic routing adjustment. For example, as shown in Figure 6, after microservice system A receives the routing path fed back by the configuration center, it executes the routing process, and microservice system A feeds back the actual routing records to the configuration center, so that the configuration center can get the real The routing situation of the microservice system is used as a reference for the next analysis.

In other embodiments of the present application, in a scenario where intelligent routing is performed on attributes of service requests, if multiple service requests are received in step S204, based on routing performance parameters, the routing paths corresponding to multiple service requests can be determined through the following Step E11 to step E12 or, step E11, step E13 to step E15 realize:

E11, if multiple service requests are received, acquire the timeliness information and/or request quantity of the multiple service requests; here, the timeliness information is used to indicate the timeliness requirements of the service requests. For example, synchronous service requests and asynchronous service requests have different timeliness information, and the timeliness information of synchronous service requests has higher requirements on timeliness than the timeliness information of asynchronous service requests.

E12, if the timeliness information of some service requests in the multiple service requests meets the timeliness condition, and/or the number of requests for multiple service requests is greater than the threshold number, based on the routing performance parameters, determine the routing path corresponding to the part of the service requests.

That is to say, for service requests with high timeliness requirements, based on the microservice-based intelligent routing method provided by this application, and based on routing performance parameters, the routing paths corresponding to some service requests with high timeliness requirements are determined. ; and/or in the scenario where the amount of requests reaches the threshold number, based on the routing performance parameters, determine the routing path corresponding to some service requests, that is, a part of all service requests, so as to timely determine a routing solution suitable for the current microservice architecture. Here, in the scenario of intelligent routing based on the attributes of service requests, such as the request volume, for the scenario where the request volume reaches the threshold number, trigger the smart path determination scheme provided by this application, and for the scenario where the request volume does not reach the threshold number, you can still use The random routing scheme, in this way, can reduce the amount of computation and improve the overall processing efficiency of service requests.

E13, for the remaining service requests in the multiple service requests, perform hash calculation on the primary key field of each request in the remaining service requests to obtain a hash value;

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

E14, perform a modulo operation on the number of all node devices under the microservice system m through the hash value, and obtain a modulo result;

E15. Send each request to the corresponding node device based on the modulus result.

In the embodiment of the present application, in the process of adopting the random algorithm, the random algorithm includes a hash (hash) modulo algorithm, that is, the remainder hash() mod n is taken for the hash result, and the node equipment is numbered from 0 to n-1 according to The custom hash() algorithm moduloes the hash() value of each request by n to obtain the remainder i, and then distributes the request to the node device numbered i.

It can be seen from the above embodiments that for service requests requiring timeliness, the role of the intelligent routing algorithm is relatively more obvious. The optimal path and the relatively high-ranked path can significantly reduce the time from the request to the receipt of the processing completion message. For synchronous requests, the intelligent routing method based on microservices provided by this application can also reflect the processing capabilities of services to a certain extent.

The following continues to describe the exemplary structure in which the microservice-based routing device 154 provided by the embodiment of the present application is implemented as a software module. In some embodiments, as shown in FIG. The software module may be a microservice-based routing device in the server 100, including:

The obtaining module 1541 is used to 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, and the queue depth represents a preset The processing performance of the node device n processing the request, the number of connections represents the number of external connections supported by the port of the node device n;

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

The processing module 1542 is used to predict the routing performance parameters of the selected node devices under the multiple micro-service systems when the routing process passes through multiple micro-service systems based on system performance parameters and statistical service request time;

The processing module 1542 is configured to determine routing paths corresponding to multiple service requests based on routing performance parameters if multiple service requests are received.

In some embodiments, the processing module 1542 is configured to configure weight parameters for processor usage, memory usage, queue depth and connection number respectively; processor usage, memory usage, queue depth, connection number, each weight The parameters, the threshold depth of node device n, and the threshold number of connections are substituted into the following calculation formula to calculate the system performance parameters of node device n. The system performance parameters of node device n are represented by PS:

Among them, the processor usage is characterized by pct _cpu , the weight parameter corresponding to pct _cpu is W _cpu , the memory usage is represented by pct _memory , the weight parameter corresponding to pct _memory is W _memory , and the weight parameter corresponding to the queue depth is W _{queue depth} , The weight parameter corresponding to the number of connections is _{the number of W connections} .

In some embodiments, the processing module 1542 is configured to respectively configure the weight parameters for the sum of system performance parameters and statistical service request time consumption of selected node devices under multiple microservice systems; the sum of system performance parameters, statistical Substituting the service request time and each weight parameter into the following calculation formula to predict the routing performance parameters, the routing performance parameters are represented by R:

R＝W _T ×T+W _ps ×(PS ₁ +PS ₂ +PS ₃ +...PS _i +...+PS _N );

Among them, the statistical service request time consumption is represented by T, the corresponding weight parameter is W _T , the total number of multiple microservice systems is N, and the system performance parameters of selected node devices under any microservice system are represented by PS _i , the system The weight parameter corresponding to the sum of the 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.

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

In some embodiments, the processing module 1542 is configured to, if multiple service requests are received, determine the identifier of the Internet data center 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, Screen out the target routing performance parameters of the selected node devices corresponding to at least one target path, wherein at least two of the selected node devices corresponding to the target path have the same Internet data center identifier; based on the target routing performance parameters, determine multiple service The routing path corresponding to the request.

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

In some embodiments, the processing module 1542 is configured to, for the remaining service requests among the plurality of service requests, perform hash calculation on the primary key field of each request in the remaining service requests to obtain a hash value; The number of all node devices under the service system m is subjected to a modulo calculation to obtain a modulo result; based on the modulo result, each request is sent to the corresponding node device.

The microservice routing device provided by the present application obtains the processor usage rate, memory usage rate, queue depth and connection number of the node device n under the microservice system m, wherein 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 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 usage, memory usage, queue depth and the number of connections, the node device n is determined system performance parameters; based on system performance parameters and statistical service request time-consuming, predict the routing performance parameters of selected node devices under multiple micro-service systems when the routing process passes through multiple micro-service systems; if multiple Service requests, based on routing performance parameters, determine the routing paths corresponding to multiple service requests; that is, this application collects the following parameters that affect performance in actual routing Processor usage, memory usage, queue depth, number of connections, and statistics Time-consuming analysis of service requests enables the collection and analysis of relevant information about node devices under each micro-service system in the request path. Then, when subsequent service requests arrive, the analysis results are put into routing scheduling to realize dynamic adjustment of routing paths. Optimize the overall service call time.

It should be noted that the description of the device in the embodiment of the present application is similar to the description of the above-mentioned method embodiment, and has similar beneficial effects to the method embodiment, so details are not repeated here. For the technical details not disclosed in the device embodiment of this application, please refer to the description of the method embodiment of this application for understanding.

The embodiment of the present application provides a storage medium storing executable instructions, and the executable instruction is stored therein. When the executable instruction is executed by the processor, it will cause the processor to execute the method provided in the embodiment of the present application, for example, as shown in FIG. 2 shows the method.

The storage medium provided by this application obtains 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, and the queue depth represents The preset processing performance of node device n processing requests, the number of connections represents the number of external connections supported by the port of node device n; based on processor usage, memory usage, queue depth and number of connections, determine the system performance of node device n Parameters; based on system performance parameters and statistical service request time-consuming, predict routing performance parameters of selected node devices under multiple micro-service systems when passing through multiple micro-service systems in the routing process; if multiple service requests are received, Based on routing performance parameters, determine the routing paths corresponding to multiple service requests; that is, this application collects the following parameters that affect performance in actual routing: processor usage, memory usage, queue depth, number of connections, and statistical service request consumption Real-time analysis to realize the collection and analysis of relevant information of node devices under each micro-service system in the request path, and then, when subsequent service requests arrive, put the analysis results into routing scheduling, realize dynamic adjustment of routing paths, and optimize overall services call time.

In some embodiments, the storage medium can 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), Erasable Programmable Read Only Memory (EPROM, Erasable Programmable Read Only Memory), Electrically Erasable Programmable Read Only Memory (EEPROM, Electrically Erasable Programmable Read Only Memory), flash memory, magnetic surface memory, optical disc, Or memory such as CD-ROM (Compact Disk-Read Only Memory); It can also be various devices including one or any combination of the above-mentioned memories.

In some embodiments, executable instructions may take the form of programs, software, software modules, scripts, or code written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and its Can be deployed in any form, including as a stand-alone program or as a module, component, subroutine or other unit suitable for use in a computing environment.

As an example, executable instructions may, but do not necessarily correspond to files in a file system, may be stored as part of a file that holds other programs or data, for example, in Hyper Text Markup Language (HTML, Hyper Text Markup Language) in one or more scripts in a document, in a single file dedicated to the program in question, or in multiple cooperating files (for example, a file that stores one or more modules, subroutines, or code sections )middle. As an example, executable instructions may be deployed to be executed 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. to execute.

The above descriptions are merely examples of the present application, and are not intended to limit the protection scope of the present application. Any modifications, equivalent replacements and improvements made within the spirit and scope of the present application are included in the protection scope of the present application.

Industrial Applicability

The microservice-based routing method, device, device, and storage medium provided in the embodiments of the present application obtain the processor usage rate, memory usage rate, queue depth, and connection number of node device n under the microservice system m, wherein, 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 processing requests, and the number of connections represents the number of external connections supported by the port of the node device n; based on processor usage and memory usage , queue depth and number of connections to determine the system performance parameters of the node device n; based on the system performance parameters and statistical service request time-consuming, when the routing process passes through multiple micro-service systems, the selected nodes under multiple micro-service systems The routing performance parameters of the device; if multiple service requests are received, based on the routing performance parameters, determine the routing path corresponding to the multiple service requests; that is to say, the embodiment of the present application collects the following parameters that affect performance in actual routing Processor usage rate , memory usage, queue depth, number of connections, and statistical service request time-consuming analysis, to realize the collection and analysis of relevant information of node devices under each micro-service system in the request path, and then, when subsequent service requests arrive, Put the analysis results into routing scheduling, realize dynamic adjustment of routing paths, and optimize the overall service call time.

Claims (10)

A microservice-based routing approach that includes: Obtain the processor usage, memory usage, queue depth and number of connections of the node device n under the microservice system m, wherein, the m and the n are positive integers greater than or equal to 2, and the queue depth represents a preset The processing performance of the processing request of the node device n, the number of connections represents the number of external connections supported by the port of the node device n; Determine system performance parameters of the node device n based on the processor usage, memory usage, queue depth, and number of connections; Predicting the routing performance parameters of the selected node devices under the multiple micro-service systems when the routing process passes through multiple micro-service systems based on the system performance parameters and the statistical time-consuming service requests; If multiple service requests are received, based on the routing performance parameters, route paths corresponding to the multiple service requests are determined. The method according to claim 1, wherein said determining the system performance parameters of said node device n based on said processor usage rate, memory usage rate, queue depth and number of connections comprises: Configuring weight parameters for the processor usage, the memory usage, the queue depth and the number of connections respectively; Substituting the processor usage rate, the memory usage rate, the queue depth, the number of connections, each weight parameter, the threshold depth of the node device n, and the threshold connection number into the following calculation formula to calculate the node device The system performance parameter of n, the system performance parameter of the node device n is characterized by PS:

Wherein, the processor usage rate is characterized by pct _cpu , the weight parameter corresponding to the pct _cpu is W _cpu , the memory usage rate is represented by pct _memory , the weight parameter corresponding to the pct _memory is W _memory , and the queue The weight parameter corresponding to the depth is W _{queue depth} , and the weight parameter corresponding to the connection number is W _{connection number} . The method according to claim 1 or 2, wherein, when the service request time-consuming based on the system performance parameters and statistics is predicted, when passing through multiple micro-service systems during the routing process, the service requests under the multiple micro-service systems Routing performance parameters of selected node devices, including: Configuring weight parameters for the sum of the system performance parameters of the selected node devices under the plurality of microservice systems and the time-consuming statistics of service requests; Substituting the sum of the system performance parameters, the statistical service request time consumption and each weight parameter into the following calculation formula to predict the routing performance parameters, the routing performance parameters are represented as R: R＝W _T ×T+W _ps ×(PS ₁ +PS ₂ +PS ₃ +...PS _i +...+PS _N ); Wherein, the statistical service request time consumption is represented by T, the corresponding weight parameter is W _T , the total number of the multiple microservice systems is N, and the system performance parameters of the selected node devices under any microservice system 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. The method according to any one of claims 1-3, wherein, if multiple service requests are received, determining routing paths corresponding to the multiple service requests based on the routing performance parameters includes: For the routing performance parameters of the selected node devices corresponding to different paths under the plurality of microservice systems, set the request quantity weight parameter; If the multiple service requests are received, determine routing paths corresponding to the multiple service requests based on the request quantity weight parameter and the request quantity of the multiple service requests. The method according to any one of claims 1-3, wherein, if multiple service requests are received, determining the routing paths corresponding to the multiple service requests based on the routing performance parameters includes: If multiple service requests are received, determine the identification of the Internet data center to which the selected node equipment corresponding to different paths belongs; From the routing performance parameters of the selected node devices corresponding to different paths, select the target routing performance parameters of the selected node devices corresponding to at least one target path, wherein at least two of the selected node devices corresponding to the target path devices have the same Internet data center identifier; Based on the target routing performance parameters, routing paths corresponding to the multiple service requests are determined. The method according to any one of claims 1-3, wherein, if multiple service requests are received, determining routing paths corresponding to the multiple service requests based on the routing performance parameters includes: If the multiple service requests are received, acquiring timeliness information and/or request quantity of the multiple service requests; If the timeliness information of some of the service requests in the multiple service requests meets the timeliness condition, and/or the number of requests for the multiple service requests is greater than the threshold number, based on the routing performance parameters, determine the timeliness corresponding to the part of the service requests routing path. The method according to claim 6, wherein, if the multiple service requests are received, after obtaining the timeliness information of the multiple service requests, the method further comprises: For the remaining service requests in the plurality of service requests, perform hash calculation on the primary key field of each request in the remaining service requests to obtain a hash value; Carrying out a modulo operation on the quantity of all node devices under the microservice system m through the hash value to obtain a modulo result; Based on the modulus result, each request is sent to a corresponding node device. A routing device based on microservices, comprising: The obtaining module is used to obtain the processor usage rate, memory usage rate, queue depth and connection number of the node device n under the microservice system m, wherein the m and the n are positive integers greater than or equal to 2, and the The queue depth represents the preset processing performance of the processing request of the node device n, and the number of connections represents the number of external connections supported by the port of the node device n; A processing module, configured to determine system performance parameters of the node device n based on the processor usage, memory usage, queue depth, and number of connections; The processing module is configured to predict the routing performance parameters of the selected node devices under the multiple micro-service systems when the routing process passes through multiple micro-service systems based on the system performance parameters and the statistical service request time-consuming ; The processing module is configured to, if multiple service requests are received, determine routing paths corresponding to the multiple service requests based on the routing performance parameters. A routing device based on microservices, including: The memory is used to store executable instructions; the processor is used to implement the method according to any one of claims 1 to 7 when executing the executable instructions stored in the memory. A storage medium storing executable instructions for causing a processor to implement the method according to any one of claims 1 to 7.

Images