Application architecture resource optimization method and device, equipment and medium

Abstract

The invention relates to the technical field of cloud computing, can be applied to business scenes of financial science and technology, medical health and the like, and discloses an application architecture resource optimization method, device, equipment and medium, and the method comprises the steps: obtaining operation data of a service component in an application architecture, and extracting load features to generate a load feature vector table; training and generating a load prediction model based on the load feature vector table, and initializing a scaling strategy set; acquiring real-time operation data, generating a scaling decision based on the real-time data and the scaling strategy set through the load prediction model, and forming a scaling instruction set; scheduling the infrastructure layer to execute the scalable instruction set to adjust the resource configuration; and analyzing the adjusted performance index and the resource utilization rate, generating a strategy analysis report, and updating the load prediction model and the scaling strategy set. According to the method, an adaptive optimization closed loop is constructed through load prediction and strategy feedback, real-time load-driven resource dynamic adjustment is realized, and the resource utilization rate and architecture flexibility are improved while the system performance is guaranteed.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cloud computing, and in particular to an application architecture resource optimization method and device, equipment and medium. BACKGROUND

[0002] In the field of financial technology business, the existing dynamic resource scaling scheme is mainly based on a static threshold triggering mechanism, for example, when the CPU utilization or memory occupancy of a transaction platform exceeds a preset threshold, a capacity expansion operation is triggered. This kind of method lacks foresight and scene perception ability, and cannot predict the load trend in advance during high concurrency, concentrated settlement period or temporary promotion activities, thereby causing resource shortage or excessive configuration of the system in a short time, directly affecting the real-time performance and stability of the financial transaction system. In addition, the existing scaling system focuses on the resource changes of a single service instance, ignoring the cross-module dependency relationship, for example, the data bus and model computing node are not expanded synchronously after the risk control engine is expanded, which easily causes overall transaction delay and resource waste. Since the scaling target is mainly to ensure performance, there is a lack of dynamic trade-off mechanism between performance, cost and energy efficiency, so that the cloud resource idle rate is high during low load, and it is difficult to achieve fine cost control. The more prominent problem is that the existing system generally lacks continuous analysis and model self-learning ability of scaling decision effect, and cannot automatically adjust the strategy parameters according to historical operation data, resulting in the need for manual intervention to adjust the strategy when the financial business faces sudden traffic fluctuations and complex dependency links, which has a large operation and maintenance burden and a lagging response.

[0003] In the field of medical and health business, with the popularity of online diagnosis and treatment, health record management and intelligent monitoring system, the volatility and complexity of application load are further enhanced. The existing scaling technology still relies on fixed threshold strategy, and in the face of scenes such as peak visits, sudden public health events or remote image diagnosis centralized processing, it cannot predict the load growth trend in real time, nor can it perform global resource optimization scheduling based on the coordination relationship of different medical subsystems (such as diagnosis and treatment services, image analysis, data storage). When the upstream diagnosis and treatment request service instance is expanded, the downstream data analysis or image processing node cannot be scaled synchronously, which will form a new performance bottleneck, affecting the diagnosis and treatment response time and service quality. In addition, the medical system usually needs to balance between security compliance and energy consumption control, and the existing scheme lacks a multi-target dynamic optimization mechanism, making it difficult to simultaneously consider performance stability and resource cost. More importantly, the existing scheme lacks adaptive recovery and strategy evolution mechanism when facing node failure, network anomaly or sudden system load migration, and cannot automatically optimize the scaling decision according to historical operation behavior, thereby reducing the continuous availability and resource utilization efficiency of the medical business. SUMMARY

[0004] The main purpose of the present application is to provide an application architecture resource optimization method, device, equipment and storage medium, aiming at solving the technical problems that the prior art lacks a global collaborative scaling mechanism based on real-time load prediction and multi-objective optimization, resulting in resource adjustment lag, imbalance between microservices scaling, and dynamic balance between performance and cost.

[0005] To achieve the above-mentioned purpose, the present application provides an application architecture resource optimization method, comprising: Collecting the running data of each service component in the application architecture, and extracting load characteristics based on the running data to generate a load characteristic vector table; Training a load prediction model based on the load characteristic vector table and initializing a scaling strategy set; Obtaining real-time service component running data; Generating a scaling decision based on the real-time service component running data and the scaling strategy set through the load prediction model, and generating a scaling instruction set according to the scaling decision; Scheduling the infrastructure layer to execute the scaling instruction set to adjust the resource configuration of the service component; Analyzing the performance indicators and resource utilization of the service component after adjusting the resource configuration, generating a strategy analysis report, and updating the load prediction model and the scaling strategy set according to the strategy analysis report.

[0006] Further, to achieve the above-mentioned purpose, the present application provides an application architecture resource optimization device, comprising: The feature extraction module is used for collecting the running data of each service component in the application architecture, and extracting load characteristics based on the running data to generate a load characteristic vector table; The model training module is used for training a load prediction model based on the load characteristic vector table and initializing a scaling strategy set; The real-time collection module is used for obtaining real-time service component running data; The decision generation module is used for generating a scaling decision based on the real-time service component running data and the scaling strategy set through the load prediction model, and generating a scaling instruction set according to the scaling decision; The resource scheduling module is used for scheduling the infrastructure layer to execute the scaling instruction set to adjust the resource configuration of the service component; The strategy update module is used for analyzing the performance indicators and resource utilization of the service component after adjusting the resource configuration, generating a strategy analysis report, and updating the load prediction model and the scaling strategy set according to the strategy analysis report.

[0007] Further, to achieve the above-mentioned purpose, the present application also provides a computer device, which comprises a memory, a processor, and an application architecture resource optimization program stored in the memory and executable on the processor, and the application architecture resource optimization program realizes the steps of the application architecture resource optimization method when executed by the processor.

[0008] Further, to achieve the above-mentioned purpose, the present application also provides a computer readable storage medium, which stores an application architecture resource optimization program, and the application architecture resource optimization program realizes the steps of the application architecture resource optimization method when executed by a processor.

[0009] Beneficial effects: The present application relates to the technical field of cloud computing, and can be applied to business scenarios such as financial technology and medical health, and discloses an application architecture resource optimization method, device, equipment and medium, which comprises the following steps: obtaining running data of each service component in an application architecture, extracting load features to generate a load feature vector table; training and generating a load prediction model based on the load feature vector table and initializing a set of scaling strategies; obtaining real-time service component running data, generating a scaling decision and a set of scaling instructions based on the real-time running data and the set of scaling strategies through the load prediction model; scheduling an infrastructure layer to execute the set of scaling instructions to adjust service component resource configuration; analyzing performance indicators and resource utilization rates of the adjusted service components, generating a strategy analysis report and updating the load prediction model and the set of scaling strategies. The present application realizes adaptive closed-loop optimization from real-time running data to resource configuration adjustment by combining load prediction and strategy feedback, so that the system can generate decisions in advance and dynamically allocate resources when the business load changes, thereby reducing resource redundancy while ensuring performance stability, and improving the elasticity and resource utilization efficiency of the micro-service architecture in a complex load environment. BRIEF DESCRIPTION OF DRAWINGS

[0010] The present application will be further described below in combination with the drawings and embodiments, and the drawings are as follows: Figure 1 An application environment schematic diagram of the application architecture resource optimization method in an embodiment of the present application; Figure 2 A flow schematic diagram of an embodiment of the application architecture resource optimization method of the present application; Figure 3 A functional module schematic diagram of a preferred embodiment of the application architecture resource optimization device of the present application; Figure 4 A structure schematic diagram of a computer device in an embodiment of the present application; Figure 5 Another structure schematic diagram of a computer device in an embodiment of the present application. DETAILED DESCRIPTION

[0011] It is to be understood that the specific embodiments described herein are merely illustrative of the present application and should not be used to limit the present application in any manner.

[0012] The application architecture resource optimization method provided by the embodiments of the present application can be applied in an application environment such as Figure 1 , wherein the client communicates with the server through the network. The server can obtain the running data of each service component in the application architecture through the client, extract the load features to generate a load feature vector table, train and generate a load prediction model based on the load feature vector table and initialize a set of scaling strategies, obtain real-time service component running data, generate a scaling decision and a set of scaling instructions based on the real-time running data and the set of scaling strategies through the load prediction model, schedule the infrastructure layer to execute the set of scaling instructions to adjust the resource configuration of the service component, analyze the performance indicators and resource utilization of the adjusted service component, generate a strategy analysis report and update the load prediction model and the set of scaling strategies. The present application realizes adaptive closed-loop optimization from real-time running data to resource configuration adjustment by combining load prediction and strategy feedback, so that the system can generate decisions in advance and dynamically allocate resources when the business load changes, thereby reducing resource redundancy while ensuring performance stability and improving the elasticity and resource utilization efficiency of the microservice architecture in a complex load environment. The client can be, but is not limited to, various personal computers, notebook computers, smart phones, tablet computers and portable wearable devices. The server can be implemented by an independent server or a server cluster composed of multiple servers. The present application will be described in detail through specific embodiments.

[0013] Please refer to Figure 2 , Figure 2 The flowchart of an embodiment of the application architecture resource optimization method provided by the present application is shown. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0014] As shown in Figure 2 , the application architecture resource optimization method provided by the present application includes the following steps: S10, collecting the running data of each service component in the application architecture, and extracting the load features based on the running data to generate a load feature vector table; In this embodiment, collecting the running data of each service component in the application architecture is the basic step to realize resource optimization, and the purpose is to build a unified data view that can be used for subsequent analysis. The running data includes real-time performance information, resource occupation information and calling behavior information of service components under different load states. These information can be automatically collected through system monitoring module, container orchestration platform or service grid framework. In order to ensure the integrity and consistency of the data, the multi-node synchronous timestamp mechanism is adopted in the collection process, so that the data generated by different components are aligned on the time axis. For distributed system environment, the collection module will also avoid data loss or uneven sampling caused by node offline or network fluctuation through heartbeat detection and log aggregation mechanism. The collection frequency of running data can be dynamically adjusted according to the characteristics of the component. High-frequency components use short-period sampling, and low-frequency components use delayed sampling strategy to balance real-time and system load.

[0015] Based on the running data, load characteristics are extracted, aiming to convert the original multi-dimensional data into measurable and comparable numerical features. Load characteristics include resource usage characteristics, performance characteristics and interaction characteristics. Resource usage characteristics involve processor utilization, memory occupation, network bandwidth consumption and disk I / O rate, which are used to describe the load intensity of hardware resources. Performance characteristics reflect the delay, throughput and response stability of service components during operation, which are used to judge the change trend of their service capacity. Interaction characteristics describe the dependence and calling relationship between services, including request frequency, error rate and transaction success rate, which are used to describe the dynamic dependence mode between components. The extraction process usually combines sliding window statistics, quantile analysis and peak-valley detection algorithm, and extracts mean features, fluctuation features and periodic features through time series modeling, so as to capture the load change law of services in different time dimensions.

[0016] Generating load feature vector table is the process of structuring and organizing multi-source and multi-dimensional feature results. Each row of the vector table represents the load state of a service component in a specific time period, and each column corresponds to a normalized feature dimension. In order to improve the calculation efficiency of subsequent analysis, the system will use feature standardization and feature dimension reduction techniques, such as Z-score normalization and principal component analysis method, to compress redundant information and retain the main feature direction. The generated vector table will be stored in a distributed data warehouse in a key-value mapping manner, with the key identifying the service component and the time period, and the value storing the corresponding feature vector, to support fast retrieval and model training.

