Low-code application performance bottleneck prediction and resource dynamic allocation method and device

Abstract

The application provides a low-code application performance bottleneck prediction and resource dynamic allocation method and device. The method comprises: obtaining model component metadata of a low-code application to be managed, and generating component identifiers associated with application versions for each model component; aligning multi-source data based on time markers to generate a multi-layer dependency graph with component identifiers as node attributes; performing graph representation learning and time series prediction processing on the multi-layer dependency graph to output a bottleneck profile; encapsulating the bottleneck profile, mapping relationship and resource constraint parameters into a decision state, inputting the decision state into a constrained reinforcement learning strategy to output a resource action combination; performing constraint verification and gray application on the resource action combination, and collecting the multi-source data after the application in a monitoring window to calculate the reward, updating the reinforcement learning strategy based on the reward and recording the action samples associated with the component identifiers. The application can improve the accuracy of bottleneck prediction, improve the stability of resource allocation, reduce cascading jitter and operation and maintenance cost.

Description

Technical Field

[0001] This application relates to the field of low-code development platform technology, and in particular to a method and apparatus for predicting performance bottlenecks and dynamically allocating resources in low-code applications. Background Technology

[0002] Low-code development platforms enable rapid construction of business applications through visual modeling. They typically run in cloud-native environments using containers, microservices, and service-oriented interfaces, relying on observable methods such as distributed tracing, resource monitoring, and log alerts for operation and maintenance management. Current performance governance methods often employ threshold- or rule-based automatic scaling and alert handling, or anomaly detection and capacity prediction based on single metrics. After performance fluctuations occur, operations personnel combine distributed tracing data and resource curves to locate bottlenecks and adjust parameters.

[0003] Because low-code applications are generated by combining model components such as pages, processes, rules, data entities, and connectors, and have frequent version iterations and complex dependency chains, existing observable data is usually at the service, interface, or function level, making it difficult to establish a traceable correspondence with model components. This makes it difficult to accumulate and reuse bottleneck attribution and optimization suggestions. At the same time, rule-based scaling is difficult to cover diverse loads and external dependency fluctuations, which can easily lead to cascading scaling, parameter jitter, and cost runaway. On the other hand, learning-based scaling solutions are mostly focused on resource layer optimization and lack unified modeling of low-code semantics, dependency propagation risks, and constraint boundaries, making it difficult to achieve stable dynamic resource allocation while meeting quota, change window, and rollback requirements. Summary of the Invention

[0004] In view of this, embodiments of this application provide a method and apparatus for predicting performance bottlenecks and dynamically allocating resources in low-code applications, in order to solve the problems of difficulty in tracing component-level bottlenecks, difficulty in driving decision-making through bottleneck prediction, and easy cascading jitter in dependent link expansion and contraction in the prior art.

[0005] A first aspect of this application provides a method for predicting performance bottlenecks and dynamically allocating resources in low-code applications, comprising: acquiring metadata of model components of the low-code application to be addressed, generating component identifiers associated with the application version for each model component, and constructing a mapping relationship between component identifiers and runtime interfaces or service units; during the runtime of the low-code application, collecting link tracing data, resource indicator data, and runtime event data carrying component identifiers from the request processing link, aligning the multi-source data based on time stamps, and generating a multi-layer dependency graph with component identifiers as node attributes; performing graph representation learning and time series prediction processing on the multi-layer dependency graph, and outputting... Bottleneck profiling is performed, which includes bottleneck type distribution, bottleneck location distribution, dependency propagation risk, and uncertainty parameters associated with component identifiers. The bottleneck profiling, mapping relationship, and resource constraint parameters are encapsulated into a decision state, which is input into a constrained reinforcement learning policy to output a resource action combination. The resource action combination is associated with the component identifier, where the resource action combination includes at least one of scaling actions and configuration parameter tuning actions. Constraint verification and grayscale application are performed on the resource action combination, and multi-source data after application is collected in the monitoring window to calculate the reward. The reinforcement learning policy is updated based on the reward, and action samples associated with the component identifier are recorded.

[0006] A second aspect of this application provides a low-code application performance bottleneck prediction and dynamic resource allocation apparatus, comprising: an acquisition module, configured to acquire metadata of model components of the low-code application to be addressed, generate component identifiers associated with the application version for each model component, and construct a mapping relationship between component identifiers and runtime interfaces or service units; an alignment module, configured to collect link tracing data carrying component identifiers, resource indicator data, and runtime event data from the request processing link during low-code application runtime, and align the multi-source data based on time stamps to generate a multi-layer dependency graph with component identifiers as node attributes; and a prediction module, configured to perform graph representation learning and time-series prediction processing on the multi-layer dependency graph. The system outputs a bottleneck profile, which includes bottleneck type distribution, bottleneck location distribution, dependency propagation risk, and uncertainty parameters associated with component identifiers. An encapsulation module encapsulates the bottleneck profile, mapping relationships, and resource constraint parameters into a decision state, inputs a constrained reinforcement learning policy, and outputs a resource action combination. This resource action combination is associated with component identifiers, and includes at least one of scaling actions and configuration / parameter tuning actions. A reward module performs constraint verification and grayscale application on the resource action combination, collects multi-source data after application within a monitoring window to calculate rewards, updates the reinforcement learning policy based on the rewards, and records action samples associated with component identifiers.

[0007] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0008] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: By acquiring the metadata of model components of the low-code application to be governed, and generating component identifiers associated with the application version for each model component, a mapping relationship is constructed between component identifiers and runtime interfaces or service units. During the low-code application runtime, link tracing data, resource indicator data, and runtime event data carrying component identifiers are collected from the request processing link, and the multi-source data is aligned based on time stamps to generate a multi-layer dependency graph with component identifiers as node attributes. Graph representation learning and time series prediction processing are performed on the multi-layer dependency graph to output a bottleneck profile, which includes bottleneck type distribution, bottleneck location distribution, dependency propagation risk, and uncertainty parameters associated with component identifiers. The bottleneck profile, mapping relationship, and resource constraint parameters are encapsulated into a decision state, input into a constrained reinforcement learning policy, and output a resource action combination. The resource action combination is associated with the component identifier, where the resource action combination includes at least one of scaling actions and configuration parameter tuning actions. Constraint verification and grayscale application are performed on the resource action combination, and multi-source data after application is collected in the monitoring window to calculate rewards. The reinforcement learning policy is updated based on the rewards, and action samples associated with component identifiers are recorded. This application can improve the accuracy of bottleneck prediction, enhance the stability of resource allocation, and reduce cascading jitter and operation and maintenance costs. Attached Figure Description

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

[0010] Figure 1 This is a flowchart illustrating the low-code application performance bottleneck prediction and dynamic resource allocation method provided in the embodiments of this application; Figure 2 This is a schematic diagram of the low-code application performance bottleneck prediction and dynamic resource allocation device provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0011] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0012] In terms of current technologies, low-code applications are typically deployed in cloud-native environments. Operations and maintenance (O&M) rely heavily on observable methods such as distributed tracing, resource monitoring, and log alerts for performance governance, employing threshold- or rule-driven autoscaling and parameter tuning, or anomaly detection and capacity prediction based on single metrics. When performance fluctuations occur, manual intervention is often required to locate bottlenecks and make governance decisions based on data at the service, interface, or function level. Furthermore, governance experience is difficult to reliably map and reuse with low-code model components.

[0013] Therefore, since low-code applications are generated by combining model components such as pages, processes, rules, data entities, and connectors, and have frequent version iterations and complex dependency chains, it is difficult to establish a traceable correspondence between existing observable data and model components, making it difficult to attribute bottlenecks at the component level. At the same time, single-indicator predictions or alarms are difficult to form bottleneck profiles that can be directly used for resource action generation, making it difficult to support stable automated governance. Rule-based scaling is prone to triggering cascading scaling and parameter jitter when there is a propagation effect in the dependency chain, which in turn brings cost and stability risks.

[0014] To address the aforementioned technical issues, this application provides a method for predicting performance bottlenecks and dynamically allocating resources in low-code applications. This method acquires metadata of the model components of the low-code application, generates component identifiers associated with the application version for each component, and constructs a mapping relationship between component identifiers and runtime interfaces or service units. During runtime, it collects link tracing data, resource metric data, and runtime event data carrying component identifiers, and forms a multi-layer dependency graph with component identifiers as node attributes based on time stamp alignment. It performs graph representation learning and time-series prediction processing on the multi-layer dependency graph, outputting a bottleneck profile including bottleneck type distribution, bottleneck location distribution, dependency propagation risk, and uncertainty parameters. It encapsulates the bottleneck profile, mapping relationship, and resource constraint parameters into a constrained reinforcement learning policy for decision state input, outputting a combination of resource actions associated with the component identifier. It then performs constraint verification and grayscale application on the resource action combination, calculates rewards within a monitoring window to update the policy, and records action samples, forming an iterative closed-loop governance mechanism.

[0015] Through the above technical solutions, this application can achieve traceable attribution of performance symptoms at the component level, improving the accuracy and interpretability of bottleneck prediction; generate more stable resource action combinations under the conditions of dependency propagation risk and resource constraints, reducing cascading expansion and contraction and parameter jitter; and achieve continuous optimization of strategies through gray-scale application and reward update, thereby improving the stability of resource allocation and reducing operation and maintenance costs.

[0016] The technical solution of this application will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0017] Figure 1 This is a flowchart illustrating the low-code application performance bottleneck prediction and dynamic resource allocation method provided in this application embodiment. Figure 1 As shown, the method may specifically include: S101: Obtain the metadata of the model components of the low-code application to be governed, generate a component identifier associated with the application version for each model component, and build a mapping relationship between the component identifier and the runtime interface or service unit. S102, during the low-code application runtime, collect link tracing data, resource indicator data and runtime event data carrying component identifiers from the request processing link, and align the multi-source data based on time stamps to generate a multi-layer dependency graph with component identifiers as node attributes. S103, perform graph representation learning and time series prediction processing on the multi-layer dependency graph, and output a bottleneck profile, which includes the bottleneck type distribution, bottleneck location distribution, dependency propagation risk and uncertainty parameters associated with component identifiers. S104, encapsulate the bottleneck profile, mapping relationship and resource constraint parameters into a decision state, input a constrained reinforcement learning policy to output a resource action combination, associate the resource action combination with the component identifier, wherein the resource action combination includes at least one of scaling up and down actions and configuration parameter tuning actions; S105 performs constraint verification and grayscale application on the resource action combination, collects multi-source data after application within the monitoring window to calculate the reward, updates the reinforcement learning strategy based on the reward, and records the action samples associated with the component identifier.

