A large model-based cross-architecture microservice scheduling management system

Abstract

The embodiment of the application provides a cross-architecture micro-service scheduling management system based on a large model, comprising: a cross-CPU architecture probe deployed on each computing node, used for collecting multi-element data of the computing node, the multi-element data comprising static instruction set features and dynamic runtime performance data; an instruction set perception layer, used for receiving and processing the multi-element data, and generating a performance portrait corresponding to the multi-element data through a large model; an intelligent monitoring layer, used for dynamically generating architecture-specific monitoring indicators based on the performance portrait and an architecture knowledge graph; a scheduling optimization layer, used for generating a service scheduling scheme according to the architecture-specific monitoring indicators and a preset multi-target dynamic balancing algorithm; and a drift adaptation layer, used for, when receiving a down drift instruction, driving a mirror real-time adaptation engine through a large model, and calling a mirror adaptation rule to perform service instance migration across the CPU architectures; the embodiment realizes maximum exertion of service performance and efficient utilization of cluster resources.

Description

Technical Field

[0001] This application relates to the fields of cloud computing and microservices technology, and in particular to a cross-architecture microservice scheduling and management system based on a large model. Background Technology

[0002] With the rapid development of cloud computing and microservice architectures, hybrid CPU architecture deployment has become a mainstream trend in key areas such as data centers, government clouds, and the industrial internet. In the current environment, the coexistence of x86 (amd64), ARM (aarch64), and domestically developed architectures has become the norm. These architectures differ significantly in instruction set design, computing unit configuration, and memory access patterns. Taking the LoongArch architecture as an example, its unique LSX vector instruction set exhibits excellent performance in AI inference scenarios, while the SW64 architecture demonstrates unique advantages in scientific computing. Against this backdrop, traditional microservice monitoring and scheduling systems primarily achieve basic cross-architecture service deployment through simple matching of node labels, but have not yet delved into performance optimization and fault diagnosis at the instruction set level, creating a technical management bottleneck in hybrid architecture environments.

[0003] However, existing technical solutions exhibit three core flaws when dealing with such complex heterogeneous environments: First, performance scheduling is severely disconnected from CPU instruction set characteristics. General scheduling algorithms only focus on macro-level metrics such as CPU utilization and memory usage, failing to perceive the differences in instruction execution efficiency across different architectures. This results in significant performance discrepancies for the same microservice running on nodes with different architectures. Second, cross-architecture service migration compatibility is severely inadequate. Existing solutions rely on pre-compiled multi-architecture Docker images, but the coverage of images for domestic architectures is generally low. When a node fails and cross-architecture migration is required, the service startup failure rate exceeds 50%. Finally, the monitoring and early warning system lacks architecture specificity. General monitoring metrics cannot effectively capture architecture-specific fault modes such as memory access conflicts in aarch64 and vector operation anomalies in loongarch, resulting in an average root cause location time exceeding 30 minutes. These three technical flaws collectively constitute the core obstacle to efficient operation and maintenance of microservices in hybrid CPU architecture environments, and these flaws urgently need to be addressed. Summary of the Invention

[0004] In view of this, embodiments of this application provide a cross-architecture microservice scheduling and management system based on a large model. One or more embodiments of this application also relate to a cross-architecture microservice scheduling and management method based on a large model, a computing device, a computer-readable storage medium, and a computer program, to address the technical deficiencies existing in the prior art.

[0005] In a first aspect, embodiments of this application provide a cross-architecture microservice scheduling and management system based on a large model, including: A cross-CPU architecture probe is deployed on each compute node to collect multi-data elements of the compute node, including static instruction set characteristics and dynamic runtime performance data. The instruction set awareness layer is communicatively connected to the cross-CPU architecture probe and is used to receive and process the multi-dimensional data, and generate a performance profile corresponding to the multi-dimensional data through a large model. The intelligent monitoring layer, which is communicatively connected to the instruction set perception layer, is used to dynamically generate architecture-specific monitoring metrics based on the performance profile and architecture knowledge graph. The scheduling optimization layer, which is connected to the intelligent monitoring layer, is used to generate a service scheduling scheme based on the architecture-specific monitoring indicators and a preset multi-objective dynamic balancing algorithm. The drift adaptation layer, which is connected to the scheduling optimization layer, is used to migrate service instances across CPU architectures by using the large model-driven real-time image adaptation engine and calling image adaptation rules when a crash drift instruction is received. The data storage center is used to store the multi-dimensional data, the performance profile, the architecture-specific monitoring metrics, the architecture knowledge graph, and the image adaptation rules.

[0006] In one possible implementation, the instruction set awareness layer includes an instruction set feature acquisition submodule; wherein the instruction set feature acquisition submodule is configured to: acquire the static instruction set features, specifically including instruction set type, number of registers and extended instruction support bitmap; acquire the dynamic runtime performance data, specifically including CPI value, cache hit rate at each level and extended instruction utilization; and perform outlier processing and verification on the acquired data.

[0007] In one possible implementation, the instruction set awareness layer further includes a large model performance prediction submodule; The large model performance prediction submodule is configured to: fuse the static instruction set features and the dynamic runtime performance data with the resource requirement features of the target service to generate a feature vector for performance prediction; process the feature vector using a pre-trained large model to output the performance score of the target service on candidate nodes; and select a set of candidate nodes suitable for scheduling the target service based on the performance score and a preset resource utilization threshold.

[0008] In one possible implementation, the large model-driven real-time image adaptation engine includes: The source architecture image is parsed using ELF parsing to extract code segments, dynamic dependencies, and symbol tables. The instruction sequence of the source architecture is then parsed based on the code segments. Based on a pre-built architecture instruction mapping table and the large model, the instruction sequence of the source architecture is translated into the instruction sequence of the target architecture. Based on the instruction sequence of the target architecture, the dynamic dependencies, and the symbol table, a service instance image of the target architecture is constructed, and compatibility verification is performed.

[0009] In one possible implementation, the multi-objective dynamic balancing algorithm preset in the scheduling optimization layer is a reinforcement learning algorithm based on a three-dimensional reward function, which includes time reward, cost reward and quality reward. The formula for calculating the time reward is as follows:

[0010] in, Indicates a time-based reward. Indicates the actual completion time of the target service. This represents the theoretical shortest completion time for the target service. This represents the service dependency coefficient.

[0011] In one possible implementation, the formula for calculating the quality reward is:

[0012] in, This indicates a quality reward. This represents the failure rate of the target service within a preset sliding time window. This represents the standard deviation of the target service response time within a preset sampling period. This represents the average response time of the target service within the sampling period; The formula for calculating the cost incentive is as follows:

[0013] in, Indicates cost incentive, This represents the actual resource cost of the target service during the scheduling period. This represents the budgeted cost allocated to the target service. This represents the penalty factor associated with resource idle time.

[0014] In one possible implementation, the intelligent monitoring layer is further configured to: mine architecture-related indicator association rules from historical fault data based on the FP-Growth algorithm to construct and update the architecture knowledge graph; the architecture knowledge graph includes indicator nodes, log nodes, and root cause nodes, wherein the nodes are connected by edges with confidence and support attributes.

[0015] In one possible implementation, when executing the multi-objective dynamic balancing algorithm, the scheduling optimization layer uses the NSGA-III algorithm to generate candidate scheduling schemes and selects the target execution scheme from the selected non-dominated solutions using the ε-greedy algorithm.

[0016] In one possible implementation, the scheduling optimization layer is configured as follows: When an optimization conflict between any two objectives in the three-dimensional reward function is detected to exceed a first preset threshold, the weight allocation module of the scheduling optimization layer is triggered to dynamically adjust the calculation weights of time, cost, and quality in the total reward function, wherein the total reward function consists of the time reward, the cost reward, and the quality reward. In response to externally input system-level scheduling policy instructions, the calculation weights of the three-dimensional rewards are set; The scheduling optimization layer is further configured as follows: Continuously monitor the combined standard deviation of multiple candidate scheduling schemes across three dimensions: time, cost, and quality during the optimization process; When the overall standard deviation of the optimization after m consecutive iterations exceeds the second preset threshold, the system is determined not to be in a convergence trend, and the following adjustment operations are performed: Based on the first downgrade coefficient, the exploration rate of the scheduling optimization layer is reduced; Based on the first adjustment factor, the learning rate of the scheduling optimization layer is increased.