[0017] In an embodiment, data collection can be achieved by deploying lightweight data collection agents in the microservice runtime environment, which share the namespace with the service container and directly read performance counters and resource occupation information through system call interfaces; for the agentless scenario, the request path and response delay can be captured through the service mesh sidecar agent to achieve non-intrusive monitoring. Load feature extraction can use a sliding window aggregation method to calculate the maximum, minimum and average values in each time window, calculate the short-term fluctuation trend using the exponential smoothing method, and detect periodic fluctuations using the fast Fourier transform. When generating the load feature vector table, a columnar storage structure can be selected to support high-concurrency queries, or a graph database form can be used for storage to retain inter-service dependency features, depending on the computing type and data size of the target system.

[0018] In another embodiment, an adaptive sampling mechanism can be introduced in the load feature extraction stage to automatically adjust the sampling interval according to the real-time system load; the sampling period is shortened when the system is in the peak period to improve data accuracy; the sampling period is extended in the low load stage to reduce overhead. When generating the load feature vector table, the features of different time periods can also be managed in a partitioned storage manner to optimize the time series access efficiency through the partition key. For environments that require cross-service comparison, standardized feature templates can be further introduced to map the feature dimensions of different services to a unified vector space, so that the subsequent model training process can be performed on a unified scale.

[0019] This embodiment can construct a high-dimensional, time-series load vector table by collecting service component running data and extracting load features, enabling the system to have data-driven self-awareness when facing complex and dynamic business environments. This process realizes the transition from bottom-layer data perception to abstract load representation, providing a computable basis for subsequent load prediction and resource optimization. Thus, potential performance bottlenecks can be identified before changes occur, providing proactive support for intelligent scaling and strategy optimization.

[0020] S20, training a load prediction model based on the load feature vector table and initializing a set of scaling strategies; In this embodiment, the load prediction model is generated and the set of scaling strategies is initialized based on the load feature vector table, which is the core step of adaptive resource optimization. The goal is to enable the system to learn from historical load patterns and autonomously deduce future load trends. The multi-dimensional data in the load feature vector table reflects the resource occupation and performance fluctuations of service components at different time periods. Through training, these patterns can be converted into predictable mathematical mapping relationships. During the training process, the mapping structure of the model input and output needs to be determined first. The input is the time-sequenced load feature vector, and the output is the load trend data in the future time period. To improve the generalization ability, recurrent neural networks, time convolution networks, or prediction network structures based on attention mechanisms can be selected to capture long-time dependency characteristics and periodic fluctuation patterns. In the model training phase, a sliding time window is used for sample division, batch gradient update is used to achieve parameter convergence, and an early stopping mechanism is introduced to prevent overfitting.

[0021] After training is completed, the model needs to be evaluated for performance through a validation set. Evaluation indicators can include mean absolute error, mean square error, and prediction confidence interval coverage rate. The validation set is derived from historical load data that did not participate in training, to test the model's generalization ability for unseen data. If the validation results meet the preset threshold, the model is saved as a load prediction model and registered in the scheduling system for real-time calling.

[0022] The process of initializing the set of scaling strategies is based on the model prediction results to construct strategy rules. The strategy set defines the resource adjustment behavior to be taken under different predicted load levels. Strategy rules can be generated by a multi-objective optimization model, with optimization objectives including performance stability, cost control, and energy efficiency. Performance stability is expressed through response time and throughput constraints, cost objectives are associated with computing resource price models, and energy efficiency is estimated through power consumption parameters. The optimization model uses weighted linear programming or heuristic evolutionary algorithms for solution, and outputs a multi-dimensional Pareto optimal solution set according to different target weights. Each solution corresponds to a scaling strategy. The strategy set records parameters such as trigger conditions, adjustment steps, cooling times, and priorities to support subsequent dynamic decision execution.

[0023] In an embodiment, the load feature vector table can be trained using an LSTM (Long Short-Term Memory) based time series model, with the input being a sequence of feature vectors of past time windows and the output being the load prediction value of future one or more time windows. The model training adopts a distributed training framework, with gradient aggregation mechanism for parallel computation on multiple nodes to improve training efficiency. After training, the model is tested using a validation set, and when the prediction error is lower than a preset threshold, the model is frozen and exported as a deployable version. The initialization of the scaling strategy set is achieved through a multi-objective optimization module, with the input being the predicted load curve and resource quota constraints, and through genetic algorithm to search for different strategy combinations to minimize the comprehensive cost function, finally outputting a set of strategies balancing performance and cost.

[0024] In another embodiment, a hybrid prediction mechanism based on statistical regression and rule learning can be used, with a time-weighted regression model to establish the basic prediction, and a decision tree-based correction module to adaptively correct the sudden load scenario to improve the prediction stability under abnormal conditions. In the initialization stage of the scaling strategy, reinforcement learning mechanism can be used, with the system executing strategy actions in a simulation environment and calculating performance feedback, constantly updating strategy parameters, so that the strategy set gradually approaches the optimal state.

[0025] This embodiment trains the load prediction model and initializes the scaling strategy set based on the load feature vector table, so that the system can identify the future load change trend in advance and make proactive resource allocation decisions. Compared with the traditional passive scaling method relying on threshold triggering, this process has the ability of self-learning and self-evolution, and can dynamically adjust the strategy parameters according to historical rules and optimization goals, thereby significantly reducing resource waste while ensuring performance stability.

[0026] S30, acquiring real-time service component running data; In this embodiment, acquiring real-time service component runtime data focuses on data timeliness and end-to-end observability, and is uniformly defined and implemented around four keywords: acquisition, real-time, service components, and runtime data. Acquisition not only includes the collection of signals such as indicators, logs, and traces by the acquisition end, but also includes in-transit transmission, data storage and disk storage, and providing external read interfaces, forming a closed loop from source to usable data. In terms of implementation, a lightweight proxy can be deployed on the service instance side, or telemetry signals can be intercepted in a bypass manner on the network side, or system counters can be read at the host layer. These three can be used individually or in combination according to the scenario. Real-time emphasizes the end-to-end latency control between data generation and usability, which is reflected in the collaborative constraints of the acquisition cycle, transmission path, buffering strategy, and aggregation window to ensure that data is accessed and consumed within a short time granularity. In terms of implementation, event-driven channels and small-batch aggregation are used in parallel, supplemented by backpressure and priority queues to avoid lag caused by congestion. Service components refer to deployable units that perform independent functions within an application architecture. These include long-running microservice instances, on-demand task instances, and stateless function instances. Each instance needs a stable identity, version identifier, and runtime topology identifier to support cross-instance and cross-version data alignment and merging. Runtime data refers to structured or semi-structured information that reflects the running status and interactive behavior of service components. Sources include resource usage metrics, performance metrics, interaction metrics, and business intensity metrics. Resource usage metrics include processor utilization, memory usage, bandwidth, and storage read / write speeds; performance metrics include response latency, throughput, and error counts; interaction metrics include inbound and outbound requests, dependencies, and call depth; and business intensity metrics include user request volume and transaction completion volume. To ensure unified access from heterogeneous sources, a common data schema needs to be agreed upon on both the collection and aggregation sides. The schema fields include timestamps, service component identifiers, instance identifiers, geographic or domain identifiers, version identifiers, metric keys, values, units, and a set of tags. Tags are used to carry contextual information such as environment, release batch, and dependency pointers.

[0027] To ensure time-series consistency and cross-node alignment, timestamp synchronization employs a combined strategy of unidirectional time synchronization and drift correction. On the agent side, a monotonically increasing local clock sequence number is appended to each record. On the aggregation side, data is double-sorted based on arrival time and sequence number to mitigate order disruptions caused by network jitter. To minimize impact on business threads, the collection end uses a non-blocking channel and a memory ring buffer. When overflow occurs, low-value data is discarded according to tag priority, and a discard count is recorded for subsequent auditing. The transport layer can use either a persistent message channel or a short-connection push channel. The former is suitable for smooth transmission in large-scale scenarios, while the latter is suitable for fast delivery in low-latency scenarios. When both channels coexist, key metrics use the priority channel, and batch logs use the background channel. Cleaning and standardization are completed at the aggregation node, including deduplication and verification, anomaly sample removal, unit and dimension unification, tag completion, and conflict resolution. Deduplication relies on the combination of instance identifier and timestamp as an idempotent key; unit unification is achieved through a mapping table between the indicator key and the unit; and tag conflicts are resolved based on source credibility. To balance real-time performance and computability, a sliding window aggregation method is used to generate an instant view. Within the window, the mean, peak value, and fluctuation range are calculated, while retaining the original details to support in-depth analysis. Data is written to the database using a layered approach of time-series storage and document storage. Time-series storage carries high-frequency metrics, while document storage carries multi-field logs and tracking fragments. The two are reversibly linked through a common record key. Data is exposed externally through a unified read interface, which has three capabilities: searching by service component identifier and time range, filtering by tag, and aggregation by window. The output format is consistent with the unified data model, thus forming real-time service component operation data that can be directly consumed by subsequent prediction and decision-making processes. To ensure security and compliance, fields containing sensitive elements are anonymized or desensitized before entering the persistence layer. Source domain tags and access control tags are added to data transferred across domains. For reliability, a combination of proxy breakpoint resume and aggregation-end idempotent mechanisms ensures continuous data flow in the event of a single point of failure, with a bypass proxy taking over data collection.

[0028] This can be achieved through a lightweight proxy and message channel. The proxy resides in the namespace of the service instance's host or container, capturing resource and performance metrics in a read-write separation mode. Telemetry data is written to a priority queue, while control information goes through a separate control queue. The message channel supports batch compression and retries. Multiple replica consumers are deployed at the aggregation end for parallel processing, performing verification and standardization first, before entering the time-series and document layers for dual writing. The read interface directly provides window aggregation results from the time-series layer and backfills detailed fields from the document layer. Alternatively, a network bypass vehicle and a centralized collector can be used. The vehicle captures inbound and outbound request metadata and latency distribution, and pushes instance-level resource metrics to the centralized collector. The centralized collector is responsible for unified clock correction, tag normalization, and window scrolling aggregation. This path has zero intrusion into the business binary and is compatible with multiple language stacks and runtime environments. A combination of host-level observation and kernel-level counters can be used to reduce application-side overhead in high-throughput, low-latency scenarios. The observation layer periodically reads system-level resource counts and network queue status, merging them with a small number of application-side instrumented metrics to form a low-disturbance data plane. To avoid cross-tenant interference, each tenant in a multi-tenant environment is assigned an independent label namespace and quota-based rate limiting strategy. For cross-datacenter or multi-cloud deployments, the access end introduces regional labels and routing weights, prioritizing data landing at the nearest aggregation point, and then batch aggregating it to the center in the backend. Real-time queries prioritize hitting the nearest replica. When cross-domain network fluctuations occur, the window granularity is automatically increased and the buffer holding time is extended to maintain data integrity. In the face of sudden peaks, the sampling rate and window width are adaptively adjusted according to a preset curve. Key metrics are fully collected, while low-value metrics are downsampled to avoid putting pressure on the production link. When the queue backlog exceeds the limit, degraded writing is enabled, retaining only window statistics and extreme points, while retaining discarded summaries to ensure post-event auditability. To improve maintainability, both the acquisition and aggregation ends expose health checks and self-monitoring indicators, which are incorporated into the same observation surface. Quotas and rate limits are set at the interface layer to prevent misuse from causing amplification effects.

[0029] This embodiment achieves collaborative processing of the collection, transmission, cleaning, aggregation, storage, and retrieval interfaces within the same real-time link. Real-time service component operation data is continuously generated in a unified mode, with controlled latency and traceable tags. Based on this, the decision-making level can promptly obtain the current operating status and short-cycle changes, thereby shifting the triggering conditions and execution time of resource adjustments forward. This leads to a reduction in queuing and cold start overhead, convergence of resource redundancy levels, and easier early exposure and handling of congestion at cross-component dependencies, resulting in simultaneous improvement in overall resilience and cost efficiency.