[0018] In some embodiments, the metadata of the model components of the low-code application to be governed is obtained, and a component identifier associated with the application version is generated for each model component. A mapping relationship is constructed between the component identifier and the runtime interface or service unit, including: Read the model definition data corresponding to the low-code application to be governed. The model definition data includes one or more descriptive information of pages, processes, data entities, rules and connectors. Based on the model definition data, extract the component type, component level and calling relationship of each model component, and generate component identifiers associated with the application version; Based on the call relationship and runtime deployment information, determine the runtime entry identifier or interface identifier corresponding to each component identifier, and generate a mapping relationship between component identifiers and runtime interfaces or service units; The mapping relationships are stored in a versioned manner, and the mapping relationship corresponding to the current application version is updated when changes are detected in the model definition data or runtime deployment information.

[0019] Specifically, model definition data refers to the structured descriptive data generated when a low-code platform models a low-code application. It is used to characterize the type, parameters, relationships, and dependencies of model components. Model definition data can originate from the model repository or metadata files in the release artifacts of the low-code platform, and its content includes at least one or more of the following: page description information, process description information, data entity description information, rule description information, and connector description information.

[0020] Page description information is used to represent page identifiers, page layout structure, page component tree, and page event binding relationships; process description information is used to represent process identifiers, node types, node jump relationships, and process input and output parameters; data entity description information is used to represent entity identifiers, field sets, field types, and relationships between entities; rule description information is used to represent rule identifiers, triggering conditions, execution actions, and dependent data sources; connector description information is used to represent external system types, endpoint identifiers, authentication methods, request templates, and retry strategies, etc.

[0021] A component identifier is a globally unique identifier generated for each model component in a low-code application. This identifier is associated with the application version and is used to establish a stable reference relationship between the model layer and the runtime layer. A component hierarchy refers to the organizational hierarchy of model components within the low-code application, describing component dependency and composition relationships. For example, a page contains page components, a process contains multiple process nodes, and rules are bound to page events or process nodes. Call relationships refer to the triggering and dependency relationships that may occur between components at runtime, describing which component calls or triggers which component. Examples include page events triggering rules, rule call connectors, and process nodes reading and writing data entities.

[0022] Runtime interfaces or service units refer to the access points and internal carrying units provided by a low-code application after deployment. Runtime interfaces represent interface endpoints that can be requested, while service units represent the deployment units that carry related interfaces and logic, such as container instances, service processes, or microservice modules. Runtime entry identifiers or interface identifiers are identification information used to uniquely identify the runtime entry point or interface endpoint, and can be formed by combining routing paths, interface names, method signatures, gateway routing keys, etc.

[0023] In some examples, reading the model definition data corresponding to the low-code application to be governed includes: before the low-code application enters the governance process, retrieving the release version number of the target application from the model repository, and locating the corresponding model definition data set based on the release version number. The model definition data set can be grouped and stored according to model component types, such as storing page sets, process sets, data entity sets, rule sets, and connector sets separately; it can also be sharded and stored according to business modules to support module-by-module loading and incremental parsing. During the reading process, the update timestamp, release sequence number, or verification digest of the model component can also be obtained simultaneously to determine whether the model has changed later.

[0024] In some examples, extracting component types, component hierarchies, and calling relationships based on model definition data, and generating component identifiers associated with the application version, includes: parsing the model definition data to obtain the component types and attributes of each model component, and constructing component hierarchical relationships. Specifically, a page can be considered a first-level component, with page components and event handling units as lower-level components; a process can be considered a first-level component, with process nodes, branch conditions, and service tasks as lower-level components; a data entity can be considered a first-level component, with fields, indexes, and entity associations as lower-level components; a rule can be considered a first-level component, with rule condition items, action items, and dependency sources as lower-level components; and a connector can be considered a first-level component, with endpoints, request templates, and authentication configurations as lower-level components.

[0025] When constructing call relationships, the triggering relationship from page to rule can be extracted from page event binding relationships, the call relationship from rule action items to connectors can be extracted from rule action items, the call relationship from process node configuration to rule or connector can be extracted from process node configuration, and the read / write relationship from rule or process to data entity can be extracted from data access configuration. Based on the above component types, component levels, and call relationships, this embodiment generates a component identifier for each model component. The component identifier can be generated by combining the application identifier, application version, component type code, component path, and component summary. The component path is used to characterize the component's position in the hierarchical structure, and the component summary is used to perform summary calculations on the component's key attributes to reduce the risk of identifier conflicts. By incorporating the application version into the component identifier generation element, components with the same name but different content in different versions can have different component identifiers.

[0026] The following example illustrates this. A low-code application under governance, version V2026.01, includes page P1, process F1, rule R1, and connector C1. The commit event of page P1 triggers rule R1, which in turn calls connector C1 to access an external interface and write data to data entity E1. In this embodiment, page P1, process F1, rule R1, connector C1, and data entity E1 each generate a component identifier associated with version V2026.01. The call relationship records the relationships of P1 triggering R1, R1 calling C1, and R1 writing to E1, ensuring that any subsequent runtime observations related to this link can be attributed to the corresponding component through the component identifier.

[0027] In some examples, determining the runtime entry identifier or interface identifier corresponding to the component identifier based on the call relationship and runtime deployment information, and generating the mapping relationship between the component identifier and the runtime interface or service unit, includes: obtaining the runtime deployment information of the low-code application. The runtime deployment information is used to characterize the carrying location and exposed interface of the model component at runtime after compilation, interpretation, or generation. The runtime deployment information may include routing configuration, gateway forwarding rules, service discovery registration information, container orchestration description information, and assembly records of components to code snippets or modules. Based on the runtime deployment information, this embodiment first determines the identifier set of each runtime interface or service unit and establishes its correspondence with the routing path, interface name, or gateway routing key; then, combined with the call relationship, it maps the entry position, call position, and carrying position of the model component on the link to the runtime interface or service unit.

[0028] For example, when the user access entry corresponding to page P1 is deployed as the gateway path / portal / p1 and forwarded to service unit S1, a mapping is established between component identifier P1 and runtime entry identifier / portal / p1 and service unit identifier S1; when rule R1 is deployed as a rule executor module in service unit S2 at runtime and exposed through the internal interface invokeRule, a mapping is established between component identifier R1 and interface identifier invokeRule and service unit identifier S2; when connector C1 is carried by connector proxy module and initiates a request through external call interface callConnector, a mapping is established between component identifier C1 and interface identifier callConnector and service unit identifier carrying the proxy module. Through the above methods, a queryable mapping relationship is formed between component identifiers and runtime interfaces or service units, supporting quick back-pointing to model components when interface identifiers or service unit identifiers appear in runtime observation data.

[0029] In some examples, versioned storage of mapping relationships and updating the mapping relationship corresponding to the current application version when changes in model definition data or runtime deployment information are detected include: writing the mapping relationship as a versioned mapping entry to the mapping repository. Each mapping entry includes at least the application identifier, application version, component identifier, runtime entry identifier or interface identifier, service unit identifier, and mapping generation time window marker. Versioned storage can employ a multi-version coexistence strategy, where different versions of the same application's mapping relationships can be retained in parallel and retrieved by application version; or a version chain strategy can be used, generating a new version entry for each release and recording references to previous versions to support rollback and difference comparison.

[0030] Change detection can be implemented based on the verification digest or update timestamp of the model definition data, or based on the release sequence number, image digest, or route configuration digest in the runtime deployment information. When a change in the model definition data is detected, this embodiment re-parses the model components and regenerates the component identifier or updates the component hierarchy and calling relationship; when a change in the runtime deployment information is detected, this embodiment re-parses the routing and service discovery information and updates the mapping relationship between the component identifier and the runtime interface or service unit; when both types of changes exist simultaneously, a new set of mapping relationships is generated with the application version as the boundary, and the old version mapping relationship is marked as a historical version for traceability.

[0031] Through the above embodiments, this application introduces component identifiers associated with application versions at the model layer and establishes a mapping relationship between component identifiers and runtime interfaces or service units. Subsequently, based on this mapping relationship, runtime-collected link tracing data, resource indicator data, and runtime event data can be stably attributed to model components. The mapping relationship remains updatable and traceable during model iteration and deployment changes, thereby providing a consistent data and identifier foundation for subsequent generation of multi-layer dependency graphs, output bottleneck profiles, and output resource action combinations based on constrained reinforcement learning.

[0032] In some embodiments, during the runtime of a low-code application, link tracing data carrying component identifiers, resource metric data, and runtime event data are collected from the request processing link, including: When a request enters the runtime entry point of a low-code application, a link context identifier is generated for the request, and the link context identifier is bound to the component identifier and written into the link propagation context. As the request propagates along the request processing link, link tracing data associated with the identifiers of each component is collected based on the link propagation context. Based on the link context identifier, resource indicator data is collected within the sampling window associated with the request. The resource indicator data includes one or more of the following: processing unit usage, storage usage, input / output waiting time, and queue depth. When a runtime event associated with the request processing link is detected, the link context identifier and component identifier are written to the runtime event; Link tracing data, resource indicator data, and runtime event data are aggregated according to link context identifiers and output as multi-source observation data carrying component identifiers.

[0033] Specifically, the link context identifier refers to the identification information used to uniquely identify the process of a request propagating across entry points, interfaces, and service units within a low-code application. It is used to associate link tracing data, resource metric data, and runtime event data with the same request context.

[0034] Link propagation context refers to the set of context fields that propagate along with the request in the request processing link. It is used to carry at least the link context identifier and the component identifier, so that each processing node in the link can perform collection and writing based on the same context.

[0035] The sampling window refers to the statistical interval set around the processing time period of the request corresponding to the link context identifier. It is used to sample and aggregate resource indicators such as processing unit usage, storage usage, input / output waiting time, and queue depth.

