A micro-service-based work order processing system and method based on dynamic load balancing

Abstract

The application discloses a kind of microservice order processing system and method based on dynamic load balancing, it is related to the technical field of microservice, the system is applied to microservice architecture, system includes: event monitoring module, the instance lifecycle event stream of containerization management layer is monitored in real time, the logical relationship of microservice instance and the state attribute of the logical relationship are determined according to instance lifecycle event stream;Intelligent decision module is used to when receiving order task request: according to the real-time load index of microservice instance, determine candidate instance set;The microservice instance in replacement relationship and the state attribute for closing is removed from candidate instance set, obtain safe candidate instance set;Based on the real-time load index of each instance in safe candidate instance set, determine target microservice instance;Order task request and target microservice instance are sent to load balancing layer.The application improves the distribution ability of load balancer in microservice architecture to order task request.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of microservices, and in particular to a microservice-based work order processing system and method based on dynamic load balancing. BACKGROUND

[0002] The basic workflow of a distributed system includes service registration, state synchronization and traffic scheduling. When a new instance starts, the instance sends a registration request to the service registry (such as Nacos / Consul) to declare the network address and availability; the registry synchronizes the information of the new instance to the load balancer, and this process has a natural network transmission and data processing delay (usually seconds); the load balancer distributes requests according to the locally cached service list. Since the load balancer needs to synchronize the state of each microservice instance through the registration table of the registry, there is a short time difference between the actual state (started / terminated) of the service instance and the state perceived by the load balancer, and during this time window, the service list held by the load balancer is outdated.

[0003] The load balancer is prone to route current task requests to old instances that are about to be offline or have been overloaded due to the lag in state perception of microservice instances, resulting in the loss of work order task requests, the generation of semi-finished work orders or dirty data in the background, and the failure of load balancing. Especially at the moment when the instance is closed, the load balancer has a high probability of making a wrong decision.

[0004] Therefore, how to improve the allocation capability of the load balancer for work order task requests in the microservice architecture has become a technical problem to be solved. SUMMARY

[0005] The technical problem solved by the present application is that the allocation capability of the load balancer for work order task requests in the microservice architecture needs to be improved.

[0006] To solve the above technical problems, the present application provides the following technical solutions: on the one hand, a micro-service work order processing system based on dynamic load balancing is provided, which is applied to a micro-service architecture, the micro-service architecture comprising a load balancing layer, a plurality of micro-service instances and a containerized management layer, the system comprising: an event listening module, which listens in real time to instance lifecycle event streams generated by the containerized management layer due to instance state changes, and determines the logical relationship of the micro-service instances and the state attribute of the logical relationship according to the event sequence in the instance lifecycle event streams; an intelligent decision-making module, which is configured to, when receiving a work order task request: determine a candidate instance set according to the real-time load indicators of the micro-service instances; remove the micro-service instances in the replacement relationship and having the state attribute of being closed from the candidate instance set to obtain a safe candidate instance set; determine a target micro-service instance based on the real-time load indicators of the instances in the safe candidate instance set; and send the work order task request and the target micro-service instance to the load balancing layer.

[0007] Preferably, the event listening module is further configured to: parse the instance lifecycle event streams to obtain the event sequence; if the event sequence contains a creation event of a first micro-service instance, the event sequence further contains a termination event of a second micro-service instance within a first preset time window corresponding to the time of the creation event, and the first micro-service instance and the second micro-service instance have the same service identifier and version label, then determine the first micro-service instance and the second micro-service instance as an instance replacement pair; take the instances in the instance replacement pair as nodes of an instance relationship graph, establish an edge from the second micro-service instance node to the first micro-service instance node, set the type attribute of the edge to a replacement relationship, and set the state attribute to closed.

[0008] Preferably, the event listening module is further configured to generate a construction signal of the instance replacement pair; and the intelligent decision-making module is further configured to: in response to the construction signal, collect historical request logs of the second micro-service instance within a second preset time window; parse the historical request logs to extract the request path distribution, the request body size distribution and the key request parameters contained in the historical request logs, and obtain a first historical request feature vector; determine a simulation request sequence containing a plurality of simulation work order requests according to the first historical request feature vector, the simulation request sequence being used to simulate real work order business requests; continuously send the simulation request sequence as exploratory traffic to the first micro-service instance for preheating; collect the resource occupation of the first micro-service instance when processing the simulation request sequence, and draw a resource occupation curve; compare the resource occupation curve with a preset standard preheating completion curve in terms of similarity; if the similarity is less than a first preset similarity threshold, continuously send the exploratory traffic to the first micro-service instance until the similarity is greater than or equal to the first preset similarity threshold, and complete the preheating of the first micro-service instance.

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

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

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

[0012] Preferably, the system further comprises a distributed link tracking module; the distributed link tracking module is configured to capture calling path information of the ticket task request when crossing a plurality of microservice instances, the calling path information including a calling initiator, a receiver, a calling timestamp and a time consumption; and the event listening module is further configured to: identify a plurality of same-family group nodes involved in the calling path information and a calling relationship between the plurality of same-family group nodes; and construct a service calling topology subgraph according to the instance relationship graph, wherein a node of the service calling topology subgraph is a same-family group node involved, and a directed edge of the service calling topology subgraph is used to indicate a calling relationship from one same-family group node to another same-family group node, and an attribute of the directed edge is set as a frequency of calling or an average response time of calling associated with the calling relationship corresponding to the directed edge.

[0013] Preferably, the intelligent decision module is further configured to: monitor real-time load indicators of the same-family group nodes in the service invocation topology subgraph; determine a downstream node to which a node of the service invocation topology subgraph is directed by a plurality of directed edges as a downstream same-family group node, and determine a node upstream of the downstream same-family group node as an upstream same-family group node of the downstream same-family group node; if it is detected that a real-time load indicator of any first downstream same-family group node exceeds a preset failure threshold, mark a first upstream same-family group node corresponding to the first downstream same-family group node as a failure source, wherein the first downstream same-family group node is a downstream node to which the first upstream same-family group node is directed by one directed edge; starting from a data shard processed by the failure source, traverse the traffic affinity edges in the instance relationship graph, aggregate data shards reachable by the traffic affinity edges, and obtain an affected data domain; ending at a same-family group node corresponding to a data shard in the affected data domain, perform reverse graph traversal in the service invocation topology subgraph, and determine a plurality of upstream same-family group nodes corresponding to the end point as an upstream same-family group node set; and determine a risk propagation path according to the upstream same-family group node set and the service invocation topology subgraph.

[0014] Preferably, the intelligent decision module is further configured to: determine whether the plurality of nodes in the risk propagation path form an instance replacement pair in the instance relationship graph; if the instance replacement pair is formed, determine the target degradation strategy as a warm-up protection mode; and if the instance replacement pair is not formed, determine the target degradation strategy as a standard degradation mode.

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

[0016] In another aspect, a microservice-based work order processing method based on dynamic load balancing is also provided, which is applied to a microservice architecture including a load balancing layer, a plurality of microservice instances, and a containerized management layer, and the method comprises: real-time monitoring of instance lifecycle event streams generated by the containerized management layer due to instance state changes, determining the logical relationship of the microservice instances and the state attribute of the logical relationship according to the event sequence in the instance lifecycle event streams; determining a candidate instance set according to the real-time load indicators of the microservice instances; removing the microservice instances in the replacement relationship and with the state attribute of being closed from the candidate instance set to obtain a safe candidate instance set; determining a target microservice instance based on the real-time load indicators of each instance in the safe candidate instance set; and sending a work order task request and the target microservice instance to the load balancing layer.

