Micro-service calling method and device and related equipment

Abstract

The invention relates to the technical field of micro-service systems, in particular to a micro-service calling method and device and related equipment. The method comprises the following steps: in response to a received data processing request, determining to-be-processed data and data information about the to-be-processed data according to the data processing request; according to the data information, evaluating each standby service node in the plurality of standby service nodes to obtain an evaluation result; determining a target service node in the plurality of standby service nodes according to the evaluation result; sending the to-be-processed data to the target service node, so that the target service node performs data processing on the to-be-processed data based on the provided micro service; the micro-service calling method and device can solve the technical problem that calling delay is prone to occurring in the micro-service calling process of an existing Spring Cloud micro-service system.

Description

Technical Field

[0001] This application relates to the field of microservice system technology, and in particular to a microservice invocation method, apparatus and related equipment. Background Technology

[0002] Compared to traditional monolithic services, microservices offer advantages such as greater scalability, easier maintenance, and more flexible deployment.

[0003] In practical applications, microservice systems that support multiple microservices are usually built on microservice development frameworks, among which Spring Cloud is a widely used one. Spring Cloud provides a complete set of functional components required by microservices to perform various functions, covering the entire lifecycle of microservice governance. Spring Cloud microservice systems typically provide microservice calls using a synchronous blocking call approach. This means that while the client in a Spring Cloud microservice system is waiting for the server to respond to its microservice call request, the client cannot process other requests, which can easily lead to delays in the microservice call process.

[0004] In summary, the microservice call process of the Spring Cloud microservice system is prone to technical issues such as call latency. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a microservice invocation method, apparatus and related equipment to solve the technical problem that the microservice invocation process of the existing Spring Cloud microservice system is prone to invocation delay.

[0006] Firstly, this application provides a microservice invocation method, applied to a client in a microservice system, wherein the system further includes multiple service nodes for providing microservices; the method includes: In response to receiving a data processing request, the system determines the data to be processed and data information about the data to be processed based on the data processing request. Based on the data information, each of the multiple standby service nodes is evaluated to obtain the evaluation result; Based on the evaluation results, a target service node is determined from among the multiple available service nodes; The data to be processed is sent to the target service node, so that the target service node can process the data based on the microservices it provides.

[0007] Secondly, this application provides a microservice invocation device for implementing the above-described method; the device includes: a control module and a load balancing module; The control module is configured to, in response to receiving a data processing request, determine the data to be processed and data information about the data to be processed based on the data processing request; The load balancing module is used to evaluate each of the multiple standby service nodes according to the data information to obtain an evaluation result. The load balancing module is used to determine the target service node from among the multiple standby service nodes based on the evaluation results. The control module is used to send the data to be processed to the target service node, so that the target service node can process the data to be processed based on the microservices it provides.

[0008] Thirdly, this application provides an electronic device including a processor and a memory, the memory being used to store an application program, and the processor enabling the electronic device to implement the microservice invocation method described above by running or executing a software program stored in the memory.

[0009] Fourthly, this application provides a computer-readable storage medium for storing program code executed by a processor, the program code being used to implement the microservice invocation method described above.

[0010] Fifthly, this application provides a computer program product containing computer instructions that, when executed on an electronic device, cause the electronic device to implement the aforementioned microservice invocation method.

[0011] Beneficial effects: The microservice invocation method provided in this application can determine the data to be processed and data information about the data to be processed based on the data processing request; then, based on the data information, evaluate each of the multiple service nodes to obtain an evaluation result; based on the evaluation result, determine the target service node among the multiple service nodes; and send the data to be processed to the target service node so that the target service node can process the data to be processed based on the microservice it provides.

[0012] In summary, before calling a microservice, this application comprehensively evaluates multiple service nodes based on the data information of the data to be processed, dynamically selects the target service node, and avoids blindly allocating requests to potentially high-latency service nodes by strongly associating data with data information. At the same time, it reduces the retry overhead caused by node failure. Therefore, this application can avoid the call latency problem in the Spring Cloud microservice system. Attached Figure Description

[0013] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. The following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 A flowchart illustrating the microservice invocation method provided in this application embodiment; Figure 2 An interactive diagram illustrating the process of determining a target service node as provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating the interaction during the process of determining a data frame, as provided in an embodiment of this application. Detailed Implementation