[0017] In one possible implementation, the drift adaptation layer is further configured as follows: When a node failure is detected, the following steps are executed synchronously: Call the container runtime interface to obtain the image of the target architecture. If the acquisition fails, retry several times. If the acquisition still fails after retrying, retrieve the image of the target architecture in the local cache. If the retrieval fails, trigger the large model-driven real-time image adaptation engine to generate the image of the target architecture. Service state synchronization is performed based on the Raft distributed consensus protocol. When an election timeout is detected, several re-elections are conducted. If the re-election fails, the system switches to a degraded operation mode, temporarily storing the service state locally. Delayed state synchronization is then performed once communication is restored.

[0018] Secondly, embodiments of this application provide a cross-architecture microservice scheduling and management method based on a large model, applied to the cross-architecture microservice scheduling and management system based on a large model provided in the first aspect. The method includes: Multi-data elements of computing nodes are collected through cross-CPU architecture probes, including static instruction set characteristics and dynamic runtime performance data. The multi-dimensional data is received and processed through the instruction set perception layer, and a performance profile corresponding to the multi-dimensional data is generated through a large model. Based on the performance profile and architecture knowledge graph, the intelligent monitoring layer dynamically generates architecture-specific monitoring metrics. The scheduling optimization layer generates a service scheduling scheme based on the architecture-specific monitoring indicators and a preset multi-objective dynamic balancing algorithm. When a crash drift instruction is received, the drift adaptation layer uses a large model-driven real-time image adaptation engine and calls image adaptation rules to migrate service instances across CPU architectures.

[0019] Thirdly, embodiments of this application provide a computing device, including: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, they implement the steps of the above-described cross-architecture microservice scheduling and management method based on a large model.

[0020] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the aforementioned cross-architecture microservice scheduling and management method based on a large model.

[0021] Fifthly, embodiments of this application provide a computer program, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described cross-architecture microservice scheduling and management method based on a large model.

[0022] The technical solution provided in this application collects multi-data, including static instruction set features and dynamic runtime performance, through cross-CPU architecture probes deployed on each computing node. The instruction set awareness layer processes this data based on large-model technology to generate a performance profile that deeply reflects the service-architecture matching relationship. The intelligent monitoring layer combines a pre-built architecture knowledge graph to dynamically generate accurate architecture-specific monitoring metrics. The scheduling optimization layer uses a multi-objective dynamic balancing algorithm to generate the optimal service scheduling scheme based on real-time metrics. When a node failure is detected, the drift adaptation layer quickly completes the migration of service instances across CPU architectures through a large-model-driven real-time image adaptation engine. The entire system achieves unified management and retrieval of data from each layer through a data storage center. This solution effectively solves three major technical challenges in hybrid architecture environments: inaccurate service performance scheduling, low cross-architecture drift success rate, and low fault location efficiency, achieving maximum service performance and efficient utilization of cluster resources. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the architecture of a cross-architecture microservice scheduling and management system based on a large model, provided in one embodiment of this application; Figure 2 This is a schematic diagram of a cross-architecture microservice scheduling and management system based on a large model, provided in one embodiment of this application; Figure 3 This is a flowchart of a cross-architecture microservice scheduling and management method based on a large model, provided in one embodiment of this application; Figure 4 This is a structural block diagram of a computing device provided in one embodiment of this application. Detailed Implementation

[0024] Many specific details are set forth in the following description to provide a full understanding of this application. However, this application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this application; therefore, this application is not limited to the specific embodiments disclosed below.

[0025] The terminology used in one or more embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this application. The singular forms “a” and “the” as used in one or more embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this application refers to and includes any or all possible combinations of one or more associated listed items.

[0026] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this application, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this application, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0027] This application provides a cross-architecture microservice scheduling management system and method based on a large model. This application also relates to a computing device and a computer-readable storage medium, which will be described in detail in the following embodiments.

[0028] See Figure 1 , Figure 1 This illustration shows an architecture diagram of a cross-architecture microservice scheduling and management system based on a large model, according to an embodiment of this application.

[0029] exist Figure 1 The architecture diagram shown adopts a "distributed layered + regionalized deployment" architecture, supporting cluster expansion from 100 to 1000 nodes. Each layer communicates with each other through dual protocols: REST API v2.0 (e.g., timeout of 300ms) and gRPC v1.54.0 (maximum concurrent connections of 1000). The end-to-end communication latency is ≤100ms (e.g., test environment: 100-node cluster, network bandwidth of 10Gbps, packet loss rate ≤0.1%).

[0030] Regarding deployment levels This layer specifically includes the core area (scheduling layer / drift layer, dual-machine hot standby), the edge area (perception layer / monitoring layer, deployed by rack partition), and the storage area (3-replica sharded storage).

[0031] Regarding redundancy The service interface gateway is deployed with 2 instances (IP: 192.168.1.100), and the data storage center uses Ceph distributed storage (3 replicas, 128 shards).

[0032] Regarding network isolation The perception layer communicates with the monitoring layer via VLAN 100, and the scheduling layer communicates with the drift layer via VLAN 200, both using 802.1Q tags.

[0033] The following example uses a specific configuration table as an illustration: Table 1

[0034] The following explains the interaction logic between the layers in the system. Perception layer → Monitoring layer: Normal process: Probe collects data → Zstandard compression (compression level 6, compression ratio ≥30%) → gRPC (port 50051, TLS encryption) transmission → monitoring layer decompression → normalization (Min-Max normalization to [0,1]) Anomaly Handling: When a gRPC connection times out (≥500ms), the probe caches data locally (maximum 1GB, cleared in FIFO order when full), and then uploads it in batches after recovery (upload rate ≤10MB / s to avoid network congestion). Monitoring layer → Scheduling layer: Normal process: The monitoring layer generates metrics → distributes them to the scheduling layer according to the architecture type (amd64 metrics are sent to scheduling instance A, loongarch / SW64 metrics are sent to scheduling instance B) → the scheduling layer caches the metrics (caching time 5 minutes). Anomaly Handling: When a metric exceeds a threshold, a Level 3 alarm (Warning / Critical / Urgent) is triggered. Urgent alarms are pushed directly to the operations and maintenance platform (response time ≤ 1 second). Scheduling layer → Drift layer: Normal process: Scheduling plan generation → JSON format (size ≤ 1KB) transmission via HTTPS (TLS 1.3) → Received by the drift layer and verified signature (RSA 2048 bits) Exception handling: If the scheme verification fails, request the scheduling layer to resend (resend 3 times, with an interval of 2 seconds). If it still fails, trigger manual intervention.

[0035] Figure 2 This is a schematic diagram of a cross-architecture microservice scheduling and management system based on a large model, provided as an embodiment of this application.

[0036] Reference Figure 2 As shown, the system may include: The cross-CPU architecture probe 201 is deployed on each compute node to collect multi-data information of the compute node, including static instruction set characteristics and dynamic runtime performance data. The instruction set perception layer 202 is connected to the cross-CPU architecture probe 201 to receive and process multi-dimensional data and generate a performance profile corresponding to the multi-dimensional data through a large model. The intelligent monitoring layer 203 communicates with the instruction set perception layer 202 and is used to dynamically generate architecture-specific monitoring metrics based on performance profiles and architecture knowledge graphs. The scheduling optimization layer 204 communicates with the intelligent monitoring layer 203 and is used to generate service scheduling schemes based on architecture-specific monitoring indicators and preset multi-objective dynamic balancing algorithms. The drift adaptation layer 205 communicates with the scheduling optimization layer 204. When a crash drift instruction is received, it uses the large model-driven real-time image adaptation engine and calls the image adaptation rules to migrate service instances across CPU architectures. Data storage center 206 is used to store diverse data, performance profiles, architecture-specific monitoring metrics, architecture knowledge graphs, and image adaptation rules.

