Micro-service chemical order processing system and method based on dynamic load balancing

Abstract

The invention discloses a micro-service work order processing system and method based on dynamic load balancing, and relates to the technical field of micro-services, the system is applied to a micro-service architecture, and the system comprises an event monitoring module for monitoring an instance life cycle event flow of a containerized management layer in real time, and sending the event flow to a server; determining a logic relationship of the micro-service instance and a state attribute of the logic relationship according to the instance life cycle event stream; the intelligent decision module is used for determining a candidate instance set according to the real-time load indexes of the micro-service instances when a work order task request is received; removing the micro-service instances which are in the replacement relationship and have closed state attributes from the candidate instance set to obtain a security candidate instance set; determining a target micro-service instance based on the real-time load index of each instance in the security candidate instance set; and sending the work order task request and the target micro-service instance to a load balancing layer. According to the invention, the allocation capability of the load balancer to the work order task request in the micro-service architecture is improved.

Description

Technical Field

[0001] This invention relates to the field of microservices, and in particular to a microservice-based chemical single-processing system and method based on dynamic load balancing. Background Technology

[0002] The basic workflow of a distributed system includes service registration, state synchronization, and traffic scheduling. When a new instance starts, it sends a registration request to a service registry (such as Nacos / Consul) to declare its network address and availability. The registry synchronizes the new instance's information with the load balancer, a process inherently involving network transmission and data processing latency (typically on the order of seconds). The load balancer distributes requests based on its locally cached service list. Because the load balancer's awareness of the start or stop status of each microservice instance needs to be synchronized through the registry, there is a brief time lag between the actual state of a service instance (started / terminated) and the state perceived by the load balancer. During this time window, the service list held by the load balancer is outdated.

[0003] Load balancers are prone to lag in their awareness of the status of microservice instances, potentially routing current task requests to older instances that are about to go offline or are overloaded. This can lead to lost task requests for work orders, the generation of incomplete or corrupted work orders in the backend, and load balancer failure. Especially at the moment of instance shutdown, load balancers have a very high probability of making incorrect decisions.

[0004] Therefore, how to improve the load balancer's ability to allocate work order requests in a microservice architecture has become an urgent technical problem to be solved. Summary of the Invention

[0005] The technical problem solved by this invention is that the load balancer in a microservice architecture needs to improve its ability to allocate work order task requests.

[0006] To address the aforementioned technical problems, this invention provides the following technical solution: On one hand, it provides a microservice-based work order processing system based on dynamic load balancing. This system is applied to a microservice architecture, which includes a load balancing layer, multiple microservice instances, and a containerized management layer. The system includes: an event monitoring module, which monitors in real-time the instance lifecycle event stream generated by instance state changes in the containerized management layer, and determines the logical relationship between microservice instances and the state attributes of that logical relationship based on the event sequence in the instance lifecycle event stream; and an intelligent decision-making module, which, upon receiving a work order request, determines a candidate instance set based on the real-time load metrics of the microservice instances; removes microservice instances in a replacement relationship with a closed state attribute from the candidate instance set to obtain a safe candidate instance set; determines the target microservice instance based on the real-time load metrics of each instance in the safe candidate instance set; and sends the work order request and the target microservice instance to the load balancing layer.

[0007] Preferably, the event listening module is further configured to: parse the instance lifecycle event stream to obtain an event sequence; if the event sequence includes a creation event of a first microservice instance, and within the first preset time window corresponding to the creation event, the event sequence also includes a termination event of a second microservice instance, and the first microservice instance and the second microservice instance have the same service identifier and version tag, then the first microservice instance and the second microservice instance are determined as an instance replacement pair; the instances in the instance replacement pair are used as nodes in the instance relationship graph, an edge is established from the second microservice instance node to the first microservice instance node, the type attribute of the edge is set to replacement relationship, and the status attribute is set to closed.

[0008] Preferably, the event listening module is further configured to generate a construction signal for instance replacement pairs; the intelligent decision-making module is further configured to: respond to the construction signal, collect historical request logs of the second microservice instance within a second preset time window; parse the historical request logs, extract the request path distribution, request body size distribution, and key request parameters contained in the historical request logs, and obtain a first historical request feature vector; determine a simulated request sequence containing multiple simulated work order requests based on the first historical request feature vector, the simulated request sequence being used to simulate real work order business requests; continuously send the simulated request sequence as exploratory traffic to the first microservice instance for warm-up; collect the resource usage of the first microservice instance when processing the simulated request sequence, and plot a resource usage curve; compare the resource usage curve with a preset standard warm-up completion curve for similarity; if the similarity is less than a first preset similarity threshold, continuously send exploratory traffic to the first microservice instance until the similarity is greater than or equal to the first preset similarity threshold, thus completing the warm-up of the first microservice instance.

[0009] Preferably, the event listening module is further configured to: identify microservice instances with the same service identifier but different version tags as family instances; create multiple family nodes in the instance relationship graph for multiple microservice instances that are family instances; create family group nodes in the instance relationship graph based on multiple family nodes; connect multiple family nodes to family group nodes; collect work order task requests processed by multiple microservice instances corresponding to family group nodes within a preset historical period; determine the original hash key based on the business identifier in each work order task request to obtain a set of original hash keys corresponding to family group nodes; perform vectorization embedding processing on each hash key in the original hash key set to obtain multiple first hash key vectors that correspond one-to-one with multiple hash keys; perform cluster analysis on the multiple first hash key vectors and define each cluster formed by clustering as a data shard; generate a data shard identifier corresponding to the data shard; determine the center vector of each cluster as the mathematical representation of the data shard; and store the data shard identifier of each data shard and its corresponding mathematical representation as attributes in the family group nodes in the instance relationship graph.

[0010] Preferably, the target microservice instance is determined based on the real-time load metrics of each instance in the security candidate instance set, including: determining the current hash key based on the business identifier of the current work order task request; performing vectorization embedding processing on the current hash key to obtain the current first hash key vector; determining the cosine similarity between the current first hash key vector and the mathematical representation of each data shard in the instance relationship graph; determining the same group node corresponding to the data shard with the highest cosine similarity as the target same group node; determining the microservice instance that is simultaneously located in the security candidate instance set and is connected to the target same group node as a node as a priority candidate instance; and determining the target microservice instance from multiple priority candidate instances based on the real-time load metrics.

[0011] Preferably, the event listening module is further configured to: extract multiple work order task requests that are jointly accessed in a single transaction from the historical task request log; generate a second historical request feature vector for each extracted work order task request based on the request path distribution, request body size distribution, and key request parameters contained in the work order task request; perform vector similarity clustering on the second historical request feature vectors of multiple work order task requests; aggregate work order task requests with vector similarity higher than a second preset similarity threshold into a traffic pattern cluster; perform vectorized embedding processing on the business identifiers of work order task requests within the traffic pattern cluster to obtain a second hash key vector; match the second hash key vector with the mathematical representations of each data shard stored in the instance relationship graph to determine the data shard to which each business identifier belongs; and in the instance relationship graph, establish traffic affinity edges between nodes corresponding to multiple data shards belonging to the same traffic pattern cluster, determine the mean vector of the second historical request feature vectors within the traffic pattern cluster, and determine the mean vector as the attribute of the traffic affinity edge.

[0012] Preferably, the system further includes a distributed link tracing module; the distributed link tracing module is used to capture the call path information of a work order task request when it spans multiple microservice instances. The call path information includes the call initiator, receiver, call timestamp, and time consumption. The event listening module is also used to: identify multiple family group nodes involved in the call path information and the call relationships between the multiple family group nodes involved; construct a service call topology subgraph based on the instance relationship graph, wherein the nodes of the service call topology subgraph are the family group nodes involved, and the directed edges of the service call topology subgraph are used to indicate the call relationship from one family group node to another family group node. The attributes of the directed edges are set to the frequency of calls associated with the call relationship corresponding to the directed edge or the average response time of the call.

[0013] Preferably, the intelligent decision-making module is further configured to: monitor the real-time load metrics of sibling nodes in the service call topology subgraph; identify downstream sibling nodes pointed to by multiple directed edges of nodes in the service call topology subgraph as downstream sibling nodes, and identify such nodes as upstream sibling nodes of downstream sibling nodes; if the real-time load metrics of any first downstream sibling node exceed a preset fault threshold, mark the first upstream sibling node corresponding to the first downstream sibling node as a fault source, wherein the first downstream sibling node is the downstream node pointed to by the first upstream sibling node through a directed edge; starting from the data shard processed by the fault source, traverse the traffic affinity edges in the instance relationship graph, aggregate the data shards reachable by the traffic affinity edges, and obtain the affected data domain; starting from the sibling nodes corresponding to the data shards in the affected data domain, perform a reverse graph traversal in the service call topology subgraph, and identify multiple upstream sibling nodes corresponding to the endpoint as the upstream sibling node set; determine the risk propagation path based on the upstream sibling node set and the service call topology subgraph.

[0014] Preferably, the intelligent decision-making module is further used to: determine whether multiple nodes in the risk propagation path form instance replacement pairs in the instance relationship graph; if instance replacement pairs are formed, the target degradation strategy is determined to be the preheating protection mode; if no instance replacement pairs are formed, the target degradation strategy is determined to be the standard degradation mode.

[0015] Preferably, the intelligent decision-making module is further configured to: broadcast a degradation instruction to the microservice instance corresponding to the node on the risk propagation path, the broadcast degradation instruction including the affected data domain and the target degradation strategy; the microservice instance receiving the degradation instruction is configured to: determine whether the data shard to which the business identifier of the received real-time work order task request belongs belongs to the affected data domain; if it belongs to the affected data domain and the target degradation strategy is a preheating protection mode, then interrupt the call to the downstream microservice instance, enable local caching or return the preset default value; if it belongs to the affected data domain and the target degradation strategy is a standard degradation mode, then enable local caching and continuously send a simulated request sequence to the downstream microservice instance at a preset rate, and monitor the recovery status of the downstream microservice instance according to the simulated request sequence.