[0015] In existing technologies, with the rapid development of Internet technology, traditional monolithic service application architecture has gradually exposed problems such as poor scalability, complex maintenance, and inflexible deployment. To solve these problems, microservice architecture has emerged. Its core idea is to break down large monolithic services into multiple independent and autonomous microservices. Microservices interact with each other through lightweight communication protocols such as HTTP (Hypertext Transfer Protocol).

[0016] In practice, implementing a microservice architecture faces numerous challenges, such as microservice registration and discovery, load balancing, configuration management, and fault tolerance. These needs have spurred the demand for a one-stop microservice solution. Against this backdrop, Spring Cloud, a microservice development framework based on Spring Boot, emerged. By integrating multiple mature technology components such as Netflix OSS (Open Source Software), Zookeeper, and Nacos, Spring Cloud provides a standardized microservice infrastructure, helping developers quickly build distributed systems. Practical experience shows that the emergence of Spring Cloud not only simplifies the development complexity of microservice architectures but also lowers the technical threshold for small and medium-sized enterprises to implement microservices.

[0017] Based on practical experience, it is known that the communication of microservice systems built on Spring Cloud relies on HTTP (Hypertext Transfer Protocol) / REST (Representational State Transfer) protocols and a complex component ecosystem, which has certain limitations in high-performance and lightweight scenarios. At the same time, the complexity of the dependent components leads to a steep learning curve.

[0018] In addition, service calls in microservice systems built on Spring Cloud depend on multiple components such as the Eureka / Nacos registry, Ribbon load balancer, Feign client, and Hystrix circuit breaker. This requires the introduction of a large number of dependency packages such as spring-cloud-starter-openfeign and spring-cloud-starter-netflix-ribbon, which increases the size and deployment complexity of the microservice system.

[0019] In addition, microservice systems built on Spring Cloud require manual configuration of service registration and discovery addresses, load balancing strategies, timeout parameters, etc., and the default configurations of microservice systems built on Spring Cloud, such as the maximum number of retries and connection timeout, may not be suitable for all scenarios and developers need to adjust them themselves.

[0020] In practical applications, service calls in microservice systems built on Spring Cloud are primarily implemented through Feign, which relies on the HTTP / REST protocol for remote communication. Feign generates client interfaces through dynamic proxies, converts interface method calls into HTTP requests, and uses Ribbon for client load balancing. However, Feign uses synchronous blocking HTTP calls such as Apache HTTP Client or OkHttp, which can lead to thread blocking in high-concurrency scenarios, impacting system throughput and causing call delays. Furthermore, HTTP / REST protocols using text formats like JSON / XML consume significant CPU and memory resources during serialization and deserialization, and their header information is redundant, resulting in lower transmission efficiency compared to binary protocols. Feign supports HTTP Keep-Alive long connections, but its reuse strategy is relatively simple, unable to dynamically adjust the connection pool size or optimize connection lifecycle management, potentially leading to connection contention or resource waste in high-concurrency scenarios.

[0021] To address the technical problems, such as call latency, caused by microservice systems built on Spring Cloud, this application provides a microservice call technology solution. This solution is implemented based on a microservice system. To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without creative effort are within the scope of protection of this application.

[0022] First, this application provides a microservice invocation method, applied to a client in a microservice system, wherein the system further includes multiple service nodes for providing microservices; such as Figure 1 As shown, Figure 1 This is a flowchart illustrating the microservice invocation method provided in an embodiment of this application. The method includes steps S100 to S400, as detailed below: S100: In response to receiving a data processing request, determine the data to be processed and data information about the data to be processed based on the data processing request.

[0023] Specifically, in this embodiment of the application, when a client in a microservice system receives a data processing request, it first needs to parse the request to determine the data content to be processed (i.e., the data to be processed) and the metadata information (i.e., the data information) related to the data to be processed. The metadata information is crucial for subsequent service node selection and data processing.

[0024] In practice, identifying the data to be processed and the data information is the foundation of the subsequent processing flow. It enables the microservice system to understand the specific content that needs to be processed and the factors that may need to be considered when processing the specific content. For example, the data size may affect the efficiency of transmission and processing, and the data type may determine the processing method to be used.

[0025] S200: Based on the data information, evaluate each of the multiple standby service nodes to obtain the evaluation results.

[0026] Specifically, in this embodiment, the microservice system evaluates multiple available service nodes (i.e., standby service nodes) based on the data information obtained in the previous step. The evaluation may be based on factors such as the current load, processing capacity, and historical performance records of the service nodes. The purpose of the evaluation is to identify the most suitable service node for processing the current data.