[0017] The beneficial effects of the present application are: by real-time monitoring of instance lifecycle event streams generated by the containerized management layer due to instance state changes, determining the logical relationship of the microservice instances and the state attribute of the logical relationship according to the event sequence in the instance lifecycle event streams, bypassing the registration center by monitoring the containerized layer events, and determining the microservice instances being closed according to the event sequence in the instance lifecycle event streams; removing the microservice instances in the replacement relationship and with the state attribute of being closed from the candidate instance set to obtain a safe candidate instance set, determining a target microservice instance based on the real-time load indicators of each instance in the safe candidate instance set, and sending a work order task request and the target microservice instance to the load balancing layer, so as to avoid determining the microservice instances being closed as the target microservice instance, that is, to avoid the time difference between the actual state of the service instance and the state perceived by the load balancer, which interferes with the task request distribution of the load balancer, thereby improving the distribution ability of the load balancer in the microservice architecture for the work order task request. BRIEF DESCRIPTION OF DRAWINGS

[0018] Figure 1 An application scenario schematic diagram of a microservice-based work order processing system based on dynamic load balancing is provided for an embodiment of the present application.

[0019] Figure 2 A basic structure schematic diagram of a microservice-based work order processing system based on dynamic load balancing is provided for an embodiment of the present application. DETAILED DESCRIPTION

[0020] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, the specific embodiments of the present application will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments.

[0021] Embodiment 1, refer 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:

[0022] 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.

[0023] 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 task 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 task request and the target microservice instance to the load balancing layer.

[0024] 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.

[0025] 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.

[0026] 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.

[0027] 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.

[0028] The containerization management layer is the only source of initiating any state change of a microservice instance. When the system needs to perform operations such as service update, expansion or contraction, the containerization management layer will actively perform the corresponding actions, for example, creating a new microservice instance or terminating an old instance. Each adjustment operation on the microservice instance will generate a standardized state event, and the state event will be collected in real time to form a continuous data stream to obtain an instance lifecycle event stream.

[0029] An event sequence is a combination of events in the instance lifecycle event stream that are arranged in chronological order and have specific logical associations.

[0030] The system can infer the logical relationship between microservice instances by analyzing the event sequence. For example, when the system detects a termination event representing a first microservice instance and then detects a creation event representing a second microservice instance within a very short time window, and the two instances have the same service identifier and version label, the system can determine that this is an instance replacement operation.

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

[0032] A work order is a data structure widely used in many business fields to record, track and handle a specific work task. For example, in the IT operation and maintenance field, a work order can represent a server fault report; in the customer service field, it can be a user's consultation or complaint; in the production and manufacturing field, it can be a product defect repair task.

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

[0034] In the conventional microservice processing flow, a work order task request first arrives at the load balancing layer, which selects a microservice instance according to its built-in simple rules (such as round robin or random algorithm), and then forwards the request to the instance, which completes the specific business processing and returns the result.

[0035] However, this conventional process lacks immediate awareness of the real-time state of instances, which can lead to incorrect request distribution. For example, an instance that is being shut down, whose load is inevitably extremely low, a zombie instance that is stuck and cannot handle requests, whose CPU and memory may also be at an extremely low level. Specifically: at time T0, microservice instance Instance-X receives a shutdown instruction (such as kubectl delete pod); at time T0+0.1s, the process of Instance-X starts to execute the shutdown process, Instance-X first sends a deregistration request to the service registry (such as Nacos), at the same time, Instance-X stops receiving new business requests; at time T0+0.2s, a storage request arrives at the load balancing layer, Instance-X still exists in the local cache of the load balancer (because the synchronization of the registry center has a delay of seconds), the load balancer collects the load indicators of each microservice instance at the current time, and the load balancer sends a probe request to Instance-X. Since Instance-X only stops receiving business requests, but its process and monitoring port (such as / metrics port) may still be running, Instance-X will return an extremely low load value; at time T0+0.3s, the load balancing algorithm sees that Instance-X has the lowest load, and perfectly allocates this new storage request to Instance-X. At time T0+0.4s, the request is sent to Instance-X and is directly rejected or connection timeout, because Instance-X no longer processes business logic, the request fails. Therefore, at the moment when the instance is shutting down, the load balancer has a high probability of making incorrect decisions.

[0036] Based on this, when distributing ticket task requests based on the load indicators 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.

[0037] Specifically, after receiving a ticket task request, the intelligent decision module will collect the real-time load indicators of all available microservice instances. Real-time load indicators are key data for measuring the current work pressure of microservice instances, and typically include CPU utilization, memory usage, network ingress and egress traffic, current connection count, request queue length, error rate, and average response time, etc.

[0038] Based on real-time load indicators, the system performs preliminary screening to form a candidate instance set. The candidate instance set includes all instances that are currently running and theoretically capable of handling new requests.

[0039] The system further queries instance relationship information maintained by the event listening module, and removes all instances in the replacement relationship and with the closed state attribute from the candidate set, thereby obtaining a safe candidate instance set. Each instance in the safe candidate instance set is not only running, but also stable and reliable in state, thereby fundamentally avoiding sending a request to an instance to be destroyed.

[0040] In determining the candidate instance set from all instances, the real-time load indicator is used to exclude those instances that have been obviously overloaded or failed; in determining the unique target microservice instance from the safe candidate instance set, the real-time load indicator is used to make a more fine selection, for example, in all instances in the safe state, the one with the lowest current load is selected to achieve optimal resource utilization and the fastest response speed.

[0041] Further, whether or not a safe candidate instance set can be successfully formed, throughout the decision-making process, the intelligent decision-making module is always the only decision-making core, and the final target microservice instance is determined by the intelligent decision-making module according to its internal algorithm and logic. If the safe candidate instance set is empty, the intelligent decision-making module makes a decision based on the original candidate instance set; if the safe candidate instance set is not empty, a decision is made based on the safe candidate instance set.

[0042] Therefore, in the present application, the load balancing layer does not participate in any selection or judgment. When the intelligent decision-making module completes the decision, the intelligent decision-making module sends the work order task request and the address information of the target microservice instance to the load balancing layer, and the load balancing layer routes the work order task request to the specified target microservice instance.

[0043] Preferably, the event listening module is further configured to: analyze the instance lifecycle event stream to obtain an event sequence; if the event sequence contains a creation event of a first microservice instance, the event sequence further contains a termination event of a second microservice instance within a first preset time window corresponding to the time of the creation event, and the first microservice instance and the second microservice instance have the same service identifier and version label, 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 taken as nodes of an instance relationship graph, an edge from the second microservice instance node to the first microservice instance node is established, the type attribute of the edge is set as a replacement relationship, and the state attribute is set as closed.

[0044] The instance lifecycle event stream is a collection of a series of events generated by the containerized management layer in the entire lifecycle of the microservice instance, which specifically includes the creation, startup, termination, deletion, and state update of the instance, etc.

[0045] The system subscribes and receives the raw event stream from the containerized management layer through the event listener module, which is usually in a serialized format such as JSON or Protocol Buffers.

[0046] The raw event stream before parsing is a sequence of data packets arranged in chronological order but logically independent, each containing the basic information of an event; after parsing, the raw data is converted into a list of structured objects, each with clearly defined fields such as event type, timestamp, instance unique identifier, service identifier, and version label. The event sequence is a list of parsed and structured event objects sorted by time.