[0016] On the other hand, a microservice-based work order processing method based on dynamic load balancing is also provided. This method is applied to a microservice architecture, which includes a load balancing layer, multiple microservice instances, and a containerized management layer. The method includes: real-time monitoring of the instance lifecycle event stream generated by the containerized management layer due to instance state changes; determining the logical relationship between microservice instances and the state attributes of this logical relationship based on the event sequence in the instance lifecycle event stream; determining a candidate instance set based on the real-time load metrics of the microservice instances; removing microservice instances in a replacement relationship with a closed state attribute from the candidate instance set to obtain a safe candidate instance set; determining the target microservice instance based on the real-time load metrics of each instance in the safe candidate instance set; and sending the work order request and the target microservice instance to the load balancing layer.

[0017] The beneficial effects of this invention are as follows: By real-time monitoring of the instance lifecycle event stream generated by instance state changes in the containerization management layer, the logical relationship of microservice instances and the state attributes of this logical relationship are determined based on the event sequence in the instance lifecycle event stream. This allows bypassing the registry center by monitoring containerization layer events and identifying microservice instances that are being shut down based on the event sequence in the instance lifecycle event stream. Microservice instances in a replacement relationship with a shut-down state attribute are removed from the candidate instance set to obtain a safe candidate instance set. Based on the real-time load metrics of each instance in the safe candidate instance set, the target microservice instance is determined. The work order task request and the target microservice instance are sent to the load balancing layer to avoid identifying a microservice instance that is being shut down as the target microservice instance. In other words, it avoids the time difference between the actual state of the service instance and the state perceived by the load balancer, which could interfere with the load balancer's task request allocation, thereby improving the load balancer's ability to allocate work order task requests in the microservice architecture. Attached Figure Description

[0018] Figure 1 This is a schematic diagram illustrating an application scenario of a microservice chemical single-processing system based on dynamic load balancing, as provided in one embodiment of the present invention. Figure 2 This is a schematic diagram of the basic structure of a microservice chemical single-processing system based on dynamic load balancing, provided as an embodiment of the present invention. Detailed Implementation

[0019] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0020] Example 1, referring to Figures 1-2As an embodiment of the present invention, a microservice-based task processing system based on dynamic load balancing is provided. This system is applied to a microservice architecture, which includes a load balancing layer, multiple microservice instances, and a containerized management layer. The system includes: The event listening module monitors the instance lifecycle event stream generated by the containerization management layer due to instance state changes in real time, and determines the logical relationship of microservice instances and the state attributes of the logical relationship based on the event sequence in the instance lifecycle event stream. The intelligent decision-making module is used to: determine a set of candidate instances based on the real-time load metrics of microservice instances when a work order request is received; remove microservice instances that are in a replacement relationship and whose status attribute is closed from the set of candidate instances to obtain a set of safe candidate instances; determine the target microservice instance based on the real-time load metrics of each instance in the set of safe candidate instances; and send the work order request and the target microservice instance to the load balancing layer.

[0021] In a microservice architecture, the load balancing layer, multiple microservice instances, and the containerized management layer constitute the core runtime environment of a distributed system.

[0022] The load balancing layer serves as the unified traffic entry point for the microservice architecture. It receives requests from external servers and distributes them efficiently and evenly to multiple backend microservice instances according to a pre-defined load balancing strategy. This prevents any single instance from becoming overloaded due to excessive requests, thereby ensuring high throughput and high availability of the microservice architecture.

[0023] In a microservice architecture, a microservice instance is an independent running unit that actually executes specific business logic. For example, one instance may be dedicated to user authentication, while another focuses on order processing. They can be deployed, updated, and scaled independently.

[0024] The containerization management layer, such as a Kubernetes-based platform, is located at the bottom layer of the microservice architecture. It is used to automate the entire lifecycle management of all microservice instances, including instance creation, startup, destruction, and resource scheduling. It provides an isolated runtime environment for microservices and ensures the dynamic allocation of computing resources and the elastic scaling capability of the system.

[0025] The containerization management layer is the sole source of any state changes for microservice instances. When the system needs to perform operations such as service updates, scaling up, or scaling down, the containerization management layer proactively executes the corresponding actions, such as creating a new microservice instance or terminating an old one. Each operation that adjusts a microservice instance generates a standardized state event, and these state events are collected in real time to form a continuous data stream, resulting in the instance lifecycle event stream.

[0026] An event sequence is a series of events arranged in chronological order and with specific logical relationships in the event flow of an instance's lifecycle.

[0027] By analyzing event sequences, the system can infer the logical relationships between microservice instances. For example, if the system detects a termination event representing a first microservice instance within a very short time window, followed immediately by a creation event representing a second microservice instance, and these two instances have the same service identifier and version tag, the system can determine that this is an instance replacement operation.

[0028] Based on this, the system determines that there is a replacement relationship between the first microservice instance and the second microservice instance. At the same time, since the first microservice instance is being terminated, the state attribute of its logical relationship is marked as closed.

[0029] A work order is a data structure widely used across multiple business domains to record, track, and process a specific work task. For example, in IT operations, a work order can represent a server failure report; in customer service, it can be a user inquiry or complaint; and in manufacturing, it can be a product defect repair task.

[0030] A work order task request is a data packet that contains all relevant information about the work order (such as work order ID, type, detailed description, creator, etc.) and requests the system to process it.

[0031] In a typical microservice processing flow, a work order request first reaches the load balancing layer. The load balancing layer selects a microservice instance based on its built-in simple rules (such as round-robin or random algorithms), and then forwards the request to that instance, which then completes the specific business processing and returns the result.

[0032] However, this conventional process lacks real-time awareness of the actual state of instances, which may lead to incorrect request distribution. For example, an instance that is shutting down will inevitably have extremely low load, and a zombie instance that is stuck and unable to process requests may also have extremely low CPU and memory usage. Specifically: At time T0, the microservice instance Instance-X receives a shutdown command (e.g., `kubectl delete pod`); at time T0+0.1s, the Instance-X process begins the shutdown process. Instance-X first sends a deregistration request to the service registry (e.g., Nacos), and simultaneously stops receiving new business requests; at time T0+0.2s, a storage request arrives at the load balancer layer. Instance-X still exists in the load balancer's local cache (because the registry synchronization has a second-level delay). The load balancer collects the load metrics of each microservice instance at the current time and sends a probe request to Instance-X. Since Instance-X has only stopped receiving business requests, but its processes and monitoring ports (e.g., the ` / metrics` port) may still be running, Instance-X will return a very low load value; at time T0+0.3s, the load balancer's algorithm sees that Instance-X has the lowest load and perfectly assigns this new storage request to Instance-X. At time T0+0.4s, the request is sent to Instance-X and is either rejected outright or times out because Instance-X is no longer processing business logic, and the request fails. Therefore, at the moment the instance shuts down, the load balancer has a very high probability of making an incorrect decision.

[0033] Based on this, when allocating work order requests based on the load metrics of microservice instances, the registry center can be bypassed, and containerization layer events can be listened to to exclude microservice instances that are being shut down.

[0034] Specifically, after receiving a work order request, the intelligent decision-making module collects real-time load metrics for all currently available microservice instances. Real-time load metrics are key data for measuring the current workload of microservice instances, and typically include CPU utilization, memory utilization, network ingress and egress traffic, current number of connections being processed, request queue length, error rate, and average response time.

[0035] Based on real-time load metrics, the system performs initial screening to form a candidate instance set. This candidate instance set includes all currently running instances that are theoretically capable of handling new requests.

[0036] The system further queries the instance relationship information maintained by the event listening module, removing all instances in the candidate set that are in a replacement relationship and whose status attribute is off, thus obtaining a safe candidate instance set. Each instance in the safe candidate instance set is not only running, but also stable and trustworthy, fundamentally avoiding sending requests to an instance that is about to be destroyed.

[0037] When determining the set of candidate instances from all instances, real-time load metrics are used to exclude instances that are obviously overloaded or have failed; when determining the unique target microservice instance from the set of safe candidate instances, real-time load metrics are used for more granular selection, such as selecting the instance with the lowest current load among all instances that are in a safe state to achieve optimal resource utilization and the fastest response time.

[0038] Furthermore, regardless of whether a set of secure candidate instances can be successfully formed, the intelligent decision-making module remains the sole decision-making core throughout the entire decision-making process. The final target microservice instance is determined by the intelligent decision-making module based on its internal algorithms and logic. If the set of secure candidate instances is empty, the intelligent decision-making module will make a decision based on the original set of candidate instances; if the set of secure candidate instances is not empty, it will make a decision based on the set of secure candidate instances.

[0039] Therefore, the load balancing layer does not participate in any selection or judgment in this application. After the intelligent decision-making module completes its decision, it sends the work order request along with the address information of the target microservice instance to the load balancing layer, which then routes the work order request to the designated target microservice instance.

[0040] Preferably, the event listening module is further configured to: parse the instance lifecycle event stream to obtain an event sequence; if the event sequence includes a creation event of a first microservice instance, and within the first preset time window corresponding to the creation event, the event sequence also includes a termination event of a second microservice instance, and the first microservice instance and the second microservice instance have the same service identifier and version tag, then the first microservice instance and the second microservice instance are determined as an instance replacement pair; the instances in the instance replacement pair are used as nodes in the instance relationship graph, an edge is established from the second microservice instance node to the first microservice instance node, the type attribute of the edge is set to replacement relationship, and the status attribute is set to closed.

