Request processing method and device for distributed system, equipment and medium

Abstract

The invention provides a request processing method and device for a distributed system, equipment and a medium, and relates to the technical field of distributed services. Comprising the following steps: acquiring state data of each distributed service node in the distributed system; obtaining a health state identifier of each distributed service node according to the state data and a preset health data threshold value; obtaining an effective service node list of the distributed system according to the health state identifier; receiving a service calling request sent by a calling party; obtaining a target node according to a preset routing algorithm and the effective service node list; and sending the service calling request to the target node. According to the method provided by the invention, the real-time state data of each distributed service node in the distributed system is acquired, and the effective service node list of the distributed system is updated in real time in combination with the preset health data threshold value, so that the balance of flow forwarding is ensured, and a fault of the distributed system caused by a single-point overload problem is avoided.

Description

Technical Field

[0001] This application relates to the field of distributed service technology, and in particular to a request processing method, apparatus, device and medium for distributed systems. Background Technology

[0002] In modern distributed system architectures, as business complexity increases and system scale expands, service modules are typically broken down into multiple loosely coupled microservice units to improve the flexibility and maintainability of the distributed system. Each microservice unit can participate in the operation of the entire distributed system as an independent distributed service node.

[0003] In existing technologies, load balancing is typically implemented using a client-side load balancing component (Ribbon). The core process is as follows: service instances corresponding to distributed service nodes register their information through a service registry, such as a distributed coordination service (ZooKeeper) or a service discovery component (Eureka), and maintain their online status using a heartbeat mechanism. When a client initiates a call request, the load balancer retrieves a list of available service instances from the service registry, then selects the target node according to a preset strategy (such as round-robin, weighted round-robin, or random algorithms) and forwards the call request.

[0004] However, in high-concurrency scenarios, existing load balancing mechanisms are prone to single-point overload problems due to sudden increases or backlogs of service call requests, leading to distributed system failures. Summary of the Invention

[0005] This application provides a request processing method, apparatus, device, and medium for a distributed system, which obtains real-time status data of each distributed service node in the distributed system and updates the list of effective service nodes in the distributed system in real time by combining preset health data thresholds, thereby ensuring the balance of traffic forwarding and avoiding distributed system failures due to single-point overload in scenarios such as message surges, uneven resource distribution, or network fluctuations.

[0006] In a first aspect, this application provides a request processing method for a distributed system, the method comprising:

[0007] Obtain the status data of each distributed service node in the distributed system;

[0008] Based on the status data and preset health data thresholds, the health status identifier of each distributed service node is obtained;

[0009] Based on the health status identifier, a list of valid service nodes in the distributed system is obtained;

[0010] Receive service call requests sent by the caller;

[0011] The target node is obtained based on the preset routing algorithm and the list of valid service nodes;

[0012] Send the service call request to the target node.

[0013] In one possible implementation, the health status of the distributed service node is identified as any one of healthy, unhealthy, or overloaded.

[0014] Based on the health status identifier, a list of valid service nodes in the distributed system is obtained, including:

[0015] Iterate through the health status indicators of each distributed service node;

[0016] Add distributed service nodes marked as healthy to the list of valid service nodes, and remove distributed service nodes marked as unhealthy or overloaded from the list of valid service nodes.

[0017] In one possible implementation, the target node is obtained based on a preset routing algorithm and a list of valid service nodes, including:

[0018] Based on the list of valid service nodes, extract the first state data corresponding to each healthy distributed service node;

[0019] Based on the first state data and the preset routing algorithm, calculate the target load score corresponding to each healthy distributed service node;

[0020] Select the distributed service node with the highest target load score from the list of valid service nodes as the target node.

[0021] In one possible implementation, the first state data includes processor utilization, memory usage, current active connections, and request error rate;

[0022] Based on the first state data and the preset routing algorithm, calculate the target load score for each healthy distributed service node, including:

[0023] The processor utilization, memory usage, current active connection count, and request error rate in the first state data are normalized to obtain the second state data corresponding to each healthy distributed service node.

[0024] The second state data is weighted and summed according to preset weighting coefficients to obtain a preliminary load score.

[0025] If the preset routing algorithm is a region affinity algorithm, then for distributed service nodes located in the same region as the caller, an affinity score is added to the corresponding preliminary load score to obtain the target load score.

[0026] For distributed service nodes that are not in the same region as the caller, the preliminary load score will be used as the target load score.

[0027] In one possible implementation, the method further includes:

[0028] If the default routing algorithm is the session persistence algorithm, then based on the session identifier carried in the service call request, the mapping relationship between the caller's historical sessions and each distributed service node in the list of valid service nodes is queried.

[0029] If there are distributed service nodes in the list of valid service nodes that are associated with the caller's historical sessions, then for the distributed service nodes associated with the caller's historical sessions, an association score is added to the corresponding preliminary load score to obtain the target load score.