[0047] The system identifies creation events and termination events by checking the event type field in the parsed event objects. When the value of this field in an event object is determined by the system to be a creation or similar enumeration value, the event is identified as a creation event.

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

[0049] The identification of termination events is similar to that of creation events, i.e. checking whether the event type field is termination or deletion.

[0050] 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 label identifies the specific code version of the service instance, such as v1.1 or v2.0.

[0051] When two instances have the same service identifier and version label, it means they are completely replaceable running units of the same service and the same version.

[0052] The same service identifier and version label ensure that the two instances are completely equivalent in terms of functionality and code, and the termination of the second microservice instance and the creation of the first microservice instance occur within the preset close 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 intention. If the above conditions are met, the first and second microservice instances can be determined as an instance replacement pair, which represents a rolling update or instance restart operation of the user in the containerized management layer.

[0053] Therefore, the instance replacement pair can represent the instantaneous state in which an old microservice instance is replaced by a new one with the same functionality in a microservice architecture, capturing the dynamic relationship of instance replacement in the service deployment process.

[0054] Preferably, the event listening module is further configured to generate a construction signal of the instance replacement pair; and the intelligent decision-making module is further configured to: in response to the construction signal, collect historical request logs of the second microservice instance within a second preset time window; parse the historical request logs to extract request path distribution, request body size distribution and key request parameters contained in the historical request logs, to obtain a first historical request feature vector; determine a simulation request sequence containing a plurality of simulation work order requests according to the first historical request feature vector, the simulation request sequence being used to simulate real work order business requests; continuously send the simulation request sequence as exploratory traffic to the first microservice instance for preheating; collect resource occupation conditions of the first microservice instance when processing the simulation request sequence, and draw a resource occupation curve; and compare the resource occupation curve with a preset standard preheating completion curve in terms of 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, and complete preheating of the first microservice instance.

[0055] The preheating of the new microservice instance is used to solve the performance problem of cold start of the instance.

[0056] When a brand new microservice instance starts and first receives requests, its underlying runtime environment (such as the just-in-time compiler of the Java virtual machine, code cache, database connection pool, etc.) has not yet reached an optimal state. Processing initial requests will trigger a large number of initialization operations, which will result in extremely high latency and low processing throughput.

[0057] The preheating process actively sends simulated representative request traffic to the instance before it formally processes real business traffic, forcing it to complete time-consuming initialization work, so that its resource occupation and response performance enter a stable and efficient running state in advance.

[0058] The second preset time window is a configurable time parameter, and its specific duration (for example, the past one hour or the past 24 hours) is set by a system administrator according to the periodic characteristics of the business.

[0059] The reason for collecting the historical request logs of the second microservice instance (i.e. the replaced old instance) within the window is that in the logic of instance replacement, the new and old instances are completely equivalent in terms of function and the role of the business they carry.

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

[0061] The historical request log contains the request mode, data distribution and parameter combination in the real business scenario, so that the preheating traffic generated based on the historical request log has high pertinence and effectiveness, far superior to using random or general test traffic.

[0062] The historical request log is a detailed record generated by the microservice instance during running for each processed request. Each log usually contains timestamp, HTTP request method, complete request URL, request header information, request body content, response status code and processing time consumption, etc.

[0063] The collection of historical request log is usually realized by integrating log recording framework (such as Logback or Log4j) in microservice, and the log information is output to standard output. Then, the log collection agent (such as Fluentd or Logstash) in the deployment environment real-time captures the log information, and forwards it to the centralized log storage system (such as Elasticsearch cluster) for unified storage and indexing, and the intelligent decision module queries the storage system to obtain the required historical request log data.

[0064] The request path distribution refers to the statistical result of the request frequency of different API interface endpoints, to reflect the calling heat of different business functions.

[0065] The request body size distribution is the statistics of the HTTP body data size of the incoming request, which is related to the network transmission and memory serialization overhead.

[0066] The key request parameter refers to the parameter that has a significant influence on the business logic execution path or database query performance, such as the keyword in the search query, the page number and the number of pages in the paging query, etc. The key request parameter is extracted to determine the request processing complexity and resource consumption.

[0067] The extraction process parses the URL and request body content in the log, and matches and extracts the corresponding parameter values and their frequencies according to the system preset parameter configuration rules.

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

[0069] The first historical request feature vector is essentially a highly condensed digital record of the workload carried by the old instance in a specific time window, which is used to represent the traffic composition, data size and business characteristics of the workload.

[0070] The conversion process usually includes: one-hot encoding or frequency encoding of 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.

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

[0072] The preset standard pre-warming completion curve is an ideal performance curve serving as a benchmark reference, which is usually drawn by performance engineers after conducting a large number of pre-warming tests in a controlled environment.

[0073] The typical form of the preset standard pre-warming completion curve is: at the beginning of pre-warming, the resource occupancy rate (such as CPU usage) is at a relatively high peak value due to initialization overhead, and then gradually decreases as cache pre-warming, code compilation and other work are completed, and finally stabilizes at a relatively low and stable level. This curve represents the ideal performance evolution path of the instance from cold start to full readiness.

[0074] Resource occupancy refers to the real-time consumption of system resources such as computing, memory, network and storage by the microservice instance when processing the simulated request sequence. These data are obtained through monitoring interfaces provided by containerized management layers (such as cAdvisor or kubelet metrics API) or integrated with monitoring systems such as Prometheus.

[0075] The intelligent decision-making module continuously collects these resource indicators at a fixed time interval (for example, every second) while sending simulated traffic. When drawing the resource occupancy curve, the module connects the time series data points collected on the coordinate system, where the X-axis represents time and the Y-axis represents resource usage (such as CPU percentage), thereby forming a dynamically changing curve.

[0076] The first preset similarity threshold is used to represent the critical point between distinguishing the "pre-warming completed" and "still in pre-warming" states of the instance.

[0077] Engineers will run multiple warm-up experiments, analyzing the degree of deviation between the actual resource-occupancy curve of the instance when it actually reaches steady state and the standard warm-up completion curve. This deviation is usually quantified using similarity algorithms (such as cosine similarity or dynamic time warping).

[0078] The first preset similarity threshold is set to an empirical value that can effectively filter out instances that have not completed warm-up while maximizing warm-up efficiency.

[0079] When the similarity of 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.

[0080] Preferably, the event monitoring module is further configured to: determine microservice instances with the same service identifier but different version labels as sibling instances; create multiple sibling nodes for the microservice instances that are sibling instances of each other in the instance relationship graph; create a sibling group node in the instance relationship graph according to the multiple sibling nodes; connect the multiple sibling nodes to the sibling group node; collect ticket task requests processed by the multiple microservice instances corresponding to the sibling group node within a preset historical period; determine an original hash key according to a business identifier in each ticket task request to obtain a set of original hash keys corresponding to the sibling group node; perform vector embedding processing on each hash key in the set of original hash keys to obtain multiple first hash key vectors corresponding to the multiple hash keys one-to-one; perform clustering 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 a center vector of each cluster as a 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 sibling group node in the instance relationship graph.

[0081] Microservice instances with the same service identifier but different version labels are determined as sibling instances to logically unify the management of microservices that belong to the same business function but are at different evolutionary stages. In a microservice architecture, services are constantly updated, released in gray, or tested in A / B mode, resulting in the existence of multiple versions of instances at the same time.