[0037] Regarding cross-CPU architecture probes In some embodiments, the cross-CPU architecture probe acts as a lightweight data acquisition agent deployed on each computing node. Its core function is to comprehensively acquire two key types of information: node hardware architecture and runtime status. Specifically, it collects static instruction set characteristics, including inherent hardware attributes such as CPU architecture type (e.g., x86, ARM, or LoongArch), supported extended instruction set bitmaps, and register size. Simultaneously, it captures dynamic runtime performance data in real time, covering micro-architectural behaviors such as instruction-level metrics (e.g., CPI cycles), cache hit rate, and vector instruction utilization. After standardization and preliminary verification, this diverse data is uploaded to the instruction set awareness layer in real time via an efficient communication protocol. This provides an indispensable data foundation for subsequently building accurate performance profiles and implementing intelligent scheduling with instruction set awareness, thus solving the core pain points of traditional monitoring tools in hybrid architecture environments: insufficient data acquisition granularity and missing architectural features.

[0038] Regarding the instruction set perception layer In some embodiments, the instruction set awareness layer includes an instruction set feature acquisition submodule; wherein the instruction set feature acquisition submodule is configured to: acquire the static instruction set features, specifically including instruction set type, number of registers and extended instruction support bitmap; acquire the dynamic runtime performance data, specifically including CPI value, cache hit rate at each level and extended instruction utilization rate; and perform outlier processing and verification on the acquired data.

[0039] In one implementation, the specific configuration parameters of the instruction set feature acquisition submodule are as follows: Compilation toolchain: LLVM 16.0.0 + Rust 1.72.0, with the -O3 optimization option enabled, and binary files compressed using UPX (compression ratio 50%, startup time ≤100ms). Data collection triggering mechanism: Static features (updated every 1 hour) use a scheduled task (crontab * * / 1 * * *), and dynamic features (updated every 100ms) use a kernel timer (timerfd_create, period 100ms).

[0040] The data collection items are described in Table 2 below: Table 2

[0041] In some embodiments, the instruction set feature acquisition submodule, as the core data preprocessing unit of the instruction set awareness layer, undertakes the crucial functions of refined data acquisition and quality control. After acquiring raw data from cross-CPU architecture probes through a standardized data interface, this submodule first systematically extracts static instruction set features, including accurately identifying the CPU's instruction set architecture type, quantifying register resource size, and recording the support status for specific extended instruction sets in bitmap form. Simultaneously, it continuously acquires dynamic runtime performance data at millisecond-level frequencies, covering CPI values ​​reflecting instruction execution efficiency, L1 / L2 / L3 cache hit rates characterizing memory subsystem performance, and the actual utilization rate of extended instructions indicating specific computing power utilization. To ensure data reliability, the submodule incorporates a multi-level data cleaning pipeline, using methods such as threshold comparison, continuity checks, and statistical outlier detection to perform real-time outlier processing and validity verification on the raw readings. This provides the upper-layer large-model performance prediction module with a standardized input dataset that has undergone rigorous quality control, laying the data foundation for the entire system to achieve accurate instruction set awareness scheduling.

[0042] In some embodiments, the instruction set awareness layer further includes a large model performance prediction submodule; wherein the large model performance prediction submodule is configured to: fuse static instruction set features and dynamic runtime performance data with the resource requirement features of the target service to generate a feature vector for performance prediction; process the feature vector using a pre-trained large model to output a performance score of the target service on candidate nodes; and select a set of candidate nodes suitable for scheduling the target service based on the performance score and a preset resource utilization threshold.

[0043] In one implementation, the training refinement process of the large model performance prediction submodule includes: Training data sources: 5 types of services (Web / AI inference / data storage / computation / message queue), 20,000 samples per type, covering 4 architectures (amd64 / aarch64 / loongarch / SW64) Data cleaning steps: ① Remove samples with missing values ​​> 10% (approximately 3% of the total sample); ② Use the 3σ principle to remove CPI outliers (approximately 5%); ③ Time series smoothing (sliding window 3 times).

[0044] Model fine-tuning parameters: batch size 32, optimizer AdamW (weight decay 0.01), learning rate warm-up (increase from 1e-6 to 2e-5 in the first 10 rounds, then linearly decay to 1e-6 in the next 90 rounds). Validation results: The test set accuracy was 92.3%, with the LoongArch architecture achieving the highest accuracy (95.1%), followed by SW64 (93.7%), and the amd64 architecture achieving the lowest accuracy (89.2%) (due to the numerous variants of the amd64 instruction set). Real-time reasoning supplement: Feature vector dimension description: Static features are 16-dimensional (4-dimensional One-Hot instruction set type + 1-dimensional register quantity + 11-dimensional bitmap of extended instruction support), dynamic features are 24-dimensional (time-series features such as CPI and cache hit rate), and service features are 8-dimensional (4-dimensional One-Hot service type + 4-dimensional resource requirements). Candidate node selection logic: In addition to a score ≥80 and resource utilization ≤70%, the following criteria have been added: "Network latency ≤5ms" (cross-rack nodes) and "Deployment in the same region" (local nodes are preferred to reduce cross-region traffic). Training branch: After fine-tuning the model → 5-fold cross-validation → if accuracy ≥ 92%, deploy; otherwise, adjust the learning rate and retry (maximum 3 times). Reasoning branches: After outputting the score, determine if there are nodes in the same region. If yes (priority filtering) → if no (cross-region filtering, network latency weighting).

[0045] In some embodiments, the large model performance prediction submodule serves as the intelligent decision-making core of the instruction set awareness layer. First, it integrates collected static instruction set features, dynamic runtime performance data, and resource requirement features of the target service through feature engineering to construct a feature vector that comprehensively represents the "service-architecture" adaptation relationship. Then, it inputs this vector into a large model pre-trained with massive amounts of cross-architecture performance data for deep inference, generating a precise quantitative performance score to predict the theoretical operating efficiency of the target service on each candidate node. Finally, based on this score and coupled with a preset resource utilization threshold, a multi-condition filtering mechanism is used to select a set of candidate nodes from the cluster that simultaneously meet the requirements of optimal performance and resource constraints. This provides the upper-layer scheduler with a data-driven scientific decision-making basis, realizing a fundamental shift from traditional rule-based scheduling to AI-predictive intelligent scheduling.

[0046] Regarding the intelligent monitoring layer In some embodiments, the intelligent monitoring layer receives performance profiles generated by the instruction set awareness layer in real time and combines them with a pre-built architecture knowledge graph (which includes multi-dimensional relationships between indicator nodes, log nodes, and root cause nodes). It then uses association rule mining algorithms to dynamically analyze the performance characteristics and fault modes under different CPU architectures, thereby generating a monitoring indicator system that is deeply adapted to the specific architecture characteristics. This system can not only track micro-indicators such as the LSX vector instruction usage efficiency of the Loongarch architecture and the SIMD unit load of the SW64 architecture in real time, but also establish a mapping relationship between indicator anomalies and potential root causes through the reasoning ability of the knowledge graph. Finally, it forms a precise monitoring view with architecture awareness, which completely solves the core pain points of traditional monitoring solutions in hybrid architecture environments, such as indicator generalization and low diagnostic accuracy.

[0047] In some embodiments, the intelligent monitoring layer is further configured to: mine architecture-related indicator association rules from historical fault data based on the FP-Growth algorithm to construct and update an architecture knowledge graph; the architecture knowledge graph includes indicator nodes, log nodes, and root cause nodes, wherein the nodes are connected by edges with confidence and support attributes.

[0048] The intelligent monitoring layer integrates the FP-Growth association rule mining algorithm to perform in-depth analysis of historical fault data, automatically discovering hidden correlation patterns between monitoring metrics, log events, and root causes of faults under different CPU architectures, and dynamically constructing and optimizing an architecture knowledge graph based on this. This knowledge graph adopts a multi-dimensional node structure, where metric nodes carry architecture-specific performance parameters (such as vector instruction error rate), log nodes record abnormal events in the kernel and application layers, and root cause nodes correspond to specific hardware or software fault entities. Semantic associations are established between nodes through edges with confidence and quantifiable attributes, forming interpretable fault reasoning paths. Ultimately, a diagnostic knowledge base with continuous evolution capabilities is constructed, providing core reasoning basis for architecture-aware monitoring.