[0030] S40, Based on the real-time service component operation data and the scaling strategy set, a scaling decision is generated using the load prediction model, and a scaling instruction set is generated according to the scaling decision; In this embodiment, a load prediction model generates scaling decisions based on real-time service component runtime data and a scaling strategy set, and generates a scaling instruction set based on these decisions. This model is the core of intelligent decision-making in the entire resource optimization process, aiming to derive specific executable instructions from data-driven prediction results and strategy rules. The input to the load prediction model is real-time service component runtime data, which comes from continuously collected multi-dimensional indicators such as resource utilization, call chain performance, transaction throughput, and response latency. The model generates load trend values ​​for future time windows through time series pattern recognition and trend regression mechanisms. The model can employ a prediction structure based on recurrent neural networks to capture long-term dependencies, or it can use a weighted prediction framework based on attention mechanisms to dynamically adjust the feature contribution of different time segments. The prediction results are output in time series form, including load estimates and confidence intervals for several future time periods.

[0031] The scaling strategy set is generated by the multi-objective optimization module, encompassing strategy combinations under three-dimensional constraints: performance, cost, and energy efficiency. Each strategy defines triggering conditions (e.g., predicted load exceeding or falling below a threshold), resource adjustment magnitude, cooldown time, and constraints. The decision engine receives the predicted output and current real-time operating data, calculates the satisfaction level of the triggering conditions through the strategy matching module, and calculates the strategy suitability score by combining dependency weights. The score calculation formula can adopt a normalized weighted summation form, considering the criticality of service components, the strength of upstream and downstream dependencies, and historical execution feedback. The system selects the strategy with the highest overall score to generate a scaling decision, which includes the scaling up or down type, target service components, adjustment magnitude, and estimated execution time.

[0032] After decision generation, the system generates a scaling instruction set based on policy rules. This process maps abstract policy actions to specific infrastructure operation commands, such as adjusting the number of instances, updating container replicas, and allocating or releasing compute resources. The command generation module extracts execution templates from the policy set and embeds decision parameters into the templates to form a set of command objects. Each command object includes an execution target, operation type, parameter group, and security constraint identifier. To ensure consistent command execution, the system performs dependency topology sorting on the command set, ensuring that resource adjustments are executed in the order of component dependencies, avoiding resource allocation deadlocks or service interruptions. Finally, the validated command set is output as a scaling instruction set and processed by the infrastructure layer execution module.

[0033] In one implementation, the load forecasting model is based on a Long Short-Term Memory (LSTM) network structure. The input layer receives multi-dimensional time series of real-time operational data, the hidden layer maintains historical states to capture periodic fluctuations and burst features, and the output layer generates load forecasts for multiple future time slices. The forecast results are smoothed and filtered, and confidence levels are corrected to reduce the impact of outliers. The strategy matching phase employs a multi-objective weighted scoring mechanism, mapping performance index deviation, cost consumption change rate, and energy efficiency index change magnitude to a unified scoring space to achieve dynamic weight adjustment. The system generates scaling decisions based on the highest-scoring strategy. If the forecast results have high uncertainty, a protection strategy is adopted to delay execution or maintain the status quo. In the instruction generation phase, a template rendering mechanism injects decision parameters into standardized command templates, forming instruction sets for different infrastructure environments. For example, Kubernetes YAML resource description instructions can be generated on containerized platforms; API call sequences can be generated on virtual machine platforms.

[0034] In another implementation, the load prediction model employs a hybrid network structure based on attention weights. It simultaneously inputs short-term trends and long-term patterns into the prediction framework, dynamically allocating feature influence through attention weights to adapt to nonlinear load changes. Policy set initialization utilizes a reinforcement learning mechanism, obtaining high-reward policies through multi-round interactive training in a simulation environment. The decision generation phase not only references predicted values ​​but also incorporates real-time dependency load comparison tables of upstream and downstream components. By calculating dependency propagation coefficients, it predicts load changes in related components, thereby adding collaborative scaling actions to the decision-making process. The instruction generation module employs multi-threaded pipeline concurrent processing, distributing multiple decision instructions to different execution channels to achieve parallel resource operations and state reclamation. Consistency and idempotency checks are performed before instruction set output to ensure that repeated execution does not affect the system state.

[0035] This embodiment utilizes a joint decision-making mechanism combining a load prediction model and a set of scaling strategies. This enables the system to generate accurate scaling decisions before load changes occur, achieving proactive resource scaling. Compared to threshold-based passive scaling mechanisms, this process offers predictability, coordination, and controllability, reducing redundant resource consumption while ensuring stable performance. The generated scaling instruction set is highly standardized and can be executed directly in different infrastructure environments, improving the system's portability and scalability.

[0036] S50, the scheduling infrastructure layer executes the scaling instruction set to adjust the resource configuration of service components; In this embodiment, the scheduling infrastructure layer executes scaling instruction sets to adjust the resource configuration of service components. This is a crucial stage in the resource optimization process, transitioning from the decision-making layer to the execution layer. It aims to ensure that the generated scaling instructions are reliably and accurately translated into actual changes to physical or virtual resources. The scheduling process relies on the resource management interface and scheduling control mechanism provided by the infrastructure layer, responsible for allocating, releasing, and reorganizing computing resources in a multi-node, multi-type resource environment. This process begins with the scheduling control module parsing the scaling instruction set, identifying the target component, operation type (expansion or contraction), instance specifications, and execution priority corresponding to each instruction. Each instruction includes an execution target identifier, a resource category identifier, and a set of parameters, including indicators such as the number of CPU cores, memory capacity, network bandwidth, and storage quota. The parsing results are transformed into unified scheduling task objects and added to a task queue. The task queue is sorted according to priority and dependencies to prevent conflicting resource operations from being executed concurrently.

[0037] During the task preparation phase, the system calls the resource orchestration module to query the current resource status of the infrastructure layer, including node health, capacity reserves, and network connectivity. The scheduler calculates a resource allocation scheme based on the real-time resource view and command parameters. The allocation algorithm can employ the weighted minimum load principle or a constraint optimization-based scheduling model to minimize resource migration costs while meeting performance requirements. For scaling up commands, the scheduler selects the target node and allocates computing units to create new service component instances. After creation, instance initialization and network registration are performed. For scaling down commands, the scheduler gradually releases the resources occupied by the instances after verifying there are no active sessions. All operations are implemented through resource management interfaces in the infrastructure layer, which may include container management APIs, virtual machine control interfaces, or bare metal management channels.

[0038] During the execution phase, a status monitoring and callback mechanism is introduced. The monitoring module tracks the execution status, time consumption, and result code of each resource operation, triggering compensation operations or retries in case of exceptions. To ensure consistency, all instruction execution follows transaction semantics: if any subtask fails, the system will perform a rollback operation to restore the resources to their pre-change state. After execution, the scheduling module updates the resource status cache and service topology mapping to ensure that the system's resource view is consistent with the actual environment. Simultaneously, it notifies the upper-layer monitoring module to record execution logs for subsequent performance analysis and strategy optimization. The entire scheduling process achieves a closed loop from logical decision-making to physical execution, ensuring that service component resource configurations are dynamically adjusted within controllable boundaries.

[0039] In one implementation, the scheduler is based on the Kubernetes resource orchestration mechanism, and scaling commands are translated into replica count adjustments for Deployments or StatefulSets. The scheduling module submits scaling requests through the Kubernetes APIServer. The control plane selects nodes and launches new instances according to the scheduling policy, while the data plane performs container image pulling and network binding, followed by updating service discovery and load balancing configurations. Scaling down first executes the Pod eviction process, releasing node resources only after confirming the session has ended. To avoid resource fluctuations, the scheduling module incorporates rate limiting and cooldown time strategies when executing commands to prevent frequent scaling up and down.

[0040] In another implementation, for hybrid virtual machine and bare metal environments, the scheduler employs a resource pool-based allocation model. Scaling commands, after being transformed, invoke the resource pool API. During scaling up, compute instances are requested from the reserved pool and bound to the target service component; during scaling down, released instances are returned to the idle pool. The system monitoring module receives execution events in real time via the message bus. Upon detecting an instance ready event, it triggers the service registration process, writing the new instance metadata to the service discovery table so that the traffic allocation module can update routes. To handle execution anomalies, the scheduler provides a multi-level retry mechanism, classifying errors as transient, recoverable, and unrecoverable to ensure eventual consistency.

[0041] This embodiment adjusts the resource configuration of service components by scheduling the execution of scaling instruction sets at the infrastructure layer, achieving a seamless connection from intelligent decision-making to resource execution. This process ensures that scaling instructions are accurately implemented in the multi-environment, multi-node infrastructure layer, significantly improving the automation and dynamic adaptability of resource configuration. Compared to manual adjustment or static configuration modes, the scheduling execution mechanism can respond to load changes within seconds, reducing resource idleness and performance bottlenecks, and improving overall service stability and operational efficiency.

[0042] S60, analyze the performance indicators and resource utilization of the service components after adjusting the resource configuration, generate a strategy analysis report, and update the load prediction model and the scaling strategy set according to the strategy analysis report.

[0043] In this embodiment, analyzing the performance metrics and resource utilization of service components after adjusting resource configuration, generating a strategy analysis report, and updating the load prediction model and scaling strategy set based on the strategy analysis report are crucial steps in forming a closed loop for resource optimization. The goal is to enable the system to continuously evolve through quantitative evaluation and pattern learning of the adjusted operating status. The analysis phase first collects performance metric data and resource utilization data after resource adjustment from the monitoring system. Performance metric data includes service component response time, throughput, error rate, request queuing time, and concurrent processing volume; resource utilization data covers dimensions such as CPU usage, memory consumption, network bandwidth usage, and disk I / O ratio. The collected data is indexed according to service component identifiers, timestamps, and environment tags to facilitate comparison with baseline data before adjustment.

[0044] The system performs baseline comparison calculations through a comparative analysis module. Comparison methods include time window alignment and performance normalization. Time window alignment ensures consistent analysis periods, while performance normalization eliminates offsets caused by load differences between different components. The analysis results generate performance improvement rates and resource utilization change rates to quantify the effectiveness of scaling operations. If the performance improvement rate is lower than the expected threshold or resource utilization increases significantly, it indicates a mismatch risk in the scaling adjustment.

[0045] Based on the above analysis results, the strategy analysis report generation module models the correlation between performance indicator changes and resource utilization changes, generating a comprehensive report that includes a summary of indicator statistics, a resource utilization graph, anomaly markers, and adjustment suggestions. The report is stored in a structured format, with fields including analysis period, rate of change of key performance indicators, prediction deviation, validity of strategy triggering conditions, and optimization suggestions. After report generation, the analysis module performs feedback processing, calculating the deviation metric of the load prediction model. The deviation metric is expressed as the mean squared error between predicted and actual observations or as a weighted residual, reflecting the degree of model accuracy degradation. During the model update phase, weight parameters are adjusted through error backpropagation or parameter retraining, allowing the model to refit to new business load characteristics. During the strategy set update phase, strategy parameters are adjusted based on the optimization suggestions in the report, such as correcting scaling thresholds, cooldown times, and resource allocation ratios, achieving adaptive evolution of the strategy.