[0082] In a dynamic and continuous delivery production environment, the design of sibling instances allows the system to perceive the overall view of a certain service (e.g., "order service") rather than only seeing scattered instances such as "order service v1.0", "order service v1.1", etc., thereby achieving unified management across versions.

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

[0084] Through the combination of service identifier and version label, any specific microservice instance can be located. The existence of different version labels reflects different stages of the software development life cycle, for example, v1.0 may be a stable version, v1.1 is a version that fixes bugs, and "feature-new-checkout" is a version that is developing new features for A / B testing.

[0085] Create same-family nodes and same-family group nodes in the instance relationship graph to build a hierarchical model structure that reflects the structure of real-world services.

[0086] Directly using original instance nodes will make the graph flat and unable to reflect the logical ownership relationship between instances. Same-family nodes represent a specific microservice instance, while same-family group nodes are a higher-level abstraction that represent the entire service family.

[0087] Same-family group nodes are used to aggregate and manage the common attributes and metadata of all their subordinate same-family nodes, such as data sharding information, overall traffic patterns, etc. When you need to operate or query the entire order service, you only need to interact with the same-family group node, without traversing all version instance nodes.

[0088] Connecting same-family nodes to same-family group nodes is achieved by establishing a directed edge from a same-family node to a same-family group node in the graph. The relationship type of this edge can be defined as belonging or member. The state attribute of the edge can be set to active, deprecated, read-only, etc. to reflect the current state of the instance in the service family.

[0089] In graph queries, you can easily traverse all member nodes of a same-family group node; in 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, thus achieving dynamic updating of the graph.

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

[0091] The preset history period reflects the real business load and request pattern of the service in the recent production environment. If the period is set too short, it may not capture the periodic business fluctuations; if it is set too long, it may contain outdated and no longer relevant request patterns, affecting the accuracy of data sharding.

[0092] The work order task request is a structured data object used to describe a to-be-processed task, usually containing fields such as work order ID, request type, initiator, timestamp, business data body, and priority. The collection of work order task requests is usually achieved by integrating log recording or message queue interception mechanisms in microservice instances, and whenever a work order request is processed, its key information is captured and sent to a central data collection system. The integrity of the data is usually guaranteed by transactional message queues or at least once (At-Least-Once) log delivery mechanisms, while the real-time performance is ensured by stream processing platforms (such as Kafka), and the data can be consumed as soon as it is generated.

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

[0094] The use of hash keys instead of directly using business identifiers is because hash keys have fixed length and uniform distribution characteristics, which facilitate subsequent mathematical processing (such as vector and clustering), and also play a certain desensitization role for sensitive business identifiers.

[0095] The original hash key is subjected to vector embedding processing in order to convert discrete, unordered hash keys into continuous numerical vectors that can be mathematically calculated.

[0096] The first hash key vector is used to represent the semantics of the hash key in the historical request context, i.e., the association of the hash key with other hash keys. Common vectorization methods include Word2Vec, Doc2Vec, or other graph embedding algorithms, and the vectorization method is to learn the pattern of the hash key in a large number of request log sequences to generate a vector. The model is trained based on a large number of historical work order request logs, with each hash key being treated as a word and a complete request path or session being treated as a sentence, and a model that can capture its context relationship is trained.

[0097] Clustering analysis usually adopts partitioning clustering algorithms such as K-means. Clusters are chosen to form data shards because clustering algorithms can automatically group hash keys with similar vector features (i.e., with similar business request patterns) together into a cluster, which naturally forms a logical data shard.

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

[0099] Data shards are a logical division of a data set by horizontal partitioning, each shard contains a subset of the data. In this scheme, a data shard is composed of a group of hash keys that are highly related in business. Defining data shards is the basis for implementing distributed storage and parallel processing, which can deploy different data shards on different physical nodes, thereby improving the overall throughput and scalability of the system.

[0100] Data shards are closely related to the load of microservice instances. If a data shard becomes a hot spot, the load of the microservice instances that handle requests related to that shard will increase.

[0101] Data shard identification is a string or number used to uniquely identify each data shard, such as using UUID or an incrementing integer with a specific prefix (such as "shard-order-001"). Its uniqueness is usually guaranteed by a central coordination service or global uniqueness check when generated. This identification is used for data routing in the future. When a request arrives and the hash key is calculated, the system needs to determine which data shard the hash key belongs to, at which point the mapping between shard identification and hash key can be queried to quickly locate it.

[0102] The center vector of the cluster is used as the mathematical representation of the data shard because the center vector is the geometric center of all vectors in 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 may belong to, by calculating the distance between the new key vector and each center vector.

[0103] The mathematical representation of the data shard is relatively static and only updated when the data shard needs to be recalculated (e.g., when significant changes in business patterns occur, making the original cluster no longer applicable).

[0104] The data shard identification and its mathematical representation are stored as attributes in the same family group node in the instance relation graph to realize centralized management and high accessibility of metadata. All data shard information about the service family is tightly coupled with its logical definition (the same family group node) to form a self-contained knowledge unit.

[0105] When the service family changes, for example, a data shard is added or the characteristics of a shard change, the system only needs to update the attributes on the same family group node, without modifying other parts of the graph.

[0106] Traditional algorithms often only focus on the real-time health status and load of instances, ignoring the correlation between request content and instance processing capacity, so that an instance that has just completed rolling update, cache or is empty, although the load is the lowest, but the performance is poor when processing a complex request. Therefore, how to route a transmitted request not only to an instance with a lower current load, but also to an instance with historical advantages and higher efficiency in processing the specific type of request, so as to combine the correlation between request content and instance processing capacity with real-time load balancing, to realize more intelligent and efficient request distribution, while ensuring system stability, maximize overall processing performance.

[0107] Preferably, the target microservice instance is determined based on the real-time load indicators of each instance in the safe candidate instance set, including: determining the current hash key according to the business identifier of the current work order task request; performing vector embedding processing on the current hash key to obtain a 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 relation graph; determining the same family group node corresponding to the data shard with the highest cosine similarity as the target same family group node; determining the microservice instance that is simultaneously located in the safe candidate instance set and connected as a node to the target same family group node as a priority candidate instance; and determining the target microservice instance from the plurality of priority candidate instances according to the real-time load indicators.

[0108] The business identifier is converted into a hash key and then into a vector to solve the problem that raw data cannot be directly used for mathematical calculation and pattern matching. Direct use of the original business identifier (such as an order number string) cannot measure the business similarity between two orders. Converting it into a hash key first obtains a unified, fixed-length numerical representation, which facilitates quick indexing and comparison.

[0109] However, the randomness of the hash key destroys the semantic association of the original identifier. Therefore, the hash key is further mapped to a high-dimensional vector space through a vectorized embedding process, and requests with similar business patterns are close to each other in the space, so as to convert the unstructured and discrete business identifier into a continuous feature vector that can be mathematically operated (such as calculating similarity) and contains business semantics, thereby providing a data basis for subsequent intelligent routing decisions.

[0110] The current first hash key vector is generated by a pre-trained vectorized embedding model. This model usually uses an algorithm similar to Word2Vec or Node2Vec, and its training data comes from all business identifier sequences of the service request processed by the microservice in a preset historical period. During training, the model regards each business identifier (or its hash key) as a node in the graph, and regards the identifier sequence in a complete business process or session as a path. By learning these paths, the model can capture the co-occurrence relationship and context dependence between different business identifiers. The generated vector finally represents the coordinates of the business identifier in a certain business feature space, and the vector as a whole represents the semantic role or functional category of the request in the entire system business mode.