[0027] For example, a microservice system may score each service node based on metrics such as CPU utilization, memory usage, and success rate. If a service node has low CPU utilization, sufficient memory, and a history of fast image processing speed and high success rate, it may receive a higher score.

[0028] In practice, by evaluating service nodes, a microservice system can dynamically select the most suitable service node to process the current data, thereby improving processing efficiency and resource utilization. This helps avoid situations where some service nodes are overloaded while others are idle, achieving load balancing.

[0029] In one implementation, the data information includes the first method requirement information of the target processing method, the target processing method being the processing method requested by the data processing request and used to process the data to be processed; the client stores a data table, which records the method details and node status information of the service nodes; S200 includes: steps (1) to (2), as detailed below: Step (1): Based on the method details recorded in the data table, identify the service nodes that provide microservices containing the target processing method among the multiple idle service nodes as the service nodes to be used.

[0030] Among them, the method details information is the detailed information of the processing methods included in the microservices provided by the service nodes.

[0031] Specifically, in this embodiment, the client first accesses its stored data table, which records the method details and node status information of all service nodes. The method details refer to the detailed information of the specific processing methods contained in the microservices provided by each service node. Based on the target processing method (first method requirement information) specified in the data processing request, the client filters out service nodes that contain the target processing method in their provided microservices and are idle. The filtered service nodes are then identified as standby service nodes.

[0032] For example, suppose a data processing request requires calling an image processing method named "resizeImage". When the client accesses the data table, it finds that service nodes A, B, and C all provide image processing microservices, but only the microservices provided by service nodes A and B contain the "resizeImage" method, and service nodes A and B are currently idle. Service nodes A and B are identified as service nodes to be used. In practice, this step ensures that only service nodes capable of handling specific requests are considered, thereby avoiding sending unnecessary requests to service nodes that cannot handle the request and improving system efficiency and response speed. Step (2): Based on the requirement information of the first method, perform a performance evaluation on the current node status information of the service nodes to be used recorded in the data table to obtain the evaluation results.

[0033] The node status information includes CPU usage ratio, response time, and number of connections.

[0034] Specifically, in this embodiment, after determining the service nodes to be used, the client performs a performance evaluation on these service nodes based on the first method requirement information (i.e., the specific requirements of the target processing method) and the current node status information of the service nodes to be used recorded in the data table (including CPU usage ratio, response time, and number of connections, etc.). The purpose of the evaluation is to find the service node most suitable for handling the current request, that is, the service node with the best evaluation result. For example, continuing with the "resizeImage" method, the client might evaluate service nodes A and B based on metrics such as CPU usage, response time, and number of connections. If service node A has a low CPU usage, short response time, and not at its connection limit, it might receive a higher evaluation score. In contrast, service node B might receive a lower evaluation score due to a higher CPU usage or longer response time. In practice, this step is significant because, through performance evaluation, the client can dynamically select the most suitable service node to handle the current request, thereby achieving load balancing and improving system stability. By considering the current state of the service nodes, the system can avoid sending requests to overloaded or poorly performing service nodes, thus improving the overall system's processing efficiency and reliability.

[0035] In one implementation, step (2) includes steps (2.1) to (2.2), as detailed below: Step (2.1): Determine the evaluation weights of various node status information based on the requirements of the first method.

[0036] Specifically, in this embodiment, the client determines the importance or weight of different node status information (such as CPU usage ratio, response time, and number of connections) in performance evaluation based on the first method requirement information (i.e., the specific requirements of the target processing method). Different processing methods may have different performance requirements for service nodes, so the evaluation weights need to be dynamically adjusted according to specific requirements. Thus, compared to static strategies such as polling or random selection used in Spring Cloud microservice systems to determine target service nodes, the dynamic adjustment method of evaluation weights adopted in this embodiment can avoid service node overload and improve system stability through a mechanism of real-time feedback of node status information.

[0037] For example, if the target processing method is a computationally intensive task, then CPU utilization might be a very important evaluation metric because it directly affects the task's processing speed. In this case, the client might assign a higher weight to CPU utilization, such as 0.6, while assigning relatively lower weights to response time and connection count, such as 0.2 and 0.2 respectively. Conversely, if the target processing method is a task highly sensitive to response time, then the weight of response time might be set higher.