[0030] For distributed service nodes that have no association with the caller's historical sessions, the preliminary load score will be used as the target load score.

[0031] In one possible implementation, after sending the service invocation request to the target node, the method further includes:

[0032] Generate request forwarding results;

[0033] The steps involve forwarding the request result to the monitoring service client and returning the status data of each distributed service node in the distributed system.

[0034] Secondly, this application provides a request processing apparatus for a distributed system, the apparatus comprising:

[0035] The acquisition module is used to acquire the status data of each distributed service node in the distributed system.

[0036] The data processing module is used to obtain the health status identifier of each distributed service node based on the status data and preset health data thresholds.

[0037] The data processing module is also used to obtain a list of valid service nodes in the distributed system based on the health status identifier;

[0038] The request receiving module is used to receive service call requests sent by the caller;

[0039] The node selection module is used to obtain the target node based on the preset routing algorithm and the list of valid service nodes;

[0040] The sending module is used to send service call requests to the target node.

[0041] In one possible implementation, the health status of the distributed service node is identified as any one of healthy, unhealthy, or overloaded.

[0042] The data processing module is also used to traverse the health status identifiers of each distributed service node;

[0043] The data processing module is also used to add distributed service nodes with a healthy health status to the list of valid service nodes, and remove distributed service nodes with an unhealthy or overloaded health status from the list of valid service nodes.

[0044] In one possible implementation, the node selection module is further configured to extract first state data corresponding to each healthy distributed service node based on the list of valid service nodes.

[0045] The node selection module is also used to calculate the target load score corresponding to each healthy distributed service node based on the first state data and the preset routing algorithm.

[0046] The node selection module is also used to select the distributed service node with the highest target load score from the list of valid service nodes as the target node.

[0047] In one possible implementation, the first state data includes processor utilization, memory usage, current active connections, and request error rate;

[0048] The node selection module is also used to normalize the processor utilization, memory usage, current active connection count and request error rate in the first state data to obtain the second state data corresponding to each healthy distributed service node.

[0049] The node selection module is also used to perform weighted summation on the second state data according to preset weight coefficients to obtain a preliminary load score;

[0050] The node selection module is also used to add an affinity score to the corresponding preliminary load score for distributed service nodes that are in the same region as the caller if the preset routing algorithm is a regional affinity algorithm, so as to obtain the target load score.

[0051] The node selection module is also used to use the preliminary load score as the target load score for distributed service nodes that are not in the same region as the caller.

[0052] In one possible implementation, the node selection module is further configured to, if the preset routing algorithm is a session persistence algorithm, query the mapping relationship between the caller's historical sessions and each distributed service node in the list of valid service nodes based on the session identifier carried in the service call request.

[0053] The node selection module is also used to add an association score to the corresponding preliminary load score to obtain the target load score if there are distributed service nodes associated with the caller's historical sessions in the list of valid service nodes.

[0054] The node selection module is also used to use the preliminary load score as the target load score for distributed service nodes that have no association with the caller's historical sessions.

[0055] In one possible implementation, the device further includes: a closed-loop feedback module;

[0056] The closed-loop feedback module is used to generate request forwarding results;

[0057] The closed-loop feedback module is also used to send the request forwarding result to the monitoring service client and return the steps for obtaining the status data of each distributed service node in the distributed system.

[0058] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor.

[0059] The memory stores the instructions that the computer executes.

[0060] The processor executes computer execution instructions stored in memory to implement a request processing method for a distributed system, as described in the first aspect of the invention.

[0061] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement a request processing method for a distributed system as described in the first aspect of the invention.

[0062] Fifthly, this application provides a computer program product, including a computer program, which, when executed by a processor, is used to implement a request processing method for a distributed system as described in the first aspect of the invention.

[0063] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods.

[0064] This application provides a request processing method, apparatus, device, and medium for a distributed system, comprising: first, acquiring the status data of each distributed service node in the distributed system; then, obtaining a health status identifier for each distributed service node based on the status data and a preset health data threshold; next, obtaining a list of valid service nodes in the distributed system based on the health status identifier; subsequently, receiving a service call request sent by a caller; then, obtaining a target node based on a preset routing algorithm and the list of valid service nodes; and finally, sending the service call request to the target node. This achieves the following technical effects: by continuously collecting multi-dimensional status data of each distributed service node through a monitoring service client, and combining it with a preset health data threshold, a health status identifier for each distributed service node is dynamically generated. Based on this health status identifier, a list of valid service nodes is maintained in real time, actively eliminating overloaded or performance-degraded nodes. Upon receiving a service call request, based on the list of valid service nodes and the preset routing algorithm, the real-time load status of each healthy distributed service node is comprehensively analyzed, and a target node is selected for forwarding the service call request. This enables distributed systems to adaptively cope with complex scenarios such as sudden increases in messages, resource fluctuations, or network anomalies, effectively avoiding distributed system failures caused by single-point overload and ensuring the overall high availability and efficient utilization of resources of the distributed system. Attached Figure Description