[0046] In one implementation, the performance indicator analysis module employs a sliding time window mechanism, with each window lasting from several minutes to several hours. Within each window, the average response time and throughput are aggregated, and the difference from the baseline is calculated. Comparative analysis uses a dynamic threshold algorithm, automatically adjusting the judgment criteria based on historical volatility to avoid misjudgments caused by short-term fluctuations. The strategy analysis report is automatically generated from a visualization template. The optimization suggestions in the report are calculated using a rule-based engine; for example, when CPU utilization is consistently below the target range and response time increases, it is recommended to reduce the scaling down or extend the cooling cycle. The load prediction model update uses an online learning mechanism. When the system detects that the model prediction error exceeds a threshold, parameter retraining is automatically triggered to reduce manual intervention. The scaling strategy set update is performed through a versioned update by the strategy management module. Old strategies are retained as rollback versions after the update, ensuring the system's safe evolution.

[0047] In another implementation, performance and resource utilization analysis employs a multidimensional feature regression model, modeling the nonlinear relationship between performance indicators and resource utilization as a regression equation, and identifying the optimization space through residual analysis. After the strategy analysis report is generated, it is not only fed back to the model and strategy set but can also be synchronized to the monitoring dashboard for manual review and strategy approval. An attention-weighted mechanism is introduced during the model update phase, making the model sensitive to recent load changes and retaining decay memory of historical long-term trends, thus balancing stability and adaptability. When updating the strategy set, reinforcement learning methods are used to automatically adjust scaling trigger conditions and execution timing based on the reward signal after strategy execution, improving the system's resource utilization efficiency under different load modes.

[0048] This embodiment, through a systematic analysis of the performance indicators and resource utilization of the adjusted service components, enables the system to identify the effectiveness and potential deviations of scaling operations, generating measurable feedback signals. Furthermore, through the generation of strategy analysis reports and a learning-based update mechanism, it achieves dynamic optimization of the load prediction model and scaling strategy set. This mechanism frees resource scheduling from relying on static thresholds, forming a data-driven, continuously evolving system that significantly improves model prediction accuracy and strategy matching, ultimately achieving a dynamic balance between resource utilization efficiency, system performance, and energy consumption control.

[0049] This invention relates to the field of cloud computing technology and can be applied to business scenarios such as fintech and healthcare. It discloses an application architecture resource optimization method, apparatus, device, and medium, comprising: acquiring operational data of each service component in the application architecture and extracting load features to generate a load feature vector table; training and generating a load prediction model based on the load feature vector table and initializing a scaling strategy set; acquiring real-time operational data of the service components, generating scaling decisions and a scaling instruction set based on the real-time operational data and the scaling strategy set through the load prediction model; scheduling the infrastructure layer to execute the scaling instruction set to adjust the resource configuration of the service components; analyzing the performance indicators and resource utilization of the adjusted service components, generating a strategy analysis report, and updating the load prediction model and the scaling strategy set. This invention, by combining load prediction and strategy feedback, achieves adaptive closed-loop optimization from real-time operational data to resource configuration adjustment. This enables the system to generate decisions in advance and dynamically allocate resources when business load changes, thereby reducing resource redundancy while ensuring performance stability and improving the elasticity and resource utilization efficiency of microservice architectures under complex load environments.

[0050] In one embodiment, step S10 above includes: S101, Deploy monitoring agents to various service components in the application architecture; S102, collect resource utilization data of the service components through the monitoring agent; S103, collect performance data of the call chain between service components through the monitoring agent; S104, collect business indicator data related to business logic; S105, perform data cleaning and preprocessing on the resource utilization rate data, call chain performance data and business indicator data to obtain preprocessed data; S106, Perform time window aggregation processing on the preprocessed data to generate a time series dataset; S107, Extract load pattern features and periodic features from the time series dataset; S108, Based on the load pattern characteristics and periodic characteristics, generate a load feature vector table containing multi-dimensional feature vectors.

[0051] In this embodiment, monitoring agents are deployed to various service components within the application architecture. These agents reside inline within the service instance runtime environment or are attached to the network and container runtime in a bypass manner. The collection cycle and sampling granularity are centrally configured and distributed. During the initialization phase, the monitoring agent registers service component identifiers, instance identifiers, version identifiers, topology identifiers, and region identifiers, establishing a dual-channel marker consisting of monotonic time-series numbering and high-precision timestamps for cross-node alignment and out-of-order resolution. Resource collection focuses on three metrics: processor utilization, memory usage, and network throughput. Processor utilization is obtained jointly through the operating system and container runtime metrics interfaces. Memory usage is represented by a combination of page frame occupancy and compression occupancy. Network throughput is represented by a combination of bidirectional byte counts and queue depth observations. Call chain performance collection focuses on two metrics: request response time and error rate. Request response time is recorded at the entry and exit points using the same distributed coding standard, recording the minimum, maximum, and quantile intervals. The error rate is recorded by pairing the total number of requests with the number of failures, with the reasons for failures carried by a set of tags. Business metrics collection focuses on two types of intensity signals: user request volume and transaction processing volume. User request volume is aggregated at the access layer, while transaction processing volume is aggregated at the business execution unit. Both are written to the same time baseline to align with resource and performance metrics.

[0052] Data cleaning and preprocessing are performed at the aggregation layer. First, idempotent deduplication is performed, with the idempotent key composed of the service component identifier, instance identifier, and timestamp. Next, unit normalization is completed, mapping all resource, performance, and business metrics to a unified dimension. Then, outlier removal is performed, using robust intervals within a sliding window to filter out spikes and distorted records. Missing value imputation combines bidirectional interpolation within the same window with cross-instance isomorphic comparison. Tag conflicts are serialized and adjudicated based on source credibility, retaining high-credibility tags and recording the adjudication trajectory. The cleaned records then enter time-window aggregation processing. The window advances in a sliding manner, with the window size and step size automatically adjusted based on service fluctuations and business rhythms. Three types of statistics—mean, peak, and fluctuation amplitude—are generated within the window, while the original details are simultaneously retained to support backtracking and diagnosis. Aggregation results and detailed results are simultaneously written to hierarchical storage. The time-series layer uses a columnar layout to carry high-frequency metrics, while the document layer carries distributed, encoded delay distributions and error records. The two layers are reversibly linked through a shared primary key.

[0053] When extracting load pattern and periodic features from time-series datasets, the mean feature is first calculated over a continuous window to characterize stable load levels, and then the peak feature is calculated near the peak to characterize instantaneous load capacity. Simultaneously, the fluctuation feature is measured using standardized deviation within the window to characterize instability. Periodic features are extracted using a joint time-domain and frequency-domain method. In the time domain, autocorrelation and sliding similarity are used to identify intraday and intraweek rhythms, while in the frequency domain, energy concentration is used to measure significant periods. Periodic phases are aligned using the maximum coherence point. To avoid amplifying noise from a single service, a topology-dependent auxiliary constraint is introduced, jointly encoding upstream outbound and downstream inbound load strengths into interactive labels, which participate in weight allocation during the feature extraction stage, enabling features to reflect collaborative load patterns rather than isolated patterns.

[0054] When generating the load feature vector table, the service component identifier and the start and end dates of the time window are used as the primary key, and multi-dimensional feature vectors are used as the value range. Vector dimensions cover elements such as resource usage triples, performance doubles, business intensity doubles, mean features, peak features, fluctuation features, periodic intensity and phase, and interaction weights. The writing process simultaneously performs standardization and offset removal, using zero mean and unit variance to map each dimension to a uniform scale, and using binning encoding to establish a stable representation for distributed features. The vector table is organized in the storage layer using a columnar index based on service components and time partitions, supporting high-concurrency reads by label filtering and time range pruning. The vector table shares a mapping relationship with the detail layer, enabling closed-loop traceability from features back to the original record. To ensure security and compliance, fields containing sensitive identifiers are anonymized or desensitized, and source domain tags and access control tags are added to cross-domain transfer records. To ensure reliability, the acquisition agent enables a breakpoint resume mechanism, and the aggregation layer write uses idempotent transaction semantics. Single-point failures are handled by bypass acquisition paths, ensuring continuous production of stable vectors.

[0055] This embodiment achieves this through a cascaded approach: using a monitoring agent as the entry point, cleaning and aggregation as the central mechanism, pattern extraction and periodic extraction as the bridge, and structured vector representation as the exit point. The original multi-source signals are transformed into a load feature vector table with a unified scale and temporal and topological semantics. This forms a high-quality input that can be directly learned and consumed in decision-making. The prediction side can obtain reliable representations along three main axes: stable level, instantaneous peak value, and fluctuation amplitude. The strategy side can incorporate periodicity and interactivity into weight allocation, resulting in earlier resource scaling trigger points, more precise amplitudes, and more sufficient dependency and coordination. Resource redundancy and queuing latency converge synchronously, significantly reducing bias and drift in subsequent training and online inference.

[0056] In one embodiment, step S20 above includes: S201, Obtain the load feature vector table for historical time periods as the training dataset; S202, the training dataset is divided into a training set and a validation set; S203, Using the training set, a load prediction model is trained and generated through time series analysis methods; S204 defines the performance, cost, and energy efficiency objectives for resource optimization; S205, Based on the aforementioned performance objectives, cost objectives, and energy efficiency objectives, a multi-objective optimization model is constructed; S206, Generate an initial scaling strategy through the multi-objective optimization model to form a scaling strategy set; S207, Use the validation set to validate the load prediction model and obtain the model validation result; S208. In a simulation environment, the training dataset is used to simulate the running environment to test the effectiveness of the scaling strategy set and obtain the strategy test results. S209, Based on the model verification results and the strategy test results, optimize the parameters of the load prediction model and the strategy parameters of the scaling strategy set; S210, storing the optimized load prediction model and scaling strategy set, completes the initialization process.

[0057] In this embodiment, a load feature vector table for historical time periods is obtained as the training dataset. First, continuous intervals are selected on the timeline to ensure coverage of load patterns such as weekdays and non-weekdays, peak and trough periods, and promotional and inactive periods. Then, using the service component identifier and time window as keys, vector rows are read in batches, and time alignment, label alignment, and missing data completion are performed to form a time-sorted sample sequence that can be directly input into the model. To avoid sample leakage, future window information is removed during the generation of the training dataset, retaining only the features up to the current window to ensure that subsequent predictions conform to causal constraints. A uniform scale mapping is used for the vector dimensions, aligning resource-type, performance-type, and business intensity-type features on the same scale to reduce gradient imbalance caused by different scales during training.

[0058] When dividing the training dataset into training and validation sets, a time-based split is used, with the first part serving as the training set and the second part as the validation set. The split boundaries are aligned with whole weeks or whole days to prevent periodic artifacts from affecting the evaluation. For environments with cross-regional deployments, a regional label is introduced for hierarchical splitting to ensure that the training and validation sets maintain a consistent regional distribution ratio, thereby ensuring that the generalization evaluation more closely resembles the real-world operating scenario. After the split, distribution summaries and periodic summaries are calculated for each part. If the difference exceeds a set tolerance range, the split boundaries are adjusted or the sample coverage is expanded until the distribution difference is within a stable range.

[0059] Using a training set, a load prediction model is trained using time series analysis. The training input receives a multi-dimensional vector sequence sorted by time, and the input and output pairs are organized in a sliding window manner. The input window carries the feature combination of several past time slices, and the output window corresponds to the load trend values ​​of several future time slices. To capture the coexistence of periodicity and suddenness, the training process introduces a short-term trend channel and a long-term rhythm channel. The former focuses on fluctuations and peaks within a small window, while the latter focuses on phase and periodic intensity within a large window. The two channels merge into a single prediction sequence at the output end, and the impact of outliers is mitigated through a residual correction unit. During training, batch normalization, gradient pruning, and early stopping strategies are used to avoid gradient explosion and overfitting. To improve robustness, some input dimensions are randomly masked for gap training, ensuring that the model maintains stable output even in real-world scenarios with insufficient testing.