[0111] The identifier itself, such as a hash key, is essentially an arbitrary and meaningless character sequence, and it does not contain any inherent information about the business type it represents. However, semantic association does not come from the identifier itself, but from its observable behavior patterns in the entire system workflow. Specifically, when a business identifier (for example, an order ID) frequently appears together with other identifiers (for example, a payment ID, a logistics ID) during processing, the system can infer that these identifiers are related in business logic. In order to quantify and utilize this complex association network, the system uses a vectorized embedding model. The model learns by analyzing massive historical business identifier sequences, and its training goal is to predict an identifier based on its context (i.e., other identifiers that co-occur with it).

[0112] 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 vector is no longer a random representation of the original identifier, but a dense mathematical encoding of its business semantics.

[0113] The distance or angle between vectors directly reflects the semantic similarity of the business identifiers they represent in the real world. In this way, semantic association is established between originally isolated identifiers, which is computable and measurable.

[0114] The cosine similarity is selected as the matching criterion, and the direction of the vector represents the service feature type of the request, while the length of the vector is related to the frequency or data volume of the request of the type.

[0115] Using the cosine similarity can effectively filter out the interference caused by different request magnitudes and focus on comparing whether two requests are similar in service nature. Compared with the Euclidean distance, the cosine similarity can better judge the pattern similarity in a high-dimensional space to more accurately identify to which data shard with similar service features the current request should belong, thereby realizing accurate routing based on content affinity.

[0116] If a microservice instance group (same family group) has been processing a certain type of service request for a long time, its runtime environment (such as JIT compilation optimization, application layer cache, database connection pool configuration, etc.) has been deeply optimized for this type of request. Therefore, when a new request has a high match with this type of service, routing it to this specialized instance group can maximize the use of these established optimizations to achieve lower latency and higher throughput.

[0117] In the graph, the connection refers to a directed edge from the same family node representing a specific microservice instance to the same family group node to which it belongs. The relationship type of this edge can be defined as belonging or member. This connection relationship is automatically created and written into the instance relationship graph by the event listening module according to the service identifier and version label of the microservice instance when it starts and registers with the service registry.

[0118] In the maintenance of the graph, when an instance goes offline, the node and its corresponding edges will be marked as unavailable or removed from the graph. Through the query language of the graph database, this connection can be efficiently queried, for example, all active member instances under a certain same family group node can be quickly found.

[0119] The strategy for determining the target microservice instance from the priority candidate instances based on real-time load indicators is usually to select the instance with the lowest comprehensive load. Real-time load indicators include CPU utilization, memory occupancy, network I / O bandwidth, disk I / O (IOPS), current active connection number, and request queue length, etc. The indicators are collected by monitoring agents (such as Prometheus Exporter) deployed inside the microservice instances and aggregated and reported by containerized management layers (such as Kubernetes) or specialized monitoring systems.

[0120] The intelligent decision-making module calculates a comprehensive load score for each priority candidate instance, for example, by weighted summation, and assigns different weights to different indicators. If the load scores of multiple instances are the same, the system can use random selection or polling as the final tie-breaking rule to ensure that requests are evenly distributed among these optimal instances.

[0121] The system based on intelligent load balancing, the intelligent routing based on data affinity and the traditional real-time load balancing are deeply fused. Compared with the simple polling or minimum connection number algorithm, the system not only considers the current state of the instance, but also considers the matching degree of the content of the request and the expertise formed in the historical processing of the instance; by preferentially routing the request to the professional instance group that has processed the same type of business, the cache hit rate and code execution efficiency can be significantly improved; at the same time, within the instance group, fine scheduling is still carried out according to the real-time load, so as to avoid local overload caused by data hotspots.

[0122] If there is no instance in the security candidate instance set in the same group node corresponding to the data shard most similar to the current request, or the load of the instance exceeds the preset high load threshold, the system will start the degradation strategy.

[0123] Firstly, the system will try to expand the search range, calculate the cosine similarity between the current request vector and the mathematical representation of the data shard with the second highest similarity, and check whether the corresponding same group node has available and reasonable load instance. If all the data affinity instance groups are unavailable, the system will finally fall back to the basic load balancing strategy, that is, in the security candidate instance set of the entire system (excluding the instances in the replacement relationship), an optimal instance is selected to process the request according to the real-time load index, so as to ensure the continuous availability of the service, although it may sacrifice part of the performance gain brought by data affinity.

[0124] Preferably, the event listening module is further configured to: extract a plurality of work order task requests that are accessed together in a single transaction from historical task request logs; generate a second historical request feature vector for each work order task request extracted according to a request path distribution, a request body size distribution and a key request parameter contained in the work order task request; perform vector similarity clustering on the second historical request feature vectors of the plurality of work order task requests; aggregate work order task requests with a vector similarity higher than a second preset similarity threshold as a traffic pattern cluster; perform vector embedding processing on the business identifiers of the work order task requests in the traffic pattern cluster to obtain a second hash key vector; match the second hash key vector 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; and establish a traffic affinity edge between nodes corresponding to a plurality of data shards belonging to the same traffic pattern cluster in the instance relationship graph, determine a mean vector of the second historical request feature vectors in the traffic pattern cluster, and determine the mean vector as an attribute of the traffic affinity edge.

[0125] The multiple ticket task requests that are co-accessed in a single transaction specifically refer to a set of interrelated background requests triggered by a complete, atomic business operation in the process of which the system handles the operation. In a distributed system, a front-end user operation, such as submitting an order, can trigger a series of service calls in the back-end, such as verifying inventory, creating a payment record, updating user points, and the like. The background requests collectively constitute all activities to complete the order submission transaction.

[0126] Defining a single transaction usually relies on a globally unique transaction identifier that is passed through all requests triggered by the transaction, for example, by passing in the message header or log metadata. The system extracts all request entries carrying the same transaction identifier from the historical task request log by parsing the log, and aggregates them as a request set within the same transaction. If the log lacks an explicit transaction identifier, the system can also use a time window-based inference rule, for example, determining that multiple requests from the same source IP address and occurring continuously within a very short time interval (such as 500 milliseconds) belong to the same transaction, but this method has lower accuracy.

[0127] Extracting co-accessed requests to rise from isolated single request analysis to correlated request pattern analysis, so as to mine the inherent logical relationship and data access rule in the business process.

[0128] A single request can only reveal its own characteristics, while a set of co-accessed requests can reveal the timing dependency, call link, and data locality between them.

[0129] For example, it can be found through analysis that the "create user" request is always followed by the "initialize user permission" request, or the "query order details" request is usually accompanied by the "query logistics information" request. This step is necessary, and if it is skipped, the system will not understand the context of the request, and can only process each request in isolation, which is inefficient, and thus loses the basis for intelligent prediction, cache warm-up, and routing optimization, ultimately leading to a decline in the overall performance and response speed of the system.

[0130] The second historical request feature vector is the same as the first historical request feature vector in terms of generation method, both of which are based on request path distribution, request body size distribution, and key request parameters, and the like, to quantify the request, but their data sources, application scenarios, and ultimate purposes are completely different.