[0065] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0066] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0067] Figure 1 This application provides an illustration of an application scenario for a request processing method for a distributed system.

[0068] Figure 2 A flowchart illustrating a request processing method for a distributed system provided in an embodiment of this application;

[0069] Figure 3 A schematic diagram of the structure of a request processing device for a distributed system provided in an embodiment of this application;

[0070] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0071] Figure label:

[0072] 101 - Distributed service node; 102 - Service management component; 103 - Caller;

[0073] 310 - Acquisition Module; 320 - Data Processing Module; 330 - Request Receiving Module; 340 - Node Selection Module; 350 - Sending Module;

[0074] 410 - Processor; 420 - Memory; 430 - Communication components; 440 - Bus. Detailed Implementation

[0075] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0076] In the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply difference. It should be noted that in the embodiments of this application, the words "exemplary" or "for example" are used to indicate that something is being used as an example, illustration, or description. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being better or more advantageous than other embodiments or design schemes. Specifically, the use of "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner. In the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more.

[0077] It should be noted that the phrase "at...time" in the embodiments of this application can refer to the instant at which a certain situation occurs, or to a period of time after the occurrence of a certain situation; the embodiments of this application do not specifically limit this. Furthermore, the request processing method for a distributed system provided in the embodiments of this application is merely an example; a request processing method for a distributed system may also include more or less content.

[0078] As modern distributed system architectures continue to evolve, with the increasing complexity of business processes and the expanding scale of systems, service modules responsible for overall business functions are typically broken down into multiple loosely coupled microservice units to improve the scalability, flexibility, and maintainability of distributed systems. Each microservice unit is deployed and runs as an independent distributed service node. However, while refining the service granularity, it also significantly increases the frequency and complexity of inter-service calls, placing higher demands on load balancing mechanisms.

[0079] Currently, mainstream microservice frameworks generally adopt a client-side load balancing model, with typical implementations including open-source components such as Ribbon. In this approach, after a service instance starts, it registers its metadata with a service registry (such as ZooKeeper or Eureka) and maintains its online status through periodic heartbeats. When a client initiates a call, it retrieves a list of currently available service instances from the registry and selects a target node for request forwarding based on a preset static strategy (such as round-robin, random, or weighted round-robin).

[0080] However, the aforementioned existing technologies have significant drawbacks. First, load balancing decisions rely solely on service availability, failing to consider the real-time operational load status of each distributed service node, such as CPU utilization, memory usage, current active connections, and request error rate. Second, the routing strategies are rigid and lack dynamic adjustment capabilities. In scenarios with high concurrency, sudden traffic spikes, or uneven resource distribution, some distributed service nodes are easily overloaded due to excessive request concentration, leading to increased response latency, service avalanches, or even system-level failures, severely restricting the high availability and stability of the distributed system.

[0081] Based on this, embodiments of this application propose a request processing method, apparatus, device, and medium for distributed systems, applicable to the field of distributed service technology, aiming to solve the aforementioned technical problems of the prior art. By continuously collecting multi-dimensional status data of each distributed service node through a monitoring service client and combining it with preset health data thresholds, a health status identifier for each distributed service node is dynamically generated. Based on this health status identifier, a list of valid service nodes is maintained in real time, proactively removing overloaded or performance-degraded nodes. Upon receiving a service call request, the real-time load status of each healthy distributed service node is comprehensively analyzed based on the list of valid service nodes and a preset routing algorithm, and a target node is selected for forwarding the service call request. This enables the distributed system to adaptively cope with complex scenarios such as sudden increases in messages, resource fluctuations, or network anomalies, effectively avoiding distributed system failures due to single-point overload issues, and ensuring the overall high availability and efficient resource utilization of the distributed system.

[0082] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0083] To better understand the solutions of the embodiments of this application, an application scenario involved in the embodiments of this application will be introduced below.

[0084] For specific application scenarios of this application, please refer to [link / reference needed]. Figure 1 . Figure 1 This is a schematic diagram illustrating an application scenario of a request processing method for a distributed system provided in an embodiment of this application. It should be noted that... Figure 1 The examples shown are merely application scenarios that can be applied to the embodiments of this application, in order to help those skilled in the art understand the technical content of this application, but do not mean that the embodiments of this application cannot be used in other devices, systems, environments or scenarios.

[0085] like Figure 1 As shown, this application scenario includes a distributed system and a caller 103. The distributed system includes multiple distributed service nodes 101 and a service management component 102.

[0086] Specifically, the service management component 102 communicates with multiple distributed service nodes 101 to receive status data of each distributed service node collected by the monitoring service client via a message queue (Kafka). It then dynamically generates a health status identifier for each distributed service node based on a preset health data threshold. Subsequently, it maintains a list of valid service nodes in real time based on this health status identifier, proactively removing overloaded or performance-degraded nodes.