[0038] In practice, this step makes performance evaluation more flexible and accurate. By dynamically adjusting the evaluation weights based on the specific needs of the target processing method, the client can more accurately assess the performance of each available service node, thereby selecting the most suitable service node to handle the current request. This helps improve the overall performance and stability of the system. Step (2.2): Evaluate the node status information of the pending service nodes recorded in the data table according to the evaluation weight to obtain the evaluation result.

[0039] Specifically, in this embodiment, after determining the evaluation weights, the client performs a weighted evaluation of the node status information of the service nodes to be used recorded in the data table according to these weights. The evaluation result will be a comprehensive score or rating, used to indicate the suitability of each service node in handling the current request.

[0040] For example, suppose the client has determined the weights for CPU usage, response time, and connection count to be 0.6, 0.2, and 0.2, respectively. Then, the client calculates the evaluation scores for service nodes A and B based on these weights and their node status information. For instance, service node A has a CPU usage of 30%, a response time of 100ms, and 50 connections; service node B has a CPU usage of 50%, a response time of 80ms, and 70 connections. Based on this data and weights, the client can calculate the evaluation scores for service node A and service node B and select the service node with the higher score as the target service node. In practice, the significance of this step lies in the fact that through weighted evaluation, the client can comprehensively consider the state information of multiple nodes to arrive at a more comprehensive and accurate evaluation result. This helps the client to select target service nodes more scientifically, thereby improving the processing efficiency and stability of the microservice system. At the same time, this weighted evaluation method also enables the microservice system to be flexibly adjusted according to different needs and scenarios, further enhancing the adaptability and scalability of the microservice system. S300: Based on the evaluation results, determine the target service node from multiple standby service nodes.

[0041] Specifically, in this embodiment of the application, the microservice system selects one of multiple pending service nodes as the target service node based on the evaluation results; the selection criterion is usually the service node with the highest score in the evaluation results, that is, the service node most suitable for processing the current data.

[0042] In practice, identifying the target service node is a crucial step in ensuring that data is processed efficiently and accurately. By selecting the most suitable service node, the system can optimize the processing flow, improve processing speed and success rate, and reduce resource waste.

[0043] In this embodiment, the microservice system is built on the high-performance network application framework Netty, and the client includes a control module, a Netty communication module, a load balancing module, and a registry center; Figure 2 As shown, Figure 2This is an interactive diagram illustrating the process of determining a target service node in an embodiment of this application. When the control module receives a data processing request sent by the user, it determines the data to be processed and data information including the first method requirement information and the amount of data to be processed, etc., based on the data processing request. The control module determines a query request for a service node to be used based on the first method requirement information and the amount of data to be processed, and uses this request to request the load balancing module to query the target service node.

[0044] After receiving a query request for a pending service node, the load balancing module sends the request to the registry center. The registry center stores a data table that records the method details and node status information of the service nodes. After receiving the query request, the registry center determines the pending service node and its current status information based on the data table it stores. The registry center then sends the pending service node and its current status information to the load balancing module.

[0045] The load balancing module then performs a performance evaluation on the current node status information to obtain the evaluation result, and determines the target service node based on the evaluation result. After determining the target service node, the load balancing module sends an instruction message about the target service node to the control module to inform the control module of the target service node.

[0046] In this application embodiment, the microservice system provides reasonable default parameters (such as connection timeout and retry strategy), is ready to use out of the box, and supports configuration of local cache registry center or static service address without relying on external registry center (such as Eureka / Nacos), and is adaptable to resource-constrained environments (such as IoT and edge computing).

[0047] S400: Send the data to be processed to the target service node so that the target service node can process the data based on the microservices it provides.

[0048] Specifically, in practice, the microservice system sends the data to be processed to the target service node determined in the previous step. After receiving the data, the target service node uses its provided microservices (such as image processing algorithms) to process the data. After processing, the target service node may return the processing result to the system or directly to the requester.

[0049] In practice, sending the data to be processed to the target service node and processing it is the core step in the entire data processing flow. Through this step, the microservice system can leverage the expertise and resources of the target service node to efficiently complete data processing tasks. This also demonstrates the advantages of microservice architecture: different service nodes can focus on processing specific types of data or tasks, thereby improving the overall system's flexibility and scalability.

[0050] In one implementation, the client includes a serialization engine; the data information includes the amount of data to be processed; the data table also records the node identifier of the service node and the method identifier of the processing method included in the microservice provided by the service node; before S400, the method also includes: steps (3) to (4), as detailed below: Step (3): Determine the target serialization method corresponding to the data to be processed based on the relationship between the data volume and the preset data volume threshold.