[0060] When defining performance, cost, and energy efficiency objectives for resource optimization, the following steps are taken: First, based on historical service level agreements and resource billing structures, establish the upper limit and stability range for the performance objective, the unit-time resource overhead range for the cost objective, and the unit-throughput energy consumption range for the energy efficiency objective. Then, map these three types of objectives to comparable dimensionless utility scores, forming an objective vector that can be processed simultaneously by the optimizer. The objective mapping table records the weight differences and business priorities of different components to support critical path components receiving higher objective weights when resources are scarce. The objective ranges and weights are stored as external input during the training phase and can be updated subsequently based on runtime feedback.

[0061] Based on performance, cost, and energy efficiency objectives, a multi-objective optimization model is constructed. The optimization variables are the set of resource adjustment actions and the set of adjustment magnitudes. Constraints include dependency on topology consistency, resource quota limits, cooldown time, and change rate limits. The optimizer searches for feasible solutions to the same predicted load curve, filters non-dominated solutions through dominance relationships, and obtains candidate combinations covering different trade-offs. To avoid congestion of the solution set in a single region, a diversity maintenance mechanism is introduced, sampling uniformly according to the spatial distance of the objectives, so that the strategy space covers different preferences such as performance priority, cost priority, and energy efficiency priority.

[0062] An initial scaling strategy is generated through a multi-objective optimization model, forming a scaling strategy set. During the generation process, each non-dominated solution is transcribed into a rule-based entry. Each entry includes a trigger condition, adjustment direction, adjustment magnitude, cooldown time, a dependency linkage list, and a fallback condition. Trigger conditions can be composed of three types of signals: predicted value crossing a threshold, predicted slope exceeding a limit, or predicted confidence band exceeding a safe interval. The dependency linkage list is automatically filled based on the service dependency graph, mapping upstream expansion actions to necessary downstream capacity expansion, avoiding bottleneck shifts caused by local expansion. After generation, the strategy set undergoes consistency verification, eliminating conflicting or overlapping entries.

[0063] The load prediction model was validated using a validation set, and the validation results were obtained. The validation process was rolled over time, recording the prediction error, confidence band coverage, and directional mismatch ratio for each time slice, and outputting stratified evaluation summaries by component, region, and time period. Segments with abnormal errors at cycle inflection points or sudden phases were marked as high-risk segments to provide a basis for subsequent parameter correction.

[0064] In the simulation environment, a training dataset is used to simulate the operating environment and test the effectiveness of the scaling strategy set, obtaining strategy test results. The simulation timetable is replayed with the actual production timetable, with the predicted flow and strategy flow driven in the real order. The resource execution model reproduces the scaling latency, cold start duration, and capacity ramp-up curves, while the traffic model reproduces peak sharpness and tail trailing. The strategy test results output metrics such as the number of strategy triggers, trigger lag, execution success rate, performance default duration, resource utilization curve, and energy consumption estimation curve, used to measure the operability and cost-benefit ratio of strategy entries.

[0065] Based on model validation and strategy testing results, the parameters of the load prediction model and the strategy parameters of the scaling strategy set are optimized. The optimization process integrates the two types of results into a unified correction signal: on the prediction side, the weights, smoothing coefficients, and confidence band widths of the short-term and long-term channels are adjusted according to the error distribution; on the strategy side, the trigger threshold, adjustment magnitude, and cooldown time are adjusted according to the default duration and resource occupancy curve, and the dependent linkage list is supplemented or simplified to avoid excessive linkage leading to unnecessary resource expansion. The optimization iteration adopts an outer-loop strategy selection and inner-loop model retraining approach, with multiple iterations until the profit improvement is lower than the convergence threshold.

[0066] The storage-optimized load prediction model and scaling strategy set complete the initialization process. The final version, along with version tags, training summaries, and evaluation summaries, is registered to the model and strategy repository in the runtime environment, providing traceable version records and canary deployment capabilities. The loading interface supports selecting differentiated versions by region, business line, and component to adapt to heterogeneous operating scenarios.

[0067] This embodiment uses a load feature vector table as the data base, time series prediction and multi-objective optimization as dual engines, and verification and simulation as a dual closed-loop correction mechanism. The load prediction model output during the training phase can stably capture trends, peaks, and periodic phases. The strategy initialization phase can explicitly transform the trade-offs between performance, cost, and energy efficiency into executable items. After joint optimization by fusing model verification results and strategy test results, prediction errors and strategy lags are compressed synchronously. The triggering conditions and adjustment ranges are closer to the actual carrying capacity, and the dependency linkage is more in line with the call chain transmission law. Once the initialization is completed, it has resource scalability with both foresight and operability, laying a stable starting point for subsequent online decision-making and continuous learning.

[0068] In one embodiment, step S40 above includes: S401 reads real-time service component runtime data from the real-time database; S402, Input the real-time service component operation data into the load prediction model to generate load trend data for future time periods; S403, Based on the load trend data and the multi-objective optimization strategies in the scaling strategy set, generate one or more candidate scaling decisions; S404, Based on the dependency graph between service components, analyze the performance impact of the candidate scaling decision on the associated service components, and obtain the performance impact analysis results; S405, Based on the performance impact analysis results, select the decision with the best overall performance from the candidate scaling decisions as the final scaling decision; S406, the final scaling decision is converted into a set of scaling instructions executable at the infrastructure layer.

[0069] In this embodiment, when reading real-time service component operation data from the real-time database, the service component identifier and time range are used as the search key, and deduplication and alignment are performed according to a unified timestamp and monotonic sequence number. The reading results include three types of metrics: resource usage, performance response, and business intensity. After the data enters the memory buffer, it undergoes dimensional standardization and missing data imputation to maintain the feature scale consistent with the load feature vector table. Before inputting the real-time service component operation data into the load prediction model, a sliding window input tensor is constructed. The window contains mean features, peak features, and fluctuation features, as well as derived quantities such as periodic phase and interaction weights. The model outputs load trend data for multiple future time slices and simultaneously provides uncertainty intervals and direction consistency markers to facilitate risk constraints in subsequent strategy selection.

[0070] When generating candidate scaling decisions based on load trend data and multi-objective optimization strategies in the scaling strategy set, the deviation of performance targets, the increment of cost targets, and the rate of change of energy efficiency targets are first calculated for each time slice. These three factors are then weighted and normalized to form a utility score. Next, the utility score is matched with the triggering conditions, adjustment range, and cooldown time in the scaling strategy set to generate several candidate scaling decisions. Each candidate includes the adjustment direction, adjustment range, effective time, duration, and cooldown constraints, and the strategy source and priority are recorded. To avoid frequent changes caused by short-cycle fluctuations, minimum effective duration and upper limit constraints on change rate are introduced. Candidates that violate these constraints are downweighted or eliminated.

[0071] When analyzing the performance impact of candidate scaling decisions on related service components based on the dependency graph of service components, the dependency graph is represented as a weighted directed graph, where edge weights represent dependency strength and call amplification coefficients, and node loads represent current inbound strength and queue depth. For each candidate, load propagation is performed along the dependency direction to calculate the expected throughput and latency of related nodes during the candidate's effective period. The effects of cold start latency and capacity ramp-up curves are then overlaid to form the performance impact analysis results. The analysis results include changes in critical path latency, queue length changes, and default risk distribution to quantify the cascading effects of the candidate. If resource bottlenecks are found in downstream nodes during propagation, collaborative adjustment suggestions are added to the candidate, or it is directly downgraded.

[0072] When selecting the optimal scaling decision for overall performance from candidate scaling decisions based on performance impact analysis results, a global objective function is constructed, with minimizing critical path latency as the primary constraint, while applying soft penalties to resource and energy consumption increments. All candidates are scored and ranked, and the item with the highest score that satisfies cooling and rate constraints is selected. If multiple candidates are equivalent under the primary constraint, the item with smaller resource increment or better energy efficiency is selected as the final scaling decision. The reasons for abandoning candidates and constraint conflicts are recorded in the audit trail for subsequent feedback and learning.

[0073] When converting the final scaling decision into a set of scaling instructions executable at the infrastructure layer, abstract actions are mapped to specific commands based on the infrastructure layer operation template. The commands include the target service component, the number or specifications of instance changes, the execution time, and the rollback conditions. Topology sorting is performed on cross-component collaborative decisions to ensure that upstream bearers are in place first or take effect synchronously with downstream bearers. Idempotency and consistency checks are performed on the command set to ensure that repeated submissions do not change the system state and that there are no resource conflicts across commands. Finally, a scaling instruction set is generated with a cooling window and monitoring hook identifiers to provide anchor points for subsequent execution and observation.

[0074] This embodiment obtains load trend data by driving a load prediction model with real-time service component runtime data, generates candidate scaling decisions using multi-objective optimization strategies in a scaling strategy set, provides performance impact analysis results using a dependency graph, and finally selects the overall optimal performance item and pushes it down to the infrastructure layer as an executable scaling instruction set. The decision-making chain forms a closure in three dimensions: predictability, coordination, and operability. The trigger point is moved forward to reduce waiting and queuing, collaborative evaluation suppresses the migration of link bottlenecks, standardized instructions reduce execution gaps, resource increments and energy consumption increments are constrained, and overall performance stability and resource utilization efficiency are improved simultaneously.

[0075] In one embodiment, step S406 includes: S4061, parse the final scaling decision and identify the service component instance scaling up or scaling down operation to be performed; S4062, Determine the corresponding infrastructure layer resource operation specifications based on the service component instance expansion or contraction operation; S4063, Based on the infrastructure layer resource operation specifications, generate a resource operation command sequence; S4064, Format the resource operation command sequence into a standardized instruction format acceptable to the infrastructure layer application interface; S4065, verify the syntactic correctness and execution feasibility of the standardized instruction format; S4066 uses a set of validated standardized instruction formats as the scaling instruction set.

[0076] In this embodiment, when parsing the final scaling decision, the input is a structured decision description, including fields such as the target service component identifier, service component instance scaling up or down operation, adjustment range, priority, planned effective time, and cooldown time. The parsing process constructs a standardized action description, maps multi-source fields to a unified key set, performs boundary pruning and unit unification on quantitative parameters, completes monotonic sequence numbering and time zone alignment for time-related parameters, and verifies whether dependency chains and execution windows conflict. After parsing, a standard action unit is generated, serving as the sole entry point for subsequent mapping and rendering.

[0077] When determining the corresponding infrastructure layer resource operation specifications based on service component instance scaling-up or scaling-down operations, a mapping table from action units to basic resource primitives is established, clarifying the differentiated interface constraints and quota models for container platforms, virtual machine platforms, and function computing platforms. The resource operation specifications define the allowed set of atomic operations, parameter fields, idempotent key construction methods, permission scope, region and availability zone selection strategies, affinity and anti-affinity constraints, network and storage binding templates, and failure rollback strategies. For scaling-up operations, the specifications must provide instance creation primitives, capacity reservation primitives, and readiness criteria; for scaling-down operations, the specifications must provide connection emptying primitives, instance removal primitives, and resource reclamation primitives. The specifications also record security and compliance restrictions for subsequent feasibility verification.

[0078] When generating resource operation command sequences based on infrastructure layer resource operation specifications, a standard action unit is expanded into an ordered command chain. Command chains in scaling-up scenarios typically include capacity assessment, quota locking, image or template retrieval, instance creation, health checks, service registration, and route updates; command chains in scaling-down scenarios include traffic diversion, connection emptying, instance removal, resource release, and route convergence. The command sequence assigns a sequence number and causal dependency to each command, marks timeouts, retry strategies, and fallback anchors, and sets concurrency and throttling parameters to ensure bounded resource usage and controllable jitter even during large-scale operations. For decisions involving cross-component linkage, the command generation phase performs topology sorting based on the dependency topology to ensure that the arrival order of upstream and downstream bearers meets business propagation rules.