[0087] The service management component 102 also communicates with the caller 103 to receive service call requests sent by the caller 103. Based on the list of valid service nodes and a preset routing algorithm, it comprehensively analyzes the real-time load status of each healthy distributed service node, selects a target node, and forwards the service call request to that target node. This effectively solves the problem of single-point overload caused by a sudden increase or backlog of service call requests in high-concurrency scenarios, ensuring the overall high availability and efficient resource utilization of the distributed system.

[0088] Figure 2 This is a flowchart illustrating a request processing method for a distributed system provided in an embodiment of this application. The execution entity in this embodiment can be... Figure 1The service management component 102 in the illustrated embodiment can also be a service mesh control plane component, a network controller, or other related computer devices; this embodiment does not impose any particular limitation on this. For ease of description, this application embodiment uniformly describes the execution entity of a request processing method for a distributed system as a central server. Figure 2 As shown, the method includes:

[0089] S201. Obtain the status data of each distributed service node in the distributed system.

[0090] Specifically, status data can be collected in real time by monitoring agents deployed on each distributed service node and reported to the central server via asynchronous message channels (such as Kafka, RabbitMQ, etc.). Status data includes, but is not limited to: CPU utilization, memory usage, disk input / output (I / O) load, network bandwidth utilization, and application-layer metrics such as Requests Per Second (QPS), current active connections, and request error rate, which comprehensively reflect the operating load and health status of each distributed service node in the distributed system.

[0091] S202. Based on the status data and preset health data thresholds, obtain the health status identifier of each distributed service node.

[0092] Specifically, the central server can perform health analysis on each distributed service node based on status data and preset health data thresholds, generating a corresponding health status identifier. The health status identifier can include categories such as healthy, overloaded, or unhealthy. For example, when the CPU utilization of a specific distributed service node exceeds 85% or the error rate is higher than 5%, that distributed service node is marked as overloaded; if its heartbeat is interrupted or a critical process malfunctions, it is marked as unhealthy; the remaining distributed service nodes that meet all threshold conditions can be marked as healthy.

[0093] S203. Based on the health status identifier, obtain the list of valid service nodes in the distributed system.

[0094] Specifically, the central server can dynamically build and maintain a list of valid service nodes in the distributed system based on the health status indicators of each distributed service node. Specifically, only nodes with a healthy health status are included in this list of valid service nodes, while nodes marked as overloaded or unhealthy are removed from the list in real time to ensure that subsequent traffic is not distributed to performance-degraded or unavailable instances.

[0095] S204. Receive the service call request sent by the caller.

[0096] Specifically, the central server can receive service call requests from the caller (i.e., the service consumer). These service call requests can be remote call requests in the form of Hypertext Transfer Protocol (HTTP), Google Remote Procedure Call (gRPC), or Remote Procedure Call (RPC), and include information such as the target service name, session identifier (e.g., SessionID), and business context.

[0097] S205. Obtain the target node based on the preset routing algorithm and the list of valid service nodes.

[0098] Specifically, the central server can select an optimal target node from the healthy distributed service nodes included in the list of valid service nodes based on a preset routing algorithm and the current list of valid service nodes. The preset routing algorithm can be configured with various strategies, including but not limited to: a weighted least connection algorithm, which prioritizes the distributed service node with the fewest currently active connections and sufficient resources.

[0099] The session consistent hashing algorithm is used to perform hash mapping based on the session identifier in the service call request, so as to ensure that the same session is always routed to the same healthy distributed service node.

[0100] The availability zone affinity routing algorithm is used to prioritize healthy distributed service nodes located in the same availability zone as the caller in order to reduce network latency.

[0101] The comprehensive load scoring algorithm is used to calculate the real-time load score of each distributed service node by combining multi-dimensional indicators such as CPU, memory, and QPS, and select the node with the highest real-time load score as the target node.

[0102] S206. Send the service call request to the target node.

[0103] Specifically, the central server can forward service call requests to the selected target nodes, completing the routing and distribution of this service call. At the same time, it can feed back the result of this forwarding (such as success, timeout, error code, response latency, etc.) to the monitoring service client in the monitoring system, so as to update the status data of the distributed service nodes, forming a closed-loop feedback mechanism, thereby enabling the distributed system to adaptively adjust to load changes.

[0104] Through the above method, this embodiment realizes dynamic and intelligent routing selection based on real-time load awareness, effectively avoiding single-point overload problems caused by static strategies or blind spots in the state of distributed service nodes, and significantly improving the high availability, resource utilization and service quality of the distributed system.