[0049] In one implementation, large model training involves using the FP-Growth algorithm to mine association rules. The minimum support is 0.05 (meaning each rule must cover ≥5% of the fault samples), and the minimum confidence is 0.8 (meaning the rule's probability of being true is ≥80%). Twelve core rules are identified, such as "loongarch node LSX error rate > 0.05% ∧ CPI > 3.0 → Vector instruction hardware failure" (confidence 91.2%). In one implementation, the attribute scale of the architecture knowledge graph is as follows: Node attributes: Metric nodes include "unit / threshold / collection frequency", log nodes include "log source (kernel / application) / log level (info / warn / error)", and root cause nodes include "fault level (P1-P4) / repair time".

[0050] Relationship attributes: Each relationship includes "confidence / support", such as "LSX vector operation error rate anomaly → vector op fail log" with a confidence of 93.5% and a support of 6.2%.

[0051] Graph size: 128 nodes in total (32 indicator nodes, 64 log nodes, and 32 root cause nodes), 256 relationships (64 anomaly relationships, 96 causal relationships, 48 ​​architecture relationships, and 48 solution relationships).

[0052] In one implementation, the indicator node is as follows: “loongarch_LSX error rate > 0.05%” → (Abnormal correlation, confidence 93.5%) → Log node “kernel: vector op fail (addr:0x1234)” → (Causal correlation, confidence 89.7%) → Root cause node “loongarch vector operation unit failure (P2)” → (Solution correlation) → “Restart node and check hardware”.

[0053] In one implementation, the positioning process is as follows: Log keyword extraction: Regular expression matching (e.g., matching "vector op fail" and "unalignedaccess") + TF-IDF (Top 5 keywords) is used, and the extraction time is ≤500ms.

[0054] Association Analysis: Improve the Apriori algorithm by introducing "architecture weights", such as loongarch architecture association weight of 1.2 and amd64 weight of 0.8, to avoid cross-architecture rule interference.

[0055] Inference optimization: The TransE algorithm has a path search depth of ≤3 layers, a number of nodes per layer of ≤20, and an inference time of ≤1s. Among them, P1 level faults (such as node crashes) are prioritized for inference (response time ≤500ms).

[0056] Regarding the scheduling optimization layer In some embodiments, the preset multi-objective dynamic balancing algorithm in the scheduling optimization layer is a reinforcement learning algorithm based on a three-dimensional reward function, which includes time reward, cost reward and quality reward. The formula for calculating the time reward is as follows:

[0057] in, Indicates a time-based reward. Indicates the actual completion time of the target service. This represents the theoretical shortest completion time for the target service. This represents the service dependency coefficient.

[0058] The formula for calculating quality rewards is:

[0059] in, This indicates a quality reward. This indicates the failure rate of the target service within a preset sliding time window. This represents the standard deviation of the target service response time within a preset sampling period. This represents the average response time of the target service within the sampling period.

[0060] The formula for calculating cost incentives is:

[0061] in, Indicates cost incentive, This represents the actual resource cost of the target service during the scheduling period. This represents the budgeted cost allocated to the target service. This represents the penalty factor associated with resource idle time.

[0062] In one implementation, the time reward is modeled as follows: Theoretical minimum time calculation: Based on the DAG task dependency graph, an improved critical path method (CPM) is used, combined with the real-time computing power (FLOPS) of each node and the service data volume (GB) to calculate the theoretical value. For example, for a process containing 3 dependent services, service A (10GB of data) needs to be executed on node 1 (200GFLOPS), service B (5GB) depends on A and needs to be executed on node 2 (150GFLOPS). The theoretical time is calculated using the formula T = Σ(data volume × processing coefficient / node computing power) + transmission latency (the processing coefficient is dynamically adjusted according to the service type, such as 1.2 for AI inference services), accurate to the 10ms level.

[0063] Dynamic adjustment of service dependency coefficients: A dependency strength matrix is ​​constructed, with direct dependencies (such as payment services depending on account services) having a coefficient of 1.5, indirect dependencies (such as recommendation services depending on log services) having a coefficient of 1.1, and no dependencies having a coefficient of 1.0. When a latency is detected in a dependent service (exceeding the theoretical value by 20%), the coefficient automatically increases to 1.8, strengthening the optimization weight of the critical path.

[0064] Real-time correction mechanism: The actual completion time is collected every 100ms. If the deviation from the theoretical value exceeds 15% for 3 consecutive times, the large model is triggered to recalculate the theoretical value to avoid the distortion of rewards due to resource fluctuations.

[0065] In one implementation, the end-to-end cost incentive calculation method is as follows: Dynamic breakdown of resource costs: Costs are broken down into basic rental fees (billed hourly), elastic scaling fees (billed minutely), and data transfer fees (billed per GB across architecture nodes). Unit prices are retrieved in real-time and the cost model is updated by connecting to the cloud vendor's billing API.

[0066] Dynamic allocation of budget expenses: The time-slice budget splitting method is adopted, and the daily budget is allocated according to the 24-hour load curve. When the actual consumption exceeds the allocated amount by 20% in a certain period, the budget adjustment for the next period is automatically triggered (up to 15%) to avoid overall overspending.

[0067] The idle time penalty is calculated in a tiered manner: no penalty for resource idle time <5 minutes, coefficient ×0.8 for 5-10 minutes, ×0.6 for 10-30 minutes, and ×0.4 for >30 minutes. The penalty coefficient is also related to the node type (edge ​​nodes have an additional ×1.2 penalty coefficient due to their high hardware cost).

[0068] In one implementation, the multi-dimensional integration of the quality reward is as follows: Failure rate statistics using a sliding window: A 10-minute sliding window is used to count the number of service instance crashes and timeout responses (exceeding the SLA). The calculation formula is: Failure rate = Number of failures / (Total number of requests + 1) (+1 to avoid a denominator of 0). For core financial services, the window is shortened to 2 minutes to improve anomaly response speed.

[0069] Weighted calculation of response fluctuation standard deviation: The response time of every 100 requests is collected, the standard deviation σ is calculated, and then converted into a stability index by 1-σ / average response time. For example, for a service with an average response time of 200ms, if σ=50ms, the index is 0.75; if σ=20ms, the index increases to 0.9. Hard constraint embedding of SLA contract: The quality indicators in the SLA (such as availability 99.99%, response time <500ms) are used as the threshold of the reward function. When Rq is lower than the SLA requirement (such as Rq<0.99 for financial services), the reward value is directly set to 0, forcibly triggering a quality-first scheduling strategy.

[0070] In some embodiments, when executing a multi-objective dynamic balancing algorithm, the scheduling optimization layer uses the NSGA-III algorithm to generate candidate scheduling schemes and selects the target execution scheme from the selected non-dominated solutions using an ε-greedy algorithm. The scheduling optimization layer is configured to: trigger the weight allocation module of the scheduling optimization layer when the optimization conflict between any two objectives in the three-dimensional reward function exceeds a first preset threshold, dynamically adjusting the calculation weights of time, cost, and quality in the total reward function, where the total reward function consists of time reward, cost reward, and quality reward; and set the calculation weights of the three-dimensional rewards in response to externally input system-level scheduling policy instructions. The scheduling optimization layer is also configured to: continuously monitor the comprehensive standard deviation of multiple candidate scheduling schemes in the three dimensions of time, cost, and quality during the optimization process; and determine that the system is not in a convergence trend when the comprehensive standard deviation of m consecutive iterations (e.g., 3) exceeds a second preset threshold, based on a first downward adjustment coefficient, and perform the following adjustment operations: reduce the exploration rate of the scheduling optimization layer based on a first upward adjustment coefficient; and increase the learning rate of the scheduling optimization layer based on a first upward adjustment coefficient.

[0071] In one implementation, the scheduling optimization layer can employ the NSGA-III algorithm when executing the multi-objective dynamic balancing algorithm. Each iteration generates 200 candidate scheduling schemes. A Pareto front evaluator pre-trained on a large model is used to select 10 non-dominated solutions. Then, an ε-greedy algorithm (ε linearly decays from 0.3 to 0.05) is used to select the execution scheme, improving efficiency, for example, by 60%. Furthermore, based on a historical best-solution library (storing non-dominated solutions from the last 7 days), a genetic algorithm can be used to generate the initial 200 candidate schemes. 80% of these are mutations of historical solutions (e.g., randomly adjusting 20% ​​of resource allocation), and 20% are entirely new random solutions, ensuring population diversity. For each scheme, three-dimensional objective values ​​(time T, cost C, quality Q) are calculated. A fast non-dominated sorting algorithm divides the schemes into three layers: Layer 1 consists of Pareto optimal solutions (no other scheme is better in T, C, and Q); Layer 2 consists of solutions dominated only by Layer 1, and so on. By introducing the crowding distance, the dispersion of solutions within the same layer is quantified. A larger distance indicates that the solution is more unique in the target space and is preferentially retained to maintain the diversity of solutions. For example, two solutions with similar time and cost but large differences in quality will have a larger crowding distance.

[0072] In one implementation, the large model pre-training evaluator functions as follows: Training data: 100,000+ historical scheduling cases (including success / failure labels), input is three-dimensional target value and architectural features (such as number of nodes, service type), output is the actual execution effect score of the solution (0-100 points).

[0073] Filtering logic: From the non-dominated solutions of the first layer, select the top 10 solutions with the highest scores from the evaluator as candidates, and remove "pseudo-optimal solutions" with scores <70.

[0074] In one implementation, the dynamic decay strategy of the ε-greedy algorithm is as follows: In the initial phase (first 24 hours), ε=0.3, allowing a 30% probability of choosing exploratory solutions (such as cross-architecture combinations never before tried), accelerating the discovery of potential optimal solutions.

[0075] During the stable phase (24-72 hours), ε linearly decays to 0.1, reducing the exploration frequency and focusing on local optimization.

[0076] During the convergence phase (>72 hours), ε is fixed at 0.05, with only a small amount of exploration reserved to cope with sudden resource changes.

[0077] In some embodiments, when the scheduling optimization layer executes a multi-objective dynamic balancing algorithm, if it detects that the optimization of one objective has caused the deterioration of another objective to exceed a threshold (e.g., cost reduction of 15% but quality reduction of 8%), the multi-objective game module of the large model is triggered. The weights are redistributed by calculating the Shapley value (e.g., emergency services temporarily adjust the quality weight from 0.3 to 0.6). The strategy adjustment is completed within 3 seconds, reducing the number of objective imbalances by 75% compared to the traditional weighted method.

[0078] In one implementation, the multi-dimensional thresholds for collision detection are as follows: Time-cost conflict: Triggered when cost decreases by ≥15% and time increases by ≥10% (e.g., choosing a low-cost edge node leads to increased latency).

[0079] Cost-quality conflict: Triggered when cost decreases by ≥12% and quality decreases by ≥5% (e.g., disabling redundant instances saves costs but increases failure rate).

[0080] Time-quality conflict: Triggered when time is reduced by ≥8% and quality is reduced by ≥6% (e.g., overclocking the CPU to speed up processing but causing a decrease in stability).

[0081] Threshold dynamic adjustment: Adjusted according to service level (P0-P3). The quality degradation threshold is set at 3% for P0 level (core transaction service) and 8% for P3 level (log analysis service).

[0082] In one implementation, each objective is treated as a game participant, and its fair weight is determined by calculating its marginal contribution across all subsets of cooperation. For example, in a financial transaction scenario: when optimizing only time, the success rate increases by 40%; when optimizing only quality, the success rate increases by 30%; when optimizing both time and quality, the success rate increases by 80%. Therefore, the Shapley value for time is (40% + (80% - 30%)) / 2 = 45%, for quality it is (30% + (80% - 40%)) / 2 = 35%, and for cost it is 20%. The large model converts the Shapley values ​​into a weight vector (e.g., [0.45, 0.20, 0.35]) and updates the calculated weights of the reward function in real time.

[0083] In one implementation, when extreme conditions are detected (such as quality metrics falling below the SLA baseline or time delay exceeding the theoretical value by 50%), a "single-objective priority" mode is triggered. During a quality crisis, the weights are adjusted to [0.1, 0.1, 0.8], allowing for a 30% increase in costs and a 20% increase in time to restore stability; In case of a time crisis (such as a live stream delay exceeding 3 seconds), the weight is adjusted to [0.8, 0.1, 0.1], and a backup node is activated to accelerate processing.

[0084] Once the crisis is resolved (the indicator returns to within the threshold for 3 minutes), it automatically reverts to dynamic weight mode to avoid resource waste caused by over-optimization.

[0085] In some embodiments, the standard deviation calculation of the multi-objective optimization results covers three dimensions: time, cost, and quality. A convergence trend determination of <2% for three consecutive iterations effectively avoids misjudgments caused by random factors. When the fluctuation range is too large, reducing the agent's exploration rate (ε×0.8) reduces ineffective exploration, while increasing the learning rate (η×1.2) accelerates the model parameter update speed. The stability proof of the Lyapunov function is verified through mathematical derivation and simulation experiments. When resource fluctuation is <20%, the system's energy function monotonically decreases, ensuring the system's inevitable convergence. The convergence speed is improved by 2-3 times, enabling the system to adapt to environmental changes more quickly.

[0086] In one implementation, the standard deviation of the multi-objective optimization results is calculated as follows: Time dimension: Collect 100 sample data points of scheduling completion time in each iteration and calculate its standard deviation. For example, if the scheduling completion time in a certain iteration is 100ms, 102ms, 98ms, etc., calculate the standard deviation of this dimension using the standard deviation formula.

[0087] Cost dimension: The resource consumption cost for each iteration is statistically analyzed, with 100 samples selected to calculate the standard deviation of the cost data. The cost data covers the total of various expenses, including basic rental fees and flexible expansion fees.

[0088] Quality dimension: Based on the service stability score (integrating indicators such as failure rate and response fluctuation), the standard deviation is calculated by selecting 100 score samples.

[0089] Comprehensive processing: The standard deviations of the three dimensions of time, cost, and quality are weighted and averaged with weights of 0.3, 0.3, and 0.4 respectively to obtain the comprehensive standard deviation of the multi-objective optimization results.

[0090] In one implementation, the process for determining the convergence trend includes: Real-time monitoring: After each iteration, the system immediately calculates the comprehensive standard deviation of the multi-objective optimization results for that iteration and stores it in the database.

[0091] Continuous comparison: Extract the combined standard deviation of the most recent 3 iterations from the database and determine whether all of them are less than 2%.

[0092] Result determination: If the overall standard deviation of three consecutive iterations is less than 2%, the system is considered to be in a convergence trend; if any one of them is greater than or equal to 2%, the results of the next iteration will continue to be monitored until the condition of three consecutive iterations is met.

[0093] Dynamic updates: Once a convergence trend is determined, the system will record the number of iterations and various indicator data at this time as a reference benchmark for subsequent optimization.

[0094] In one implementation, the adjustment mechanism for excessive fluctuations is as follows: Exploration rate adjustment: When the overall standard deviation is detected to be greater than 5%, the system automatically multiplies the agent's exploration rate ε by 0.8. For example, if the original ε was 0.3, it will be adjusted to 0.24, reducing the agent's blind exploration of new solutions and lowering system fluctuations.

[0095] Learning rate adjustment: Simultaneously multiply the learning rate η by 1.2 to speed up the update of model parameters. Assuming the original learning rate is 0.01, the adjusted rate becomes 0.012, allowing the agent to learn from errors more quickly and return to a stable state.

[0096] Real-time feedback: After adjustment, the system continues to monitor the iteration process. If the overall standard deviation falls back to within 5%, the current exploration rate and learning rate are maintained; if it is still greater than 5%, adjustments are made again until the fluctuation range meets the requirements.

[0097] In one implementation, the specific application of the Lyapunov function stability proof is as follows: Function computation: For the results of multi-objective optimization in each iteration (Including specific values ​​for time, cost, and quality), and their average values. via Lyapunov functions Calculate the energy function value of the system.

[0098] Trend analysis: Continuously monitor the changing trend of the energy function value. If it shows a monotonically decreasing trend, it indicates that the system is in a stable convergence state when the resource fluctuation is less than 20%.

[0099] Simulation Verification: A simulation environment was constructed to simulate various scenarios where resource fluctuations are within 20%, the system was run, and the energy function values ​​at different times were calculated. Extensive simulation results show that the energy function value always monotonically decreases, verifying the system's inherent convergence.

[0100] Improved convergence speed: Compared with traditional algorithms, under the same experimental environment and convergence criteria, the number of iterations required for the system to reach convergence is reduced by 50%-66.7%, which means the convergence speed is improved by 2-3 times. It can adapt to environmental changes and operate stably more quickly.

[0101] In some embodiments, the scheduling optimization layer continuously receives architecture-specific monitoring metrics generated by the intelligent monitoring layer, driving a preset multi-objective dynamic balancing algorithm to generate the optimal service scheduling scheme. Its core implementation is based on a three-dimensional reward function: first, time rewards are calculated based on the actual and theoretical completion times of the service. Cost rewards are derived by combining the dynamic ratio of resource costs to budget with an idle penalty factor. Then, based on the fluctuations in failure rate and response time, a quality reward is derived. Next, the three-dimensional rewards are weighted and fused to construct the total reward function. The NSGA-III algorithm is used to generate the Pareto optimal solution set, and the ε-greedy algorithm is used to complete the final decision. When the target conflict exceeds the threshold, a weight redistribution mechanism based on Shapley value is immediately initiated to dynamically adjust the optimization direction. This scheme realizes multi-objective collaborative optimization of service scheduling in a hybrid architecture environment, which improves the performance of services on the target architecture, reduces resource costs, and improves service availability. The single round of multi-objective optimization takes ≤200ms, supports scheduling decisions for 500+ service instances per second, and meets the needs of high-concurrency scenarios. In the hybrid architecture test environment, the comprehensive optimization deviation rate of time, cost, and quality is <5%, which is 60% lower than the traditional NSGA-III algorithm. In the face of sudden resource fluctuations (such as node failure), the algorithm can regenerate the balancing strategy within 1 second, and the service interruption time is shortened to less than 50ms.

[0102] Regarding the drift adaptation layer In some embodiments, the large model-driven real-time image adaptation engine includes: performing ELF parsing on the source architecture image to extract code segments, dynamic dependencies, and symbol tables, and parsing the source architecture's instruction sequence based on the code segments; translating the source architecture's instruction sequence into the target architecture's instruction sequence based on a pre-built architecture instruction mapping table and the large model; and constructing a service instance image of the target architecture based on the target architecture's instruction sequence, dynamic dependencies, and symbol tables, and performing compatibility verification.

[0103] In one implementation, the ELF parsing configuration is as follows: libelf 0.8.13 + dwelf 0.17.0 is used to extract the .text segment (code section), .dynamic segment (dynamic dependencies), and .symtab segment (symbol table), with a parsing time of ≤200ms / MB (approximately 380ms for a 2MB image).

[0104] Architecture - Instruction Mapping Table Extension: Added "Translation Confidence" field (0-100), calculated based on historical translation success rate, such as MOVAPS→VMOV confidence 98%, CLFLUSH→DCBI confidence 92% (because DCBI requires an additional memory barrier).

[0105] Model optimization: The T5-XXL model uses TensorRT 8.6.1 quantization (INT8 precision), reducing the model size from 15GB to 4.2GB and the inference latency from 5ms / KB to 2.8ms / KB.

[0106] Dependency library matching logic: ① Prioritize matching architecture-specific libraries (such as libc6-loongarch64 for loongarch); ② If no architecture-specific library exists, match compatible libraries (such as libc6-ports); ③ If no compatible library exists either, trigger source code compilation (call gcc 12.2.0, with a compilation timeout of 30 seconds). The following is supplementary information regarding compatibility verification: Test case generation: 100 test cases including 30 boundary scenarios (such as empty instructions, excessively long instruction sequences, privileged instructions). If the pass rate is ≥99%, the service will be started. If the pass rate is 95%-98%, manual confirmation is required. If the pass rate is <95%, QEMU simulation will be triggered (QEMU version 7.2.0, KVM acceleration enabled, performance loss ≤20%).

[0107] In some embodiments, the crash drift execution process includes: Heart rate monitoring: Three consecutive no responses → mark as down → simultaneously trigger "node health check" (ping / SSH port check) to confirm whether it is truly down (avoiding false alarms due to network jitter).

[0108] Mirror fetch: If a containerd API call fails (e.g., the image repository is offline), retry 3 times (1 second interval). If it still fails, use the local cached image (if it exists). If there is no cache, trigger real-time adaptation.

[0109] State synchronization: Raft election timeout (>1.5s) → re-initiate election (maximum 2 times) → if still unsuccessful, switch to single-player mode (temporarily store state, synchronize after restoration).

[0110] In some embodiments, the drift adaptation layer is further configured to synchronously execute the following steps upon detecting a node failure: The system calls the container runtime interface to obtain the image of the target architecture. If the acquisition fails, it retryes several times. If the acquisition still fails after retrying, it retrieves the image of the target architecture from the local cache. If the retrieval fails, it triggers the large model-driven real-time image adaptation engine to generate the image of the target architecture. Service state synchronization is performed based on the Raft distributed consensus protocol. When an election timeout is detected, a re-election is performed several times. If the re-election fails, it switches to a degraded running mode and temporarily stores the service state locally. Delayed state synchronization is performed after communication is restored.

[0111] After confirming a node failure, the drift adaptation layer employs a dual-path parallel execution mechanism to simultaneously initiate the image acquisition process and the service status synchronization process. This architecture breaks through the traditional serial processing mode, parallelizing the two independent subtasks of image preparation (program entity) and state restoration (running data), effectively significantly reducing the time consumed on the critical path.

[0112] Furthermore, a four-level progressive mirror acquisition guarantee mechanism can be constructed, as follows: Level 1: Pull pre-compiled images directly through the standard container runtime interface. Level 2: Implement a limited retry mechanism to avoid instantaneous network jitter. Level 3: Search the local mirror repository, leveraging the principle of spatiotemporal locality to accelerate the acquisition. Level 4: Triggers a real-time image generation engine driven by a large model, dynamically building the target architecture image through instruction sequence translation and dependency library adaptation.

[0113] The chain-like protection of the above four-level architecture ensures that the success rate of cross-architecture migration can still be maintained at a certain probability (e.g., 99%) even in the case of missing pre-compiled images.

[0114] One such mechanism is an adaptive state synchronization mechanism that uses the Raft protocol to synchronize service states and introduces the following dual-protection strategy: Basic model: Ensure strong state consistency through a distributed consensus protocol.

[0115] Degradation mode: When network partitioning causes consensus failure, it automatically switches to local persistent storage and marks the system as pending synchronization.

[0116] This adaptive state synchronization uses eventual consistency instead of strong consistency, prioritizing service availability in extreme failure scenarios, and completing data repair through delayed synchronization after the network recovers.

[0117] In addition, the system sets a global synchronization point, requiring that the final service instance only start after both the image acquisition and state synchronization processes are completed in parallel. This design ensures that the new instance has both an executable program carrier and the correct runtime state, avoiding startup failures or data inconsistencies caused by partial readiness.

[0118] In some embodiments, after detecting a node failure event, the drift adaptation layer first eliminates network jitter interference through a dual confirmation mechanism of heartbeat detection and node health check, and then initiates the cross-architecture service instance migration process: its built-in large model-driven real-time image adaptation engine performs ELF structure parsing on the source service image, extracts instruction sequences from code segments and performs real-time translation in conjunction with the architecture-instruction mapping table, and simultaneously ensures the compatibility of the generated target architecture image through dynamic dependency library matching and boundary test case verification; when the image repository is unavailable, it automatically triggers a dual-path disaster recovery mechanism of local cache degradation and real-time generation, and finally completes service state synchronization under the guarantee of the Raft consensus protocol. This implementation improves the cross-architecture drift success rate from less than 50% to over 99%, and reduces migration time from minutes to less than 10 seconds, completely solving the core bottleneck of service high availability in hybrid architecture environments.

[0119] About the data storage center In some embodiments, the data storage center serves as the unified data hub of the system, employing a distributed architecture and multi-level storage strategy to classify and persist critical data across the entire data chain: it stores multi-data elements from probes (including static characteristics of instruction sets and dynamic performance metrics) through a time-series database; it persists the architecture knowledge graph (including metrics, logs, root cause nodes, and their relationships) generated by fault rule mining using a graph database; it manages mirror adaptation rules and performance profiling model parameters using a relational database; and it archives historical monitoring metrics and mirror templates through an object storage service. By defining a unified data interface specification and service-oriented access mechanism, this center provides highly available and strongly consistent data support for model training in the instruction set perception layer, graph updates in the intelligent monitoring layer, decision analysis in the scheduling optimization layer, and rule invocation in the drift adaptation layer, ultimately constructing a closed-loop data foundation that drives intelligent decision-making throughout the entire system.

[0120] The technical solution of this application is illustrated by a specific embodiment below: Example 1 Network configuration: Core switch Huawei S12700, edge switch Huawei S5735, inter-node bandwidth 10Gbps, cross-architecture node network latency: amd64→loongarch 3.2ms, loongarch→SW64 4.8ms Monitoring tool: Grafana v10.2.0, dashboard includes architecture-specific metrics panels (such as the LSX usage trend chart from loongarch and the SIMD parallelism heatmap from SW64). The performance scheduling comparison is shown in Table 3 below: Table 3

[0121] The comparison of crash drift is shown in Table 4 below: Table 4

[0122] Based on this example, it can be shown that after 30 consecutive days of monitoring: service availability is 99.992% (only 1 downtime drift, lasting 8 seconds), the average time to locate the root cause of a fault is 2.8 minutes (1.5 minutes for P1 level faults and 3 minutes for P2 level faults), and the adaptation cycle for the new Loongarch architecture is 1.5 hours (the existing solution requires 1 week, a reduction of 96.4%).

[0123] This application's technical solution constructs a complete intelligent management system. First, cross-CPU architecture probes deployed on each computing node collect multi-data elements, including instruction set characteristics and real-time operational status. These elements are then processed by a large model in the instruction set awareness layer to generate a performance profile that deeply reflects the service-architecture adaptation relationship. The intelligent monitoring layer uses this profile and integrates it with an architecture knowledge graph dynamically constructed using the FP-Growth algorithm to generate precise architecture-specific monitoring metrics. The scheduling optimization layer uses a multi-objective dynamic balancing algorithm that integrates time, cost, and quality reward functions, combined with conflict resolution and convergence guarantee mechanisms, to generate optimal scheduling decisions. When a node failure occurs, the drift adaptation layer uses a large model-driven real-time mirror adaptation engine to overcome architectural differences and achieve second-level service migration. The entire process is supported by end-to-end data from a distributed data storage center. The solution ultimately achieved three major breakthroughs: First, it improved service performance on the target architecture by more than 40% through instruction set-aware scheduling; second, it increased the success rate of cross-architecture failure migration from less than 50% to over 99% with a time limit of less than 10 seconds; and third, it reduced the root cause location time from 30 minutes to less than 3 minutes by leveraging an architecture-specific indicator system and knowledge graph. It comprehensively solved the core technical challenges of performance optimization, high availability assurance, and intelligent operation and maintenance for microservice clusters in a hybrid CPU architecture environment.

[0124] See Figure 3 , Figure 3 This paper illustrates a cross-architecture microservice scheduling management method based on a large model according to an embodiment of the present application, applied to the cross-architecture microservice scheduling management system based on a large model provided in the first aspect. The method includes the following steps: Step 301: Collect multi-data elements of the computing node through a cross-CPU architecture probe. The multi-data elements include static instruction set characteristics and dynamic runtime performance data. Step 302: Receive and process the multi-dimensional data through the instruction set perception layer, and generate a performance profile corresponding to the multi-dimensional data through a large model; Step 303: Based on the performance profile and architecture knowledge graph, the intelligent monitoring layer dynamically generates architecture-specific monitoring metrics; Step 304: The scheduling optimization layer generates a service scheduling scheme based on the architecture-specific monitoring indicators and the preset multi-objective dynamic balancing algorithm; Step 305: Upon receiving a crash drift instruction, the drift adaptation layer uses the large model-driven real-time image adaptation engine and calls the image adaptation rules to migrate service instances across CPU architectures. Step 306: Store the multi-dimensional data, the performance profile, the architecture-specific monitoring metrics, the architecture knowledge graph, and the image adaptation rules through the data storage center.

[0125] In one possible implementation, the instruction set awareness layer includes an instruction set feature acquisition submodule; wherein the instruction set feature acquisition submodule is configured to: acquire the static instruction set features, specifically including instruction set type, number of registers and extended instruction support bitmap; acquire the dynamic runtime performance data, specifically including CPI value, cache hit rate at each level and extended instruction utilization; and perform outlier processing and verification on the acquired data.

[0126] In one possible implementation, the instruction set awareness layer further includes a large model performance prediction submodule; The large model performance prediction submodule is configured to: fuse the static instruction set features and the dynamic runtime performance data with the resource requirement features of the target service to generate a feature vector for performance prediction; process the feature vector using a pre-trained large model to output the performance score of the target service on candidate nodes; and select a set of candidate nodes suitable for scheduling the target service based on the performance score and a preset resource utilization threshold.

[0127] In one possible implementation, the large model-driven real-time image adaptation engine includes: The source architecture image is parsed using ELF parsing to extract code segments, dynamic dependencies, and symbol tables. The instruction sequence of the source architecture is then parsed based on the code segments. Based on a pre-built architecture instruction mapping table and the large model, the instruction sequence of the source architecture is translated into the instruction sequence of the target architecture. Based on the instruction sequence of the target architecture, the dynamic dependencies, and the symbol table, a service instance image of the target architecture is constructed, and compatibility verification is performed.

[0128] In one possible implementation, the multi-objective dynamic balancing algorithm preset in the scheduling optimization layer is a reinforcement learning algorithm based on a three-dimensional reward function, which includes time reward, cost reward and quality reward. The formula for calculating the time reward is as follows:

[0129] in, Indicates a time-based reward. Indicates the actual completion time of the target service. This represents the theoretical shortest completion time for the target service. This represents the service dependency coefficient.

[0130] In one possible implementation, the formula for calculating the quality reward is:

[0131] in, This indicates a quality reward. This represents the failure rate of the target service within a preset sliding time window. This represents the standard deviation of the target service response time within a preset sampling period. This represents the average response time of the target service within the sampling period; The formula for calculating the cost incentive is as follows:

[0132] in, Indicates cost incentive, This represents the actual resource cost of the target service during the scheduling period. This represents the budgeted cost allocated to the target service. This represents the penalty factor associated with resource idle time.

[0133] In one possible implementation, the intelligent monitoring layer is further configured to: mine architecture-related indicator association rules from historical fault data based on the FP-Growth algorithm to construct and update the architecture knowledge graph; the architecture knowledge graph includes indicator nodes, log nodes, and root cause nodes, wherein the nodes are connected by edges with confidence and support attributes.

[0134] In one possible implementation, when executing the multi-objective dynamic balancing algorithm, the scheduling optimization layer uses the NSGA-III algorithm to generate candidate scheduling schemes and selects the target execution scheme from the selected non-dominated solutions using the ε-greedy algorithm.

[0135] In one possible implementation, the scheduling optimization layer is configured as follows: When the optimization conflict between any two objectives in the three-dimensional reward function exceeds the first preset threshold, the weight allocation module of the scheduling optimization layer is triggered to dynamically adjust the calculation weights of time, cost and quality in the total reward function, which consists of time reward, cost reward and quality reward. In response to external input system-level scheduling policy instructions, the calculation weights of the three-dimensional rewards are set; The scheduling optimization layer is also configured as follows: Continuously monitor the combined standard deviation of multiple candidate scheduling schemes across three dimensions: time, cost, and quality during the optimization process; When the overall standard deviation of m consecutive iterations of optimization exceeds the second preset threshold, the system is determined not to be in a convergent trend, and the following adjustment operations are performed: Based on the first reduction factor, the exploration rate of the scheduling optimization layer is reduced; Based on the first adjustment factor, the learning rate of the scheduling optimization layer is increased.

[0136] In one possible implementation, the drift adaptation layer is also configured as follows: When a node failure is detected, the following steps are executed synchronously: Call the container runtime interface to obtain the image of the target architecture. If the acquisition fails, retry several times. If the acquisition still fails after retrying, retrieve the image of the target architecture in the local cache. If the retrieval fails, trigger the large model-driven real-time image adaptation engine to generate the image of the target architecture. Service state synchronization is performed based on the Raft distributed consensus protocol. When an election timeout is detected, several re-elections are conducted. If the re-election fails, the system switches to a degraded operation mode, temporarily storing the service state locally. Delayed state synchronization is then performed once communication is restored.

[0137] Figure 4 A structural block diagram of a computing device 400 according to an embodiment of this application is shown. The components of the computing device 400 include, but are not limited to, a memory 410 and a processor 420. The processor 420 is connected to the memory 410 via a bus 430, and a database 450 is used to store data.

[0138] The computing device 400 also includes an access device 440, which enables the computing device 400 to communicate via one or more networks 460. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 440 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0139] In one embodiment of this application, the aforementioned components of the computing device 400 and Figure 4 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 4 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.