[0079] When formatting resource operation command sequences into a standardized instruction format acceptable to the infrastructure layer application interface, structured rendering is performed according to the target interface specification. Required and default fields are filled in, authentication domains, tenant identifiers, region identifiers, and availability zone identifiers are completed, idempotent keys and idempotency policies are generated, and request validity periods, idempotency windows, and cooldown windows are set. Instructions are batch-encapsulated into batches with monotonic sequence numbers, and the command graph and dependency graph are recorded within each batch to facilitate consistent scheduling at the execution end. Sensitive fields are anonymized or encrypted, and source domains and access control tags are appended to batches requiring cross-domain delivery.

[0080] When verifying the syntactic correctness and execution feasibility of standardized instruction formats, the following steps are performed: First, schema and constraint validation are conducted to ensure that field types, required fields, and value ranges meet the interface specifications. Next, reference integrity and existence validation are performed to confirm that referenced objects such as images, networks, storage, service accounts, and node pools exist and are in a usable state. Then, resource feasibility and scheduling feasibility validation are performed, assessing schedulability within the target window based on quotas, remaining capacity, affinity and anti-affinity constraints, topology distribution, and fault domain isolation strategies. Finally, conflict detection and concurrency safety assessment are conducted to identify resource conflicts, rate conflicts, and cooling conflicts with in-transit batches, and to provide conflict resolution solutions or degradation paths. After all validations pass, an execution signature and audit digest are generated to ensure traceability and replayability of subsequent executions.

[0081] When a standardized set of validated instruction formats is used as a scaling instruction set, it is written to the instruction repository and its version, batch number, and expiration date are registered. A one-to-one mapping relationship is established with the final scaling decision, along with a list of rollback batches and observation hooks. Observation hooks are used to report ready events, failure events, and key performance indicators during execution. The scaling instruction set exposes read and callback interfaces to the scheduling layer, ensuring that the scheduler consumes according to dependency order and rate constraints and reports changes in state, thereby maintaining a consistent state view and audit loop during execution.

[0082] This embodiment achieves a stable transformation of abstract decisions into executable infrastructure objects through standardized parsing, mapping of platform-differentiated resource operation specifications, generation of ordered command chains, standardized rendering at the interface level, full-stack verification and audit signature, and finally, traceable and scalable instruction set output. This eliminates the semantic gap between strategy and execution, as well as the uncertainty caused by platform differences. Feasibility and conflict verification before execution reduces the probability of failure and rollback; topology sorting and rate constraints reduce link jitter and resource oscillation; and idempotent strategies and audit mechanisms improve the security and controllability of repeated triggering and anomaly recovery. Ultimately, this results in faster deployment speed, lower execution deviation, and higher cross-environment portability.

[0083] In one embodiment, step S50 above includes: S501, parse the scaling instruction set and identify the specifications and quantity of service component instances that need to be added or reduced; S502, Generate resource operation instructions based on the service component instance specifications and quantity; S503, send the resource operation command to the resource manager of the infrastructure layer; S504, the resource operation instruction is executed through the resource manager to allocate processing resources to create new service component instances or release the processing resources occupied by idle service component instances; S505 monitors the resource allocation process and registers the new service component instance with the service discovery component after the new service component instance is created. S506 updates the load balancing strategy based on changes in the number of service component instances.

[0084] In this embodiment, when parsing the scaling instruction set, a unified action description is constructed using the scaling instructions as input. Elements such as service component identifier, service component instance specification, number of service component instances, scaling up or down type, execution priority, planned effective time, and cooldown time are extracted to achieve dimensional unification and boundary trimming. Combined with historical in-transit tasks, a deduplication and deconcurrency-free view is generated. For multiple instructions for the same service component within overlapping time windows, they are merged into a single instruction according to priority and cooldown constraints, providing topological dependencies and execution order to form an executable task graph. The task graph undergoes conflict detection before entering the execution queue, including resource quota conflicts, affinity and anti-affinity conflicts, fault domain isolation conflicts, and version compatibility conflicts. Conflicts are resolved through delayed execution, batch execution, or degraded execution. Each task generates an idempotent key and rollback anchor point to ensure deterministic repeat triggering and anomaly recovery.

[0085] When generating resource operation instructions based on the service component instance specifications and the number of service component instances, the specifications are mapped to infrastructure primitives. Specification parameters include compute resource quotas, memory quotas, network bandwidth, and storage binding templates; quantity parameters are transformed into replica targets or instance targets. Scaling up generates sub-instructions such as capacity verification, quota locking, image or template retrieval, instance creation, health checks, configuration injection, service registration, and route refresh; scaling down generates sub-instructions such as traffic diversion, connection emptying, instance removal, resource reclamation, and route convergence. Each sub-instruction includes timeout, retry, and backoff strategies, and is connected by causal edges in the task graph, marking the maximum concurrency and throttling thresholds to avoid platform instability caused by concentrated operations. During cross-component collaboration, topology sorting is performed based on dependency relationships to ensure that the arrival order of upstream and downstream bearers conforms to the call chain propagation rules.

[0086] When sending resource operation instructions to the resource manager at the infrastructure layer, temporary credentials are obtained through authentication and authorization channels. A batch sending strategy and monotonic sequence numbers are used to ensure that the boundaries and order of instructions are not disrupted. Rate limits and concurrency limits are imposed on external interfaces, and critical operations on the delivery plane and non-critical operations on the back-end plane are distinguished. Critical operations are given priority in using rate quotas. Network anomalies and transient failures are handled through fast retries, while structural failures are handled through rollback branches or manual fallback branches. Error classification and handling strategies are written into the audit flow.

[0087] When creating new service component instances or releasing computing resources occupied by idle instances by executing resource operation commands through the resource manager, the scaling path selects capacity within the node pool, taking into account node health, remaining resources, affinity and anti-affinity constraints, fault domain and availability zone distribution to complete instance placement. After the instance is launched, image verification, configuration injection, and key loading are performed. Only after the health check is passed can it enter the ready state. Network and storage binding are automatically completed according to the template, and side-vehicles and probes are enabled as needed. The scaling path first performs traffic switching at the load balancing layer, then performs connection draining on the instance. After confirming that there are no active sessions, the instance is removed and resources are reclaimed. Storage volumes select detachment or retention strategies based on the binding mode to avoid data loss. Transactional control is enabled throughout the scaling process. Any failure of a sub-command triggers a partial rollback or a batch rollback. The rollback path is driven by pre-generated anchors to ensure that the state can be recovered.

[0088] During the monitoring of resource allocation and registration with the service discovery component after the creation of a new service component instance, the execution plane and the observation plane are decoupled. The event stream transmits the creation, ready, failure, and rollback statuses in real time, and the monitor updates the execution progress in an event-driven manner. The instance writes the component name, instance address, version number, availability zone tag, and health status through the service registration interface. The registration items set the lifetime and renewal period to prevent zombie instances from being left behind. After registration, a consistency check is triggered to ensure that the registry is consistent with the actual set of instances, and abnormal items enter the automatic correction process.

[0089] When updating load balancing strategies based on changes in the number of service component instances, the latest instance set of the service discovery component is read, and targeted updates are performed for different balancing algorithms. In weighted round-robin scenarios, weights are recalculated and applied smoothly according to thresholds. In least-connections scenarios, connection counts are rebuilt and traffic is slowed down for new instances. In consistent hashing scenarios, the hash ring is updated, and key migration is reduced in stages. Simultaneously, dynamic calibration of circuit breaker thresholds and retry strategies is applied to ensure stable request paths during topology changes. The entire update process follows the principles of zero interruption and zero amplification, employing gradual scaling and graceful connection migration to prevent jitter caused by sudden surges.

[0090] To ensure traceability and controllability, the execution chain records audit events and metrics at key nodes: submission rate, queuing time, creation time, ready time, rollback count, success rate, and resource reclamation ratio. These metrics are fed back through a unified observation plane, providing input for subsequent strategy analysis and parameter tuning. To enhance security and isolation capabilities, multi-tenant environments use independent namespaces and quotas for different tenant applications. Cross-domain and cross-availability zone operations are labeled with source and target domains, and access control is validated at both the data plane and control plane. All interface calls are configured with idempotent policies and expiration dates to prevent replay and out-of-order execution.

[0091] This embodiment generates an ordered task graph by parsing the scaling instruction set, constructs atomic-level resource operation instructions based on specifications and quantities, and sends them to the resource manager for execution via a controlled-rate and idempotent delivery pipeline. New instances are then included in service discovery through an event-driven observation and registration process, and load balancing updates are completed using a progressive strategy. The semantic gap between instruction and execution is eliminated, ensuring the timing and topological consistency of scaling. Transactional control and rollback anchors reduce failure costs, throttling and concurrency constraints suppress resource fluctuations, graceful traffic redirection and soft start avoid the impact of momentary jitter on request paths, and auditing and metric feedback provide quantitative evidence for subsequent optimization. This approach maintains service availability and response stability while improving resource reclamation efficiency and scaling speed, forming a highly reliable and elastic execution loop.

[0092] In one embodiment, step S60 above includes: S601, collect performance metrics and resource utilization data of service components after adjusting resource configuration; S602, compare and analyze the performance index data and resource utilization data with the baseline data before adjustment to obtain the comparison and analysis results; S603, Generate a strategy analysis report based on the comparative analysis results; S604, Update the parameters of the load prediction model and the strategies in the scaling strategy set according to the strategy analysis report.

[0093] In this embodiment, performance metrics and resource utilization data of service components after resource configuration adjustments are collected and segmented into observation windows aligned with resource change events, using runtime as the time base. The left boundary of the observation window is taken as the change completion signal or the new instance readiness signal, and the right boundary is taken as the cooldown time end signal or the stability threshold satisfaction signal, ensuring that the evaluation object is the stable range after the change. Performance metrics data cover dimensions such as response time distribution, throughput, failure count, queuing time, and concurrency, while resource utilization data covers processor usage, memory usage, network throughput, and disk read / write. Both types of data are assigned unified timestamps and tags at the collection end, and after entering the aggregation end, they are deduplicated, unit normalized, and missing data filled in. To reduce the bias of instantaneous spikes on the conclusions, the original details and aggregated statistics are retained simultaneously within the window. Sliding statistics are used to generate the mean, peak value, and fluctuation range, and event context tags are recorded, including dependent topology version, release batch, business activity identifier, and region identifier, to support hierarchical comparison and multidimensional attribution.

[0094] When comparing performance metrics and resource utilization data with baseline data before adjustment, time window alignment is first performed. The baseline window is selected to be the same time period in the same business rhythm and region as the target window to ensure time series and scenario comparability. Subsequently, distribution alignment and scale alignment are performed to map the dimensions of different instances and nodes to a unified scale. The comparative analysis outputs two types of quantities: one is a performance improvement metric, such as response time quantile difference, throughput increment, and default duration reduction; the other is a resource utilization change metric, such as changes in processor and memory utilization intervals, and changes in network and storage bandwidth. To identify indirect effects caused by dependency chain propagation, call chain propagation calculation is introduced. Upstream load changes are propagated on the dependency graph according to weights, the expected changes in downstream metrics are calculated, and the deviation is compared with the actual observations to obtain propagation residuals. When the residuals are significant, collaborative scaling suggestions are triggered. The comparative analysis also outputs uncertainty characterization, including measurement noise intervals and change coverage (the coverage sequence of the proportion of new and old instances over time), which is used for evidence weight assessment in subsequent reports.