[0051] Specifically, in this embodiment, the client first determines the relationship between the amount of data to be processed and a preset data volume threshold. The preset data volume threshold is a value set based on system performance and requirements, used to distinguish between small and large data volume scenarios. Based on the comparison between the data volume and the threshold, the client selects a suitable serialization method. More precisely, when the data volume is less than the preset data volume threshold, it is determined to be a small data volume scenario. In this scenario, JSON / Fastjson (debugging-friendly) is used for quick verification and log analysis. When the data volume is greater than the preset data volume threshold, it is determined to be a large data volume scenario. In this scenario, the client automatically switches to Kryo / Protobuf+Snappy / Lz4 compression algorithms to reduce transmission volume and memory usage. Therefore, compared to the default JSON serialization method of the Spring Cloud microservice system, this embodiment effectively optimizes resource utilization through this dynamic selection of serialization methods.

[0052] For example, suppose the preset data size threshold is 1MB. If the data to be processed is less than 1MB, the client will choose the JSON / Fastjson serialization method because this method is more user-friendly for debugging and facilitates quick verification and log analysis. If the data to be processed is greater than or equal to 1MB, the client will automatically switch to the Kryo / Protobuf+Snappy / Lz4 compression algorithm to reduce transmission size and memory usage.

[0053] In practice, by dynamically selecting the serialization method based on the data volume, the client can optimize resource utilization while ensuring system performance. For small data volume scenarios, using a debug-friendly serialization method can accelerate development and debugging; for large data volume scenarios, using compression algorithms can reduce network transmission overhead and memory usage, thereby improving overall system performance.

[0054] Step (4): The serialization engine encapsulates the data to be processed, the target node identifier of the target service node, the target method identifier of the target processing method, and the target link identifier into a data frame that conforms to the binary communication protocol according to the target serialization method.

[0055] The link identifier is the identifier of the link through which the data frame is transmitted.

[0056] Specifically, in this embodiment, after determining the target serialization method, the client encapsulates the data to be processed, the node identifier of the target service node, the method identifier of the target processing method, and the target link identifier into a data frame conforming to the binary communication protocol through the serialization engine. The binary communication protocol is an efficient data transmission protocol that only retains key metadata such as service name (i.e., target node identifier), method name (i.e., target method identifier), and traceID (i.e., target link identifier), avoiding redundant fields of the HTTP / REST protocol, thereby reducing network transmission overhead. For example, suppose the client has determined to use the Kryo / Protobuf+Snappy / Lz4 compression algorithm as the target serialization method and has obtained the node identifier of the target service node (e.g., "NodeA"), the method identifier of the target processing method (e.g., "resizeImage"), and the target link identifier (e.g., "Link1"). The client will encapsulate this information and the data to be processed into a binary data frame, and then send it to the target service node through the Netty communication module using an asynchronous non-blocking I / O model. In practice, by encapsulating data into data frames that conform to a binary communication protocol, the client can achieve efficient data transmission. The binary protocol reduces network transmission overhead and improves data transmission speed. Simultaneously, encapsulating the data to be processed, node identifier, method identifier, and link identifier together facilitates the server's parsing and processing of requests. This design allows the system to better adapt to high-concurrency, low-latency network environments, improving the overall performance and stability of the system.

[0057] In this embodiment, the protocol header of the data frame generated by the microservice system only contains metadata information, avoiding redundant fields of the HTTP / REST protocol (such as Content-Type and Accept), thus effectively reducing network transmission overhead.

[0058] In one implementation, S400 includes step (5), as detailed below: Step (5): Based on the asynchronous non-blocking I / O mechanism, send the data frame carrying the data to be processed to the target service node.

[0059] Among them, the asynchronous non-blocking I / O mechanism indicates that multiple processing links can be processed in parallel. A processing link is a communication link formed by at least one target service node during the data processing of the data to be processed through at least one target service node.

[0060] Specifically, in this embodiment, the client utilizes an asynchronous non-blocking I / O mechanism to send a data frame encapsulating data to be processed to a previously determined target service node. Asynchronous non-blocking I / O is an efficient I / O processing mode that allows a program to immediately continue executing other tasks after initiating an I / O operation, without waiting for the I / O operation to complete. This mechanism, through an event-driven approach, notifies the program to process the I / O operation when it is ready, thereby achieving parallel processing of multiple processing links. A processing link refers to the communication link formed by at least one target service node during the data processing of the data to be processed.