[0036] Multi-source observation data refers to a data set aggregated by link context identifier, which includes at least link tracing information associated with component identifier, resource indicator statistics, and runtime event records, and is used as input for subsequent time alignment and dependency graph construction.

[0037] In some examples, when a request enters the runtime entry point of a low-code application, a link context identifier is generated for the request, and the link context identifier is bound to the component identifier and written into the link propagation context. This includes: when a user accesses a page or interface of a low-code application through a unified entry point, the runtime entry point parses the entry route, interface identifier, or gateway route key, and determines the component identifier corresponding to the entry point based on the mapping relationship established in the previous embodiment.

[0038] Subsequently, the runtime entry point generates a link context identifier for this request and writes the link context identifier and component identifier into the link propagation context. This ensures that the request carries the same link context identifier and component identifier when entering subsequent page rendering, process orchestration, rule execution, or connector invocation. To reduce the risk of conflicts during cross-service unit propagation, the link context identifier can be generated by combining the application version, entry identifier, and request arrival time slice, or it can be allocated by the runtime entry point within a preset identifier space. The validity period and verification information of the link context identifier are also written into the link propagation context to facilitate deduplication in abnormal propagation or retry scenarios.

[0039] In some examples, as a request propagates along the request processing chain, tracing data associated with each component identifier is collected based on the propagation context. This includes: the low-code runtime triggering tracing data collection at key boundary points in the request processing chain. These key boundary points include at least one or more of the following: page event trigger points, process node switching points, rule engine execution points, data entity read / write points, and connector call points. At each boundary point, the tracing context identifier and component identifier in the propagation context are read during collection, and tracing data associated with the component identifier is generated.

[0040] Link tracing data includes one or more of the following: span timestamp, parent-child span relationship, and interface identifier. The span timestamp characterizes the start and end times of processing at the boundary point; the parent-child span relationship characterizes the call order and nesting relationship between boundary points; and the interface identifier characterizes the runtime interface or internal call interface that triggered the boundary point. For cross-service unit calls, the caller passes the link propagation context to the callee, enabling the callee to continue collecting and forming a consistent parent-child span relationship at its boundary points. This allows subsequent reconstructing of the complete request processing link based on the link context identifier.

[0041] The following example scenario illustrates this. A user accesses page P1 and triggers a submit event. The component identifier corresponding to page P1 is written into the link propagation context. The submit event triggers rule R1 and calls connector C1 to access the external system. The rule execution point and the connector call point collect their respective span timestamps and parent-child span relationships, and carry the corresponding component identifier in the link tracing data. This allows for subsequent differentiation of whether the bottleneck occurs in the page event processing, rule execution, or connector call phase.

[0042] In some examples, resource metrics data are collected within a sampling window associated with a request, based on the link context identifier. This includes: after generating the link context identifier, the runtime entry point initiates a sampling window associated with that link context identifier, and samples resource metrics for the runtime interface or service unit handling the request within the sampling window. Resource metrics data include one or more of the following: processing unit usage, storage usage, input / output wait time, and queue depth. Processing unit usage characterizes the processing unit load or usage of the service unit within the sampling window; storage usage characterizes memory usage or memory pressure levels; input / output wait time characterizes the waiting time statistics for disk or network input / output; and queue depth characterizes the backlog of thread pool queues, task queues, or message queues. During collection, resource metrics data are associated with the link context identifier, and attribution tags for resource sampling can be further recorded according to the component identifier dimension. For example, the resource sampling record of a service unit can be labeled as "rule execution segment triggered by component identifier R1" or "external call segment triggered by component identifier C1" for subsequent dependency graph node attribute writing.

[0043] In some examples, when a runtime event associated with a request processing chain is detected, a chain context identifier and a component identifier are written to the runtime event. This includes: a runtime event record that characterizes an event affecting performance and stability in the request processing chain, including but not limited to one or more of timeouts, retries, rate limiting, circuit breaking, and external dependency exceptions. When the runtime detects the aforementioned runtime event, the event processing unit reads the chain context identifier and component identifier from the chain propagation context and writes them to the runtime event record, ensuring that the runtime event can be accurately attributed to the model component that triggered the event and the corresponding request chain.

[0044] For example, when connector C1 times out and triggers a retry when calling an external interface, the runtime event log writes the link context identifier and component identifier C1, along with the number of retries, the retry interval, and the exception type. When rule R1 triggers a rate limiting policy, the runtime event log writes the link context identifier and component identifier R1, along with the rate limiting threshold flag and the count of rejected requests. By binding runtime events with link context identifiers and component identifiers, bottleneck type distribution and dependency propagation risks can be identified in subsequent bottleneck profiling.

[0045] In some examples, link tracing data, resource metric data, and runtime event data are aggregated by link context identifier and output as multi-source observation data carrying component identifiers. This includes: when the sampling window ends or request processing is completed, the aggregation unit aggregates link tracing data, resource metric data, and runtime event data using the link context identifier as the key to generate multi-source observation data corresponding to that link context identifier. The multi-source observation data includes at least a set of link tracing segments associated with the component identifier, a set of resource metric statistics, and a set of runtime events, and can further include the application version, entry identifier, and sampling window boundary to support subsequent time-stamp-based alignment processing.

[0046] To reduce duplication and noise caused by multi-source acquisition, deduplication and consistency checks can be performed on multi-source observation data before output. For example, duplicate span records with the same component identifier can be merged according to the parent-child span relationship, the same running event can be merged according to the link context identifier in the retry scenario, and resource index data can be summarized and statistically analyzed according to the sampling window.

[0047] Through the above embodiments, this application introduces link context identifiers and link propagation contexts during low-code application runtime, enabling the continuous propagation of component identifiers in the request processing link. Link tracing data associated with component identifiers is collected at link boundary points, and resource indicator data associated with link context identifiers is collected within the sampling window. Simultaneously, triggered runtime events are written to link context identifiers and component identifiers. Finally, multi-source observation data carrying component identifiers is aggregated according to link context identifiers, thereby improving the correlation of multi-source data and component-level attribution capabilities. This provides a consistent data foundation for subsequent time alignment to generate multi-layer dependency graphs and output bottleneck profiles, and reduces the cost of manually investigating the correspondence between links and resource consumption.

[0048] In some embodiments, aligning multi-source data based on time stamps to generate a multi-layer dependency graph with component identifiers as node attributes includes: A first time stamp is generated based on the span timestamp in the link tracing data, and a second time stamp is generated based on the collection time of resource indicator data and runtime event data. The first and second time markers are mapped to a unified time base, and the multi-source observation data are time-bucketed according to a preset time window to form aligned data units corresponding to each time window; For any aligned data unit, construct a multi-layered node set containing runtime interface or service unit nodes, external dependency nodes, and component identifier nodes, and write at least one of component type, component level, and application version to the component identifier node; Call edges are generated based on the parent-child span relationship and interface identifier in the link tracing data, and dependency edges are generated based on the external dependency exception or retry relationship in the runtime event. At the same time, node resource attributes are generated based on resource indicator data. Merge and deduplicatize the call edges, dependency edges, and node resource attributes, and output a multi-layer dependency graph with the component identifier as the node attribute.

[0049] Specifically, the first time stamp refers to the time stamp generated from the span timestamps in the link tracing data, used to characterize the start and end times of each span in the request processing link on a unified time axis. The second time stamp refers to the time stamp generated from the collection times of resource indicator data and runtime event data, used to characterize the positions of resource sampling and event triggering on a unified time axis.

[0050] A unified time base refers to a time reference that maps a first time mark and a second time mark to the same time reference system. A unified time base can be the runtime system clock time base or a relative time base with the arrival time of an entry request as the zero point.

[0051] A preset time window refers to the length of the window used to bin multi-source observation data over time, merging data at different time granularities into aligned data units within the same time period. An aligned data unit is a set of data corresponding to a specific time window, which includes at least the set of link tracing spans, resource indicator statistics, and runtime events within that time window.

[0052] A multi-layered dependency graph is a graph that hierarchically represents the relationships between runtime interfaces or service units, external dependencies, and model components within the same graph structure. Component identifiers, as node attributes or node types, are used to point runtime behavior back to the model component layer. External dependency nodes are nodes abstracted from connector endpoints or external service endpoints, representing the external system interface or external service instance that the connector calls to.

[0053] In some examples, generating a first time stamp based on the span timestamp in the link tracing data and generating a second time stamp based on the collection time of resource indicator data and runtime event data includes: reading the span start timestamp and span end timestamp of each span record in the link tracing data, and forming a first time stamp set using the span start timestamp and span end timestamp; reading the sampling time and sampling period boundary of the resource indicator data, and forming a second time stamp set using the sampling time; and reading the event trigger time of the runtime event data, and forming a second time stamp set using the event trigger time. To reduce errors caused by time drift from different sources, this embodiment simultaneously writes a time source identifier and a sampling granularity identifier when generating time stamps. For example, "link tracing time source" is written for span records, and "resource sampling time source" is written for resource sampling. The time source identifier is then used for calibration when mapping to a unified time base.

[0054] In some examples, mapping the first and second time stamps to a unified time base and performing time bucketing on multi-source observation data according to preset time windows to form aligned data units corresponding to each time window includes: determining the reference zero point and reference scale of the unified time base, wherein the reference zero point can be selected as the time when the request corresponding to the link context identifier arrives at the runtime entry point, and the reference scale can be selected as the millisecond or microsecond scale of the runtime system clock. Mapping the span timestamp in the first time stamp and the sampling time and event trigger time in the second time stamp to a unified time value under the unified time base, and placing the unified time value into the corresponding time bucket according to the preset time window.

[0055] For example, a preset time window can be set to 1 second or 5 seconds. The request processing link span, resource sampling records, and runtime event records are divided into the same time bucket according to their uniform time values, forming aligned data units. An aligned data unit includes the span set within the time window, the resource indicator statistics within the time window, and the event set within the time window. The resource indicator statistics can be statistics such as the average processing unit usage, peak storage usage, input / output waiting quantiles, and queue depth change rate. To accommodate differences in request processing duration, this embodiment can establish time window numbers for the aligned data units, allowing the same link context identifier to correspond to multiple consecutive time windows, thereby forming a time window sequence that can be used for subsequent time series prediction.