[0140] The computing device 400 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 400 can also be a mobile or stationary server.

[0141] The processor 420 executes computer-executable instructions, which, when executed by the processor, implement the steps of the aforementioned cross-architecture microservice scheduling and management method based on a large model. The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the aforementioned cross-architecture microservice scheduling and management method based on a large model belong to the same concept. Details not described in detail in the technical solution of the computing device can be found in the description of the technical solution of the aforementioned cross-architecture microservice scheduling and management method based on a large model.

[0142] An embodiment of this application also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the above-described cross-architecture microservice scheduling and management method based on a large model.

[0143] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solution of the cross-architecture microservice scheduling and management method based on a large model described above. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the cross-architecture microservice scheduling and management method based on a large model described above.

[0144] An embodiment of this application also provides a computer program, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described cross-architecture microservice scheduling and management method based on a large model.

[0145] The above is an illustrative example of a computer program in this embodiment. It should be noted that the technical solution of this computer program belongs to the same concept as the technical solution of the aforementioned cross-architecture microservice scheduling and management method based on a large model. Details not described in detail in the computer program's technical solution can be found in the description of the aforementioned cross-architecture microservice scheduling and management method based on a large model.

[0146] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0147] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0148] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments of this application.

[0149] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0150] The preferred embodiments disclosed above are merely illustrative of this application. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments of this application. These embodiments are selected and specifically described in this application to better explain the principles and practical applications of the embodiments of this application, thereby enabling those skilled in the art to better understand and utilize this application. This application is limited only by the claims and their full scope and equivalents.