[0105] This embodiment provides a request processing method for a distributed system. First, the status data of each distributed service node in the distributed system is obtained. Then, based on the status data and a preset health data threshold, a health status identifier of each distributed service node is obtained. Next, based on the health status identifier, a list of valid service nodes in the distributed system is obtained. Subsequently, a service call request sent by the caller is received. Then, based on a preset routing algorithm and the list of valid service nodes, the target node is obtained. Finally, the service call request is sent to the target node.

[0106] The following technical effects were achieved: Multi-dimensional status data of each distributed service node was continuously collected by the monitoring service client, and a health status identifier for each distributed service node was dynamically generated based on preset health data thresholds. A list of valid service nodes was maintained in real time based on this health status identifier, proactively removing overloaded or performance-degraded nodes. Upon receiving a service call request, the real-time load status of each healthy distributed service node was comprehensively analyzed based on the list of valid service nodes and a preset routing algorithm, and the target node was selected for forwarding the service call request. This enabled the distributed system to adaptively cope with complex scenarios such as sudden increases in messages, resource fluctuations, or network anomalies, effectively avoiding distributed system failures due to single-point overload issues, and ensuring the overall high availability and efficient resource utilization of the distributed system.

[0107] In one possible implementation, the health status of the distributed service node is identified as any one of healthy, unhealthy, or overloaded.

[0108] Based on the health status identifiers, a list of valid service nodes in the distributed system is obtained, including: traversing the health status identifiers of each distributed service node; adding distributed service nodes with a healthy health status to the list of valid service nodes, and removing distributed service nodes with an unhealthy or overloaded health status from the list of valid service nodes.

[0109] Specifically, the central server can iterate through the health status identifiers of all distributed service nodes currently registered with the service registry.

[0110] For distributed service nodes whose health status is identified as healthy, their service instance information (such as IP address, port, metadata, etc.) is added to the list of valid service nodes as candidate targets for subsequent routing.

[0111] For distributed service nodes whose health status is marked as unhealthy (e.g., due to lost heartbeat, process crash, or abnormal key indicators) or overloaded (e.g., CPU utilization, memory usage, or error rate exceeding preset health data thresholds), they are immediately removed from the list of valid service nodes and marked as unhealthy to ensure that traffic is not distributed to distributed service nodes with degraded performance or potential failures.

[0112] Through this mechanism, the central server can dynamically maintain a list of available and reasonably loaded service nodes, providing an accurate and reliable data foundation for subsequent intelligent routing decisions based on real-time load awareness. This effectively prevents service call requests from being mistakenly forwarded to high-load or abnormal distributed service nodes, thereby improving the overall stability and response quality of the distributed system.

[0113] In one possible implementation, obtaining the target node based on a preset routing algorithm and a list of valid service nodes includes: extracting first state data corresponding to each healthy distributed service node based on the list of valid service nodes; calculating the target load score corresponding to each healthy distributed service node based on the first state data and the preset routing algorithm; and selecting the distributed service node with the highest target load score from the list of valid service nodes as the target node.

[0114] Specifically, firstly, the central server can extract the first-state data corresponding to each healthy distributed service node based on the list of valid service nodes. This first-state data consists of key real-time metrics used for routing decisions, including but not limited to: CPU utilization, memory usage, current active connections, and request error rate. This first-state data can be continuously collected by the monitoring agent and synchronized to the central server.

[0115] Secondly, the central server can calculate the target load score for each healthy distributed service node based on the initial state data and a preset routing algorithm. Specifically, different routing algorithms correspond to different scoring logics. For example, if the weighted least connection algorithm is used, the number of active connections is the main factor, combined with resource utilization for weighted normalization. The fewer the connections and the more idle the resources, the higher the target load score.

[0116] If a comprehensive load awareness algorithm is used, the various indicators are standardized and then weighted and summed according to preset weights (such as CPU weight 0.4, memory weight 0.3, and request error rate weight 0.3) to obtain a comprehensive load score. The higher the score, the lighter the load and the better the performance of the distributed service node.

[0117] If the availability zone affinity policy is enabled, the distributed service nodes that are in the same availability zone as the caller will receive an affinity bonus on their base score.

[0118] If session persistence mode is used and the current request carries a historical session identifier, the distributed service node associated with that session will be retained first.

[0119] Finally, the distributed service node with the highest target load score is selected from the list of valid service nodes as the target node for this service call request. This target node is the forwarding target with the lightest load, best performance, and meets the constraints of the preset routing algorithm.

[0120] Through the above mechanism, this embodiment realizes fine-grained routing selection based on multi-dimensional real-time status data and preset routing algorithms. While ensuring the high availability of the distributed system, it maximizes the utilization efficiency of distributed system resources and can effectively cope with complex operating scenarios such as high concurrency, sudden traffic and uneven resource distribution.

[0121] In one possible implementation, the first state data includes processor utilization, memory usage, current active connections, and request error rate.