[0056] The following example scenario illustrates this. A request corresponding to a certain link context identifier enters the entry point at 0ms; page event processing spans from 10ms to 80ms; rule execution spans from 90ms to 220ms; and connector call spans from 230ms to 900ms. Resource sampling collects processing unit occupancy and queue depth every 200ms; external dependency exceptions trigger a retry event at 650ms. By using a unified time base mapping and 1s preset time window binning, aligned data units covering 0ms to 1000ms can be formed. These units include the span sets of page events, rule execution, and connector calls, resource metric statistics corresponding to the sampling window, and retry event records. This allows the subsequent dependency graph to simultaneously express link behavior, resource status, and event triggering within the same time window.

[0057] In some examples, for any aligned data unit, a multi-layered node set is constructed, including runtime interface or service unit nodes, external dependency nodes, and component identifier nodes. The component identifier node is written with at least one of the following: within the aligned data unit, the runtime interface node is obtained by parsing the interface identifier in the link tracing data, and the service unit node is obtained by parsing the mapping relationship between the interface identifier and the service unit identifier; the external dependency node is obtained by parsing the external endpoint information in the runtime event or link tracing; and the component identifier node is obtained by parsing the component identifier carried by the span record.

[0058] Subsequently, at least one of the following is written to the component identifier node: component type, component level, and application version. The component type and component level can be obtained from the model definition data parsing results of the previous embodiment, and the application version can be obtained from the component identifier or mapping relationship entry. By writing the above attributes into the component identifier node, the multi-layer dependency graph can structurally retain both the interface and service unit perspectives of the runtime layer and the component perspective of the model layer, and provide node feature input for subsequent graph representation learning.

[0059] In some examples, call edges are generated based on the parent-child span relationship and interface identifier in the link tracing data, and dependency edges are generated based on external dependency anomalies or retry relationships in the runtime events. Simultaneously, node resource attributes are generated based on resource metric data, including: for the span set in the aligned data unit, the call order and nesting relationship are determined according to the parent-child span relationship, and call edges are generated between the corresponding interface nodes or service unit nodes. These call edges can carry edge attributes such as the number of calls and the span duration quantile. For the runtime event set, if there are external dependency anomalies or retry relationships, dependency edges are generated between the component identifier node initiating the call and the external dependency node. These dependency edges can carry edge attributes such as the anomaly type, the number of retryes, and the backoff interval flag. For the resource metric statistics set, statistics such as processing unit occupancy, storage occupancy, input / output waiting time, and queue depth are written into the interface nodes or service unit nodes as node resource attributes. Furthermore, based on the span attribution relationship of the component identifier, resource attributes can be generated as attribution attributes according to the component identifier dimension to support subsequent identification of bottleneck type distribution and dependency propagation risks.

[0060] In some examples, merging and deduplication are performed on call edges, dependency edges, and node resource attributes. The output multi-layer dependency graph with component identifiers as node attributes includes: merging repeated interface identifier nodes, service unit nodes, external dependency nodes, and component identifier nodes within the same aligned data unit; merging edge attributes of call edges with the same start and end points according to preset rules, such as accumulating call counts and updating span duration attributes to quantile statistics; merging dependency edges according to the combination key of external dependency nodes and component identifier nodes, and summarizing exception types and retries; and performing consistency checks and deduplication on node resource attributes according to the sampling window to avoid bias caused by repeated writing of the same statistic. The final output multi-layer dependency graph uses component identifiers as one of the node attributes or node types, and maintains the cross-layer connections between runtime interface or service unit nodes, external dependency nodes, and component identifier nodes, enabling subsequent graph representation learning to simultaneously capture link topology, external dependency propagation paths, and resource pressure distribution within the same graph structure.

[0061] Through the above embodiments, this application maps the span timestamps of link tracing data with the collection times of resource indicator data and runtime event data to a unified time base, and forms aligned data units according to a preset time window, enabling multi-source observations to be correlated under the same temporal semantics; further, within the aligned data unit, a multi-layer node set containing runtime interfaces or service units, external dependencies, and component identifiers is constructed, generating call edges and dependency edges and writing them into node resource attributes, and after merging and deduplication, a multi-layer dependency graph with component identifiers as node attributes is obtained, thereby improving the consistency and usability of multi-source data fusion modeling, enabling bottleneck locations, dependency propagation, and resource pressure to be synchronously depicted in the graph structure, providing a more stable input basis for the subsequent generation of bottleneck profiles, and reducing erroneous and missed correlations caused by inconsistent time granularity.

[0062] In some embodiments, graph representation learning and temporal prediction processing are performed on the multi-layer dependency graph to output a bottleneck profile, including: Structural and temporal features are extracted from each node and edge in the multi-layer dependency graph. Structural features include node degree, critical path location and / or cross-layer dependency relationship, while temporal features include quantile delay sequence, resource consumption sequence and / or event frequency sequence. Based on structural and temporal features, graph representation learning is performed on the multi-layer dependency graph to generate graph embedding vectors corresponding to each component identifier, and the bottleneck risk score of the component identifier is calculated based on the graph embedding vectors. Temporal prediction processing is performed on graph embedding vectors and quantile delay sequences to generate risk evolution sequences within the target prediction window; A bottleneck profile is generated based on the bottleneck risk score and risk evolution sequence.

[0063] Specifically, structural features refer to the feature information extracted from the topology and cross-layer connections of a multi-layer dependency graph, which is used to characterize the centrality, criticality and cross-layer coupling degree of a node in the dependency network.

[0064] Critical path location refers to the relative position of a node or edge in the critical path of a request processing link, which is used to characterize its contribution to the overall latency of the link.

[0065] Cross-layer dependency refers to the connection between component identifier nodes and runtime interface or service unit nodes, as well as external dependency nodes, and is used to characterize the mapping and coupling of model components to runtime behavior and external dependencies.

[0066] Temporal features refer to sequential observation features formed according to a preset time window, which are used to characterize the delay, resource pressure and event triggering changes of nodes or edges in a continuous time window.

[0067] Quantile delay sequence refers to a sequence of span duration quantile values ​​obtained statistically over multiple consecutive time windows, used to characterize the changing trend of link performance distribution.

[0068] Resource occupancy sequence refers to a sequence of resource indicators such as processing unit occupancy, storage occupancy, input / output waiting time, and queue depth obtained statistically over multiple consecutive time windows.

[0069] An event frequency sequence refers to a sequence of the number of times or the rate of occurrence of runtime events such as timeouts, retries, rate limiting, circuit breakers, and external dependency anomalies, obtained statistically within multiple consecutive time windows.

[0070] Graph embedding vectors are vectorized representations of nodes generated after graph representation learning is performed on a multi-layer dependency graph. They are used to express the topological location, attribute distribution, and temporal context of nodes in a vector space.

[0071] Risk evolution sequence refers to the prediction sequence of bottleneck risk over time within the target prediction window, used to characterize the upward, diffusion or downward trend of bottleneck risk.

[0072] Bottleneck profiling refers to a structured description of the bottleneck type, bottleneck location, and dependency propagation trend. It includes risk score distribution and risk evolution information for component identification, and can further carry uncertainty parameters for subsequent policy gating.

[0073] In some examples, extracting structural and temporal features for each node and edge in a multi-layer dependency graph includes: calculating the node degree for each node in the multi-layer dependency graph corresponding to a single time window; determining the critical path location for each node, which can be determined based on the parent-child span relationship and span duration quantile statistics in the link tracing data; specifically, marking the call chain segment that contributes the most to the quantile delay as the critical path segment, and marking the interface node, service unit node, and component identifier node falling on the chain segment as having critical path location attributes; and extracting cross-layer dependency features for each node, which are used to characterize the number, type, and attribute distribution of cross-layer edges between the component identifier node and the interface node, service unit node, and external dependency node.

[0074] Simultaneously, temporal features are extracted from nodes and edges within a time window sequence composed of multiple consecutive time windows. These temporal features include one or more of the following: quantile delay sequence, resource occupancy sequence, and event frequency sequence. Specifically, the quantile delay sequence can be formed by the quantile statistics of the link tracing span within each time window; the resource occupancy sequence can be formed by the statistical values ​​of node resource attributes within each time window; and the event frequency sequence can be formed by the count of runtime events associated with dependent edges or nodes. By assigning structural features and temporal features to component identifier nodes, interface nodes, and external dependent nodes, respectively, this embodiment can simultaneously express "topology" and "temporal evolution" in subsequent graph representation learning.

[0075] In some examples, graph representation learning is performed on the multi-layer dependency graph based on structural and temporal features to generate graph embedding vectors corresponding to each component identifier, and the bottleneck risk score of the component identifier is calculated based on the graph embedding vectors. This includes encoding the structural and temporal features into node feature vectors and edge feature vectors, and using them as input for graph representation learning.

[0076] Graph representation learning is used to generate node representations under the constraints of adjacency and cross-layer dependency relationships in a multi-layer dependency graph, where a graph embedding vector is output for component identifier nodes. To enable component identifier nodes to incorporate runtime interface or service unit and external dependency context information, this embodiment sets cross-layer propagation weights for cross-layer dependency edges during graph representation learning, allowing component identifier nodes to absorb resource attributes of associated interface nodes, frequency of external dependency events, and critical path location attributes when generating graph embedding vectors.

[0077] Furthermore, the risk assessment unit calculates the bottleneck risk score of component identifiers based on graph embedding vectors. The bottleneck risk score can be generated from the graph embedding vectors using a risk mapping function. The risk mapping function maps the graph embedding vectors to a preset risk range and can weight the risk score by combining the critical path location and node resource attributes, so that component identifiers located on the critical path and under high resource pressure have a higher risk score. To enhance the interpretability of bottleneck location, this embodiment can output risk contribution items while generating the bottleneck risk score, such as "critical path contribution," "resource pressure contribution," and "external dependency anomaly contribution." However, the contribution components are used as constituent fields of the bottleneck profile rather than independent action instructions.