Claims

1. A cross-architecture microservice scheduling and management system based on a large model, characterized in that, The system includes: A cross-CPU architecture probe is deployed on each compute node to collect multi-data elements of the compute node, including static instruction set characteristics and dynamic runtime performance data. The instruction set awareness layer is communicatively connected to the cross-CPU architecture probe and is used to receive and process the multi-dimensional data, and generate a performance profile corresponding to the multi-dimensional data through a large model. The intelligent monitoring layer, which is communicatively connected to the instruction set perception layer, is used to dynamically generate architecture-specific monitoring metrics based on the performance profile and architecture knowledge graph. The scheduling optimization layer, which is connected to the intelligent monitoring layer, is used to generate a service scheduling scheme based on the architecture-specific monitoring indicators and a preset multi-objective dynamic balancing algorithm. The drift adaptation layer, which is connected to the scheduling optimization layer, is used to migrate service instances across CPU architectures by using the large model-driven real-time image adaptation engine and calling image adaptation rules when a crash drift instruction is received. The data storage center is used to store the multi-dimensional data, the performance profile, the architecture-specific monitoring metrics, the architecture knowledge graph, and the image adaptation rules.

2. The system according to claim 1, characterized in that, The instruction set perception layer includes an instruction set feature acquisition submodule; The instruction set feature acquisition submodule is configured as follows: The static instruction set characteristics are collected, specifically including instruction set type, number of registers, and extended instruction support bitmap; The collected dynamic runtime performance data specifically includes CPI values, cache hit rates at all levels, and extended instruction utilization; and The collected data undergoes outlier handling and validation.