[0061] For example, suppose a client needs to process an image scaling request and has already identified the target service node as "NodeC" and the corresponding method identifier as "resizeImage" through previous steps. The client encapsulates the image data into a data frame and sends the data frame to "NodeC" using an asynchronous non-blocking I / O mechanism. While sending the data frame, the client can continue processing other requests or tasks without waiting for "NodeC" to return the processing result. When "NodeC" completes the image scaling operation and returns the result, the client will receive the result through an event notification mechanism and perform subsequent processing.

[0062] In this embodiment, the client connects to the server, which includes multiple service nodes, each comprising a data processing module and a deserialization engine; the client also includes a serialization engine; as shown below. Figure 3 As shown, Figure 3 This is an interactive diagram illustrating the process of determining a data frame in an embodiment of this application. After the control module determines the target service node, it sends the data to be processed and data information to the serialization engine for serialization processing according to the target serialization method. Then, the serialized data, along with the target node identifier, target method identifier, and target link identifier, is encapsulated into a data frame conforming to the binary communication protocol. Based on an asynchronous non-blocking I / O mechanism, the control module sends the data frame to the data processing module in the target service node on the server. The data processing module sends the data frame to the deserialization engine, which performs deserialization processing on the data frame to obtain the data to be processed and sends the data to be processed back to the data processing module.

[0063] After receiving the data to be processed, the data processing module processes the data using the target processing method to obtain the data processing result, and then sends the data processing result to the Netty communication module. The Netty communication module then sends the data processing result to the control module based on the asynchronous non-blocking I / O mechanism, so that the control module can feed back the data processing result to the user.

[0064] In this embodiment, the Netty microservice system constructed only includes necessary functional modules such as load balancing, serialization engine, and registry center. Therefore, the data processing of the Netty microservice system is highly efficient. In addition, the Netty microservice system constructed in this application supports on-demand loading. For example, in edge computing scenarios, the registry center can be turned off and service nodes can be called directly. Thus, compared with the "full-featured and comprehensive" design of Spring Cloud microservice system, this embodiment avoids redundant dependencies (such as Eureka, Hystrix, Feign, etc.), reducing deployment size and runtime memory overhead.

[0065] In practice, asynchronous non-blocking I / O mechanisms, which send data frames carrying data to be processed to target service nodes, offer advantages such as improved system throughput, parallel processing, and enhanced system stability. Firstly, asynchronous non-blocking I / O allows clients to process other tasks immediately after sending a data frame, thus fully utilizing system resources and increasing overall throughput. This mechanism is particularly suitable for high-concurrency scenarios, significantly enhancing system processing capabilities. Secondly, multiple processing chains can run in parallel through asynchronous non-blocking I / O, meaning clients can simultaneously send data frames to multiple target service nodes and wait for their processing results. This parallel processing significantly shortens system response time and improves user experience. Furthermore, asynchronous non-blocking I / O reduces client blocking time while waiting for I / O operations to complete, thereby mitigating performance bottlenecks and failure risks caused by I / O operations. This mechanism enables the system to operate more stably, maintaining good performance even when handling a large number of requests.

[0066] In one implementation, the data table records the correspondence between method requirement information and node identifiers and method identifiers; after S400, the method further includes: steps (6) to (7), as detailed below: Step (6): In response to receiving the second data processing request, determine the second method requirement information corresponding to the second data processing request.

[0067] Specifically, in this embodiment, the client listens for and responds to received second data processing requests. Upon receiving such a request, the client parses the request content to determine the corresponding second method requirement information. This method requirement information typically includes the specific method to be called, parameters, and expected output format, which is crucial for subsequent service node selection and data processing.

[0068] For example, suppose a client receives a request to crop an image. After parsing the request, the client determines that the second method requirement is "crop image" and may include parameters such as the specific size and position of the crop.

[0069] In practice, determining the requirements of the second method is fundamental to subsequent processing. Only by accurately understanding the specific requirements of the request can the client correctly select the service node, call the appropriate method, and return the expected result. This step ensures that the microservice system can provide accurate services for different requests.

[0070] Step (7): If the data table records the correspondence of the second method requirement information, determine the node identifier and method identifier corresponding to the second method requirement information as the target node identifier and target method identifier corresponding to the second method requirement information.