[0041] The instance lifecycle event stream is a collection of events generated by the containerization management layer throughout the entire lifecycle of a microservice instance. These events specifically include instance creation, startup, termination, deletion, and state updates.

[0042] The system subscribes to and receives raw event data streams from the containerized management layer through the event listening module. The data streams are typically serialized formats such as JSON or Protocol Buffers.

[0043] Before parsing, the raw event stream is a sequence of logically independent data packets arranged in chronological order, with each packet containing basic information about an event. After parsing, the raw data is transformed into a structured list of objects, each with clearly defined fields such as event type, timestamp, unique instance identifier, service identifier, and version tag. The event sequence is then a parsed and structured list of event objects ordered by time.

[0044] The system identifies creation and termination events by examining the event type field in the parsed event object. When the system determines that the value of this field of an event object is creation or a similar enumerated value, the event is identified as a creation event.

[0045] The first preset time window is a configurable time parameter whose specific duration (e.g., several seconds or several minutes) is set by the system administrator according to the characteristics of the deployment environment. For example, 10 seconds is used to determine whether two events logically belong to the same deployment operation.

[0046] The identification method for termination events is similar to that for creation events, that is, checking whether the event type field is termination or deletion.

[0047] The service identifier is used to define the service type to which the microservice instance belongs, such as order service or user service; the version tag identifies the specific code version of the service instance, such as v1.1 or v2.0.

[0048] When two instances have the same service identifier and version label, it means that they are completely interchangeable runtime units of the same service and version.

[0049] The identical service identifier and version tag ensure that the two instances are completely equivalent at the functional and code levels. The termination of the second microservice instance and the creation of the first microservice instance occur within a pre-defined tight time window, ruling out the possibility that the first and second microservice instances are two independent operations, indicating that they are consecutive steps under the same deployment intent. If all the above conditions are met, the first and second microservice instances can be identified as an instance replacement pair. An instance replacement pair is used to represent a rolling update or instance restart operation performed by the user at the containerization management layer.

[0050] Therefore, instance replacement pairs can characterize the transient state in a microservice architecture where an old microservice instance is replaced by a new, functionally identical instance, capturing the dynamic relationship of instance replacement during service deployment.

[0051] Preferably, the event listening module is further configured to generate a construction signal for instance replacement pairs; the intelligent decision-making module is further configured to: respond to the construction signal, collect historical request logs of the second microservice instance within a second preset time window; parse the historical request logs, extract the request path distribution, request body size distribution, and key request parameters contained in the historical request logs, and obtain a first historical request feature vector; determine a simulated request sequence containing multiple simulated work order requests based on the first historical request feature vector, the simulated request sequence being used to simulate real work order business requests; continuously send the simulated request sequence as exploratory traffic to the first microservice instance for warm-up; collect the resource usage of the first microservice instance when processing the simulated request sequence, and plot a resource usage curve; compare the resource usage curve with a preset standard warm-up completion curve for similarity; if the similarity is less than a first preset similarity threshold, continuously send exploratory traffic to the first microservice instance until the similarity is greater than or equal to the first preset similarity threshold, thus completing the warm-up of the first microservice instance.

[0052] Warm up new microservice instances to address performance issues associated with cold starts.