3. The system according to claim 2, characterized in that, The instruction set perception layer also includes a large model performance prediction submodule; The large model performance prediction submodule is configured as follows: The static instruction set features and the dynamic runtime performance data are fused with the resource requirement features of the target service to generate a feature vector for performance prediction. The feature vector is processed using a pre-trained large model to output the performance score of the target service on the candidate node; Based on the performance score and the preset resource utilization threshold, a set of candidate nodes suitable for scheduling the target service is selected.

4. The system according to claim 1, characterized in that, The real-time image adaptation engine driven by a large model includes: The source architecture image is parsed using ELF to extract code segments, dynamic dependencies, and symbol tables, and the instruction sequence of the source architecture is parsed based on the code segments. Based on the pre-built architecture instruction mapping table and the large model, the instruction sequence of the source architecture is translated into the instruction sequence of the target architecture; Based on the instruction sequence of the target architecture, the dynamic dependencies, and the symbol table, a service instance image of the target architecture is constructed, and compatibility verification is performed.

5. The system according to claim 1, characterized in that, The multi-objective dynamic balancing algorithm preset in the scheduling optimization layer is a reinforcement learning algorithm based on a three-dimensional reward function, which includes time reward, cost reward and quality reward. The formula for calculating the time reward is as follows: in, Indicates a time-based reward. Indicates the actual completion time of the target service. This represents the theoretical shortest completion time for the target service. This represents the service dependency coefficient.