[0122] Based on the first-state data and the preset routing algorithm, the target load score for each healthy distributed service node is calculated. This includes: normalizing the processor utilization, memory usage, current active connections, and request error rate in the first-state data to obtain the second-state data for each healthy distributed service node; weighting and summing the second-state data according to preset weight coefficients to obtain a preliminary load score; if the preset routing algorithm is a region affinity algorithm, then for distributed service nodes located in the same region as the caller, an affinity score is added to the corresponding preliminary load score to obtain the target load score; for distributed service nodes not located in the same region as the caller, the preliminary load score is used as the target load score.

[0123] Specifically, firstly, the central server can normalize the various metrics in the first-state data—processor utilization, memory usage, current active connections, and request error rate—mapping them to a uniform numerical range (e.g., [0, 1]) to eliminate dimensional differences and facilitate comprehensive analysis, thereby obtaining the second-state data corresponding to each healthy distributed service node. The normalization method can employ min-max scaling or dynamic normalization based on a historical sliding window to ensure the comparability of the metric values.

[0124] Secondly, the central server can perform a weighted summation of the second-state data based on pre-configured weighting coefficients (such as processor utilization weight of 0.3, memory usage weight of 0.2, active connection count weight of 0.3, and request error rate weight of 0.2) to calculate a preliminary load score for each healthy distributed service node. This preliminary load score reflects the current overall load pressure of the distributed service node; a higher value indicates that the distributed service node is less overloaded or has better performance.

[0125] Furthermore, it is determined whether the preset routing algorithm is a region affinity algorithm (e.g., availability zone-aware routing). If so, the network region or availability zone where the caller is located is identified, and for the distributed service nodes in the list of valid service nodes that are in the same region as the caller, a preset affinity score is added to their initial load score (e.g., adding 0.1 affinity score or a fixed priority offset) to obtain their target load score.

[0126] For distributed service nodes that are not located in the same region as the caller, no affinity score is added, and their initial load score is directly used as the target load score.

[0127] Ultimately, each healthy distributed service node receives a unified and comparable target load score, which can be used as a basis for selecting target nodes in the future.

[0128] This embodiment, while taking into account the resource load balancing of the distributed system, incorporates a network topology affinity strategy, effectively reducing the latency and bandwidth overhead caused by cross-regional calls, and realizing intelligent routing decisions that optimize performance and efficiency in a coordinated manner.

[0129] In one possible implementation, the method further includes: if the preset routing algorithm is a session persistence algorithm, then querying the mapping relationship between the caller's historical sessions and each distributed service node in the list of valid service nodes based on the session identifier carried in the service call request; if there are distributed service nodes in the list of valid service nodes that are associated with the caller's historical sessions, then adding an association score to the corresponding preliminary load score for the distributed service nodes associated with the caller's historical sessions to obtain a target load score; for distributed service nodes that are not associated with the caller's historical sessions, using the preliminary load score as the target load score.

[0130] Specifically, if the default routing algorithm is a session persistence algorithm, the central server can, after receiving a service call request, first parse the session identifier carried in the service call request, such as a session ID, token, or user ID.

[0131] Subsequently, based on the session identifier, the central server can query a pre-maintained session-node mapping table to obtain the distributed service nodes associated with the caller's historical sessions. This session-node mapping table can be stored in an in-memory database such as a remote dictionary server (Redis) or in a local cache.

[0132] It further determines whether the distributed service node associated with the caller's historical session exists in the list of valid service nodes.

[0133] If there is a distributed service node associated with the historical session in the current list of valid service nodes (i.e., the distributed service node associated with the historical session is still in a healthy state and has not been removed), then a preset correlation score (e.g., 0.15 correlation scores or a configurable priority offset value) is added to the distributed service node associated with the historical session based on its initial load score, so as to obtain its target load score, in order to reflect the priority guarantee of session continuity.

[0134] If there is no node associated with the historical session in the list of valid service nodes (e.g., the node associated with the historical session is overloaded, offline, or marked as unhealthy), or if the service call request is a new session (without history), then no association score will be applied to any of the distributed service nodes in the list of valid service nodes, and their initial load scores will be used as their respective target load scores.

[0135] Through the above mechanism, while ensuring the overall efficiency of load balancing, prioritizing the reuse of service instances bound to existing sessions can improve application layer state consistency and user experience. Simultaneously, when there is no distributed service node associated with the historical session in the list of valid service nodes—that is, when the original bound node is unavailable—it automatically falls back to the optimal selection based on real-time load, balancing reliability, continuity, and adaptability.

[0136] In one possible implementation, after sending the service call request to the target node, the method further includes: generating a request forwarding result; sending the request forwarding result to the monitoring service client; and returning the steps of obtaining the status data of each distributed service node in the distributed system.

[0137] Specifically, after sending the service call request to the target node, a closed-loop feedback step is also included. First, the central server can generate a request forwarding result. This result includes, but is not limited to, key performance and reliability indicators such as: whether the service call request was successfully delivered, the target node's response status (e.g., HTTP status code), end-to-end processing latency, and error type (e.g., timeout, connection refusal, business exception).