[0078] The following example illustrates this. Within a certain time window, the frequency of retry events on external dependency nodes corresponding to the connector component identifier increases, and the connector call span is located on the critical path, while the queue depth on the service unit node continues to rise. After graph representation learning, the graph embedding vector of this connector component identifier will incorporate information such as external dependency anomalies, critical path, and queue pressure. Based on this, the risk assessment unit outputs a higher bottleneck risk score, enabling the bottleneck location distribution to focus on this component identifier.

[0079] In some examples, performing time-series prediction processing on graph embedding vectors and quantile delay sequences to generate a risk evolution sequence within a target prediction window includes: constructing a graph embedding sequence from graph embedding vectors within multiple consecutive time windows in chronological order, and constructing a delay sequence from the quantile delay sequences of the critical path; inputting the graph embedding sequence and the delay sequence into a time-series prediction unit to predict the risk evolution sequence within the target prediction window. The target prediction window is used to represent several future time windows, such as three or five future time windows.

[0080] During the prediction process, the temporal prediction unit can simultaneously utilize the topological and attribute evolution information expressed in the graph embedding sequence, as well as the link performance evolution information expressed in the quantile delay sequence, to output the risk prediction value for each future time window, forming a risk evolution sequence. To improve the stability of risk prediction, this embodiment can simultaneously output an uncertainty parameter in the risk evolution sequence. The uncertainty parameter is used to characterize the confidence level of the prediction result and can be used as the action gating input for subsequent constrained reinforcement learning strategies.

[0081] In some examples, the bottleneck profile is generated based on the bottleneck risk score and the risk evolution sequence. This includes: summarizing the bottleneck risk scores of each component identifier under the current time window into a risk score distribution, and combining the risk evolution sequence to determine the set of component identifiers whose risk increases or spreads under future time windows; writing the risk score distribution and the risk evolution sequence into the bottleneck profile, and recording the bottleneck location marker, critical path location marker, and cross-layer dependency strength marker associated with the component identifier in the bottleneck profile.

[0082] Furthermore, this embodiment can generate a dependency propagation risk field in the bottleneck profile to characterize the possibility of risk propagating upstream or downstream along dependency edges. This field can be generated jointly by the risk evolution sequence and dependency edge attributes. For example, when external dependency anomalies occur continuously in multiple adjacent time windows and the number of calls to the call edge increases significantly, the dependency propagation risk is set to a high-risk state. After the bottleneck profile is output, it will serve as a key input for subsequent encapsulation of decision states and input into the constrained reinforcement learning strategy, enabling resource action combinations to be generated for high-risk component identifiers and their associated runtime interfaces or service units.

[0083] Through the above embodiments, this application extracts structural and temporal features based on a multi-layer dependency graph, uses graph representation learning to generate graph embedding vectors corresponding to component identifiers and calculates bottleneck risk scores, and combines graph embedding vectors with quantile delay sequences to perform temporal prediction to obtain risk evolution sequences within the target prediction window. Finally, a bottleneck profile that can be used for subsequent decision state encapsulation is formed, thereby improving the accuracy and interpretability of bottleneck location identification, enhancing the ability to characterize bottleneck risk evolution and dependency propagation trends, providing a more stable input basis for subsequent resource action combination generation, and reducing misjudgments and lags caused by relying solely on single-indicator alarms.

[0084] In some embodiments, the bottleneck profile, mapping relationship, and resource constraint parameters are encapsulated as a decision state, input to a constrained reinforcement learning policy, and output a combination of resource actions, including: Based on the mapping relationship, the bottleneck location distribution in the bottleneck profile is mapped to a set of candidate governance objects. The set of candidate governance objects includes runtime interface or service unit identifiers associated with component identifiers. Obtain the resource constraint parameters corresponding to the candidate governance object set, and obtain historical action samples associated with the candidate governance object set; The bottleneck profile, candidate governance object set, resource constraint parameters and historical action samples are encoded into a decision state vector, and the application version and time window tag are written into the decision state vector. The decision state vector is input into the constrained reinforcement learning policy to output a combination of resource actions under the condition of satisfying the resource constraint parameters. Generate action identifiers associated with component identifiers for resource action combinations, and write the action identifiers into the action log for execution and auditing.

[0085] Specifically, the candidate governance object set refers to the set of objects to be intervened that are jointly determined by the bottleneck profile and mapping relationship. Its elements include at least the runtime interface identifier or service unit identifier associated with the component identifier, which is used to limit the scope of the resource action combination.

[0086] Resource constraint parameters refer to a set of constraint parameters used to constrain the generation and application of resource action combinations, including but not limited to one or more of the following: quota limit, minimum number of instances, change window flag, cost budget, scaling step size limit, or parameter tuning boundary.

[0087] Historical action samples refer to the combinations of resource actions that have been performed within a historical time window, along with their corresponding reward results and contextual information. These samples are used to enable constrained reinforcement learning policies to leverage historical experience to reduce the jitter in policy output.

[0088] The decision state vector refers to the vectorized input formed by encoding the bottleneck profile, the set of candidate governance objects, resource constraint parameters and historical action samples, which is used as the state representation for reinforcement learning.

[0089] Constrained reinforcement learning strategies refer to policy models that explicitly introduce constraints during the optimization process of reinforcement learning strategies, and are used to output resource action combinations under the premise of satisfying resource constraint parameters.

[0090] Resource action combination refers to the set of actions generated for a set of candidate governance objects, which includes one or more of scaling up / down actions and configuration / parameter tuning actions.

[0091] Action logs refer to record entries used for execution and auditing, including but not limited to: action identifier, associated component identifier, candidate governance object identifier, action content, application version, and time window marker.

[0092] In some examples, based on the mapping relationship, the bottleneck location distribution in the bottleneck profile is mapped to a set of candidate governance objects. This includes: reading the bottleneck location distribution field from the bottleneck profile, whereby the bottleneck location distribution represents the set of component identifiers with high bottleneck risk scores and their risk score ranking information within the current time window. The mapping unit, based on the mapping relationship between component identifiers and runtime interfaces or service units, maps bottleneck component identifiers to a set of runtime interface identifiers and a set of service unit identifiers, and then aggregates the mapped interface identifiers and service unit identifiers into a set of candidate governance objects.

[0093] To avoid an excessively large set of candidate governance objects leading to an overexpansion of the action space, this embodiment can filter based on bottleneck risk score thresholds, critical path location markers, or dependency propagation risk markers. For example, it can prioritize retaining service unit identifiers corresponding to component identifiers that are on the critical path and have a high dependency propagation risk, or merge multiple component identifiers within the same service unit to form a set of candidate governance objects with service units as the main component. At the same time, it can retain the association information between component identifiers and service units in the set elements to support the generation of action identifiers.

[0094] The following example scenario illustrates this. The bottleneck profile shows that connector component identifier C1 and rule component identifier R1 have high bottleneck risk scores, and C1 exhibits an increased frequency of external dependency anomalies. The mapping relationship shows that C1 corresponds to the connector proxy interface identifier callConnector, carried by service unit S2, and R1 corresponds to the rule execution interface identifier invokeRule, also carried by service unit S2. Therefore, the candidate governance object set can include service unit identifier S2 and the interface identifiers callConnector and invokeRule, with the associated component identifiers C1 and R1 recorded in the set elements.

[0095] In some examples, obtaining resource constraint parameters corresponding to the candidate governance object set and obtaining historical action samples associated with the candidate governance object set includes: the constraint acquisition unit reads the resource constraint parameters corresponding to each service unit or interface identifier in the candidate governance object set. These resource constraint parameters can come from tenant quota configurations, cluster resource quotas, application release policies, and change control policies. Resource constraint parameters include, but are not limited to, quota limits and minimum instance counts, used to restrict the upper and lower limits of scaling actions. They may also include change window flags, used to restrict whether resource action combinations are allowed to be applied within a specific time period, and cost budgets, used to limit the allowed resource increments within a unit time window.

[0096] The historical action sample acquisition unit retrieves historical action sample libraries based on the candidate governance object set, obtaining historical action combinations and their reward results associated with the same service unit identifier, interface identifier, or component identifier. Further filtering based on application version and time window similarity can be performed to avoid sample migration bias caused by cross-version structural changes. To enhance policy stability, this embodiment sets recent samples as high-weighted samples and cross-version samples as low-weighted samples, while retaining action jitter statistics in the historical action samples for subsequent jitter penalties.

[0097] In some examples, the bottleneck profile, candidate governance object set, resource constraint parameters, and historical action samples are encoded into a decision state vector, and the application version and time window markers are written into the decision state vector. This includes: the state encoding unit vectorizing the bottleneck profile fields, including but not limited to encoding the bottleneck risk score distribution, dependency propagation risk markers, and uncertainty parameters into a risk vector; encoding the candidate governance object set, including mapping service unit identifiers and interface identifiers into object indices and generating object existence vectors, while writing the association matrix between component identifiers and object indices; encoding resource constraint parameters, including encoding quota limits, minimum number of instances, change window markers, and cost budgets into constraint vectors; and encoding historical action samples, including encoding the action types, action magnitudes, and reward results of the most recent time windows into historical vectors.

[0098] Subsequently, the risk vector, object vector, constraint vector, and historical vector are concatenated in a preset order to form a decision state vector. The application version and time window markers are written into the decision state vector to characterize the version boundary and time semantics of the state vector, so that subsequent strategy output and action auditing can be traced back according to version and time window.

[0099] In some examples, inputting the decision state vector into a constrained reinforcement learning policy to output a combination of resource actions under the condition of satisfying resource constraint parameters includes: using the decision state vector as input to the constrained reinforcement learning policy; the policy performs constraint pruning on the action space during the output phase to ensure that the target number of scaling actions does not exceed the quota limit and is not less than the minimum number of instances; ensuring that the parameter adjustment range of the configuration tuning action falls within the preset tuning boundary; and outputting an empty action or a conservative action when the change window indicates that changes are not allowed.

[0100] The resource action combination includes one or more of scaling up / down actions and configuration tuning actions. The scaling up / down actions are used to adjust the number of service unit instances or resource quotas in the candidate governance object set, while the configuration tuning actions are used to adjust one or more of the concurrency, queue parallelism, connection pool limit, or retry backoff parameters associated with the interface or service unit.