6. The system according to claim 5, characterized in that, The formula for calculating the quality bonus is as follows: in, This indicates a quality reward. This represents the failure rate of the target service within a preset sliding time window. This represents the standard deviation of the target service response time within a preset sampling period. This represents the average response time of the target service within the sampling period; The formula for calculating the cost incentive is as follows: in, Indicates cost incentive, This represents the actual resource cost of the target service during the scheduling period. This represents the budgeted cost allocated to the target service. This represents the penalty factor associated with resource idle time.

7. The system according to claim 1, characterized in that, The intelligent monitoring layer is also configured as follows: The FP-Growth algorithm is used to mine association rules of architecture-related indicators from historical failure data in order to construct and update the architecture knowledge graph. The architecture knowledge graph includes indicator nodes, log nodes, and root cause nodes, with each node connected by edges that have confidence and support attributes.

8. The system according to claim 5 or 6, characterized in that, When executing the multi-objective dynamic balancing algorithm, the scheduling optimization layer uses the NSGA-III algorithm to generate candidate scheduling schemes and selects the target execution scheme from the selected non-dominated solutions using the ε-greedy algorithm.

9. The system according to claim 8, characterized in that, The scheduling optimization layer is configured as follows: When an optimization conflict between any two objectives in the three-dimensional reward function is detected to exceed a first preset threshold, the weight allocation module of the scheduling optimization layer is triggered to dynamically adjust the calculation weights of time, cost, and quality in the total reward function, wherein the total reward function consists of the time reward, the cost reward, and the quality reward. In response to externally input system-level scheduling policy instructions, the calculation weights of the three-dimensional rewards are set; The scheduling optimization layer is further configured as follows: Continuously monitor the combined standard deviation of multiple candidate scheduling schemes across three dimensions: time, cost, and quality during the optimization process; When the overall standard deviation of the optimization after m consecutive iterations exceeds the second preset threshold, the system is determined not to be in a convergence trend, and the following adjustment operations are performed: Based on the first downgrade coefficient, the exploration rate of the scheduling optimization layer is reduced; Based on the first adjustment factor, the learning rate of the scheduling optimization layer is increased.

10. The system according to claim 4, characterized in that, The drift adapter layer is also configured to: When a node failure is detected, the following steps are executed synchronously: Call the container runtime interface to obtain the image of the target architecture. If the acquisition fails, retry several times. If the acquisition still fails after retrying, retrieve the image of the target architecture in the local cache. If the retrieval fails, trigger the large model-driven real-time image adaptation engine to generate the image of the target architecture. Service state synchronization is performed based on the Raft distributed consensus protocol. When an election timeout is detected, several re-elections are conducted. If the re-election fails, the system switches to a degraded operation mode, temporarily storing the service state locally. Delayed state synchronization is then performed once communication is restored.

Images