[0138] Subsequently, the central server can send the request forwarding results to the monitoring service client. The monitoring service client can be deployed locally on the load balancer or run as a standalone microservice to receive and aggregate real-time feedback data from each forwarding operation.

[0139] Furthermore, the central server can return to the step of obtaining the status data of each distributed service node in the distributed system, forming a continuous closed-loop adaptive control process. Specifically, the monitoring service client can dynamically update the status data of the corresponding target node based on the forwarding results of newly received requests, combined with existing system resource indicators (such as CPU, memory, etc.). This updated status data can be reused for health analysis of distributed service nodes, maintenance of the list of effective service nodes, and load score calculation in the next routing decision.

[0140] Through this feedback mechanism, the central server can perceive the actual effect of service calls in real time. It not only relies on static resource indicators but also integrates application layer behavioral feedback (such as sudden increases in error rate and latency deterioration). This allows for more accurate identification of potentially overloaded or degraded distributed service nodes, enabling an intelligent evolution from passively eliminating faulty nodes to proactively avoiding performance-degraded nodes, and significantly improving the stability and service quality of the distributed system.

[0141] This application embodiment can divide an electronic device or main control device into functional modules according to the above method examples. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional module. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division; in actual implementation, there may be other division methods.

[0142] Figure 3 This is a schematic diagram of the structure of a request processing device for a distributed system provided in an embodiment of this application. Figure 3 As shown, the device includes: an acquisition module 310, a data processing module 320, a request receiving module 330, a node selection module 340, and a sending module 350.

[0143] The acquisition module 310 is used to acquire the status data of each distributed service node in the distributed system.

[0144] The data processing module 320 is used to obtain the health status identifier of each distributed service node based on the status data and the preset health data threshold.

[0145] The data processing module 320 is also used to obtain a list of valid service nodes in the distributed system based on the health status identifier.

[0146] The request receiving module 330 is used to receive service call requests sent by the caller.

[0147] The node selection module 340 is used to obtain the target node based on the preset routing algorithm and the list of valid service nodes.

[0148] The sending module 350 is used to send service call requests to the target node.

[0149] In one possible implementation, the health status of the distributed service node is identified as any one of healthy, unhealthy, or overloaded.

[0150] The data processing module 320 is also used to traverse the health status identifiers of each distributed service node.

[0151] The data processing module 320 is also used to add distributed service nodes with a healthy health status to the list of valid service nodes, and remove distributed service nodes with an unhealthy or overloaded health status from the list of valid service nodes.

[0152] In one possible implementation, the node selection module 340 is further configured to extract first state data corresponding to each healthy distributed service node based on the list of valid service nodes.

[0153] The node selection module 340 is also used to calculate the target load score corresponding to each healthy distributed service node based on the first state data and the preset routing algorithm.

[0154] The node selection module 340 is also used to select the distributed service node with the highest target load score from the list of valid service nodes as the target node.

[0155] In one possible implementation, the first state data includes processor utilization, memory usage, current active connections, and request error rate.

[0156] The node selection module 340 is also used to normalize the processor utilization rate, memory usage rate, current active connection count and request error rate in the first state data to obtain the second state data corresponding to each healthy distributed service node.

[0157] The node selection module 340 is also used to perform weighted summation on the second state data according to preset weight coefficients to obtain a preliminary load score.

[0158] The node selection module 340 is also used to, if the preset routing algorithm is a regional affinity algorithm, add an affinity score to the corresponding preliminary load score for distributed service nodes that are in the same region as the caller, to obtain the target load score.

[0159] The node selection module 340 is also used to use the preliminary load score as the target load score for distributed service nodes that are not in the same region as the caller.

[0160] In one possible implementation, the node selection module 340 is further configured to, if the preset routing algorithm is a session persistence algorithm, query the mapping relationship between the caller's historical sessions and each distributed service node in the list of valid service nodes based on the session identifier carried in the service call request.

[0161] The node selection module 340 is also used to add an association score to the distributed service node associated with the caller's historical session if there is a distributed service node in the list of valid service nodes that is associated with the caller's historical session, so as to obtain the target load score.

[0162] The node selection module 340 is also used to use the preliminary load score as the target load score for distributed service nodes that have no association with the caller's historical sessions.

[0163] In one possible implementation, the device further includes a closed-loop feedback module.

[0164] The closed-loop feedback module is used to generate request forwarding results.

[0165] The closed-loop feedback module is also used to send the request forwarding result to the monitoring service client and return the steps for obtaining the status data of each distributed service node in the distributed system.

[0166] This embodiment provides a request processing device for a distributed system, which can execute a request processing method for a distributed system in the above embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0167] In the aforementioned specific implementation of a request processing device for a distributed system, each module can be implemented as a processor, and the processor can execute computer execution instructions stored in the memory, thereby enabling the processor to execute the aforementioned request processing method for a distributed system.