[0131] The data source of the first historical request feature vector is all the request logs of a single microservice instance in a certain historical time period, and the purpose is to reproduce the typical load characteristics of the instance for preheating the new instance to a stable running state. The data source of the second historical request feature vector is multiple requests that are accessed together in a single transaction, and the purpose is to depict the request mode of a specific business process.

[0132] Vector similarity clustering usually adopts the K-Means algorithm because it is computationally efficient when dealing with high-dimensional vector data, and easy to implement and extend. Before performing clustering, all second historical request feature vectors need to be standardized or normalized to eliminate the dimensional differences between different feature dimensions (such as the request body size unit is bytes, and the request path is an enumeration type) that interfere with the clustering results.

[0133] The dimension of the clustered feature vector depends on the number of key request parameters and the quantization granularity of the request path and request body size distribution, usually between tens and hundreds of dimensions. The K-Means algorithm is selected because it can quickly divide a large number of vectors into a pre-set number of clusters, each cluster representing a request mode with similar characteristics.

[0134] The second pre-set similarity threshold is a filtering parameter for refining the clustering results, which can be set based on historical data statistics or can be a parameter that can be dynamically configured by the system administrator. The threshold is used to measure the similarity between two request vectors in the same cluster, and if the cosine similarity or Euclidean distance between the two vectors is lower than the threshold, they are considered to belong to different modes. The height of this threshold directly affects the granularity of the traffic mode cluster: a higher threshold will form fewer and more compact clusters, meaning that only requests with highly consistent features will be classified into the same mode; while a lower threshold will form more and more loose clusters, which can capture more extensive request modes, but may introduce noise.

[0135] Traffic mode clusters represent a set of requests with high similarity in business logic or data access behavior, which depict the similarity of request characteristics rather than strict time sequences. For example, a traffic mode cluster may contain all create order requests from different transactions, which are different in time but have very similar request paths, request body sizes, and key parameter structures. It reflects what these requests look like, rather than the order in which they occur. By identifying these clusters, the system can abstract typical business operation modes.

[0136] After the service signature vectors in a traffic pattern cluster are identified, the mathematical representation of the data shards are de-matched, which aims to establish the mapping relationship between the request behavior pattern and the data storage location, so as to indicate the data shards that are usually accessed when the system processes a certain type of request pattern.

[0137] By matching the hash key vector representing the service pattern with the mathematical representation of the data shard location, the system can infer the core data set associated with the pattern. This association can solve the data locality optimization problem, for example, the system can intelligently preload the cache according to this, or when scheduling tasks, the instances processing the pattern are preferentially matched with the physical nodes storing related data to reduce network transmission delay.

[0138] Traffic affinity edge is a special relationship defined in the instance relationship graph, which connects data shard nodes. The establishment of this edge aims to explicitly represent the strong association between two or more data shards, that is, they are often accessed by the same traffic pattern cluster containing requests; the attribute of the edge, that is, the mean vector of all request feature vectors in the traffic pattern cluster, is a quantitative description of this association pattern.

[0139] The mean vector can be regarded as the prototype feature of the traffic pattern. Later, 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 the edge, thereby triggering the corresponding optimization operation, such as pre-fetching data or adjusting the routing strategy.

[0140] The mean vector of the second historical request feature vector in the traffic pattern cluster is used as the attribute of the traffic affinity edge because this mean vector is the most core and condensed mathematical representation of the traffic pattern. It provides a computable and comparable feature signature for the entire edge. When the system needs to make decisions, such as judging whether a new request belongs to a known traffic pattern, it does not need to re-traverse all vectors in the cluster, but only needs to compare with the mean vector stored on the edge, which greatly improves the efficiency of query and matching. This attribute makes the relationship in the graph not a simple connection, but carries rich semantic information, making the graph a knowledge base that can make complex reasoning and prediction.

[0141] By mining traffic affinity, the system can improve performance at multiple levels: first, at the cache level, intelligent preheating can be achieved, when a request pattern is identified, the system can preload the data shards it may access in advance, thereby significantly improving cache hit rate; second, at the routing level, intelligent scheduling based on data affinity can be achieved, requests are preferentially distributed to instances that have cached related data or are closer in physical location, reducing response delay; finally, at the architecture level, through visual traffic affinity edges, development and operation personnel can clearly identify the implicit data dependencies and coupling relationships between services, providing data-driven decision support for continuous optimization and evolution of system architecture.

[0142] In the microservice architecture, an external request often needs to go through multiple independent microservices to complete the cooperation, which makes it very complex to analyze the system behavior. Although the instance relationship graph and the event listening module can reflect the life cycle and logical relationship of a single instance, 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 difficult to quickly determine which specific service link is out of order. Therefore, the distributed link tracking module is introduced, which assigns a unique tracking ID to each request and records the call context in each service it passes through, connecting the originally scattered call points into a complete call link, to solve the problems of cross-instance performance bottleneck positioning, service dependency relationship analysis, fault root cause positioning, and other previously difficult-to-handle problems, thereby providing end-to-end observability for the system. Preferably, the system further comprises a distributed link tracking module; the distributed link tracking module is configured to capture call path information of the work order task request when crossing multiple microservice instances, the call path information comprising a call initiator, a call receiver, a call timestamp, and a call duration; the event listening module is further configured to: identify a plurality of same-family group nodes involved in the call path information and a call relationship between the plurality of same-family group nodes; construct a service call topology subgraph according to the instance relationship graph, wherein a node of the service call topology subgraph is a same-family group node involved, and a directed edge of the service call topology subgraph is used to indicate a call relationship from one same-family group node to another same-family group node, and an attribute of the directed edge is set as a frequency of a call or an average response time of a call associated with the call relationship corresponding to the directed edge.

[0143] 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.

[0144] When a request enters a service, the probe generates a Span record with information such as the start time, service name, instance name, etc. When the service calls a downstream service, the probe passes the trace ID and parent SpanID through HTTP headers or message metadata, and the downstream service creates a new child Span accordingly. The probe generally captures information at the method level or RPC call level, and can accurately record the interaction process between services. To reduce the impact on business performance, the probe usually works asynchronously, only records necessary metadata, and does not collect large amounts of data such as request bodies or response bodies. In addition, with the help of a sidecar proxy such as Istio, link information can also be automatically collected without modifying the business code.

[0145] The caller and callee recorded in the call path are logical service identifiers, such as "order-service" calling "payment-service", rather than specific IP and port. At the same time, the probe also records specific instance information for processing requests, such as "order-service-v2-pod-xyz". The event listener module relies on these logical service names and version labels when identifying the same family group nodes involved in the call path. It queries the instance relationship graph to find the corresponding same family nodes according to the service name and version label. If an instance in the call chain does not belong to any defined same family group, the system can treat it as an unclassified node, display it in a special style in the topology subgraph, or be classified into a default group according to rules, so as to maintain the integrity of the topology structure.

[0146] The core goal of building this subgraph is to provide a high-level view of system dependency relationships, facilitating dependency analysis, performance bottleneck identification, and architecture optimization. For example, architects can quickly locate key paths and core services with the help of this view, and operations personnel can assess the scope of fault impact and carry out capacity planning accordingly.

[0147] The directed edges in the service call topology subgraph usually select 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 service interaction.

[0148] Call frequency refers to the number of calls from one service to another service per unit time, reflecting the dependency strength and business importance between services; average response time reflects the performance of the called service. Selecting these two attributes can directly reveal performance bottlenecks and high-traffic paths in the system. Although error rate or throughput is also valuable, it is usually used as an auxiliary indicator, which can be further obtained through logs or monitoring systems when needed. In actual analysis, call frequency is often used for capacity planning and core service identification, and average response time is directly used for performance monitoring and exception alerting.