[0101] To reduce cascading jitter, this embodiment can output action priority information through a strategy, so that resource action combinations are applied sequentially according to priority. For example, configuration parameter tuning actions are output first to alleviate queue backlog, and expansion and contraction actions are output when the risk evolution sequence continues to rise, thereby forming an action combination that matches the bottleneck risk evolution.

[0102] In some examples, generating action identifiers associated with component identifiers for resource action combinations and writing the action identifiers into action records for execution and auditing includes: after the action generation unit outputs resource action combinations according to the strategy, it generates an action identifier for each resource action combination. The action identifier includes at least the application version, time window marker, and candidate governance object identifier, and is further written into the set of component identifiers associated with the resource action combination, so that the action identifier can point back to the bottleneck component source that triggered the action.

[0103] Subsequently, the action identifier and resource action combination are written into the action record. The action record includes, but is not limited to: action identifier, associated component identifier, candidate governance object set identifier, action type, action magnitude, constraint pruning result, and policy output confidence information. The action record is then output to the execution unit and the audit unit. The execution unit can apply scaling or configuration tuning actions to the corresponding runtime interface or service unit based on the action record. The audit unit can trace the source of the action, constraint satisfaction, and version boundary based on the action record.

[0104] Through the above embodiments, this application combines bottleneck profiling with mapping relationships to form a set of candidate governance objects. Based on the obtained resource constraint parameters and historical action samples, it encodes a decision state vector carrying application version and time window semantics, enabling the constrained reinforcement learning strategy to output resource action combinations associated with component identifiers within the constraint boundaries. Through action identifiers and action records, it realizes action execution and audit traceability, thereby improving the executability and controllability of resource action generation, reducing the risk of action jitter caused by lack of constraints and lack of historical experience, and providing a consistent action link closed loop for subsequent gray-scale application and reward update.

[0105] In some embodiments, constraint verification and grayscale application are performed on resource action combinations, and multi-source data after application is collected within a monitoring window to calculate rewards, including: Perform consistency and security checks on the resource action combination call constraint verification rule set, and generate a rejection record when the check fails. The consistency check includes one or more of the following: quota limit check, minimum instance count check, and action conflict check. The security check includes one or more of the following: change window check, rollback availability check, and risk threshold check. When the verification is successful, a subset of grayscale application objects is determined from the candidate governance object set based on the preset grayscale ratio and grayscale object selection rules, and a grayscale identifier is generated for the subset of grayscale application objects. The resource action combination is applied to a subset of grayscale application objects according to the grayscale identifier, and the monitoring window timer is triggered after application to collect the link tracing data, resource indicator data and runtime event data after application. The reward is calculated based on multi-source data after the application, and the reward includes one or more of the following: service level indicator deviation items, cost deviation items, and motion jitter penalty items. Rewards are associated with and stored with action identifiers, component identifiers, and application versions to form empirical samples for updating constrained reinforcement learning policies.

[0106] Specifically, the constraint verification rule set refers to the set of rules used to determine the compliance of resource action combinations, including consistency verification rules and security verification rules. Consistency verification checks whether resource action combinations meet resource quotas and configuration boundaries, including one or more of quota limit verification, minimum instance count verification, and action conflict verification. Action conflict verification determines whether there are contradictory or incompatible actions for the same candidate governance object within the same time window, such as simultaneously outputting scaling up and down adjustments, or concurrently applying mutually exclusive parameter adjustments to the same object. Security verification checks whether resource action combinations meet change control and rollback security requirements, including one or more of change window verification, rollback availability verification, and risk threshold verification. Rollback availability verification determines whether there is an executable rollback path or rollback configuration snapshot, while risk threshold verification determines whether the uncertainty parameters, dependency propagation risks, or historical failure rates in the bottleneck profile exceed preset thresholds.

[0107] The grayscale ratio refers to the coverage ratio or number of actions applied to the candidate governance object set, used to control the scope of impact of a single action. Grayscale object selection rules refer to the set of rules used to select a subset of objects to be affected during grayscale implementation from the candidate governance object set. Selection can be based on risk score, object importance, traffic share, version distribution, or rollback capability. The subset of objects to be affected during grayscale implementation refers to the subset of candidate governance objects that actually receive the combination of resource actions during a single grayscale phase.

[0108] The monitoring window refers to the time interval used to collect multi-source data after an action is performed and to evaluate the effect of the action. The reward is an evaluation value calculated based on the multi-source data after the action is performed within the monitoring window, including one or more of the following: service level indicator deviation items, cost deviation items, and action jitter penalty items.

[0109] In some examples, the process of calling the constraint verification rule set to perform consistency and security checks on the combination of resource actions and generating a rejection record when the checks fail includes: after the policy outputs the combination of resource actions, the verification unit reads the candidate governance object identifier, action type and action magnitude from the action record, and calls the constraint verification rule set to perform consistency and security checks.

[0110] For consistency verification, the verification unit performs at least quota limit verification and minimum instance count verification, that is, comparing the target instance count of scaling actions with the resource quota against the quota limit and minimum instance count; for configuration parameter tuning actions, it verifies whether the parameter adjustment values ​​fall within the preset parameter tuning boundaries and meet object-level constraints. For action conflict verification, the verification unit determines whether actions are mutually exclusive based on the action set of the same candidate governance object, and determines whether there is a conflict with historical actions being executed based on time window markers.

[0111] For security verification, the verification unit performs at least change window verification and rollback availability verification. This involves determining whether changes are permitted within the current time window and whether an available rollback configuration snapshot or an executable rollback action exists. Simultaneously, a risk threshold verification is performed, comparing risk inputs such as uncertainty parameters, dependency propagation risks, and historical failure rates from the bottleneck profile with preset thresholds. If the threshold is exceeded, the action is rejected or downgraded to a conservative action. When verification fails, the verification unit generates a rejection record, which includes the action identifier, associated component identifier, rejection reason code, trigger rule identifier, and application version. The rejection record is then output to the audit unit and policy feedback unit for subsequent constraint and correction of policy outputs.

[0112] In an example scenario, an action record requests to expand service unit S2 to 12 instances, but the quota limit for this service unit is 10 instances. In this case, the quota limit verification fails, the verification unit generates a rejection record and marks the rejection reason code as "quota limit exceeded". If the action is within a time window where changes are prohibited, the change window verification fails and a rejection record is generated. If the frequency of external dependency anomalies corresponding to the connector component identifier is too high and the uncertainty parameter exceeds the threshold, the risk threshold verification fails, the verification unit can reject the expansion action and allow only more conservative configuration parameter tuning actions to be applied.

[0113] In some examples, upon successful verification, a subset of objects to be subject to grayscale application is determined from the candidate governance object set based on a preset grayscale ratio and grayscale object selection rules. Grayscale identifiers are then generated for this subset. This includes the grayscale control unit reading the preset grayscale ratio and grayscale object selection rules. The preset grayscale ratio can be set according to the proportion of object quantity, traffic share, or instance share. Grayscale object selection rules may include selection based on risk score sorting, stratified sampling based on object importance, selection based on version and geographical distribution, and selection based on rollback capability priority.

[0114] The grayscale control unit selects a subset of objects for grayscale application from the candidate governance object set and generates a grayscale identifier for this grayscale batch. The grayscale identifier includes at least the application version, time window marker, and batch number, and is written to the action record so that subsequent monitoring window collection and reward calculation can be linked to this grayscale batch. If the candidate governance object set contains multiple service units and interface identifiers, the subset of objects for grayscale application can prioritize objects with strong rollback capabilities or low traffic percentages to reduce potential risks.

[0115] In some examples, resource action combinations are applied to a subset of grayscale application objects based on grayscale identifiers, and a monitoring window is triggered after application to collect post-application link tracing data, resource metric data, and runtime event data. This includes: the execution unit applying resource action combinations to the subset of grayscale application objects based on action records and grayscale identifiers. For scaling up / down actions, the execution unit submits instance number change requests or resource quota change requests to the resource orchestration system; for configuration parameter tuning actions, the execution unit submits parameter change requests to the configuration center or runtime management interface and records the parameter version number to support rollback.

[0116] Furthermore, after the application is completed, the monitoring unit starts the monitoring window timing using grayscale identifiers and action identifiers as association keys. Within the monitoring window, the aforementioned runtime acquisition mechanism is reused to collect post-application link tracing data, resource indicator data, and runtime event data. The multi-source data is then aggregated at the sampling window dimension to form post-application multi-source observation data. To avoid the influence of other changes during the acquisition process, this embodiment can write change isolation markers within the monitoring window or write grayscale identifiers into the multi-source observation data to distinguish observation results from different grayscale batches.

[0117] In some examples, rewards are calculated based on multi-source data after application. The reward includes one or more of the following: a service level indicator (SLE) deviation item, a cost deviation item, and a motion jitter penalty item. The reward calculation unit reads multi-source observation data from the monitoring window after application and calculates the reward. The SLE deviation item characterizes the deviation between the applied SLE and the baseline value. The SLE can be generated from critical path quantile delay, error rate, timeout rate, or availability statistics. The baseline value can be the statistical value of the same type of time window before application or the target threshold of the same version. The cost deviation item characterizes the deviation between the applied resource cost and the baseline cost. The resource cost can be generated by combining the number of instances, resource quota, and unit cost coefficient. The motion jitter penalty item suppresses instability caused by frequent round-trip adjustments or excessive motion amplitude. It can be generated based on the number of motion direction flips, the rate of change of motion amplitude, or the number of short-cycle repeated applications of the same object within adjacent time windows. The reward calculation can use a weighted combination method, combining the above deviation and penalty items into a single reward value. An uncertainty correction factor can be written into the reward to make the reward update more conservative in high-uncertainty prediction scenarios, thereby reducing policy overfitting.