[0168] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device includes at least one processor 410 and a memory 420. The electronic device also includes a communication component 430. The processor 410, memory 420, and communication component 430 are connected via a bus 440.

[0169] In the specific implementation process, at least one processor 410 executes computer execution instructions stored in memory 420, causing at least one processor 410 to execute a request processing method for a distributed system as executed on the electronic device side as described above.

[0170] The specific implementation process of processor 410 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0171] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0172] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage.

[0173] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0174] The above description of the functions implemented by electronic devices and main control devices has introduced the solutions provided by the embodiments of the present invention. It is understood that, in order to implement the above functions, the electronic device or main control device includes hardware structures and / or software modules corresponding to the execution of each function. By combining the units and algorithm steps of the various examples described in the embodiments of the present invention, the embodiments of the present invention can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the technical solutions of the embodiments of the present invention.

[0175] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the request processing method for a distributed system described above.

[0176] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0177] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in an electronic device or a host device.

[0178] This application also provides a computer program product, which includes a computer program stored in a readable storage medium. At least one processor of an electronic device can read the computer program from the readable storage medium, and the at least one processor executes the computer program to cause the electronic device to perform the solution provided in the above embodiments.

[0179] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disk, or optical disk.

[0180] The technical solutions of this application have been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it is readily understood by those skilled in the art that the scope of protection of this application is obviously not limited to these specific embodiments. The above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A request processing method for a distributed system, characterized in that, include: Obtain the status data of each distributed service node in the distributed system; Based on the status data and the preset health data threshold, the health status identifier of each of the distributed service nodes is obtained; Based on the health status identifier, a list of valid service nodes in the distributed system is obtained; Receive service call requests sent by the caller; The target node is obtained based on the preset routing algorithm and the list of valid service nodes; The service call request is sent to the target node.

2. The method according to claim 1, characterized in that, The health status of the distributed service node is identified by any one of the following: healthy, unhealthy, or overloaded. The step of obtaining the list of valid service nodes in the distributed system based on the health status identifier includes: Iterate through the health status identifiers of each distributed service node; Add distributed service nodes whose health status is marked as healthy to the list of valid service nodes, and remove distributed service nodes whose health status is marked as unhealthy or overloaded from the list of valid service nodes.

3. The method according to claim 1, characterized in that, The step of obtaining the target node based on the preset routing algorithm and the list of valid service nodes includes: Based on the list of valid service nodes, extract the first state data corresponding to each healthy distributed service node; Based on the first state data and the preset routing algorithm, calculate the target load score corresponding to each healthy distributed service node; Select the distributed service node with the highest target load score from the list of valid service nodes as the target node.

4. The method according to claim 3, characterized in that, The first status data includes processor utilization, memory usage, current active connections, and request error rate; The step of calculating the target load score for each healthy distributed service node based on the first state data and the preset routing algorithm includes: The processor utilization rate, memory usage rate, current active connection count, and request error rate in the first state data are normalized to obtain the second state data corresponding to each healthy distributed service node. The second state data is weighted and summed according to preset weighting coefficients to obtain a preliminary load score; If the preset routing algorithm is a region affinity algorithm, then for distributed service nodes located in the same region as the caller, an affinity score is added to the corresponding preliminary load score to obtain the target load score; For distributed service nodes that are not located in the same region as the caller, the preliminary load score is used as the target load score.

5. The method according to claim 4, characterized in that, Also includes: If the preset routing algorithm is a session persistence algorithm, then based on the session identifier carried in the service call request, the mapping relationship between the caller's historical sessions and each distributed service node in the list of valid service nodes is queried. If there are distributed service nodes in the list of valid service nodes that are associated with the caller's historical sessions, then for the distributed service nodes associated with the caller's historical sessions, an association score is added to the corresponding preliminary load score to obtain the target load score. For distributed service nodes that are not associated with the caller's historical sessions, the preliminary load score is used as the target load score.

6. The method according to any one of claims 1 to 5, characterized in that, After sending the service call request to the target node, the process further includes: Generate request forwarding results; The request forwarding result is sent to the monitoring service client, and the step of obtaining the status data of each distributed service node in the distributed system is returned.

7. A request processing apparatus for a distributed system, characterized in that, include: The acquisition module is used to acquire the status data of each distributed service node in the distributed system. The data processing module is used to obtain the health status identifier of each of the distributed service nodes based on the status data and the preset health data threshold. The data processing module is further configured to obtain a list of valid service nodes of the distributed system based on the health status identifier. The request receiving module is used to receive service call requests sent by the caller; The node selection module is used to obtain the target node based on the preset routing algorithm and the list of valid service nodes; The sending module is used to send the service call request to the target node.

8. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 6.

Images