[0053] When a brand-new microservice instance starts up and receives its first request, its underlying runtime environment (such as the Java Virtual Machine's just-in-time compiler, code cache, database connection pool, etc.) is not yet in its optimal state. Processing the initial request triggers a large number of initialization operations, which leads to extremely high latency and low processing throughput.

[0054] The warm-up process involves sending simulated, representative request traffic to the instance before it begins processing real business traffic, forcing it to complete time-consuming initialization work and enabling its resource usage and response performance to enter a stable and efficient operating state in advance.

[0055] The second preset time window is a configurable time parameter, the specific duration of which (e.g., the past hour or the past 24 hours) is set by the system administrator according to the periodic characteristics of the business.

[0056] The reason for collecting the historical request logs of the second microservice instance (i.e., the old instance that was replaced) in this window is that in the instance replacement logic, the new and old instances are completely equivalent in terms of functionality and the business roles they undertake.

[0057] Therefore, the request traffic recently processed by the old instance is the most accurate and realistic prediction of the traffic that the new instance will face.

[0058] Historical request logs contain request patterns, data distributions, and parameter combinations from real business scenarios, making the preheating traffic generated based on historical request logs highly targeted and effective, far superior to using random or general test traffic.

[0059] Historical request logs are detailed records generated by a microservice instance during runtime for every request it has processed. Each log entry typically includes a timestamp, HTTP request method, complete request URL, request headers, request body content, response status code, and processing time.

[0060] Historical request logs are typically collected by integrating a logging framework (such as Logback or Log4j) within the microservice, with the log information output to standard output. Subsequently, a log collection agent in the deployment environment (such as Fluentd or Logstash) captures the log information in real time and forwards it to a centralized log storage system (such as an Elasticsearch cluster) for unified storage and indexing. The intelligent decision-making module then queries this storage system to obtain the required historical request log data.

[0061] Request path distribution refers to the statistical results of the request frequency of different API interface endpoints, in order to reflect the call popularity of different business functions.

[0062] Request body size distribution is a statistic of the size of the HTTP body data of an incoming request, and it relates to the overhead of network transmission and memory serialization.

[0063] Key request parameters are those that significantly impact the execution path of business logic or the performance of database queries, such as keywords in search queries, page numbers and the number of pages per page in paginated queries. Extracting key request parameters helps determine request processing complexity and resource consumption.

[0064] The extraction process involves parsing the URLs and request body content in the logs, and matching and extracting the corresponding parameter values ​​and their frequencies according to the system's preset parameter configuration rules.

[0065] The extracted distributions and parameters are converted into the first historical request feature vector to transform unstructured log information into a structured numerical data format that can be directly processed by the algorithm.

[0066] The first historical request feature vector is essentially a highly condensed digital record of the workload carried by the old instance within a specific time window, used to characterize the traffic composition, data scale, and business characteristics of that workload.

[0067] The transformation process typically includes: performing one-hot encoding or frequency encoding on categorical data such as path distribution and parameter distribution; normalizing numerical data such as request body size; and finally concatenating all processed numerical features into a high-dimensional array in a predetermined order.

[0068] Determining the simulated request sequence based on the first historical request feature vector is a process of traffic reconstruction based on feature vectors. The intelligent decision-making module maintains a request template library containing structured templates for various requests supported by the service. The decision-making module parses the feature vectors; for example, the vector may indicate that "the request proportion of path A is 30%, and the proportion of path B is 70%", and "the request body size of path A is concentrated between 1KB and 5KB". Based on the above information, the module selects the corresponding templates from the template library proportionally and fills the template content according to the distribution characteristics (such as size and parameter values) defined in the vector, thereby generating a simulated request sequence that is highly consistent with the historical workload in terms of statistical characteristics.

[0069] The preset standard warm-up completion curve is an ideal performance curve used as a benchmark, which is usually drawn by performance engineers after conducting a large number of warm-up tests in a controlled environment.

[0070] The typical shape of the preset standard warm-up completion curve is as follows: at the beginning of the warm-up phase, resource utilization (such as CPU utilization) is at a relatively high peak due to initialization overhead. Subsequently, as cache warm-up, code compilation, and other tasks are completed, resource utilization gradually decreases and eventually stabilizes at a low, stable level. This curve represents the ideal performance evolution path of an instance from cold start to full readiness.

[0071] Resource usage refers to the real-time consumption of system resources such as computing, memory, network, and storage by a microservice instance when processing a simulated request sequence. This data is obtained through monitoring interfaces provided by the containerization management layer (such as cAdvisor or kubelet's metrics API) or through integration with monitoring systems such as Prometheus.

[0072] While sending simulated traffic, the intelligent decision-making module continuously collects these resource metrics at fixed time intervals (e.g., every second). When plotting the resource utilization curve, the module connects the collected time-series data points on a coordinate system, where the X-axis represents time and the Y-axis represents resource utilization (e.g., CPU percentage), thus forming a dynamically changing curve.

[0073] The first preset similarity threshold is used to characterize the critical point that distinguishes between the two states of an instance: "completed preheating" and "still in preheating".

[0074] Engineers will conduct multiple warm-up experiments to analyze the degree of deviation between the actual resource usage curve and the standard warm-up completion curve when the instance truly reaches a stable state. This deviation is usually quantified using similarity algorithms (such as cosine similarity or dynamic time warping).

[0075] The first preset similarity threshold is set as an empirical value that can effectively filter out instances that have not completed preheating, while maximizing preheating efficiency.

[0076] When the similarity between the two curves reaches or exceeds this threshold, there is sufficient confidence that the performance of the new instance has approached the ideal state and it is safe to start processing real traffic.

[0077] Preferably, the event listening module is further configured to: identify microservice instances with the same service identifier but different version tags as family instances; create multiple family nodes in the instance relationship graph for multiple microservice instances that are family instances; create family group nodes in the instance relationship graph based on multiple family nodes; connect multiple family nodes to family group nodes; collect work order task requests processed by multiple microservice instances corresponding to family group nodes within a preset historical period; determine the original hash key based on the business identifier in each work order task request to obtain a set of original hash keys corresponding to family group nodes; perform vectorization embedding processing on each hash key in the original hash key set to obtain multiple first hash key vectors that correspond one-to-one with multiple hash keys; perform cluster analysis on the multiple first hash key vectors and define each cluster formed by clustering as a data shard; generate a data shard identifier corresponding to the data shard; determine the center vector of each cluster as the mathematical representation of the data shard; and store the data shard identifier of each data shard and its corresponding mathematical representation as attributes in the family group nodes in the instance relationship graph.

[0078] Microservice instances with the same service identifier but different version tags are identified as family instances to logically unify the management of microservices belonging to the same business function but at different stages of evolution. In a microservice architecture, services are constantly iterated, updated, canary released, or A / B tested, resulting in the coexistence of multiple version instances.

[0079] In a dynamic, continuously delivering production environment, the design of family instances allows the system to perceive a holistic view of a service (such as "order service"), rather than only seeing scattered instances such as "order service v1.0" and "order service v1.1", thereby achieving unified management across versions.

[0080] The service identifier is used to identify the name of the microservice business function, such as "user-service" or "payment-service"; the version tag is used to identify the software version of a specific instance under the service identifier, following the semantic versioning specification (such as v1.0.0, v1.2.3), or it can be the hash value of a Git commit, the name of a feature branch, or a specific tag used for canary releases (such as "gray-v2.1").

[0081] By combining service identifiers and version tags, any specific microservice instance can be located. The existence of different version tags reflects different stages of the software development lifecycle. For example, v1.0 may be a stable version, v1.1 is a version that has fixed bugs, while "feature-new-checkout" is a version that is developing new features for A / B testing.

[0082] Create sibling nodes and sibling group nodes in the instance relationship graph to construct a hierarchical model structure that reflects the service structure of the real world.

[0083] Using raw instance nodes directly flattens the graph and fails to reflect the logical relationships between instances. Family nodes represent a specific microservice instance, while family group nodes serve as a higher-level abstraction, representing the entire service family.

[0084] Family group nodes are used to aggregate and manage common attributes and metadata of all their subordinate family nodes, such as data sharding information and overall traffic patterns for the service family. When operations or queries are needed on the entire order service, only the family group node needs to be interacted with, without having to traverse all versions of instance nodes.

[0085] Connecting a sibling node to a sibling group node is achieved by creating a directed edge in the graph from the sibling node to the sibling group node. The relationship type of this edge can be defined as either "belongs to" or "members". The edge's state attribute can be set to "active", "deprecated", "read-only", etc., to reflect the current state of the instance within the service family.

[0086] In graph queries, all member nodes can be easily traversed through the same family group node; during maintenance, when a new microservice instance (new version) is deployed, the system will create a same family node for it and automatically establish an edge pointing to the corresponding same family group node, thereby realizing dynamic updates of the graph.

[0087] The preset historical period is a configurable time length, such as the past 7 days or 30 days. Its setting needs to balance the representativeness and timeliness of the data. The choice of this period determines the range of data samples used for subsequent data analysis (such as generating data shards).

[0088] The preset historical period reflects the service's real business load and request patterns in the recent production environment. If the period is set too short, it may fail to capture periodic business fluctuations; if it is set too long, it may include outdated and irrelevant request patterns, thus affecting the accuracy of data sharding.

[0089] A work order request is a structured data object used to describe a task to be processed. It typically includes fields such as work order ID, request type, initiator, timestamp, business data body, and priority. Work order requests are usually collected by integrating logging or message queue interception mechanisms into microservice instances. Whenever a work order request is processed, its key information is captured and sent to a central data collection system. Data integrity is usually guaranteed through transactional message queues or at-least-once logging mechanisms, while real-time performance is ensured through stream processing platforms (such as Kafka), allowing data to be consumed as soon as it is generated.

[0090] The business identifier is a field in a work order task request used to uniquely identify the core business entity, such as order_id in an order system or customer_id in a customer system. The original hash key is determined based on the business identifier, which is usually achieved by applying a standard hash algorithm (such as SHA-256) to the identifier itself to generate a fixed-length, unique hash value.

[0091] Hash keys are used instead of business identifiers because hash keys have the characteristics of fixed length and uniform distribution, which facilitates subsequent mathematical processing (such as vectors and clustering), and can also play a certain role in desensitizing sensitive business identifiers.

[0092] The original hash keys are vectorized and embedded to convert discrete, unordered hash keys into continuous numerical vectors that can be used for mathematical calculations.

[0093] The first hash key vector is used to represent the semantics of the hash key in the historical request context, that is, the association between the hash key and other hash keys. Common vectorization methods include Word2Vec, Doc2Vec, or other graph embedding algorithms. These vectorization methods generate vectors by learning the patterns of hash keys in a large number of request log sequences. The model is trained based on a large number of collected historical ticket request logs, treating each hash key as a word and a complete request path or session as a sentence, to train a model that can capture its contextual relationships.

[0094] Cluster analysis typically employs partitioning clustering algorithms such as K-means. Clustering is chosen to form data shards because clustering algorithms can automatically group hash keys with similar vector characteristics (i.e., similar business request patterns) together to form a cluster, which naturally constitutes a logical data shard.

[0095] Clustering parameters, especially the number of clusters (K value), can be determined by business requirements (such as the desired number of database shards) or by analyzing the distribution characteristics of the data itself using statistical methods (such as the elbow rule and silhouette coefficient).

[0096] Data sharding is a logical partitioning of a dataset horizontally, with each shard containing a subset of the data. In this scheme, a data shard consists of a set of hash keys that are highly relevant to the business logic. Defining data sharding is fundamental to implementing distributed storage and parallel processing; it allows different data shards to be deployed on different physical nodes, thereby improving the overall throughput and scalability of the system.

[0097] Data sharding is closely related to the load of microservice instances. If a data shard becomes a hotspot, the load on the microservice instances that handle requests related to that shard will increase.

[0098] A data shard identifier is a string or number used to uniquely identify each data shard, such as a UUID or an incrementing integer with a specific prefix (e.g., "shard-order-001"). Its uniqueness is typically guaranteed by a central coordination service or through a global uniqueness check performed at the time of generation. This identifier is subsequently used for data routing. When a request arrives and its hash key is calculated, the system needs to determine which data shard that hash key belongs to. This can be done quickly by querying the mapping between the shard identifier and the hash key.

[0099] The cluster center vector is used as the mathematical representation of the data shard because it is the geometric center of all vectors within the cluster, and it best represents the overall characteristics of the cluster (i.e., the data shard). This representation can be used to quickly determine which data shard a new hash key might belong to, simply by calculating the distances between the new key's vector and each center vector.

[0100] The mathematical representation of data shards is relatively static and is only updated when data shards need to be recalculated (for example, when a significant change in business model renders the original clusters no longer applicable).

[0101] Data shard identifiers and their mathematical representations are stored as attributes in the same-family group nodes in the instance relationship graph to achieve centralized management and high accessibility of metadata. All data shard information about this service family is tightly coupled with its logical definition (same-family group nodes) to form a self-contained knowledge unit.

[0102] When a service family changes, such as adding a new data shard or a change in the characteristics of a shard, the system only needs to update the attributes on nodes in the same family group, without modifying other parts of the graph.

[0103] Traditional algorithms often focus only on the real-time health and load of instances, neglecting the correlation between request content and instance processing capabilities. This means that an instance that has just completed a rolling update and whose cache is still empty, while having the lowest load, may perform poorly when handling a complex request. Therefore, the key is to route an incoming request not only to an instance with a currently low load but also to an instance that has a historical advantage and higher efficiency in handling that specific type of request. By combining the correlation between request content and instance processing capabilities with real-time load balancing, we can achieve smarter and more efficient request distribution, maximizing overall processing performance while ensuring system stability.

[0104] Preferably, the target microservice instance is determined based on the real-time load metrics of each instance in the security candidate instance set, including: determining the current hash key based on the business identifier of the current work order task request; performing vectorization embedding processing on the current hash key to obtain the current first hash key vector; determining the cosine similarity between the current first hash key vector and the mathematical representation of each data shard in the instance relationship graph; determining the same group node corresponding to the data shard with the highest cosine similarity as the target same group node; determining the microservice instance that is simultaneously located in the security candidate instance set and is connected to the target same group node as a node as a priority candidate instance; and determining the target microservice instance from multiple priority candidate instances based on the real-time load metrics.

[0105] The business identifier is converted into a hash key, and then further converted into a vector. This addresses the problem that the raw data cannot be directly used for mathematical calculations and pattern matching. Directly using the raw business identifier (such as an order number string) cannot measure the business similarity between two orders. Converting it to a hash key first provides a unified, fixed-length numerical representation, facilitating fast indexing and comparison.

[0106] However, the randomness of hash keys disrupts the semantic association of the original identifiers. Therefore, further vectorized embedding processing is used to map hash keys to a high-dimensional vector space. Requests with similar business patterns will have their vectors located close to each other in the space. This transforms unstructured, discrete business identifiers into continuous feature vectors that can be mathematically processed (such as calculating similarity) and contain business semantics, thus providing a data foundation for subsequent intelligent routing decisions.

[0107] The first hash key vector is generated using a pre-trained vectorized embedding model. This model typically employs algorithms similar to Word2Vec or Node2Vec, and its training data comes from the sequence of business identifiers of all work order requests processed by the microservice within a preset historical period. During training, the model treats each business identifier (or its hash key) as a node in a graph, and the sequence of identifiers in a complete business process or session as a path. By learning these paths, the model can capture the co-occurrence relationships and contextual dependencies between different business identifiers. The resulting vector, where each dimension represents the coordinates of the business identifier in a certain business feature space, collectively represents the semantic role or functional category of the request within the overall system business model.

[0108] Identifiers themselves, such as hash keys, are essentially arbitrary, meaningless sequences of characters that contain no inherent information about the business type they represent. However, semantic associations do not originate from the identifiers themselves, but rather from their observable behavioral patterns throughout the system workflow. Specifically, when a business identifier (e.g., an order ID) frequently appears alongside other identifiers (e.g., a payment ID, a logistics ID) during processing, the system can infer that these identifiers are logically related. To quantify and leverage this complex network of associations, the system employs a vectorized embedding model. This model learns by analyzing massive sequences of historical business identifiers, with the training objective of predicting an identifier based on its context (i.e., other identifiers that co-occur with it).

[0109] During training, the model is forced to map identifiers with similar co-occurrence patterns to positions close to each other in a high-dimensional vector space. Therefore, the final generated vectors are no longer random representations of the original identifiers, but rather dense mathematical encodings of their business semantics.

[0110] The distance or angle between vectors directly reflects the semantic similarity of the business identifiers they represent in the real world. It is in this way that calculable and measurable semantic relationships are established between originally isolated identifiers.

[0111] Cosine similarity is chosen as the matching criterion. The direction of the vector represents the business feature type of the request, while the magnitude of the vector is related to the frequency or amount of data of that type of request.

[0112] Using cosine similarity can effectively filter out interference caused by different request volumes, focusing on comparing whether two requests are similar in business nature. Compared to Euclidean distance, cosine similarity can better determine pattern similarity in high-dimensional space, more accurately identifying which data shard with similar business characteristics the current request should belong to, thereby achieving precise routing based on content affinity.

[0113] If a microservice instance group (family group) handles a certain type of business request for a long time, its runtime environment (such as JIT compilation optimization, application-layer caching, database connection pool configuration, etc.) has already been deeply optimized for this type of request. Therefore, when the characteristics of a new request highly match that type of business, routing it to this specialized instance group can maximize the use of these established optimizations, resulting in lower latency and higher throughput.

[0114] In the graph, a connection refers to a directed edge from a sibling node representing a specific microservice instance to a sibling group node to which it belongs. The relationship type of this edge can be defined as either "belongs to" or "members". This connection relationship is automatically created and written into the instance relationship graph by the event listening module based on its service identifier and version tag when the microservice instance starts up and registers with the service registry.

[0115] In graph maintenance, when an instance goes offline, the node and its corresponding edges are marked as unavailable or removed from the graph. The graph database's query language allows for efficient searching of these connections; for example, it can quickly find all active member instances of a given family of nodes.

[0116] The strategy for ultimately determining the target microservice instance from priority candidate instances based on real-time load metrics typically involves selecting the instance with the lowest overall load. Real-time load metrics include CPU utilization, memory usage, network I / O bandwidth, disk I / O (IOPS), current active connections, and request queue length. These metrics are collected by a monitoring agent (such as Prometheus Exporter) deployed within the microservice instance and aggregated and reported by a containerization management layer (such as Kubernetes) or a dedicated monitoring system.

[0117] The intelligent decision-making module calculates a comprehensive load score for each priority candidate instance, for example, through a weighted summation, and assigns different weights to different metrics. If multiple instances have the same lowest load score, the system can use random selection or round-robin as the final decision rule to ensure that requests are evenly distributed among these optimal instances.

[0118] The system is based on intelligent load balancing, deeply integrating data affinity-based intelligent routing with traditional real-time load balancing. Compared to simple round-robin or least-connection algorithms, this system not only considers the current state of the instance but also the matching degree between the content of the request and the expertise formed during the instance's historical processing. By prioritizing the routing of requests to specialized instance groups that have handled similar business, cache hit rate and code execution efficiency can be significantly improved. At the same time, within the instance group, fine-grained scheduling is still performed based on real-time load, avoiding local overload caused by data hotspots.

[0119] If there are no instances in the set of safe candidate instances under the same family group node corresponding to the data shard most similar to the current request, or if the load of all instances exceeds the preset high load threshold, the system will initiate a degradation strategy.

[0120] First, the system attempts to expand the search scope by calculating the cosine similarity between the current request vector and the mathematical representation of the second most similar data shard, and checking if there are any available, reasonably loaded instances in the corresponding family of nodes. If all instances with data affinity are unavailable, the system will eventually fall back to the basic load balancing strategy, which involves selecting the optimal instance from the entire set of safe candidate instances (excluding instances in replacement relationships) based entirely on real-time load metrics to handle the request, thereby ensuring continuous service availability, even though this may sacrifice some performance gains from data affinity.

[0121] Preferably, the event listening module is further configured to: extract multiple work order task requests that are jointly accessed in a single transaction from the historical task request log; generate a second historical request feature vector for each extracted work order task request based on the request path distribution, request body size distribution, and key request parameters contained in the work order task request; perform vector similarity clustering on the second historical request feature vectors of multiple work order task requests; aggregate work order task requests with vector similarity higher than a second preset similarity threshold into a traffic pattern cluster; perform vectorized embedding processing on the business identifiers of work order task requests within the traffic pattern cluster to obtain a second hash key vector; match the second hash key vector with the mathematical representations of each data shard stored in the instance relationship graph to determine the data shard to which each business identifier belongs; and in the instance relationship graph, establish traffic affinity edges between nodes corresponding to multiple data shards belonging to the same traffic pattern cluster, determine the mean vector of the second historical request feature vectors within the traffic pattern cluster, and determine the mean vector as the attribute of the traffic affinity edge.

[0122] In a single transaction, multiple work order task requests accessed jointly refer to a series of interrelated background requests triggered by a single, atomic business operation during the system's processing of a complete operation. In a distributed system, a front-end user action, such as submitting an order, may trigger a series of service calls in the back-end, such as verifying inventory, creating payment records, and updating user points. These background requests collectively constitute all the activities required to complete the order submission transaction.

[0123] Defining a single transaction typically relies on a globally unique transaction identifier, which is passed through all requests initiated by that transaction, for example, through message headers or log metadata. The system parses historical task request logs to extract all request entries carrying the same transaction identifier, thus aggregating them into a set of requests within the same transaction. If the logs lack explicit transaction identifiers, the system can also use time-window-based inference rules, such as classifying multiple requests from the same source IP address that occur consecutively within a very short time interval (e.g., 500 milliseconds) as belonging to the same transaction; however, this method has lower accuracy.

[0124] Extracting common access requests allows us to move from analyzing isolated single requests to analyzing related request patterns, thereby uncovering the inherent logical relationships and data access patterns within the business process.

[0125] A single request can only reveal its own characteristics, while a group of requests that access each other can reveal their temporal dependencies, call chains, and data locality.

[0126] For example, analysis reveals that a "create user" request always follows a "initialize user permissions" request, or a "query order details" request is usually accompanied by a "query logistics information" request. This step is essential; skipping it prevents the system from understanding the request context, leading to isolated and inefficient processing of each request. This undermines the foundation for intelligent prediction, cache preheating, and routing optimization, ultimately resulting in a decline in overall system performance and response speed.

[0127] The second historical request feature vector is generated in the same way as the first historical request feature vector. Both are based on the distribution of request paths, the distribution of request body size, and key request parameters to quantify requests. However, their data sources, application scenarios, and ultimate goals are completely different.

[0128] The first historical request feature vector is generated from the request logs of a single microservice instance within a certain historical time period. Its purpose is to reproduce the typical load characteristics of the instance and to warm up new instances to a stable operating state. The second historical request feature vector, on the other hand, is generated from multiple requests accessed in a single transaction. Its purpose is to characterize the request patterns of a specific business process.

[0129] Vector similarity clustering typically employs the K-Means algorithm because it is computationally efficient when processing high-dimensional vector data and is easy to implement and extend. Before performing clustering, all second-historical request feature vectors need to be standardized or normalized to eliminate the interference of differences in units between different feature dimensions (such as request body size being in bytes while request path is an enumeration type) on the clustering results.

[0130] The dimensionality of the feature vectors in clustering depends on the number of key request parameters and the quantization granularity of the distribution of request paths and request body sizes, typically ranging from tens to hundreds of dimensions. The K-Means algorithm is chosen because it can quickly divide a large number of vectors into a predetermined number of clusters, each cluster representing a request pattern with similar characteristics.

[0131] The second preset similarity threshold is a filtering parameter used to refine clustering results. Its setting can be based on empirical values ​​derived from historical data statistics, or it can be a parameter that can be dynamically configured by the system administrator. This threshold measures the similarity between two request vectors within the same cluster. If the cosine similarity or Euclidean distance between two vectors is below this threshold, they are considered to belong to different patterns. The level of this threshold directly affects the granularity of traffic pattern clusters: a higher threshold results in fewer, more compact clusters, meaning only requests with highly consistent features will be classified into the same pattern; while a lower threshold results in more, looser clusters, capturing a wider range of request patterns, but may introduce noise.

[0132] Traffic pattern clusters characterize a set of requests that are highly similar in business logic or data access behavior. They depict the similarity patterns of request characteristics, rather than a strict temporal sequence. For example, a traffic pattern cluster might contain all order creation requests from different transactions. Although these requests occur at different times, their request paths, request body sizes, and key parameter structures are very similar. It reflects what these requests look like, not the order in which they occur. By identifying these clusters, the system can abstract typical business operation patterns.

[0133] After vectorizing the business identifiers within the traffic pattern cluster, the mathematical representation of the data shards is matched. The purpose is to establish a mapping relationship between request behavior patterns and data storage locations, thereby indicating the data shards that are typically accessed when the system processes a certain type of request pattern.

[0134] By matching the hash key vector representing a business pattern with the mathematical representation representing the location of a data shard, the system can infer the core data set associated with that pattern. This association can solve the problem of data locality optimization. For example, the system can use this to perform intelligent cache preloading, or when scheduling tasks, prioritize matching instances that process the pattern with the physical nodes that store the relevant data to reduce network transmission latency.

[0135] Traffic affinity edges are a special type of relationship defined in the instance relationship graph, connecting data shard nodes. The purpose of establishing this edge is to explicitly represent a strong association between two or more data shards, meaning they are frequently accessed by requests contained in the same traffic pattern cluster; the edge's attribute, namely the mean vector of all request feature vectors within that traffic pattern cluster, is a quantitative description of this association pattern.

[0136] The mean vector can be seen as a prototype feature of this traffic pattern. Subsequently, when a new request arrives, the system can quickly compare its feature vector with the mean vector attribute of the traffic affinity edge. If the similarity is high, the system can predict that the request is likely to access all data shards connected by this edge, thereby triggering corresponding optimization operations, such as prefetching data or adjusting the routing strategy.

[0137] The mean vector of the second historical request feature vector within a traffic pattern cluster is used as an attribute of the traffic affinity edge because this mean vector is the most core and condensed mathematical representation of that traffic pattern. It provides a computable and comparable feature signature for the entire edge. When the system needs to make decisions, such as determining whether a new request belongs to a known traffic pattern, it does not need to retrace all vectors within the entire cluster; it only needs to compare them with the mean vector stored on the edge, greatly improving the efficiency of querying and matching. This attribute makes the relationships in the graph no longer simple connections, but carries rich semantic information, making the graph a knowledge base capable of complex reasoning and prediction.

[0138] By mining traffic affinity relationships, the system can achieve performance improvement at multiple levels: First, at the cache level, intelligent preheating can be achieved. When a request pattern is recognized, the system can preload the data shards it may access in advance, thus significantly improving the cache hit rate. Second, at the routing level, intelligent scheduling based on data affinity can be realized, and requests can be preferentially distributed to instances that have already cached relevant data or are physically closer, reducing response latency. Finally, at the architecture level, through visual traffic affinity edges, developers and operators can clearly identify the implicit data dependencies and coupling relationships between services, providing data-driven decision support for the continuous optimization and evolution of the system architecture.

[0139] In a microservices architecture, an external request often needs to be completed through the cooperation of multiple independent microservices, which makes it very complex to analyze system behavior. Although the instance relationship graph and event listening module can reflect the life cycle and logical relationships of individual instances, it is difficult to track the complete flow path of a request within the system. For example, when the system encounters performance problems or errors, it is very difficult to quickly determine which specific service link is in trouble. Therefore, a distributed tracing module is introduced. By assigning a unique trace ID to each request and recording the call context in each service it passes through, the originally scattered call points are concatenated into a complete call chain to solve problems that were previously difficult to handle, such as cross-instance performance bottleneck location, service dependency relationship sorting, and root cause of failure location, thus providing end-to-end observability for the system. Preferably, the system further includes a distributed tracing module; the distributed tracing module is used to capture the call path information when a work order task request crosses multiple microservice instances, and the call path information includes the call initiator, receiver, call timestamp, and elapsed time; the event listening module is further used to: identify multiple同族组 nodes involved in the call path information and the call relationships between the multiple同族组 nodes involved; construct a service call topology subgraph according to the instance relationship graph, where the nodes of the service call topology subgraph are the同族组 nodes involved, and the directed edges of the service call topology subgraph are used to indicate the call relationship from one同族组 node to another同族组 node, and the attribute of the directed edge is set to the frequency of the call or the average response time of the call associated with the call relationship corresponding to the directed edge.

[0140] The capture of the call path is generally achieved by embedding lightweight probes in the business code, and such probes usually follow industry standards such as OpenTelemetry or SkyWalking.

[0141] It should be noted that the term "同族组" in the original text seems to be an incorrect or unclear expression. It may need to be further clarified or corrected in the original content for a more accurate translation.When a request enters a service, the probe generates a Span to record information such as the operation start time, service name, and instance name. When this service calls a downstream service, the probe passes the tracking ID and parent Span ID through HTTP headers or message metadata, and the downstream service creates a new child Span accordingly. Probes typically capture information at the method level or RPC call level, accurately recording the interaction process between services. To minimize the impact on business performance, probes usually work asynchronously, recording only necessary metadata and not collecting large amounts of data such as request or response bodies. Furthermore, by leveraging service meshes such as Istio's sidecar proxy, automatic collection of link information can be achieved without modifying business code.

[0142] The caller and callee recorded in the call path are logical service identifiers. For example, when the order service calls the payment service, it is recorded as "order-service" to "payment-service," not specific IPs and ports. Simultaneously, the probe also records the specific instance information handling the request, such as "order-service-v2-pod-xyz." The event listening module relies on these logical service names and version tags to identify family members involved in the call path. It queries the instance relationship graph to find the corresponding family members based on the service name and version tag. If an instance in the call chain does not belong to any defined family group, the system can treat it as an unclassified node, displaying it in a special style in the topology subgraph, or assigning it to a default group according to rules, thus maintaining the integrity of the topology structure.

[0143] The core objective of building this subgraph is to provide a high-level view of system dependencies, facilitating dependency analysis, performance bottleneck identification, and architecture optimization. For example, architects can use this view to quickly locate critical paths and core services, while operations personnel can use it to assess the impact of failures and conduct capacity planning.

[0144] In the service call topology subgraph, the directed edges are usually selected with call frequency and average response time as key attributes, because these two indicators are the core quantitative basis for measuring the health and efficiency of inter-service interactions.

[0145] Call frequency refers to the number of times one service calls another within a unit of time, reflecting the strength of dependencies between services and their business importance; average response time reflects the performance of the called service. Selecting these two attributes can intuitively reveal performance bottlenecks and high-traffic paths in the system. While metrics such as error rate or throughput are also valuable, they are usually used as supplementary indicators and can be further obtained through logs or monitoring systems when needed. In practical analysis, call frequency is often used for capacity planning and core service identification, while average response time is directly used for performance monitoring and anomaly alerts.

[0146] The service call topology subgraph employs a dynamic update mechanism, typically balancing real-time performance and resource overhead through incremental updates. The system does not refresh the entire graph in real-time for each request; instead, it sets a short-period aggregation window, such as 10 seconds. Within this window, the link tracing module collects information on all newly added call paths, calculates the changes in call frequency and average response time for each edge, and then applies these incremental updates to the topology graph. This near real-time update mechanism ensures data timeliness while avoiding the computational pressure caused by frequent graph reconstruction. Historical data is retained according to a configured period, such as 7 days; expired data is automatically cleaned up or transferred to low-cost storage.

[0147] The constructed service call topology subgraph serves multiple roles and systems. For developers and operations personnel, it can be rendered as a visual topology on a monitoring dashboard, displaying real-time call relationships, traffic volume, and health status between services. When the response time of an edge abnormally increases, that edge will be highlighted in red for rapid alerting. For intelligent decision-making systems, this topology graph is an important input for load forecasting and elastic scaling. For example, by analyzing the call frequency trend from the user service to the order service, future traffic peaks can be predicted, and target services can be scaled up in advance. In real-world scenarios, such as during a major promotional event, if the operations team discovers a surge in call frequency and deteriorating response time from the promotion service to the inventory service through monitoring the topology graph, they can quickly identify the inventory service as the bottleneck and scale it up in a timely manner to avoid system crashes.

[0148] Attribute data such as call frequency and average response time generally employ a hybrid storage strategy to balance query efficiency and scalability. The core structure of the topology subgraph, including the definitions of nodes and edges and their latest attribute values, is typically stored in a graph database, as graph databases excel at handling relational queries, such as finding all upstream services that call a particular service. Detailed historical time-series data for these attributes is stored in a time-series database. Edges in the graph database retain pointers or IDs to the corresponding data sequences in the time-series database. To query the response time curve of a service over the past 24 hours, the system first retrieves the edge ID from the graph database and then uses that ID to query the complete time series in the time-series database. This design ensures both topology query efficiency and leverages the advantages of time-series databases in data compression and historical data management. Historical data retention strategies can be configured in the time-series database; for example, high-precision data can be retained for 7 days, low-precision aggregated data for 1 year, and expired data can be automatically cleaned up to control storage costs.

[0149] Preferably, the intelligent decision-making module is further configured to: monitor the real-time load metrics of sibling nodes in the service call topology subgraph; identify downstream sibling nodes pointed to by multiple directed edges of nodes in the service call topology subgraph as downstream sibling nodes, and identify such nodes as upstream sibling nodes of downstream sibling nodes; if the real-time load metrics of any first downstream sibling node exceed a preset fault threshold, mark the first upstream sibling node corresponding to the first downstream sibling node as a fault source, wherein the first downstream sibling node is the downstream node pointed to by the first upstream sibling node through a directed edge; starting from the data shard processed by the fault source, traverse the traffic affinity edges in the instance relationship graph, aggregate the data shards reachable by the traffic affinity edges, and obtain the affected data domain; starting from the sibling nodes corresponding to the data shards in the affected data domain, perform a reverse graph traversal in the service call topology subgraph, and identify multiple upstream sibling nodes corresponding to the endpoint as the upstream sibling node set; determine the risk propagation path based on the upstream sibling node set and the service call topology subgraph.

[0150] Determining the preset fault thresholds is a hybrid process combining static configuration and dynamic adjustment. The system sets a basic static threshold for each node in a family of nodes based on its Service Level Objective (SLO), such as CPU utilization not exceeding 80% or P99 latency not exceeding 500 milliseconds. Simultaneously, the system continuously analyzes the node's load performance over a preset historical period (e.g., the past week) to calculate its load baseline. If the current load consistently deviates from the baseline, the system dynamically adjusts the thresholds, for example, temporarily relaxing the thresholds during peak business periods or tightening them during off-peak periods. This dynamic adjustment logic aims to avoid a large number of false alarms due to fixed thresholds, while ensuring timely alerts in genuine anomalies. Its core is to establish a flexible fault judgment standard that adapts to cyclical changes in business operations.

[0151] In a microservice architecture, downstream node overload rarely occurs in isolation; it is often caused by upstream nodes sending traffic beyond their processing capacity. For example, an upstream service might initiate a retry storm due to a code defect or send a large number of invalid requests downstream due to a logical error, both of which directly lead to downstream service overload. By marking upstream nodes as sources of failure, the system can quickly pinpoint the root cause of the problem, rather than simply addressing the surface symptoms (i.e., downstream overload). While this causal relationship is not absolute, and downstream services may also experience overload due to reasons such as memory leaks, in most scenarios, this upward tracing strategy effectively narrows down the scope of investigation and provides a clear intervention target for subsequent automatic remediation measures (such as rate limiting upstream).

[0152] Starting with the data shard processed by the faulty node, the system traverses the traffic affinity edges in the instance relationship graph to conduct an in-depth assessment of the impact scope. The impact of a node failure is not limited to that node itself but can propagate to other related business areas through data correlation. For example, if a microservice instance processing order data fails, based on the previously constructed traffic affinity edges, the system knows that requests accessing order data typically also access user and inventory data. Therefore, the purpose of this traversal operation is to identify all other data shards strongly correlated with the data processed by the faulty node, thereby predicting the potential business scope affected by the failure, such as user queries and inventory management functions, providing a basis for subsequent risk control and user notification decisions.

[0153] The traversal rule for traffic affinity edges employs a depth-limited breadth-first search (BFS) algorithm. The system starts from the data shard node corresponding to the fault source and visits all adjacent nodes reachable through traffic affinity edges, layer by layer. To avoid infinite loops in complex affinity networks, the algorithm sets a maximum traversal depth, for example, a maximum of 3 layers. Simultaneously, the system maintains a record table of visited nodes, ensuring that each node is visited only once in a single traversal. This design effectively controls computational overhead while ensuring sufficient coverage of the impact, preventing the algorithm from failing to terminate due to circular dependencies (such as A relating to B, B relating to C, and C relating to A).

[0154] An affected data domain specifically represents a logically interconnected set of multiple data shards. These shards, due to traffic affinity, are highly likely to be affected by the cascading impact of the same failure event. It represents a potential unit of business risk. By aggregating this data domain, the system can perform risk assessment and resource scheduling as a whole. For example, the system can calculate the total QPS of this data domain and assess the overall impact on the system if services throughout the domain are affected. Furthermore, this aggregated data domain information can guide subsequent backup and recovery strategies, ensuring that critical business data can be prioritized for recovery in the event of a disaster.

[0155] The specific algorithm for reverse graph traversal in the service call topology subgraph typically employs Breadth-First Search (BFS) because BFS can find all upstream nodes affecting the source of the fault layer by layer, making it ideal for analyzing the propagation path of risk. The traversal starts at all nodes in the same family corresponding to the previously determined affected data domain, and proceeds in the reverse direction along the edges of the call topology subgraph. The traversal stops when all root nodes without further upstream nodes are found, or when the traversal depth reaches a preset upper limit. This means the system will identify all services that directly or indirectly call the source of the fault, thus constructing a complete call chain graph.

[0156] The system first lists all complete call paths from the root node to the fault source node based on the results of the reverse graph traversal. Then, it assigns a risk weight to each directed edge on each path. This weight is calculated based on the edge's call frequency and average response time; for example, edges with higher call frequency and longer response times have higher risk weights. Finally, the system sums the risk weights of all edges on the path to obtain the total risk value for each path and sorts all paths from highest to lowest risk value. In this way, the system not only identifies the propagation paths of risk but also quantifies the degree of danger of different paths, thus helping operations personnel prioritize the most critical call chains.

[0157] In real-world systems, failures can manifest in various ways, including but not limited to: service instances ceasing to respond due to resource exhaustion (e.g., CPU overload, memory overflow); service instances entering an infinite loop, causing CPU utilization to consistently reach 100%; service instances exhausting their connection pools with the database, unable to handle new requests; failures in external systems that service instances depend on (e.g., third-party payment gateways), resulting in numerous request timeouts; or service instances introducing serious program defects after deploying a new version, causing frequent exceptions when processing requests. The need to determine risk propagation paths arises precisely from the need to quickly understand the system boundaries that failures may affect, and to take precise isolation and recovery measures when these failures occur, in order to prevent the impact from expanding indefinitely.

[0158] Compared to conventional methods, this approach excels in the depth and breadth of its analysis. Conventional fault detection methods are typically limited to single services or instances, identifying problems by setting independent alarm thresholds. When a fault occurs, operations personnel rely on experience and manual troubleshooting to understand its impact, a time-consuming process prone to overlooking hidden dependencies. This approach, however, combines instance relationship graphs (data affinity) and service call topology subgraphs (call relationships) to construct a cross-level, global system view. It automatically starts from a single fault point, intelligently reasoning along data associations and call chains to accurately depict the risk propagation path and affected business domains. This graph-based association analysis method enables the system to discover implicit cross-service dependencies invisible in traditional monitoring views, achieving more accurate risk assessment and more effective automated intervention, significantly improving the system's self-healing capabilities and operational efficiency.

[0159] Preferably, the intelligent decision-making module is further used to: determine whether multiple nodes in the risk propagation path form instance replacement pairs in the instance relationship graph; if instance replacement pairs are formed, the target degradation strategy is determined to be the preheating protection mode; if no instance replacement pairs are formed, the target degradation strategy is determined to be the standard degradation mode.

[0160] Preferably, the intelligent decision-making module is further configured to: broadcast a degradation instruction to the microservice instance corresponding to the node on the risk propagation path, the broadcast degradation instruction including the affected data domain and the target degradation strategy; the microservice instance receiving the degradation instruction is configured to: determine whether the data shard to which the business identifier of the received real-time work order task request belongs belongs to the affected data domain; if it belongs to the affected data domain and the target degradation strategy is a preheating protection mode, then interrupt the call to the downstream microservice instance, enable local caching or return the preset default value; if it belongs to the affected data domain and the target degradation strategy is a standard degradation mode, then enable local caching and continuously send a simulated request sequence to the downstream microservice instance at a preset rate, and monitor the recovery status of the downstream microservice instance according to the simulated request sequence.

[0161] Once the system detects a risk propagation path, it will further determine whether there are instance replacement pairs between multiple nodes along that path in the instance relationship graph. The purpose of this determination is to assess whether the services along that path have high availability and rapid recovery capabilities.

[0162] The existence of instance replacement pairs means that when a service instance on the path fails, the system has a pre-warmed, functionally identical new instance ready to seamlessly take over its work. If such replacement pairs exist on the path, it indicates strong resilience, and the system can choose a more lenient degradation strategy that prioritizes protecting downstream services—the pre-warming protection mode. Conversely, if there are no replacement pairs on the path, it means that if a node fails, there will be no backup instance to replace it, and the system must take more decisive and aggressive measures to protect itself—the standard degradation mode.

[0163] After determining the target degradation strategy, the intelligent decision-making module broadcasts a degradation command to all microservice instances corresponding to nodes along the risk propagation path. This command contains two core pieces of information: first, the affected data domains identified through previous analysis; and second, the target degradation strategy determined for this instance.

[0164] Broadcast mechanisms typically employ a publish / subscribe pattern, such as through a message queue or the control plane of a service mesh, to quickly and reliably distribute instructions to every relevant instance along the path. The instruction format is standardized, ensuring that all instances can correctly parse and execute it, and its content clearly defines which business data requires special handling and what degradation behavior should be adopted.

[0165] Upon receiving a degradation command, a microservice instance enters a special degradation execution mode. It first checks the business identifier of the currently received real-time work order request and then determines whether the data to be processed by the request belongs to the affected data domain specified in the command by querying the data sharding mapping relationship stored in the instance relationship graph. This determination is a prerequisite for executing all subsequent degradation actions, ensuring that only requests related to the fault are specially handled, while unrelated normal business requests continue to be processed according to the original process, thereby minimizing interference with the overall system functionality.

[0166] If the assessment determines that the request belongs to the affected data domain and the target degradation strategy is warm-up protection mode, the microservice instance will take a circuit breaker-style protection measure. It will immediately interrupt any calls to downstream microservice instances to prevent the failure from spreading further downstream. Simultaneously, to provide basic services to the caller as much as possible, it will enable local caching. If the required data exists in the cache, it will return directly; otherwise, it will return a preset default value or a static response that conforms to business logic. The core of this mode is protection, sacrificing the integrity of some functions in exchange for the stability of the downstream system and the speed of fault isolation.

[0167] If the assessment determines that the request belongs to the affected data domain, but the target degradation strategy is the standard degradation mode, the microservice instance will adopt a more proactive and tentative recovery strategy. It will also enable local caching to handle requests to reduce pressure on downstream services. However, unlike the warm-up protection mode, it will not completely interrupt calls to downstream services. Instead, it will continuously send a pre-constructed sequence of simulated requests to downstream microservice instances at a preset, very low rate (e.g., 1 request per second). This simulated request sequence is generated by the system based on the service's historical request characteristics and can simulate real business requests. By monitoring the response status (e.g., response time, success rate) of downstream microservice instances handling these simulated requests, the system can detect in real-time and securely whether downstream services have returned to normal, providing a basis for decision-making regarding the subsequent full traffic recovery.

[0168] This application embodiment monitors the instance lifecycle event stream generated by instance state changes in the containerization management layer in real time. Based on the event sequence in the instance lifecycle event stream, it determines the logical relationship between microservice instances and the state attributes of that logical relationship. This bypasses the registry center by monitoring containerization layer events and identifies microservice instances that are being shut down based on the event sequence in the instance lifecycle event stream. Microservice instances in a replacement relationship with a "shutdown" state attribute are removed from the candidate instance set to obtain a safe candidate instance set. Based on the real-time load metrics of each instance in the safe candidate instance set, the target microservice instance is determined. The work order task request and the target microservice instance are sent to the load balancing layer to avoid identifying a microservice instance that is being shut down as the target microservice instance. In other words, it avoids the time difference between the actual state of the service instance and the state perceived by the load balancer, which could interfere with the load balancer's task request allocation, thereby improving the load balancer's ability to allocate work order task requests in the microservice architecture.

[0169] On the other hand, a microservice-based work order processing method based on dynamic load balancing is also provided. This method is applied to a microservice architecture, which includes a load balancing layer, multiple microservice instances, and a containerized management layer. The method includes: real-time monitoring of the instance lifecycle event stream generated by the containerized management layer due to instance state changes; determining the logical relationship between microservice instances and the state attributes of this logical relationship based on the event sequence in the instance lifecycle event stream; determining a candidate instance set based on the real-time load metrics of the microservice instances; removing microservice instances in a replacement relationship with a closed state attribute from the candidate instance set to obtain a safe candidate instance set; determining the target microservice instance based on the real-time load metrics of each instance in the safe candidate instance set; and sending the work order request and the target microservice instance to the load balancing layer.

[0170] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code. The 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 Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0171] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A microservice-based chemical order processing system based on dynamic load balancing, characterized in that, The system is applied to a microservice architecture, which includes a load balancing layer, multiple microservice instances, and a containerized management layer. The system includes: The event listening module monitors the instance lifecycle event stream generated by the containerization management layer due to instance state changes in real time, and determines the logical relationship of microservice instances and the state attributes of the logical relationship based on the event sequence in the instance lifecycle event stream. The intelligent decision-making module is used when a work order task request is received: The candidate instance set is determined based on the real-time load metrics of the microservice instances; Remove microservice instances that are in a replacement relationship and whose status attribute is closed from the candidate instance set to obtain a safe candidate instance set; The target microservice instance is determined based on the real-time load metrics of each instance in the set of security candidate instances. Send the work order task request and the target microservice instance to the load balancer layer.

2. The system as described in claim 1, characterized in that, The event listening module is also used for: The event sequence is obtained by parsing the instance lifecycle event stream; If the event sequence includes a creation event of a first microservice instance, and within the first preset time window corresponding to the creation event, the event sequence also includes a termination event of a second microservice instance, and the first microservice instance and the second microservice instance have the same service identifier and version tag, then the first microservice instance and the second microservice instance are determined as an instance replacement pair. Use the instances in the instance replacement pair as nodes in the instance relationship graph, establish an edge from the second microservice instance node to the first microservice instance node, set the type attribute of the edge to replacement relationship, and set the status attribute to closed.

3. The system as described in claim 2, characterized in that, The event listening module is also used to generate the construction signal for the instance replacement pair; The intelligent decision-making module is also used for: In response to the build signal, the historical request logs of the second microservice instance within a second preset time window are collected; The historical request logs are parsed to extract the request path distribution, request body size distribution, and key request parameters contained in the historical request logs, thereby obtaining a first historical request feature vector; Based on the first historical request feature vector, a simulated request sequence containing multiple simulated work order requests is determined, and the simulated request sequence is used to simulate real work order business requests; The simulated request sequence is continuously sent to the first microservice instance as exploratory traffic for warm-up; Collect the resource usage of the first microservice instance when processing the simulated request sequence, and plot the resource usage curve; The resource usage curve is compared with the preset standard preheating completion curve for similarity. If the similarity is less than a first preset similarity threshold, then exploratory traffic is continuously sent to the first microservice instance until the similarity is greater than or equal to the first preset similarity threshold, thus completing the warm-up of the first microservice instance.

4. The system as described in claim 3, characterized in that, The event listening module is also used for: Microservice instances with the same service identifier but different version labels are identified as family instances; Multiple microservice instances that are of the same family create multiple family nodes in the instance relationship graph; Based on the multiple sibling nodes, create a sibling group node in the instance relationship graph; Connect the plurality of sibling nodes to the sibling group nodes; Collect work order task requests processed by multiple microservice instances corresponding to the same family group nodes within a preset historical period; The original hash key is determined based on the business identifier in each work order task request, and the set of original hash keys corresponding to the nodes of the same family group is obtained. Each hash key in the original hash key set is vectorized and embedded to obtain multiple first hash key vectors that correspond one-to-one with the multiple hash keys. Cluster analysis is performed on the multiple first hash key vectors, and each cluster formed by the clustering is defined as a data partition; Generate a data fragment identifier corresponding to the data fragment; The center vector of each cluster is determined as the mathematical representation of that data partition; The data fragment identifier of each data fragment and its corresponding mathematical representation are stored as attributes in the same group nodes of the instance relationship graph.

5. The system as described in claim 4, characterized in that, The determination of the target microservice instance based on the real-time load metrics of each instance in the security candidate instance set includes: Determine the current hash key based on the business identifier of the current work order task request; The current hash key is vectorized and embedded to obtain the current first hash key vector; Determine the cosine similarity between the current first hash key vector and the mathematical representation of each data piece in the instance relationship graph; The nodes in the same family corresponding to the data segment with the highest cosine similarity are identified as the target nodes in the same family. The microservice instance that is simultaneously located in the set of security candidate instances and is connected as a node to the target family group node is determined as the priority candidate instance; The target microservice instance is determined from multiple priority candidate instances based on real-time load metrics.

6. The system as described in claim 5, characterized in that, The event listening module is also used for: Extract multiple work order task requests that were accessed in common within a single transaction from the historical task request log; For each extracted work order task request, a second historical request feature vector is generated based on the request path distribution, request body size distribution, and key request parameters contained in the work order task request. Perform vector similarity clustering on the second historical request feature vectors of the multiple work order task requests; Work order requests with vector similarity higher than the second preset similarity threshold are aggregated into traffic pattern clusters; The service identifier of the work order task request within the traffic pattern cluster is vectorized and embedded to obtain the second hash key vector; The second hash key vector is matched with the mathematical representation of each data shard stored in the instance relationship graph to determine the data shard to which each business identifier belongs; In the instance relationship graph, traffic affinity edges are established between nodes corresponding to multiple data shards belonging to the same traffic pattern cluster. The mean vector of the second historical request feature vector within the traffic pattern cluster is determined, and the mean vector is determined as the attribute of the traffic affinity edge.

7. The system as described in claim 6, characterized in that, The system also includes a distributed link tracing module; The distributed tracing module is used to capture the call path information of the work order task request when it crosses the multiple microservice instances. The call path information includes the call initiator, the receiver, the call timestamp, and the time consumed. The event listening module is also used for: Identify the multiple family group nodes involved in the call path information and the call relationships between the multiple family group nodes involved; A service call topology subgraph is constructed based on the instance relationship graph, wherein the nodes of the service call topology subgraph are the nodes of the same family group involved, the directed edges of the service call topology subgraph are used to indicate the call relationship from one family group node to another family group node, and the attribute of the directed edge is set to the frequency of the call or the average response time of the call associated with the call relationship corresponding to the directed edge.

8. The system as described in claim 7, characterized in that, The intelligent decision-making module is also used for: Monitor the real-time load metrics of nodes in the same family group in the service call topology subgraph; The nodes of the service call topology subgraph are identified as downstream same-family nodes by the downstream nodes pointed to by multiple directed edges, and these nodes are identified as upstream same-family nodes of the downstream same-family nodes. If the real-time load index of any first downstream same group node exceeds the preset fault threshold, the first upstream same group node corresponding to the first downstream same group node is marked as the fault source, wherein the first downstream same group node is the downstream node pointed to by the first upstream same group node through a directed edge. Starting with the data shard processed by the fault source, the traffic affinity edges in the instance relationship graph are traversed, and the data shards reachable by the traffic affinity edges are aggregated to obtain the affected data domain; Taking the same group node corresponding to the data shard in the affected data domain as the endpoint, perform reverse graph traversal in the service call topology subgraph to determine multiple upstream same group nodes corresponding to the endpoint as the upstream same group node set. The risk propagation path is determined based on the upstream family node set and the service call topology subgraph.

9. The system as described in claim 8, characterized in that, The intelligent decision-making module is also used for: Determine whether multiple nodes in the risk propagation path form instance replacement pairs in the instance relationship graph; If an instance replacement pair is formed, the target degradation strategy will be determined as the preheating protection mode; If no instance replacement pair is formed, the target degradation strategy will be set to the standard degradation mode. A degradation instruction is broadcast to the microservice instances corresponding to the nodes on the risk propagation path. The broadcast degradation instruction includes the affected data domain and the target degradation strategy. Determine whether the data segment to which the service identifier of the received real-time work order task request belongs belongs to the affected data domain; If the data belongs to the affected data domain and the target degradation strategy is in preheating protection mode, then the call to the downstream microservice instance is interrupted, local caching is enabled, or the preset default value is returned. If the data belongs to the affected data domain and the target degradation strategy is the standard degradation mode, then local caching is enabled, and simulated request sequences are continuously sent to downstream microservice instances at a preset rate. The recovery status of the downstream microservice instances is monitored based on the simulated request sequences.

10. A microservice-based process order processing method based on dynamic load balancing, characterized in that, The method is applied to a microservice architecture, which includes a load balancing layer, multiple microservice instances, and a containerized management layer. The method includes: Real-time monitoring of instance lifecycle event streams generated by instance state changes in the containerization management layer; determining the logical relationships of microservice instances and the state attributes of these logical relationships based on the event sequence in the instance lifecycle event stream. The candidate instance set is determined based on the real-time load metrics of the microservice instances; Remove microservice instances that are in a replacement relationship and whose status attribute is closed from the candidate instance set to obtain a safe candidate instance set; The target microservice instance is determined based on the real-time load metrics of each instance in the set of security candidate instances. Send the work order task request and the target microservice instance to the load balancer layer.

Images