[0118] In some examples, rewards are associated with action identifiers, component identifiers, and application versions to form experience samples for updating constrained reinforcement learning policies. This involves the experience generation unit associating rewards with action identifiers, grayscale identifiers, a set of associated component identifiers, a set of candidate governance object identifiers, application versions, and monitoring window markers to generate experience samples. Experience samples include decision state vectors, resource-action combinations, rewards, action identifiers, and monitoring window markers. They can also be further inscribed with verification results and rejection record markers to identify "applicable samples" and "rejected samples" during policy updates. If the application is grayscale, the experience sample also includes grayscale identifiers and grayscale ratios for reuse when expanding to full application. After generation, the experience samples are output to the experience pool, providing training data for subsequent reward-based updates to constrained reinforcement learning policies.

[0119] Through the above embodiments, this application performs consistency and security checks on the resource action combinations output by the strategy and generates rejection records to ensure action compliance. When the check passes, a subset of grayscale application objects is determined based on the grayscale ratio and grayscale object selection rules, and grayscale identifiers are generated to achieve controlled application. Link tracing data, resource indicator data, and runtime event data after application are collected in the monitoring window to calculate rewards including service level indicator deviation items, cost deviation items, and action jitter penalties. The rewards are associated with action identifiers, component identifiers, and application versions to form experience samples, thereby improving the security and traceability of resource action application, reducing the risks caused by direct full changes, and providing quantifiable feedback data for strategy iteration to enhance the stability of subsequent resource allocation.

[0120] In some embodiments, the reinforcement learning policy is updated based on rewards and action samples associated with component identifiers are recorded, including: Experience samples are written into the experience pool. The experience samples include decision state vectors, resource action combinations, rewards, and monitoring window markers. The constrained reinforcement learning policy is updated based on the experience pool. The policy update includes introducing a constraint penalty term or a Lagrange multiplier term into the objective function so that the updated policy satisfies the resource constraint parameters. After the strategy update is completed, the resource action combination, rewards and component identifiers associated with the resource action combination are summarized into action sample records, and the application version, time window marker and grayscale identifier are written into the action sample records. The action sample records are deduplicated and versioned, and when an application version switch is detected, the action sample records associated with the historical application version are marked as untrainable samples or downweighted samples.

[0121] Specifically, the experience pool refers to a sample storage area used to store experience samples and support retrieval by time window, object identifier, and version. It is used to provide training data for the policy update process. Lagrange multipliers are weight terms used in constrained optimization to introduce the degree of constraint violation into the objective function, enabling the policy to suppress actions that violate resource constraint parameters while optimizing rewards. Reduced-weighted samples are experience samples whose sampling probability or loss weight is reduced during policy updates to reduce sample migration bias caused by cross-version structural changes.

[0122] In some examples, writing experience samples into the experience pool involves the following steps: After reward calculation, the experience generation unit encapsulates the key fields of this closed loop into experience samples and writes them into the experience pool. Experience samples include decision state vectors, resource action combinations, reward and monitoring window markers, and may also include one or more of the following: action identifiers, grayscale identifiers, candidate governance object identifier sets, constraint pruning results, and rejection record markers, for subsequent training and audit correlation. During the writing process, the experience generation unit generates sample identifiers for the experience samples and establishes an index using "application version + time window marker + candidate governance object primary key" as the index key. This allows the experience pool to quickly retrieve recent samples by version and time window, and also to retrieve historically similar samples by service unit identifier or component identifier.

[0123] Furthermore, to improve the usability of the experience pool, this embodiment performs two types of processing on samples entering the pool. The first is sample integrity verification, which checks whether the decision state vector contains bottleneck profile encoding, constraint vector encoding, and candidate governance object encoding; whether the resource action combination contains action type and target; and whether the reward contains at least one deviation or penalty item. If these conditions are not met, the sample is marked as incomplete and its training weight is reduced. The second is sample timeliness marking, which involves writing an "expiration date" or "expiration threshold" to the sample and binning the samples according to the application version switch time, so that the latest version and the most recent time window samples are sampled first when the strategy is updated.

[0124] In some examples, policy updates for constrained reinforcement learning policies based on experience pools include: a policy update unit draws a batch of training samples from the experience pool at a preset update frequency. This update frequency can be triggered by a time window or by the number of new samples added to the experience pool. During sampling, the policy update unit prioritizes samples that are consistent with the current application version and have already been applied in grayscale, avoiding directly using rejected samples and unapplied samples as positive learning signals. Simultaneously, to prevent the policy from getting trapped in local optima, the policy update unit can mix in a certain proportion of downweighted samples from historical versions, allowing the policy to retain some generalization ability.

[0125] During the policy update process, this embodiment introduces a constraint penalty term or a Lagrange multiplier term into the objective function, making the policy sensitive to constraint violations while pursuing higher rewards. Specifically, the policy update unit calculates the constraint violation degree based on the resource action combination and resource constraint parameters for each sample. The constraint violation degree is used to quantify whether the action triggers a violation of the quota limit, minimum number of instances, change window, cost budget, or parameter tuning boundary. When the sample comes from executable actions after constraint pruning, the constraint violation degree approaches 0; when the sample is marked as a rejected record or out-of-bounds action, the constraint violation degree is non-zero and triggers a stronger penalty. Subsequently, the constraint violation degree is multiplied by the Lagrange multiplier term to form the constraint penalty amount, which, together with the reward, participates in the policy parameter update, causing the policy to gradually tend to output action combinations that satisfy the resource constraint parameters.

[0126] The following example illustrates the policy update process. If a service unit experiences increased queue depth and critical path latency across multiple consecutive time windows, and the policy previously output the action combination of "expanding by 2 instances and reducing retry concurrency," and the monitoring window reward shows improved service level indicator deviations and cost deviations within budget, then this empirical sample generates a positive gradient in the policy update, making the policy more inclined to output similar actions under similar conditions. Conversely, if the policy outputs a significant expansion under high uncertainty, resulting in cost deviations exceeding budget and increased action jitter penalties, then this sample has lower rewards and higher constraint penalties. After the policy update, it will reduce the probability of outputting significant expansions under similar conditions and may shift to more conservative parameter tuning actions or smaller step-size expansion actions.

[0127] In some examples, after the policy update is completed, the resource action combination, reward, and component identifiers associated with the resource action combination are aggregated into an action sample record. This includes: the action accumulation unit filters "effective experience samples" from the sample batch that has just completed training. Effective experience samples can be defined as samples that have passed grayscale application and whose reward calculation is effective. For each effective experience sample, the action accumulation unit reads the resource action combination, reward, candidate governance object identifier, and the set of component identifiers associated with the action combination, and aggregates them into an action sample record. The action sample record is used to form governance knowledge entries oriented towards component identifiers, which include, but are not limited to: component identifier, action type, action magnitude, reward statistics, and monitoring window marker. The application version, time window marker, and grayscale identifier are also written into the action sample record to align it with the specific version's model component structure and runtime mapping relationship.

[0128] Furthermore, to enhance the reusability of action sample records, this embodiment adds two types of derived information to the action sample records. The first is a state summary, used to record key bottleneck profiles that trigger the action in compressed form, such as the bottleneck risk score range, dependency propagation risk level, and uncertainty parameter range, enabling subsequent retrieval to match action samples based on similar states. The second is an action stability marker, used to record whether the action undergoes reverse or repeated adjustments in adjacent time windows, thereby providing sample-level evidence for subsequent action jitter penalties.

[0129] In some examples, deduplication and versioning archiving are performed on action sample records. When an application version switch is detected, action sample records associated with historical application versions are marked as untrainable or downweighted samples. This includes: the archiving unit establishing an archiving primary key for action sample records based on "application version + component identifier + candidate governance object identifier + action type," and performing deduplication on duplicate records under the same primary key. Deduplication can employ a merging strategy, i.e., statistically summarizing the rewards of duplicate records to obtain the mean, quantile, or stability index, and retaining the most representative action amplitude as the representative action for that primary key. After deduplication, the archiving unit performs versioning archiving on the action sample records, storing action samples under different application versions separately, and establishing version inheritance relationships to characterize which component identifiers remain stable and which component identifiers are reconstructed or split during version iterations.

[0130] Furthermore, when an application version switch is detected, this embodiment determines whether the component identifier has changed based on the versioned storage of the aforementioned mapping relationship. If the component identifier does not have a corresponding relationship in the new version, or its component type, component level, and calling relationship have changed significantly, the historical action sample record associated with the component identifier is marked as an untrainable sample to avoid erroneously migrating action experience from the old version to the new version. If the component identifier still exists but its runtime interface or service unit mapping has been migrated, for example, from service unit S2 to service unit S3, the historical action sample record is marked as a deweighted sample so that it can still provide a weak reference during policy updates but does not dominate policy output. For component identifiers that have only undergone minor changes, the archiving unit can retain them as normal samples and write a version difference mark in the status summary to support rapid policy convergence in the early stages of the new version.

[0131] Through the above embodiments, this application writes the experience samples formed by reward feedback into an experience pool and establishes version and object indexes. Based on the experience pool, it introduces constraint penalty terms or Lagrange multiplier terms to update the constrained reinforcement learning policy, so that the policy can suppress actions that violate resource constraint parameters while optimizing rewards. After the policy is updated, the resource action combination and reward are deposited according to the component identifier to form an action sample record. The action sample record is deduplicated and versioned for archiving. When the application version is switched, historical samples are marked as untrainable or downweighted, thereby improving the stability and transferability of policy iteration, reducing the risk of cross-version mislearning, and enhancing the ability to deposit and reuse component-level governance experience.

[0132] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0133] Figure 2 This is a schematic diagram of the low-code application performance bottleneck prediction and dynamic resource allocation device provided in an embodiment of this application. Figure 2 As shown, the device includes: The acquisition module 201 is used to acquire the metadata of the model components of the low-code application to be governed, generate a component identifier associated with the application version for each model component, and build a mapping relationship between the component identifier and the runtime interface or service unit. Alignment module 202 is used to collect link tracing data, resource indicator data and runtime event data carrying component identifiers from the request processing link during low-code application runtime, and align the multi-source data based on time stamps to generate a multi-layer dependency graph with component identifiers as node attributes. The prediction module 203 is used to perform graph representation learning and time series prediction processing on the multi-layer dependency graph and output a bottleneck profile, wherein the bottleneck profile includes bottleneck type distribution, bottleneck location distribution, dependency propagation risk and uncertainty parameters associated with component identifiers. The encapsulation module 204 is used to encapsulate the bottleneck profile, mapping relationship and resource constraint parameters into a decision state, input a constrained reinforcement learning policy, output a resource action combination, and associate the resource action combination with the component identifier, wherein the resource action combination includes at least one of scaling up and down actions and configuration parameter tuning actions. The reward module 205 is used to perform constraint verification and grayscale application on resource action combinations, collect multi-source data after application in the monitoring window to calculate rewards, update reinforcement learning strategies based on rewards, and record action samples associated with component identifiers.