[0095] When generating a strategy analysis report based on the comparative analysis results, the report is structured into four sections: data summary, effect estimation, risk assessment, and adjustment recommendations. The data summary section provides the observation window, indicator coverage, and data quality labels. The effect estimation section provides interval-based measures of performance improvement and resource changes, as well as dependency propagation residuals. The risk assessment section provides the level of evidence and regression risk based on uncertainty and change coverage. The adjustment recommendations section maps effects and risks to actionable parameter changes, including threshold fine-tuning, adjustment magnitude correction, cooldown time correction, and supplementation or simplification of the collaboration list. The report is stored with a bidirectional index established for change batches, service component identifiers, and dependency topology versions, and an audit summary is generated for subsequent learning and backtracking.

[0096] When updating the parameters of the load forecasting model and the strategies in the scaling strategy set based on the strategy analysis report, the learning channel is divided into the model side and the strategy side. The model side takes the predicted residual time series as input and decomposes it into three types of signals: trend offset, periodic phase offset, and volatility offset. Correspondingly, it adjusts the weights, smoothing coefficients, and period parameters of the short-term and long-term channels. For components exhibiting systematic offsets, it performs small-batch online incremental training or triggers retraining, maintaining convergence within a predetermined error threshold. The strategy side takes effect estimation and risk assessment as input, calculates the strategy utility change according to target weights (performance, cost, energy efficiency), and parameterizes the triggering conditions, adjustment magnitude, cooldown time, and coordination list. When the propagation residual is persistently high, it adds downstream load linkage items to the upstream scaling strategy or increases the linkage priority. When resource utilization is consistently low and performance is stable, it lowers the scaling-down protection threshold or shortens the cooldown time. All parameter updates generate versioned records. Old versions are retained in read-only mode to support rollback. Update events are broadcast to the online decision-making and execution channels through the control channel to ensure that new parameters are actually consumed in the next scaling round.

[0097] Example Description: In a fintech business scenario, the system operates on a cloud-native application architecture with multiple business units. First, monitoring agents are deployed at the runtime nodes of each service component to continuously collect data on the operational status of core components such as credit approval, account management, payment clearing, and risk assessment. These agents record real-time CPU utilization, memory usage, network bandwidth throughput, service call latency and error rate, and simultaneously collect business metrics such as transaction count, concurrent request volume, and transaction throughput. After cleaning, normalizing, and time-aligning all raw data, a time-series dataset is generated by aggregating data according to time windows. Load pattern features such as mean, peak, and fluctuation amplitude, as well as daily and weekly cycle features, are extracted from this dataset to form a load feature vector table. This load feature vector table serves as training input, establishing a mapping relationship between load and resource changes over historical periods. The system generates a load prediction model based on time-series modeling methods and sets three optimization objectives: performance, cost, and energy efficiency. An initial scaling strategy set is output through a multi-objective optimization model. After verification and testing in a simulation environment, the model and strategies enter the runtime phase.

[0098] During operation, the system reads the latest operational data of each component from the database in real time, and the load prediction model forecasts load trends for future periods. For predicted short-term traffic peaks, such as payment peaks or billing batch processing windows, the system generates candidate scaling decisions by combining multi-objective optimization strategies from the strategy set. These decisions simultaneously consider response time constraints, budget limits, and energy efficiency weights. The candidate scaling decisions are evaluated using a service dependency graph to assess the impact of scaling on upstream risk control and downstream settlement services, selecting the globally optimal solution. The final decision is parsed into an executable instruction set at the infrastructure layer, including container instance scaling commands and resource reclamation commands. After syntax and feasibility checks, the instruction set is distributed to the compute cluster for execution by the resource manager.

[0099] Upon receiving the instruction, the infrastructure layer parses out the specific scaling task, identifies the instance specifications and quantity of the target service component, and generates corresponding resource operation commands. The resource manager allocates new computing resources within the availability zone based on the current node pool health, quotas, and affinity constraints, creates new service component instances, and completes image retrieval and configuration injection. After passing health checks, instances are automatically registered to the service discovery module. The system's load balancing strategy dynamically adjusts with the number of instances, and the traffic redirection strategy gradually allocates traffic to new instances to achieve smooth scaling. In scaling-down scenarios, the system first performs connection emptying and traffic migration, then performs instance deregistration and resource release to ensure the continuity of accounting flow processing.

[0100] After scaling up or down is completed, the system enters the evaluation phase. The scheduling center collects performance metrics and resource utilization data before and after scaling up or down, covering response latency distribution, transaction success rate, CPU and memory utilization ranges, etc. By comparing and analyzing the differences between the performance after the change and the baseline data, the system calculates the performance improvement and resource recovery ratio. If the performance improvement is insufficient or resource utilization is too low, a strategy analysis report is generated, which includes performance deviation, prediction error, and resource waste metrics. Based on the report results, the system updates the trend parameters and periodic weights of the load prediction model and adjusts the trigger thresholds, scaling up / down ranges, and cooldown times in the scaling strategy set, completing the strategy iteration.

[0101] The entire process forms a continuously converging adaptive resource optimization closed loop within the financial business system. When the workload of payment transactions or risk models experiences periodic peaks, the model can predict in advance and proactively trigger capacity expansion to ensure low latency and high throughput of transaction channels. When entering off-peak periods at night or during holidays, the strategy set automatically triggers capacity reduction, reclaiming idle resources to reduce costs. Through continuous model updates and strategy fine-tuning, the system gradually matches resource allocation to the actual business load, achieving a dynamic balance between stability and cost control. In a multi-tenant financial environment, this mechanism significantly reduces infrastructure idle rates, improves the economic efficiency of computing resource utilization, and enhances service continuity and reliability in environments where high-concurrency transactions and asynchronous batch processing coexist.

[0102] In healthcare scenarios, the system runs on a regional health data management platform to support services such as chronic disease follow-up, remote health monitoring, and intelligent rehabilitation guidance. The system first deploys data acquisition agents at each health monitoring node. These agents are embedded in wearable devices, mobile terminals, and edge health monitoring gateways to collect physiological signals and behavioral data. The collected operational data includes physiological indicators such as body temperature, heart rate, blood oxygen saturation, cadence, and sleep duration. It also acquires device resource utilization data, such as CPU usage and memory usage of the computing module, and network throughput of the communication module. The data acquisition agents also capture inter-device interaction performance indicators, including data transmission latency and error rate, to measure device link stability. The system also collects business indicator data related to health service logic, such as user activity frequency, data upload volume, and task completion rate. After timestamp alignment, missing value repair, and outlier smoothing, all data is aggregated within a time window to form a time-series dataset. From this dataset, load pattern characteristics and periodic change characteristics, such as mean, peak value, and fluctuation amplitude, are extracted to generate a load feature vector table, providing a foundation for subsequent prediction and resource optimization.

[0103] The load feature vector table is input into the training module, and the system uses data from historical time periods for model training. The model employs a joint modeling approach combining time series analysis and multi-objective optimization to seek a dynamic balance among performance, energy consumption, and cost. The performance objective corresponds to system response latency and service continuity; the energy consumption objective corresponds to edge node power consumption and device lifespan; and the cost objective corresponds to cloud resource expenditure. After training, a load prediction model is generated, and an initial scaling strategy set is generated by combining it with the multi-objective optimization model. The system verifies the model's prediction accuracy and the effectiveness of strategy execution in a simulation environment using historical data playback, resulting in a validated model and strategy.

[0104] During operation, the system continuously retrieves operational data from the real-time database for each health service component. The load prediction model forecasts service load changes over future time periods based on real-time input, such as increased data reporting during peak periods of chronic disease management or concentrated periods of user data synchronization at night. The prediction results, combined with multi-objective optimization strategies from the strategy set, generate several candidate scaling decisions. These decisions include scaling up edge node computing instances, adjusting cloud analytics task scheduling, and changing cache layer capacity. The system analyzes the impact of these decisions on the performance of upstream and downstream components based on the dependency graph of health data transmission paths, selecting the final scaling decision with the best overall performance and lowest energy consumption. The final decision is parsed into an executable instruction set at the infrastructure layer, including commands for node instance creation, resource release, and communication channel adjustment, and is executed after syntax and feasibility checks.

[0105] During the execution phase, the resource manager parses the scaling instruction set, identifies the number of edge computing nodes and cloud analytics task instances that need to be adjusted, and generates resource operation commands. The resource manager selects target nodes from the available node pool based on health and quotas, allocates new computing resources for the scaling task, and starts the instance. For scaling-down tasks, it performs data buffer transfer, session migration, and resource reclamation to ensure no monitoring data is lost. After completing health checks, new instances register with the service discovery module. The system's load balancing strategy is dynamically updated based on instance changes, enabling a smooth migration of data to the new nodes. All execution operations are monitored in real time, and key metrics such as task startup latency, instance registration success rate, and bandwidth utilization are recorded for subsequent evaluation.

[0106] After the scaling up / down task is completed, the system collects performance metrics and resource utilization data before and after the adjustment, including data processing latency, task success rate, node power consumption, and resource occupancy. By comparing and analyzing the differences before and after the change, the system calculates the performance improvement and energy consumption change, and generates a strategy analysis report. The report records model prediction bias, strategy execution effect, and potential bottlenecks. Based on the report results, the system updates the load prediction model parameters and scaling strategy set, adjusts the prediction window, energy consumption weight, and resource allocation threshold, and achieves adaptive model evolution.

[0107] In healthcare scenarios, this mechanism ensures that the data collection and analysis platform can automatically scale resources according to actual load. For example, during peak periods of regional health monitoring (such as when elderly people upload their regular health reports), the system anticipates traffic increases and proactively expands edge node capacity to ensure stable data transmission and analysis latency. During low-load periods at night or on holidays, the system automatically reclaims idle node resources to reduce energy consumption. Over long-term operation, the model continuously learns load patterns and behavioral patterns, forming differentiated scaling strategies for different user groups and device types. This process not only improves the real-time performance and accuracy of medical data processing but also reduces the operating costs of the cloud-edge integrated architecture, enabling health monitoring and remote management services to operate continuously and stably with limited resources.

[0108] This embodiment uses aligned data collection, distribution consistency comparison, and dependency propagation residual characterization with the changed stable window as the evaluation unit. The effects and risks given in the report are quantifiable and traceable. The joint update of model parameters and strategy parameters driven by this compresses prediction bias and execution lag in sync, making the trigger threshold, adjustment range, and cooldown time closer to the actual carrying capacity. The collaborative list is more in line with the call chain propagation law, which improves the hit rate and accuracy of subsequent scaling, reduces the performance default time and resource redundancy level, and forms a continuously converging self-correcting closed loop.

[0109] In one embodiment, an application architecture resource optimization apparatus is provided, which corresponds one-to-one with the application architecture resource optimization method in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the application architecture resource optimization device of the present invention. The modules include a feature extraction module 10, a model training module 20, a real-time acquisition module 30, a decision generation module 40, a resource scheduling module 50, and a policy update module 60. Detailed descriptions of each functional module are as follows: The feature extraction module 10 is used to collect the running data of each service component in the application architecture, and extract load features based on the running data to generate a load feature vector table. Model training module 20 is used to train and generate a load prediction model based on the load feature vector table and initialize the scaling strategy set; Real-time acquisition module 30 is used to acquire real-time service component operation data; The decision generation module 40 is used to generate a scaling decision based on the real-time service component operation data and the scaling strategy set through the load prediction model, and generate a scaling instruction set according to the scaling decision; Resource scheduling module 50 is used to schedule the infrastructure layer to execute the scaling instruction set in order to adjust the resource configuration of service components; The strategy update module 60 is used to analyze the performance indicators and resource utilization of service components after adjusting resource configuration, generate a strategy analysis report, and update the load prediction model and the scaling strategy set according to the strategy analysis report.