[0071] Specifically, in this embodiment, after determining the second method requirement information, the client queries its internally stored data table to check whether the data table records a corresponding relationship for the second method requirement information. If such a corresponding relationship exists in the data table, the client determines the node identifier and method identifier in the corresponding relationship as the target node identifier and target method identifier. The above identifiers can be directly used for subsequent service node selection and method invocation. In this embodiment, the reuse of service nodes is driven by the EventLoop event-driven model, thus enabling multiplexing of long connections, reducing thread blocking and context switching overhead. Compared with the synchronous blocking HTTP calls of Feign in the Spring Cloud microservice system, this embodiment can significantly reduce thread waiting time and improve concurrency performance.

[0072] For example, continuing with image cropping, suppose the data table records the correspondence between the method requirement information of "crop image" and a certain service node (such as "NodeB") and its provided cropping method (such as "cropImage"). When the client receives the image cropping request and determines that the second method requirement information is "crop image", it will query the data table and find the corresponding node identifier "NodeB" and method identifier "cropImage". Then, the client will identify these two identifiers as the target node identifier and the target method identifier. In practice, by querying data tables and determining the target node and target method identifiers, the client can automatically select the most suitable service node and method to handle the current request. This mechanism improves the system's flexibility and scalability, enabling it to easily adapt to different service node configurations and method requirements. Simultaneously, it reduces the need for manual intervention, increasing the system's automation level and efficiency.

[0073] In this embodiment of the application, the constructed Netty microservice system also includes a Netty memory pool, which pre-allocates memory pools through PooledByteBufAllocator, reuses buffers, and reduces the pressure of frequent GC (GCGarbageCollection).

[0074] Second, this application provides a microservice invocation apparatus for implementing the above-mentioned microservice invocation method; the apparatus includes: a control module and a load balancing module; The control module is used to respond to a received data processing request and determine the data to be processed and data information about the data to be processed based on the data processing request. The load balancing module is used to evaluate each of the multiple waiting service nodes based on data information to obtain the evaluation result; The load balancing module is used to determine the target service node from multiple standby service nodes based on the evaluation results. The control module is used to send the data to be processed to the target service node, so that the target service node can process the data based on the microservices it provides.

[0075] In one implementation, the data information includes first method requirement information of the target processing method, the target processing method being the processing method requested by the data processing request and used to process the data to be processed; the client stores a data table, which records the method details and node status information of the service nodes; the load balancing module is further used to determine the service nodes that provide microservices containing the target processing method among multiple idle service nodes as standby service nodes based on the method details recorded in the data table; Among them, the method details information is the detailed information of the processing methods included in the microservices provided by the service nodes; The load balancing module is also used to perform performance evaluation on the current node status information of the service nodes to be used recorded in the data table based on the requirements information of the first method to obtain the evaluation result. The node status information includes CPU usage ratio, response time, and number of connections.

[0076] In one implementation, the load balancing module is also used to determine the evaluation weights of various node status information based on the first method requirement information. The load balancing module is also used to evaluate the node status information of the pending service nodes recorded in the data table according to the evaluation weight to obtain the evaluation result.

[0077] In one implementation, the client includes a serialization engine; the data information includes the amount of data to be processed; the data table also records the node identifier of the service node and the method identifier of the processing method included in the microservice provided by the service node; the control module is also used to determine the target serialization method corresponding to the data to be processed based on the relationship between the amount of data and a preset data amount threshold. The serialization engine is used to encapsulate the data to be processed, the target node identifier of the target service node, the target method identifier of the target processing method, and the target link identifier into a data frame that conforms to the binary communication protocol, according to the target serialization method. The link identifier is the identifier of the link through which the data frame is transmitted.

[0078] In one implementation, the data table records the correspondence between method requirement information and node identifiers and method identifiers; the control module is also used to determine the second method requirement information corresponding to the second data processing request in response to receiving the second data processing request. The control module is also used to determine the node identifier and method identifier corresponding to the second method requirement information as the target node identifier and target method identifier corresponding to the second method requirement information if the data table records a correspondence relationship about the second method requirement information.

[0079] In one implementation, the device further includes: a Netty communication module; The Netty communication module is used to send data frames carrying data to be processed to the target service node based on an asynchronous non-blocking I / O mechanism. Among them, the asynchronous non-blocking I / O mechanism indicates that multiple processing links can be processed in parallel. A processing link is a communication link formed by at least one target service node during the data processing of the data to be processed through at least one target service node.

[0080] Third, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps S100 to S400 provided in the above embodiments.