[0134] Figure 3 This is a schematic diagram of the electronic device 3 provided in an embodiment of this application. Figure 3As shown, the electronic device 3 of this embodiment includes: a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, it implements the steps in the various method embodiments described above. Alternatively, when the processor 301 executes the computer program 303, it implements the functions of each module / unit in the various device embodiments described above.

[0135] Electronic device 3 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 3 may include, but is not limited to, processor 301 and memory 302. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or different components.

[0136] The processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0137] The memory 302 can be an internal storage unit of the electronic device 3, such as a hard disk or memory of the electronic device 3. The memory 302 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 3. The memory 302 can also include both internal and external storage units of the electronic device 3. The memory 302 is used to store computer programs and other programs and data required by the electronic device.

[0138] 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 merely 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. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0139] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a readable storage medium (e.g., a computer-readable storage medium). Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which may be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable storage medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0140] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such 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 this application, and should all be included within the protection scope of this application.

Claims

1. A method for predicting performance bottlenecks and dynamically allocating resources in low-code applications, characterized in that, include: Obtain the metadata of the model components of the low-code application to be governed, generate a component identifier for each model component that is associated with the application version, and build a mapping relationship between the component identifier and the runtime interface or service unit. When the low-code application is running, link tracing data, resource indicator data and runtime event data carrying component identifiers are collected from the request processing link, and the multi-source data is aligned based on time stamps to generate a multi-layer dependency graph with component identifiers as node attributes. Graph representation learning and temporal prediction processing are performed on the multi-layer dependency graph to output a bottleneck profile, wherein the bottleneck profile includes bottleneck type distribution, bottleneck location distribution, dependency propagation risk and uncertainty parameters associated with component identifiers; The bottleneck profile, mapping relationship, and resource constraint parameters are encapsulated into a decision state, and a constrained reinforcement learning policy is input to output a resource action combination. The resource action combination is associated with a component identifier, wherein the resource action combination includes at least one of scaling up / down actions and configuration parameter tuning actions. Constraint verification and grayscale application are performed on resource action combinations, and multi-source data after application are collected in the monitoring window to calculate rewards. The reinforcement learning strategy is updated based on the rewards, and action samples associated with component identifiers are recorded.

2. The method according to claim 1, characterized in that, The process of obtaining metadata of model components of the low-code application to be governed, generating component identifiers associated with the application version for each model component, and constructing a mapping relationship between component identifiers and runtime interfaces or service units includes: Read the model definition data corresponding to the low-code application to be governed. The model definition data includes one or more descriptive information of pages, processes, data entities, rules and connectors. Based on the model definition data, extract the component type, component level and calling relationship of each model component, and generate a component identifier associated with the application version; Based on the call relationship and runtime deployment information, determine the runtime entry identifier or interface identifier corresponding to each component identifier, and generate a mapping relationship between component identifiers and runtime interfaces or service units; The mapping relationship is stored in a versioned manner, and the mapping relationship corresponding to the current application version is updated when changes in model definition data or runtime deployment information are detected.

3. The method according to claim 1, characterized in that, The process of collecting link tracing data, resource metric data, and runtime event data carrying component identifiers during low-code application runtime includes: When a request enters the runtime entry point of a low-code application, a link context identifier is generated for the request, and the link context identifier is bound to the component identifier and written into the link propagation context. As the request propagates along the request processing link, link tracing data associated with the identifiers of each component is collected based on the link propagation context. Based on the link context identifier, resource indicator data is collected within the sampling window associated with the request. The resource indicator data includes one or more of the following: processing unit usage, storage usage, input / output waiting time, and queue depth. When a runtime event associated with the request processing link is detected, the link context identifier and component identifier are written to the runtime event; The link tracing data, resource indicator data, and runtime event data are aggregated according to the link context identifier and output as multi-source observation data carrying component identifiers.

4. The method according to claim 3, characterized in that, The step of aligning multi-source data based on time stamps to generate a multi-layer dependency graph with component identifiers as node attributes includes: A first time stamp is generated based on the span timestamp in the link tracing data, and a second time stamp is generated based on the collection time of the resource indicator data and the running event data. The first time stamp and the second time stamp are mapped to a unified time base, and the multi-source observation data are time-divided according to a preset time window to form aligned data units corresponding to each time window; For any aligned data unit, construct a multi-layer node set containing runtime interface or service unit nodes, external dependency nodes, and component identifier nodes, and write at least one of component type, component level, and application version for the component identifier node; Call edges are generated based on the parent-child span relationship and interface identifier in the link tracing data, and dependency edges are generated based on the external dependency exception or retry relationship in the running event. At the same time, node resource attributes are generated based on the resource indicator data. Merge and deduplicate the call edges, dependency edges, and node resource attributes, and output a multi-layer dependency graph with component identifiers as node attributes.

5. The method according to claim 1, characterized in that, The process of performing graph representation learning and temporal prediction on the multi-layer dependency graph, and outputting a bottleneck profile, includes: Structural and temporal features are extracted from each node and edge in the multi-layer dependency graph. The structural features include node degree, critical path location and / or cross-layer dependency relationship. The temporal features include quantile delay sequence, resource consumption sequence and / or event frequency sequence. Based on the structural features and the temporal features, graph representation learning processing is performed on the multi-layer dependency graph to generate graph embedding vectors corresponding to each component identifier, and the bottleneck risk score of the component identifier is calculated based on the graph embedding vectors. Perform time-series prediction processing on the graph embedding vector and the quantile delay sequence to generate a risk evolution sequence within the target prediction window; The bottleneck profile is generated based on the bottleneck risk score and the risk evolution sequence.

6. The method according to claim 1, characterized in that, The process of encapsulating the bottleneck profile, mapping relationship, and resource constraint parameters into a decision state, inputting it into a constrained reinforcement learning policy, and outputting a resource action combination includes: Based on the mapping relationship, the bottleneck location distribution in the bottleneck profile is mapped to a set of candidate governance objects, which includes runtime interface or service unit identifiers associated with component identifiers. Obtain the resource constraint parameters corresponding to the candidate governance object set, and obtain the historical action samples associated with the candidate governance object set; The bottleneck profile, candidate governance object set, resource constraint parameters and historical action samples are encoded into a decision state vector, and the application version and time window marker are written into the decision state vector. The decision state vector is input into the constrained reinforcement learning policy to output a combination of resource actions under the condition of satisfying the resource constraint parameters; Generate an action identifier associated with the component identifier for the resource action combination, and write the action identifier into the action record for execution and auditing.

7. The method according to claim 1, characterized in that, The process of performing constraint verification and grayscale application on resource action combinations, and collecting multi-source data after application within the monitoring window to calculate rewards, includes: The resource action combination call constraint verification rule set is used to perform consistency verification and security verification, and a rejection record is generated when the verification fails. The consistency verification includes one or more of quota limit verification, minimum instance number verification and action conflict verification, and the security verification includes one or more of change window verification, rollback availability verification and risk threshold verification. When the verification is successful, based on the preset grayscale ratio and grayscale object selection rules, a subset of grayscale application objects is determined from the candidate governance object set, and grayscale identifiers are generated for the subset of grayscale application objects. The resource action combination is applied to a subset of grayscale application objects according to the grayscale identifier, and a monitoring window timer is triggered after application to collect link tracing data, resource indicator data and runtime event data after application. The reward is calculated based on the multi-source data after the application, and the reward includes one or more of the following: service level indicator deviation item, cost deviation item, and motion jitter penalty item; The rewards are associated with and stored with the action identifier, component identifier, and application version to form experience samples for updating the constrained reinforcement learning strategy.

8. The method according to claim 7, characterized in that, The reward-based reinforcement learning strategy, which records action samples associated with component identifiers, includes: The experience samples are written into the experience pool, and the experience samples include decision state vectors, resource action combinations, rewards, and monitoring window markers. Based on the experience pool, a policy update is performed on the constrained reinforcement learning policy, wherein the policy update includes introducing a constraint penalty term or a Lagrange multiplier term into the objective function so that the updated policy satisfies the resource constraint parameters. After the strategy update is completed, the resource action combination, reward and component identifier associated with the resource action combination are summarized into an action sample record, and the application version, time window mark and grayscale mark are written into the action sample record. The action sample records are deduplicated and versioned, and when the application version switch is detected, the action sample records associated with the historical application version are marked as untrainable samples or downweighted samples.

9. A device for predicting performance bottlenecks and dynamically allocating resources in low-code applications, characterized in that, include: The acquisition module is used to acquire the metadata of the model components of the low-code application to be governed, generate a component identifier associated with the application version for each model component, and build a mapping relationship between the component identifier and the runtime interface or service unit. The alignment module is used to collect link tracing data, resource indicator data and runtime event data carrying component identifiers from the request processing link during low-code application runtime, and align the multi-source data based on time stamps to generate a multi-layer dependency graph with component identifiers as node attributes. The prediction module is used to perform graph representation learning and time series prediction processing on the multi-layer dependency graph and output a bottleneck profile, wherein the bottleneck profile includes bottleneck type distribution, bottleneck location distribution, dependency propagation risk and uncertainty parameters associated with component identifiers. An encapsulation module is used to encapsulate the bottleneck profile, mapping relationship and resource constraint parameters into a decision state, input a constrained reinforcement learning policy, output a resource action combination, and associate the resource action combination with a component identifier, wherein the resource action combination includes at least one of scaling up / down actions and configuration parameter tuning actions; The reward module is used to perform constraint verification and grayscale application on resource action combinations, collect multi-source data after application within the monitoring window to calculate rewards, update reinforcement learning strategies based on rewards, and record action samples associated with component identifiers.

10. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 8.

Images