[0149] The service call topology subgraph adopts a dynamic updating mechanism, and generally balances real-time performance and resource consumption through incremental updating. The system does not refresh the entire graph in real time for each request, but sets a short-period aggregation window, for example, 10 seconds. Within the window, the link tracking module collects all newly added call path information, calculates the change in call frequency and average response time of each edge, and then applies these incremental updates to the topology graph. This quasi-real-time updating mechanism can ensure data timeliness while avoiding the computational pressure caused by frequent graph reconstruction. Historical data is retained according to the configured period, for example, 7 days, and data beyond the period is automatically cleaned up or stored in low-cost storage.

[0150] The constructed service call topology subgraph serves multiple roles and systems. For developers and operators, it can be rendered into a visual topology on a monitoring dashboard, showing real-time service call relationships, traffic size, and health status. When the response time of a certain edge abnormally increases, the edge will be highlighted in red, achieving rapid alarm. For intelligent decision systems, the topology graph is an important input for load prediction and elastic scaling. For example, by analyzing the call frequency trend of user services to order services, future traffic peaks can be predicted and target services can be expanded in advance. In actual scenarios, during the promotion period, the operation and maintenance team found that the call frequency of the promotion service to the inventory service increased sharply and the response time deteriorated, so they quickly located the inventory service as the bottleneck and performed expansion in time to avoid system collapse.

[0151] Attribute data such as call frequency and average response time generally adopts a hybrid storage strategy to balance query efficiency and scalability. The core structure of the topology subgraph, including node and edge definitions and the latest attribute values, is usually stored in a graph database because graph databases are good at handling relationship queries, such as finding all upstream services that call a certain service. Detailed historical time series data for the above attributes is stored in a time series database. The edges in the graph database retain pointers or IDs pointing to the corresponding data sequences in the time series database. If you want to query the response time curve of a service in the past 24 hours, the system will first get the edge ID from the graph database, and then use the ID to query the complete time series from the time series database. This design ensures topology query efficiency and takes advantage of time series databases in data compression and historical data management. The retention policy of historical data can be configured in the time series database, for example, high-precision data is retained for 7 days, low-precision aggregated data is retained for 1 year, and data beyond the period is automatically cleaned up to control storage costs.

[0152] Preferably, the intelligent decision module is further configured to: monitor real-time load indicators of the same-family group nodes in the service invocation topology subgraph; determine a downstream node pointed to by a node in the service invocation topology subgraph through a plurality of directed edges as a downstream same-family group node, and determine the node as an upstream same-family group node of the downstream same-family group node; if it is detected that a real-time load indicator of any first downstream same-family group node exceeds a preset failure threshold, mark a first upstream same-family group node corresponding to the first downstream same-family group node as a failure source, wherein the first downstream same-family group node is a downstream node pointed to by the first upstream same-family group node through one directed edge; take a data shard processed by the failure source as a starting point, traverse a traffic affinity edge in the instance relationship graph, aggregate data shards reachable by the traffic affinity edge, and obtain an affected data domain; take a same-family group node corresponding to a data shard in the affected data domain as an end point, perform reverse graph traversal in the service invocation topology subgraph, and determine a plurality of upstream same-family group nodes corresponding to the end point as an upstream same-family group node set; and determine a risk propagation path according to the upstream same-family group node set and the service invocation topology subgraph.

[0153] The determination of the preset failure threshold is a hybrid process combining static configuration and dynamic adjustment. The system sets a basic static threshold for each same-family group node according to its service level objective (SLO), for example, CPU usage is not more than 80% or P99 delay is not more than 500 milliseconds. At the same time, the system also continuously analyzes the load performance of the node in a preset historical period (such as the past week), and calculates the load baseline. If the current load continues to deviate from the baseline, the system will dynamically adjust the threshold, for example, temporarily relax the threshold during the peak period, or tighten the threshold during the low peak period. The logic of such dynamic adjustment aims to avoid false positives caused by fixed thresholds, while ensuring timely alarm in real abnormal situations. The core is to establish a failure judgment standard that can adapt to the periodic changes of business and has flexibility.

[0154] In the microservice architecture, the overload of the downstream node is often not isolated, but it is likely to be caused by the upstream node initiating traffic exceeding its processing capacity. For example, an upstream service initiates a retry storm due to code defects, or sends a large number of invalid requests to the downstream due to logic errors, which will directly cause the downstream service to overload. By marking the upstream node as the failure source, the system can quickly locate the root cause of the problem, rather than just dealing with the surface symptoms (i.e. downstream overload). Although this causal relationship is not absolute, there may be cases where the downstream itself is overloaded due to memory leaks, etc., but in most scenarios, this upward tracing strategy can effectively narrow down the scope of troubleshooting and provide a clear intervention target for subsequent automatic repair measures (such as rate limiting on the upstream).

[0155] Starting from the data shard handled by the fault source, the traffic affinity edges in the instance relationship graph are traversed to perform a depth assessment of the impact scope. The failure of a node is not limited to the node itself, but also spreads to other related business domains through data association. For example, a microservice instance that handles order data fails. According to the traffic affinity edges constructed earlier, the system knows that requests accessing order data usually also access user and inventory data. Therefore, the purpose of this traversal operation is to find all other data shards that have strong association with the data handled by the failed node, so as to predict the business scope that may be affected by the failure, such as user query and inventory management functions, to provide decision basis for subsequent risk control and user notification.

[0156] The traversal rule of the traffic affinity edge adopts a breadth-first search (BFS) algorithm with depth limit. The system starts from the data shard node corresponding to the fault source and accesses all adjacent nodes reachable through traffic affinity edges layer by layer. In order to avoid infinite loops in complex affinity relationship networks, the algorithm sets a maximum traversal depth, for example, a maximum of 3 layers. At the same time, the system maintains a record table of visited nodes to ensure that each node is only visited once in a single traversal. This design can effectively control the calculation overhead while ensuring sufficient coverage of the impact scope, preventing the problem of algorithm termination due to circular dependency (e.g. A is associated with B, B is associated with C, and C is associated with A).

[0157] The affected data domain specifically represents a set of multiple data shards that are logically closely related. The data shards in this set are likely to be affected by the same fault event due to the existence of traffic affinity relationship. It represents a potential business risk unit. After 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 how much impact the system as a whole will suffer if all services in the entire domain are affected. In addition, this aggregated data domain information can also be used to guide subsequent backup and recovery strategies to ensure that critical business data can be restored preferentially in the event of a disaster.

[0158] The specific algorithm for reverse graph traversal in the service invocation topology subgraph usually adopts breadth-first search (BFS), because BFS can find all upstream nodes that affect the fault source layer by layer, and is very suitable for analyzing the conduction path of risk. The starting point of traversal is all the same group nodes corresponding to the affected data domain determined earlier, and the direction of traversal is along the reverse direction of the edges in the invocation topology subgraph. The stopping condition of traversal is when all root nodes without more upstream nodes are found, or when the traversal depth reaches the preset upper limit, the algorithm stops. This means that the system will find all services that directly or indirectly call the fault source node, thereby constructing a complete invocation link graph.