[0110] In one embodiment, the feature extraction module 10 is specifically used for: Deploy monitoring agents to various service components in the application architecture; The monitoring agent collects resource utilization data of the service components. The monitoring agent collects performance data on the call chain between service components. Collect business metrics data related to business logic; The resource utilization data, call chain performance data, and business indicator data are cleaned and preprocessed to obtain preprocessed data. The preprocessed data is then subjected to time window aggregation to generate a time series dataset; Extract load pattern features and periodic features from the time series dataset; Based on the load pattern characteristics and periodic characteristics, a load feature vector table containing multi-dimensional feature vectors is generated.

[0111] In one embodiment, the model training module 20 is specifically used for: Obtain the load feature vector table for historical time periods as the training dataset; The training dataset is divided into a training set and a validation set; Using the training set, a load prediction model is trained and generated through time series analysis methods. Define the performance, cost, and energy efficiency objectives for resource optimization; Based on the aforementioned performance, cost, and energy efficiency objectives, a multi-objective optimization model is constructed. The multi-objective optimization model generates an initial scaling strategy, forming a scaling strategy set. The load prediction model is validated using the validation set to obtain the model validation results; In a simulation environment, the training dataset is used to simulate the running environment to test the effectiveness of the scaling strategy set and obtain the strategy test results; Based on the model validation results and the strategy test results, the parameters of the load prediction model and the strategy parameters of the scaling strategy set are optimized. The storage-optimized load prediction model and scaling strategy set are used to complete the initialization process.

[0112] In one embodiment, the decision generation module 40 is specifically used for: Read real-time service component runtime data from the real-time database; The real-time service component operation data is input into the load prediction model to generate load trend data for future time periods; Based on the load trend data and the multi-objective optimization strategies in the scaling strategy set, one or more candidate scaling decisions are generated. Based on the dependency graph between service components, the performance impact of the candidate scaling decision on the associated service components is analyzed, and the performance impact analysis results are obtained. Based on the performance impact analysis results, the decision that is optimal for overall performance is selected from the candidate scaling decisions as the final scaling decision; The final scaling decision is then translated into a set of scaling instructions that can be executed at the infrastructure layer.

[0113] In one embodiment, the decision generation module 40 is specifically used for: The final scaling decision is analyzed to identify the service component instance scaling up or scaling down operations that need to be performed. Based on the scaling up or scaling down operation of the service component instance, determine the corresponding infrastructure layer resource operation specifications; Based on the aforementioned infrastructure layer resource operation specifications, a sequence of resource operation commands is generated. The resource operation command sequence is formatted into a standardized instruction format acceptable to the infrastructure layer application interface; Verify the syntactic correctness and execution feasibility of the standardized instruction format; The set of standardized instruction formats that have passed verification will be used as the scaling instruction set.

[0114] In one embodiment, the resource scheduling module 50 is specifically used for: Parse the scaling instruction set to identify the specifications and quantity of service component instances that need to be added or reduced; Based on the service component instance specifications and quantity, generate resource operation instructions; Send the resource operation instructions to the resource manager in the infrastructure layer; The resource manager executes the resource operation instructions to allocate processing resources to create new service component instances or release the processing resources occupied by idle service component instances. Monitor the resource allocation process and register the new service component instance with the service discovery component after the new service component instance is created. Update the load balancing strategy based on changes in the number of service component instances.

[0115] In one embodiment, the policy update module 60 is specifically used for: Collect performance metrics and resource utilization data of service components after adjusting resource configuration; The performance index data and resource utilization rate data are compared and analyzed with the baseline data before adjustment to obtain the comparison and analysis results; A strategy analysis report is generated based on the comparative analysis results. Based on the strategy analysis report, update the parameters of the load prediction model and the strategies in the scaling strategy set.

[0116] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides deterministic and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of an application architecture resource optimization method on the server side.

[0117] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements client-side functions or steps of an application architecture resource optimization method.

[0118] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Collect the running data of each service component in the application architecture, and extract load features based on the running data to generate a load feature vector table; A load prediction model is trained and generated based on the load feature vector table, and a scaling strategy set is initialized. Obtain real-time service component runtime data; Based on the real-time service component operation data and the scaling strategy set, the load prediction model generates scaling decisions and generates a scaling instruction set according to the scaling decisions. The scheduling infrastructure layer executes the scaling instruction set to adjust the resource configuration of service components; After analyzing and adjusting the resource configuration, the performance indicators and resource utilization of the service components are analyzed, a strategy analysis report is generated, and the load prediction model and the scaling strategy set are updated based on the strategy analysis report.

[0119] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Collect the running data of each service component in the application architecture, and extract load features based on the running data to generate a load feature vector table; A load prediction model is trained and generated based on the load feature vector table, and a scaling strategy set is initialized. Obtain real-time service component runtime data; Based on the real-time service component operation data and the scaling strategy set, the load prediction model generates scaling decisions and generates a scaling instruction set according to the scaling decisions. The scheduling infrastructure layer executes the scaling instruction set to adjust the resource configuration of service components; After analyzing and adjusting the resource configuration, the performance indicators and resource utilization of the service components are analyzed, a strategy analysis report is generated, and the load prediction model and the scaling strategy set are updated based on the strategy analysis report.

[0120] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0121] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0122] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0123] It should be noted that if any software tools or components not belonging to this company appear in the embodiments of this application, they are merely illustrative examples and do not represent actual use. The embodiments described above are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for optimizing application architecture resources, characterized in that, Includes the following steps: Collect the running data of each service component in the application architecture, and extract load features based on the running data to generate a load feature vector table; A load prediction model is trained and generated based on the load feature vector table, and a scaling strategy set is initialized. Obtain real-time service component runtime data; Based on the real-time service component operation data and the scaling strategy set, the load prediction model generates scaling decisions and generates a scaling instruction set according to the scaling decisions. The scheduling infrastructure layer executes the scaling instruction set to adjust the resource configuration of service components; After analyzing and adjusting the resource configuration, the performance indicators and resource utilization of the service components are analyzed, a strategy analysis report is generated, and the load prediction model and the scaling strategy set are updated based on the strategy analysis report.

2. The application architecture resource optimization method as described in claim 1, characterized in that, Collect operational data from each service component in the application architecture, and extract load features based on the operational data to generate a load feature vector table, including: Deploy monitoring agents to various service components in the application architecture; The monitoring agent collects resource utilization data of the service components. The monitoring agent collects performance data on the call chain between service components. Collect business metrics data related to business logic; The resource utilization data, call chain performance data, and business indicator data are cleaned and preprocessed to obtain preprocessed data. The preprocessed data is then subjected to time window aggregation to generate a time series dataset; Extract load pattern features and periodic features from the time series dataset; Based on the load pattern characteristics and periodic characteristics, a load feature vector table containing multi-dimensional feature vectors is generated.

3. The application architecture resource optimization method as described in claim 1, characterized in that, Based on the load feature vector table, a load prediction model is trained and generated, and a scaling strategy set is initialized, including: Obtain the load feature vector table for historical time periods as the training dataset; The training dataset is divided into a training set and a validation set; Using the training set, a load prediction model is trained and generated through time series analysis methods. Define the performance, cost, and energy efficiency objectives for resource optimization; Based on the aforementioned performance, cost, and energy efficiency objectives, a multi-objective optimization model is constructed. The multi-objective optimization model generates an initial scaling strategy, forming a scaling strategy set. The load prediction model is validated using the validation set to obtain the model validation results; In a simulation environment, the training dataset is used to simulate the running environment to test the effectiveness of the scaling strategy set and obtain the strategy test results; Based on the model validation results and the strategy test results, the parameters of the load prediction model and the strategy parameters of the scaling strategy set are optimized. The storage-optimized load prediction model and scaling strategy set are used to complete the initialization process.

4. The application architecture resource optimization method as described in claim 1, characterized in that, Based on the real-time service component operation data and the scaling policy set, the load prediction model generates scaling decisions and, according to the scaling decisions, generates a scaling instruction set, including: Read real-time service component runtime data from the real-time database; The real-time service component operation data is input into the load prediction model to generate load trend data for future time periods; Based on the load trend data and the multi-objective optimization strategies in the scaling strategy set, one or more candidate scaling decisions are generated. Based on the dependency graph between service components, the performance impact of the candidate scaling decision on the associated service components is analyzed, and the performance impact analysis results are obtained. Based on the performance impact analysis results, the decision that is optimal for overall performance is selected from the candidate scaling decisions as the final scaling decision; The final scaling decision is then translated into a set of scaling instructions that can be executed at the infrastructure layer.

5. The application architecture resource optimization method as described in claim 4, characterized in that, The final scaling decision is translated into a set of scaling instructions executable at the infrastructure layer, including: The final scaling decision is analyzed to identify the service component instance scaling up or scaling down operations that need to be performed. Based on the scaling up or scaling down operation of the service component instance, determine the corresponding infrastructure layer resource operation specifications; Based on the aforementioned infrastructure layer resource operation specifications, a sequence of resource operation commands is generated. The resource operation command sequence is formatted into a standardized instruction format acceptable to the infrastructure layer application interface; Verify the syntactic correctness and execution feasibility of the standardized instruction format; The set of standardized instruction formats that have passed verification will be used as the scaling instruction set.

6. The application architecture resource optimization method as described in claim 1, characterized in that, The scheduling infrastructure layer executes the scaling instruction set to adjust the resource configuration of service components, including: Parse the scaling instruction set to identify the specifications and quantity of service component instances that need to be added or reduced; Based on the service component instance specifications and quantity, generate resource operation instructions; Send the resource operation instructions to the resource manager in the infrastructure layer; The resource manager executes the resource operation instructions to allocate processing resources to create new service component instances or release the processing resources occupied by idle service component instances. Monitor the resource allocation process and register the new service component instance with the service discovery component after the new service component instance is created. Update the load balancing strategy based on changes in the number of service component instances.

7. The application architecture resource optimization method as described in claim 1, characterized in that, Analyze the performance metrics and resource utilization of service components after adjusting resource configuration, generate a strategy analysis report, and update the load prediction model and scaling strategy set based on the strategy analysis report, including: Collect performance metrics and resource utilization data of service components after adjusting resource configuration; The performance index data and resource utilization rate data are compared and analyzed with the baseline data before adjustment to obtain the comparison and analysis results; A strategy analysis report is generated based on the comparative analysis results. Based on the strategy analysis report, update the parameters of the load prediction model and the strategies in the scaling strategy set.

8. An application architecture resource optimization device, characterized in that, The application architecture resource optimization device includes: The feature extraction module is used to collect the running data of each service component in the application architecture, and extract load features based on the running data to generate a load feature vector table. The model training module is used to train and generate a load prediction model based on the load feature vector table and initialize the scaling strategy set; The real-time acquisition module is used to acquire real-time service component operation data; The decision generation module is used to generate a scaling decision based on the real-time service component operation data and the scaling strategy set through the load prediction model, and to generate a scaling instruction set based on the scaling decision; The resource scheduling module is used to schedule the infrastructure layer to execute the scaling instruction set in order to adjust the resource configuration of service components; The strategy update module is used to analyze the performance indicators and resource utilization of service components after adjusting resource configuration, generate a strategy analysis report, and update the load prediction model and the scaling strategy set according to the strategy analysis report.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and an application architecture resource optimization program stored in the memory and executable on the processor. When the application architecture resource optimization program is executed by the processor, it implements the steps of the application architecture resource optimization method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores an application architecture resource optimization program, which, when executed by a processor, implements the steps of the application architecture resource optimization method as described in any one of claims 1-7.

Images