[0081] Fourth, this application also provides a computer-readable storage medium storing a computer program, wherein the computer program is executed by a processor to perform the steps of S100 to S400 of the above embodiments.

[0082] Fifth, the computer program product provided in this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods in the preceding method embodiments. For specific implementation, please refer to the steps of S100 to S400 of the method embodiments, which will not be repeated here.

[0083] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

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

[0085] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0086] It should be noted that if the function is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0087] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0088] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A microservice invocation method, characterized in that, A client-side application in a microservice system, the system further comprising multiple service nodes for providing microservices; the method includes: In response to receiving a data processing request, the system determines the data to be processed and data information about the data to be processed based on the data processing request. Based on the data information, each of the multiple standby service nodes is evaluated to obtain the evaluation result; Based on the evaluation results, a target service node is determined from among the multiple available service nodes; The data to be processed is sent to the target service node, so that the target service node can process the data based on the microservices it provides.

2. The method according to claim 1, characterized in that, The data information includes first method requirement information of the target processing method, wherein the target processing method is the processing method requested by the data processing request and is used to process the data to be processed; The client stores a data table, which records the method details and node status information of the service node. The step of evaluating each of the multiple standby service nodes based on the data information to obtain an evaluation result includes: Based on the method details recorded in the data table, the service node that provides the target processing method among the multiple idle service nodes is identified as the service node to be used. The method details information refers to the microservices provided by the service node, including the details of the processing methods therein. Based on the requirement information of the first method, the current node status information of the service node to be used recorded in the data table is evaluated to obtain the evaluation result; The node status information includes CPU usage ratio, response time, and number of connections.

3. The method according to claim 2, characterized in that, The step of evaluating the current node status information of the service nodes to be used, recorded in the data table, based on the first method requirement information to obtain an evaluation result includes: Based on the requirement information of the first method, determine the evaluation weights of various node state information; The node status information of the pending service nodes recorded in the data table is evaluated according to the evaluation weight to obtain the evaluation result.

4. The method according to claim 2, characterized in that, The client includes a serialization engine; the data information includes the data volume of the data to be processed; the data table also records the node identifier of the service node and the method identifier of the processing method included in the microservice provided by the service node; before sending the data to be processed to the target service node, the method further includes: Based on the relationship between the data volume and the preset data volume threshold, a target serialization method corresponding to the data to be processed is determined; The serialization engine encapsulates the data to be processed, the target node identifier of the target service node, the target method identifier of the target processing method, and the target link identifier into a data frame that conforms to the binary communication protocol according to the target serialization method. The link identifier is the identifier of the link through which the data frame is transmitted.

5. The method according to claim 4, characterized in that, The data table records the correspondence between method requirement information and the node identifier and the method identifier; After sending the data to be processed to the target service node, the method further includes: In response to receiving a second data processing request, determine the second method requirement information corresponding to the second data processing request; If the data table records a correspondence regarding the second method requirement information, the node identifier and the method identifier corresponding to the second method requirement information are determined as the target node identifier and target method identifier corresponding to the second method requirement information.

6. The method according to claim 1, characterized in that, Sending the data to be processed to the target service node includes: Based on the asynchronous non-blocking I / O mechanism, the data frame carrying the data to be processed is sent to the target service node; The asynchronous non-blocking I / O mechanism indicates that multiple processing links can be processed in parallel. The processing link is a communication link formed by at least one target service node during the data processing of the data to be processed through at least one target service node.

7. A microservice invocation device, characterized in that, The apparatus is used to implement the method of claim 1; the apparatus includes: a control module and a load balancing module; The control module is configured to, in response to receiving a data processing request, determine the data to be processed and data information about the data to be processed based on the data processing request; The load balancing module is used to evaluate each of the multiple standby service nodes according to the data information to obtain an evaluation result. The load balancing module is used to determine the target service node from among the multiple standby service nodes based on the evaluation results. The control module is used to send the data to be processed to the target service node, so that the target service node can process the data to be processed based on the microservices it provides.

8. An electronic device, characterized in that, The electronic device includes a processor and a memory for storing applications. The processor enables the electronic device to implement the microservice invocation method as described in any one of claims 1 to 6 by running or executing software programs stored in the memory.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store program code executed by the processor, the program code being used to implement the microservice invocation method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed on an electronic device, cause the electronic device to implement the microservice invocation method as described in any one of claims 1 to 6.

Images