[0159] First, the system will list all complete invocation paths from the most upstream root node to the fault source node based on the results of reverse graph traversal. Then, the system will assign a risk weight to each directed edge on each path, which can be calculated based on the invocation frequency and average response time of the edge, for example, the higher the invocation frequency and the longer the response time of the edge, the higher the risk weight. Finally, the system calculates the total risk value of each path by accumulating the risk weights of all edges on the path, and sorts all paths in descending order of risk value. In this way, the system not only identifies the propagation path of risk, but also quantifies the danger level of different paths, thereby helping operation and maintenance personnel to prioritize the most critical invocation links.

[0160] Faults in actual systems can correspond to a variety of specific situations, including but not limited to: service instances stop responding due to resource exhaustion (such as CPU full, memory overflow); service instances have a dead loop, causing CPU utilization to remain at 100%; the connection pool of the service instance and the database is exhausted and cannot handle new requests; the external system (such as a third-party payment gateway) on which the service instance depends fails, causing a large number of requests to timeout; or the service instance introduces a serious program defect after deploying a new version, causing frequent exceptions when processing requests. The need to determine the risk propagation path is to prevent the scope of impact from expanding indefinitely when these faults occur, quickly understand the system boundaries that may be affected by the fault, and take precise isolation and recovery measures.

[0161] 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.

[0162] 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.

[0163] 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.

[0164] 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.

[0165] The existence of an example replacement pair means that when a certain service instance on the path fails, the system is ready to seamlessly take over its work with a pre-warmed, functionally identical new instance. If there is such a replacement pair on the path, it means that the path is more resilient, and the system can choose a more gentle, more focused on protecting downstream services degradation strategy, namely the pre-warming protection mode; on the contrary, if there is no replacement pair on the path, it means that once a node fails, there will be no standby instance to replace it, and the system must take more decisive and aggressive measures to protect itself, namely the standard degradation mode.

[0166] After determining the target degradation strategy, the intelligent decision-making module will broadcast a degradation instruction to all microservice instances corresponding to the nodes on the risk propagation path. This instruction contains two core pieces of information: one is the affected data domain obtained through previous analysis, and the other is the target degradation strategy determined this time.

[0167] The broadcast mechanism usually adopts the publish / subscribe mode, such as through message queues or service mesh control planes, to quickly and reliably distribute the instruction to every relevant instance on the path. The format of the instruction is standardized to ensure that all instances can correctly parse and execute it, and its content specifies which business data needs special handling and which degradation behavior should be adopted.

[0168] The microservice instance that receives the degradation instruction will enter a special degradation execution mode. It first checks the business identifier of the real-time work order task request currently received, and determines whether the data to be processed by the request belongs to the affected data domain specified in the instruction by querying the data shard mapping relationship stored in the instance relationship graph. This judgment is the prerequisite for executing all subsequent degradation behaviors, ensuring that only fault-related requests are specially handled, while unrelated normal business requests continue to be processed according to the original process, thereby minimizing the interference with the overall function of the system.

[0169] If the judgment result is that the request belongs to the affected data domain and the target degradation strategy is the pre-warming protection mode, the microservice instance will take a circuit-breaking protection measure. It will immediately interrupt any calls to downstream microservice instances to prevent the fault from further spreading downstream. At the same time, in order 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 be returned directly; if not, a preset, business logic-compliant default value or static response will be returned. The core of this mode is protection, which sacrifices part of the integrity of the function to exchange for the stability of the downstream system and the rapidity of fault isolation.

[0170] If the judgment result is that the request belongs to the affected data domain, but the target degradation policy is the standard degradation mode, the microservice instance adopts a more active and exploratory recovery strategy. It also enables local caching to handle requests to reduce pressure on the downstream. But unlike the warm-up protection mode, it does not completely interrupt the call to the downstream, but continuously sends a pre-constructed simulation request sequence to the downstream microservice instance at a preset very low rate (for example, 1 request per second). This simulation request sequence is generated by the system according to the historical request characteristics of the service, which can simulate real business requests. By monitoring the response state (such as response time, success rate) of the downstream microservice instance when processing these simulation requests, the system can detect in real time and safely whether the downstream service has recovered to normal, providing a basis for decision-making for subsequent recovery of full traffic.

[0171] The embodiment of the application determines the logical relationship of the microservice instances and the state attribute of the logical relationship according to the event sequence in the instance lifecycle event stream, so as to bypass the registration center by listening to the containerization layer event, and determine the microservice instance that is being closed according to the event sequence in the instance lifecycle event stream; remove the microservice instance in the replacement relationship and with the closed state attribute from the candidate instance set to obtain a safe candidate instance set, determine the target microservice instance based on the real-time load indicators of each instance in the safe candidate instance set, and send the work order task request and the target microservice instance to the load balancing layer, so as to avoid determining the microservice instance that is being closed as the target microservice instance, that is, avoid the time difference between the actual state of the service instance and the state perceived by the load balancer, which interferes with the task request distribution of the load balancer, thereby improving the distribution ability of the load balancer for the work order task request in the microservice architecture.

[0172] On the other hand, a microservice-based work order processing method based on dynamic load balancing is also provided, which is applied to a microservice architecture including a load balancing layer, a plurality of microservice instances and a containerization management layer. The method comprises: real-time listening to the instance lifecycle event stream generated by the containerization management layer due to the change of the instance state, and determining the logical relationship of the microservice instances and the state attribute of the logical relationship according to the event sequence in the instance lifecycle event stream; determining a candidate instance set according to the real-time load indicators of the microservice instances; removing the microservice instance in the replacement relationship and with the closed state attribute from the candidate instance set to obtain a safe candidate instance set; determining a target microservice instance based on the real-time load indicators of each instance in the safe candidate instance set; and sending a work order task request and the target microservice instance to the load balancing layer.

[0173] Those skilled in the art will appreciate that embodiments of the present application can be readily used as a method, a system or a computer program product. Accordingly, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application can take the form of a computer program product on one or more computer-usable storage media (or computer- readable storage media) having computer-usable program code embodied in the medium. The medium can be any available medium or combination thereof that is accessible by a general purpose or special purpose computer. By way of example, such computer-usable storage media can include a volatile memory, a non-volatile memory, a hard disk drive, a solid state drive, a magnetic diskette, an optical disk (e.g., a compact disk (CD) or a digital versatile disk (DVD)), or a floppy disk, all of which are tangible of computer- readable media. The computer-usable program code, when executed, can enable a general purpose computer, special purpose computer, or other programmable data processing apparatus to perform a method in accordance with the article of manufacture containing the computer program code. The software is able to operate in Figure 1 one or more functions specified in the flow or flows and / or blocks Figure 1 one or more functions specified in the flow or flows and / or blocks

[0174] It should be noted that the above-mentioned embodiments are only used to illustrate but not to limit the technical solutions of the present application. Although the present application is described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present application can be modified or replaced equivalently without departing from the spirit and scope of the technical solutions of the present application, and they should be covered in the scope of the claims of the present application.

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 to: 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 balancing layer; 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. 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, collect the historical request logs of the second microservice instance within a second preset time window; 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.

2. The system as described in claim 1, 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.

3. The system as described in claim 2, 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.

4. The system as described in claim 3, 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.

5. The system as described in claim 4, 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.

6. The system as described in claim 5, 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.

7. The system as described in claim 6, 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.

8. 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 balancing layer; The process of determining the logical relationships between microservice instances and the state attributes of these logical relationships includes: 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. Collect historical request logs of the second microservice instance within a second preset time window; 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.

Images