Method and system for deploying multi-service load integrated control for edge computing

Abstract

The application discloses a multi-service load integrated control deployment method and system for edge computing, and relates to the technical field of edge computing. The method comprises the following steps: submitting service data to a resource middle platform by a micro-service task module; developing an intelligent deployment engine, abstracting the service data into a weighted service synapse, performing pulse coding, driving a service threshold to form a self-organizing topology structure based on pulse mode characteristics, and instantiating a deployment strategy in the topology structure by a decision module; and adopting a container orchestration engine to execute strategy deployment and resource binding, and continuously monitoring and regulating management. The technical problems of low resource utilization efficiency and rigid deployment decision caused by large differences in multi-service load types and dynamic changes in service requirements in the edge computing scenario are solved, the technical effects of dynamically and accurately generating and continuously optimizing the deployment strategy through the pulse coding and self-organizing mechanism inspired by the nervous system, improving the edge resource utilization rate, and guaranteeing the service quality and real-time performance of the multi-service mixed load are achieved.

Description

Technical Field

[0001] This application relates to the field of edge computing technology, specifically to a multi-service load integration control deployment method and system for edge computing. Background Technology

[0002] With the rapid development of the Internet of Things, artificial intelligence, and next-generation information and communication technologies, edge computing is gradually becoming an important computing paradigm supporting real-time perception, intelligent analysis, and local decision-making. In typical application scenarios such as urban rail trains, intelligent transportation, and industrial control, a large number of services run simultaneously at the edge, covering various service types such as real-time control, status monitoring, video analysis, data inference, and batch processing. The requirements of different services in terms of latency, computing power, bandwidth, and reliability vary significantly.

[0003] Existing edge computing platforms mostly adopt static or rule-driven resource scheduling and deployment methods, typically designed for single or homogeneous service loads. This makes it difficult to achieve efficient collaboration in multi-service concurrent and dynamically changing operating environments. Especially in resource-constrained edge nodes, traditional deployment strategies lack comprehensive awareness of service priorities, real-time requirements, and operational status, easily leading to low resource utilization, degraded response performance of critical services, and a lack of continuous adaptive adjustment mechanisms during operation.

[0004] Therefore, there is an urgent need for a multi-service load integrated control and deployment method for edge computing environments, which can perform unified modeling and intelligent perception of different service loads, and realize adaptive deployment decisions and dynamic resource regulation. Summary of the Invention

[0005] This application provides a multi-service load integration control and deployment method and system for edge computing, aiming to solve the technical problems of low resource utilization efficiency and rigid deployment decisions caused by the large differences in the types of multi-service loads and the dynamic changes in business needs in edge computing scenarios.

[0006] The first aspect disclosed in this application provides a multi-service load balancing control deployment method for edge computing. The method includes: submitting multi-threaded business data to a resource platform using microservice task modules as the business submission form; developing an intelligent deployment engine in the resource platform, abstracting business data into weighted business synapses, performing pulse-based encoding of business functions and performance requirements, driving business thresholds to perform topology self-organization based on pulse pattern characteristics, making module instantiation deployment decisions in the topology structure, and determining the deployment strategy; and using a container orchestration engine to perform resource binding and containerized deployment based on the deployment strategy, and performing control and management under continuous operation monitoring.

[0007] Another aspect of this application discloses a multi-service load integration control and deployment system for edge computing. The system includes: a data submission unit that submits multi-threaded business data to a resource platform using microservice task modules as the business submission form; a strategy decision unit that develops an intelligent deployment engine in the resource platform, abstracting business data into weighted business synapses, pulse-encoding business functions and performance requirements, driving business thresholds to perform topology self-organization based on pulse pattern characteristics, making module instantiation deployment decisions within the topology, and determining the deployment strategy; and a control and management unit that uses a container orchestration engine to perform resource binding and containerized deployment based on the deployment strategy, and executes control and management under continuous operation monitoring.

[0008] One or more technical solutions provided in this application have at least the following technical effects or advantages:

[0009] The aforementioned multi-service load balancing and deployment method for edge computing first uses microservice task modules as business carrier units, submitting multi-threaded services to a resource platform for centralized management. Then, an intelligent deployment engine is built within the resource platform to abstractly model business data, transforming functional and performance requirements into weighted pulse features. This guides edge nodes to adaptively form business processing topologies based on different pulse patterns, thereby making deployment decisions for microservice instances. Finally, a container orchestration engine completes resource binding and containerized deployment according to deployment strategies, continuously monitoring the operational status during business operation and dynamically adjusting resource allocation and deployment structure to achieve efficient and stable operation of multi-service loads.

[0010] The above description is merely an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

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

[0012] Figure 1 This is a flowchart illustrating a multi-service load integration control deployment method for edge computing in one embodiment.

[0013] Figure 2 This is a diagram of a multi-service load balancing control deployment system architecture for edge computing in one embodiment.

[0014] Explanation of reference numerals in the attached diagram: Data submission unit 11, strategy decision-making unit 12, control and management unit 13. Detailed Implementation

[0015] This application provides a method and system for integrated control and deployment of multi-service loads for edge computing, which solves the technical problems of low resource utilization efficiency and rigid deployment decisions caused by large differences in the types of multi-service loads and dynamic changes in service requirements in edge computing scenarios.

[0016] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0017] It should be noted that the terms “comprising” and “having”, and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or modules that are not explicitly listed or that are inherent to such process, method, product, or device.

[0018] Example 1, as Figure 1 As shown, this application provides a multi-service load integration control deployment method for edge computing, the method comprising:

[0019] Using microservice task modules as the business submission method, multi-threaded business data is submitted to the resource platform.

[0020] In this embodiment, a microservice task module is used as a unified submission and execution module to decompose train, track, and station-related businesses into services. Specifically, business functions such as train operation control, onboard status monitoring, trackside equipment sensing, video and image analysis, energy consumption statistics, fault diagnosis, and operation scheduling support are broken down into several independently deployable, upgradeable, and scalable microservice task modules. Each microservice task module encapsulates its business processing logic, operating environment dependencies, interface specifications, and resource requirements, and is registered in the resource platform through a standardized service description file. During train operation, business data from onboard control units (such as ATO, TCMS), trackside equipment (such as signals, turnout monitoring devices), platform systems (such as platform screen doors, passenger flow detection equipment), and onboard and platform video acquisition terminals are accessed concurrently in a multi-threaded manner. Different threads carry different types of data streams, such as train speed and position status data, braking and traction status data, signal and traffic permit information, carriage and platform video streams, and equipment status and alarm data. Before data submission, each thread encapsulates and annotates the business data, generating metadata related to each microservice task module. This metadata includes at least the train number, line section, station identifier, business type, priority level, real-time requirements, expected processing latency, data sampling period, and reliability level. Subsequently, each thread submits the business data and its corresponding metadata to the resource platform through a unified data access interface. The resource platform verifies the identity of the received data, categorizes it into business types, and registers it as a task. Based on the train operation stage and business importance, it manages the data in a queue, unifying data streams from multiple trains, lines, and services into a schedulable set of business inputs. Simultaneously, based on the registered microservice task module information, the resource platform routes the business data to the corresponding task scheduling queue or deployment instance, achieving unified access, management, and scheduling of multi-source, multi-threaded business data from urban rail trains at the edge. This provides a clear and traceable business foundation for subsequent intelligent deployment decisions and resource orchestration based on business real-time performance and security levels.

[0021] Develop an intelligent deployment engine in the resource platform. By abstracting business data into weighted business synapses, pulse-encode business function and performance requirements, drive business thresholds to perform topology self-organization based on pulse pattern characteristics, and make module instantiation deployment decisions in the topology to determine the deployment strategy.

[0022] In one embodiment, the resource platform first extracts business characteristics and constraint parameters from the submission information of each microservice task module, such as business type, priority level, security level, expected end-to-end latency, and throughput target. Then, it constructs a business synapse abstraction for each microservice task module. These business synapses use synapse weights to represent the module's preference strength and activation threshold for different resource dimensions. For example, real-time control modules are assigned a weight of "low latency + high reliability," video inference modules are assigned a weight of "GPU / NPU computing power + bandwidth," and historical statistics modules are assigned a weight of "storage + batch processing throughput." Next, the intelligent deployment engine uses its internal first task encoding component to pulse-encode business functions and performance requirements, thereby mapping business data into a sequence of business pulses with temporal characteristics. High-priority, low-latency, and high-real-time train control / signal-related businesses generate high-frequency synchronous pulses, video inference pipeline businesses generate medium-frequency continuous pulses, and offline statistics and batch analysis businesses generate low-frequency asynchronous pulses. When a business pulse sequence is input into the edge cluster, the second business organization component of the intelligent deployment engine performs topology self-organization to generate a topology that matches the business, serving as the business structure. For example, for high real-time businesses such as train operation control, signal linkage, and positioning calculation, a star-shaped processing path centered on nodes with high computing power and low latency is generated; for inference pipeline businesses such as video recognition-tracking-alarm, a tree-like or hierarchical distributed processing topology is generated. Then, the intelligent deployment engine makes module instantiation deployment decisions within the generated topology. In this process, it analyzes the weights and thresholds of each business synapse, calculates the resource demand intensity of each microservice task module at the current moment, and combines the real-time resource status, node health, and geographical proximity of each candidate computing node in the topology to select the deployment node, number of instances, and affinity / anti-affinity constraints for each module, forming an executable deployment strategy. This deployment strategy includes at least the "module-node" mapping relationship, the number of instance replicas, resource quotas, priority and preemption rules, and disaster recovery and redundancy deployment requirements for critical businesses, thereby achieving adaptive integrated deployment of multiple business loads on the urban rail train at the edge.

[0023] Furthermore, this application provides, prior to developing an intelligent deployment engine in the resource platform, the following:

[0024] By using synaptic business modeling, each microservice task module is abstracted into a plastic business synapse. The weights dynamically represent the preference intensity and activation threshold of the microservice task module for different types of computing resources. Through intent pulse sequence encoding, business requirements are encoded into digital pulse sequences with spatiotemporal characteristics. High-priority, low-latency businesses generate high-frequency synchronous pulses, while batch computing businesses generate low-frequency asynchronous pulses. The pulse pattern drives the resource request behavior of the synapses.

[0025] Preferably, the resource platform first acquires the business attributes and operational constraints of each microservice task module. This information includes at least the business function type, business security level, real-time requirements, expected processing latency, throughput target, fault tolerance level, and preference for computing, storage, and network resources. Then, each microservice task module is abstracted into a malleable business synapse object. Each business synapse corresponds to a multi-dimensional weight vector, which represents resource dimensions such as CPU computing power, GPU or NPU computing power, memory capacity, storage read / write capability, and network bandwidth and latency sensitivity. Each weight value dynamically represents the microservice task module's preference for different types of computing resources. Simultaneously, an activation threshold is set for each resource dimension to indicate when the resource meets the threshold condition, triggering the business synapse and incorporating it into deployment decisions. For example, for high real-time services such as train operation control, signal linkage, and positioning calculation, a higher low-latency weight and a lower activation threshold are set; for video analysis and inference services, a higher GPU / NPU computing power weight is set; and for historical data statistics and energy consumption analysis services, a higher storage and batch processing throughput weight is set. The weights and thresholds of business synapses can be updated based on business configuration files and historical operational data. After completing the synaptic business modeling, the resource platform maps the functional requirements and performance constraints of microservice task modules into digital pulse sequences with spatiotemporal characteristics, based on the business intent of the microservice task modules. Specifically, business intent parameters, such as business type, priority level, security level, and real-time constraints, are extracted from the business description information of the microservice task modules. Then, based on the operational characteristics of different business types of urban rail trains, a mapping table between business intents and pulse parameters is established in the resource platform. Business priority and real-time performance are mapped to pulse frequency, business security level is mapped to pulse synchronization, data generation period is mapped to pulse interval, and business data scale and computational complexity are mapped to pulse duration or amplitude. For example, high-priority, low-latency urban rail train operation control, signal interaction, and emergency alarm services are encoded as high-frequency, synchronous pulse sequences to continuously trigger resource scheduling responses; video stream inference and online recognition services are encoded as medium-frequency, quasi-synchronous pulse sequences; and batch computation services such as equipment health assessment, log analysis, and statistical calculations are encoded as low-frequency, asynchronous pulse sequences.

[0026] Subsequently, the resource platform generates corresponding digital pulse sequences on the time axis according to the aforementioned mapping rules. By adjusting the frequency, period, duration, and phase relationship of the pulses, it reflects the service's requirements for response speed and continuous processing capabilities. High real-time services correspond to dense and short-interval pulse sequences, while low real-time or periodic services correspond to sparse and long-interval pulse sequences. Based on the generated digital pulse sequences, spatial identification information is added to each pulse. This spatial identification includes at least the train number, line number, section or station identifier, and the type of the service's source node. Through the binding of spatial identification, the pulse sequence not only expresses the urgency of the service but also indicates the service's processing location in the edge cluster. Then, the pulse sequence, with its time and spatial features encoded, serves as the final unified digital representation of the service intent. It acts as an input signal on the corresponding service synapse. The frequency, amplitude, and synchronization characteristics of the pulses are matched with the weight and activation threshold of the service synapse, thereby driving the service synapse to generate corresponding resource request behaviors. When the pulse intensity reaches or exceeds the activation threshold of a certain resource dimension, the business synapse is activated, outputting a clear resource demand signal to the intelligent deployment engine. When the pulse intensity decreases or the pulse interval becomes longer, the activation level of the business synapse decays accordingly, and the resource request intensity decreases synchronously. Through the synergistic effect of the above-mentioned synaptic modeling and intent pulse sequence encoding, differentiated perception, dynamic response, and adaptive resource requests of multiple service loads of urban rail trains in the edge computing environment are realized, providing a computable and evolvable input basis for subsequent topology self-organization and deployment decisions.

[0027] Furthermore, this application provides a method for developing an intelligent deployment engine within a resource platform, including:

[0028] For each edge computing node in the edge cluster, a service threshold defined by the deployment function is set. The service threshold includes a hardware abstraction layer, a resource scheduling layer, and an internal bus layer. The hardware abstraction layer is used to identify service pulse patterns, the resource scheduling layer is used to constrain computing, storage, and bandwidth resources, and the internal bus layer is used to determine the direction and efficiency of data processing flow. An intelligent deployment engine is composed of a first task encoding component based on digital pulse sequences, a second service organization component based on service thresholds, and a third deployment decision component based on service synapses.

[0029] Optionally, functionally defined service threshold components are first deployed on various edge computing nodes in the edge cluster, such as train-mounted computing units, platform-side edge servers, and trackside equipment-side computing nodes. These service thresholds are uniformly composed of a hardware abstraction layer, a resource scheduling layer, and an internal bus layer to achieve layered perception and control of service load. The hardware abstraction layer is deployed at the bottom layer of each edge computing node to uniformly abstract and perceive the node's local computing resources and access services. This hardware abstraction layer standardizes and encapsulates CPUs, GPUs or NPUs, memory, storage devices, and network interfaces. Simultaneously, it receives digital pulse sequence inputs to analyze the frequency, synchronization, and intensity of the pulses to identify the pulse pattern characteristics of the service. Through pulse pattern recognition, the hardware abstraction layer distinguishes between high-real-time train control and signal linkage services, medium-real-time video inference services, and low-real-time statistical and analysis services, and determines whether the node has the basic capability to support the corresponding services. The resource scheduling layer runs above the hardware abstraction layer. It is used to constrain and allocate computing, storage, and bandwidth resources based on the pulse patterns identified by the hardware abstraction layer and the current resource status of the nodes. The resource scheduling layer maintains the available quotas, usage thresholds, and preemption strategies for various resources within the nodes. Combined with the resource weight information carried by the service synapses, it sets differentiated resource allocation strategies for different service modules. For example, on the vehicle edge node, the resource scheduling layer prioritizes CPU and memory resources for high-security, high-real-time services such as train operation control and positioning calculation; on the platform edge node, it prioritizes computing power and bandwidth for video analysis and passenger flow statistics services; and on the trackside edge node, it focuses on ensuring low-latency communication and stable operation for signal acquisition, equipment monitoring, and alarm services. The internal bus layer manages the data processing flow and transmission efficiency within and between nodes. Based on the business pulse pattern and business type, the internal bus layer dynamically determines the data flow path between microservice instances within the node, and whether data needs to be forwarded to other edge nodes or upper-layer nodes for processing. For example, for high real-time control data generated by the vehicle, the internal bus layer prioritizes processing within the vehicle node; for platform video streams or trackside sensing data, the internal bus layer can guide the data to nearby platform nodes or trackside nodes for collaborative processing based on computing load, thereby optimizing overall processing latency and link occupancy.

[0030] Building upon the aforementioned business threshold mechanism, an intelligent deployment engine is constructed. This engine comprises a first task encoding component, a second business organization component, and a third deployment decision component. The first task encoding component receives business data and intent information from the resource platform, executes task encoding based on digital pulse sequences, generates business pulse sequences carrying spatiotemporal characteristics, and distributes them to the corresponding edge computing nodes. The second business organization component, based on the business threshold perception results returned by each edge computing node, uses lightweight metadata exchange to perceive the resource status, load level, and pulse matching of onboard, platform, and trackside nodes. This drives the business to self-organize within the edge cluster based on pulse pattern characteristics, forming a processing topology adapted to current business needs. The third deployment decision component, based on business synapses, analyzes the self-organized business topology, combines the resource capabilities, geographical proximity, and real-time operating status of each node, determines the specific deployment nodes, instance counts, and resource quotas for microservice task modules, and ultimately generates an executable deployment strategy. This enables collaborative perception, intelligent organization, and adaptive deployment among various types of edge computing nodes, including onboard, platform, and trackside nodes in urban rail transit.

[0031] Furthermore, this application provides a method for performing topological self-organization based on pulse pattern features, including:

[0032] The first task encoding component receives multi-threaded business data, performs encoding based on digital sequence pulses, and determines the business pulse sequence. When the business pulse sequence reaches the edge cluster, it triggers the second business organization component. The business threshold performs hierarchical state awareness through lightweight metadata exchange, performs business structure self-organization based on pulse pattern characteristics, and generates a business structure.

[0033] Optionally, when using the intelligent deployment engine for topology self-organization, the first task encoding component in the intelligent deployment engine first receives multi-threaded business data from the resource platform, such as train operation status and control data threads, signal and traffic permission data threads, and carriage and platform video data threads. The first task encoding component parses the data of each thread, extracting business characteristics such as the function type, priority, security level, real-time requirements, data generation cycle, and source location. Based on pre-established encoding rules, it distinguishes different businesses by adjusting the frequency, amplitude, duration, and synchronization relationship of the pulses, thereby generating a set of digital pulse sequences with time characteristics for the business data corresponding to each thread. These pulse sequences are the business pulse sequences, used to uniformly express the intensity of the business's demand for computing resources and response timeliness. Subsequently, when the service pulse sequence is sent and arrives at the edge cluster, the second service organization component of the intelligent deployment engine is triggered. At this time, the second service organization component distributes the corresponding service pulse sequence to each edge computing node. The pre-deployed service threshold component within each edge computing node parses the received pulse sequence. In this process, the hardware abstraction layer in the service threshold first identifies the frequency and synchronization characteristics of the pulse to determine whether the service belongs to the high real-time, medium real-time, or low real-time category. The resource scheduling layer assesses the node's capacity to carry the service based on the node's current computing, storage, and bandwidth resource status. The internal bus layer determines whether the data needs to be processed within the node or forwarded to other nodes based on the service type and node load. During the above process, each edge computing node reports status information such as node resource availability, load level, link latency, and pulse matching degree through a lightweight metadata exchange mechanism. The second service organization component aggregates and analyzes the status information from nodes at different levels.

[0034] During hierarchical state aggregation, the second business organization component performs hierarchical aggregation processing of state metadata according to the hierarchical structure of the edge cluster. Specifically, at the local level, the status of onboard nodes within the same train, platform nodes within the same station, or trackside nodes within the same section are aggregated first, and the average resource availability, load balancing, and service carrying capacity within that local area are calculated. At the regional level, the local aggregation results of multiple stations or sections are further merged to form a regional-level resource and load status. At the global level, the regional-level status of the entire edge cluster is integrated to form a global status covering onboard, platform, and trackside nodes. Through hierarchical aggregation, the hierarchical state perception result, which combines global and local data, retains the fine-grained status of local nodes while avoiding excessive communication and computational overhead caused by directly aggregating all data. Subsequently, based on the state awareness results, the second business organization component drives the business to perform a structural self-organization process in the edge cluster according to the pattern characteristics reflected by the business pulse sequence. That is, the second business organization component uses the frequency, synchronicity, and intensity reflected by the business pulse sequence as an expression of the business urgency and processing continuity, and uses the resource availability, load level, link latency, and geographical proximity of each level of nodes as structural constraints to dynamically reconstruct the business processing method at the logical level. In this process, the processing path or computing nodes of the business are not fixed in advance, but rather the set of computing nodes required for business processing and their connection relationships are adaptively selected according to the matching relationship between the business pulse and the node state: when the high frequency and synchronicity are the same, the business processing is not fixed in advance. When pulses continuously act on nodes with sufficient resource reserves and low link latency, business processing functions are preferentially aggregated on these nodes, forming a centralized or star-shaped computing structure with a few key nodes as the core and the shortest processing path. When pulses exhibit continuous but not strongly synchronous characteristics, and multiple nodes have complementary capabilities in computing power and bandwidth, business processing functions are split and distributed across multiple nodes. The processing order is automatically established between nodes according to data dependencies, gradually forming a pipelined or tree-like distributed computing structure. When pulses are sparse and asynchronous, and the business has low real-time requirements, business processing functions are guided to nodes with low resource load or caching capabilities, forming a loosely coupled computing structure with multi-level buffering and hierarchical processing characteristics. During the self-organization process, each node can adjust its participation level according to its own state changes and pulse input changes without centralized scheduling instructions. When the node load increases or link conditions deteriorate, its responsiveness to business pulses decreases, and business processing functions migrate to other more suitable nodes, thereby continuously evolving a dynamic computing structure that matches the current business characteristics within the edge cluster. The resulting business structure, as a dynamic computing structure adapted to the current business characteristics and resource status, provides clear structural constraints and decision-making basis for subsequent module instantiation deployment decisions and resource binding.

[0035] Furthermore, this application provides that if the pulse pattern is characterized by high real-time business type, the business structure is a star-shaped processing path centered on a strong computing layer; if the pulse pattern is characterized by inference pipeline business type, the business structure is a tree-like distributed processing topology; if the pulse pattern is characterized by data-intensive business type, the business structure is a multi-layer cache and preprocessing enclosing layer topology.

[0036] Preferably, after receiving the service pulse sequence, the second service organization component analyzes the frequency, synchronization, duration, and burstiness of the pulses, identifies the pulse pattern type of the current service, and classifies it into high real-time service type, inference pipeline service type, or data-intensive service type. At the same time, it associates the pulse pattern with the hierarchical state perception results to obtain the computing power, link latency, load level, and data locality information of each level node at the vehicle, platform, and trackside, providing constraints for the subsequent service structure generation.

[0037] When a pulse pattern is identified as a high-real-time service, the second service organization component prioritizes selecting the node level with strong computing power, low latency, and physical location closest to the service source as the core computing level, such as onboard edge nodes or nearby trackside edge nodes. Subsequently, a star-shaped processing path is constructed with this high-computing-level node as the central node. That is, the data acquisition, lightweight preprocessing, and result output modules are used as peripheral nodes, directly connected to the central node via the shortest link, forming a "direct data access - centralized computing - rapid feedback" structure. In this process, data forwarding across levels and regions is restricted, reducing intermediate processing steps, thereby meeting the deterministic latency and high reliability requirements of services such as train operation control and signal linkage.

[0038] When a pulse pattern is identified as belonging to an inference pipeline business, the second business organization component divides the business logic into multiple processing stages based on the continuity and phased characteristics of the pulse. It then selects multiple nodes with complementary resource capabilities within the edge cluster to form processing layers. For example, the data preprocessing stage is mapped to platform or trackside nodes close to the data source; the feature extraction and model inference stages are mapped to platform nodes with GPU or NPU computing power; and the result aggregation and alarm stages are mapped to edge nodes with lower loads. Next, parent-child relationships are established between nodes at each level according to the business processing order, forming a tree-like distributed processing topology. This allows data to flow and be processed step-by-step along the tree path, thereby achieving parallel processing and throughput optimization for inference pipeline businesses such as video analysis and target recognition.

[0039] When the pulse pattern is identified as indicative of a data-intensive business, the second business organization component focuses on analyzing the data scale, access frequency, and dependence on historical data. It prioritizes nodes with large storage capacity and stable bandwidth as the core data processing layer. Subsequently, a multi-layered caching and preprocessing enclosing layer is constructed around the core processing nodes. Nodes closer to the data source handle preprocessing functions such as data caching, filtering, and compression; intermediate nodes handle batch aggregation and preliminary analysis; and central nodes handle in-depth analysis or long-term storage access. This layered enclosing structure filters and aggregates large-scale data step-by-step, reducing cross-layer data transmission pressure and improving overall processing efficiency. It is suitable for business scenarios such as equipment health assessment, operational log analysis, and energy consumption statistics.

[0040] Finally, the second business organization component will output a business structure that matches the characteristics of the current business pulse pattern, based on the star-shaped processing path, tree-like distributed processing topology, or multi-layer cache and preprocessing enclosing layer topology generated by the above process. This business structure will then be provided to the subsequent module instantiation and deployment decision component to determine the specific deployment location and resource allocation method of the microservice task module in the edge cluster.

[0041] Furthermore, this application provides a method for making module instantiation deployment decisions within the topology structure and determining deployment strategies, including:

[0042] After obtaining the business structure, the resource demand intensity of each microservice task module is determined by parsing the weight parameters of the business synapses. Based on the resource demand intensity, business synapse mapping relationship and real-time resource status, a deployment strategy is determined, with the deployment of each abstract microservice task module in the computing nodes of the business structure serving as the decision guide.

[0043] Optionally, after the second business organization component generates a business structure that matches the business characteristics, the third deployment decision component obtains this business structure as input. This business structure clarifies the current business's computational hierarchy, node role division, and data flow relationships within the edge cluster, such as core computing nodes, auxiliary processing nodes, and edge access nodes. Based on this, the third deployment decision component calls the corresponding business synapse for each microservice task module involved in the business structure to parse its weight parameters. These weight parameters are multi-dimensional vectors, corresponding to resource dimensions such as computing power, storage capacity, network bandwidth, latency sensitivity, and reliability requirements. By calculating the weight values ​​of each dimension and their activation thresholds, the resource demand intensity of the microservice task module in the current business scenario is obtained, which is used to quantitatively represent the module's comprehensive demand level for different resources. Subsequently, the third deployment decision component, combining the business synapse mapping relationship, matches the logical processing nodes in the business structure with the actual edge computing nodes. This business synapse mapping relationship describes the adaptation constraints between microservice task modules and the roles of each computing node in the business structure. For example, which modules must be deployed on nodes close to the data source, which modules are suitable for deployment on nodes with accelerated computing power, and which modules can be distributed across nodes. During this process, the third deployment decision component synchronously obtains real-time resource status information for each edge computing node. This real-time resource status information includes at least the node's available CPU / GPU / NPU computing power, remaining memory capacity, available bandwidth, current load level, node health status, and the physical location level of the node. After integrating the above information, the third deployment decision component, guided by the deployment of microservice task modules on computing nodes in the business structure, executes the deployment strategy generation process. Specifically, for each microservice task module, edge computing nodes that meet its resource requirements and activation thresholds are prioritized from the set of computing nodes that match its functional role within the business structure. If multiple candidate nodes exist, they are ranked according to real-time resource status, prioritizing nodes with high resource matching, low load, low link latency, and satisfactory reliability for deployment. Simultaneously, based on resource requirements and business importance, the number of instances, replica distribution, and resource quota for the microservice task module are determined to ensure sufficient redundancy and stability for critical business modules. Finally, the third deployment decision component organizes the above decisions into a deployment strategy output. This strategy includes at least the mapping relationship between microservice task modules and edge computing nodes, the number of instances for each module, resource quota parameters, and necessary affinity or anti-affinity deployment constraints. Through this process, the synergy between the business structure, business synapse model, and real-time resource status is achieved, enabling multi-service workloads to be instantiated and deployed in a structured, controllable, and adaptive manner within the urban rail train edge computing environment.

[0044] A container orchestration engine is used to perform resource binding and containerized deployment based on the deployment strategy, and to perform control and management under continuous operation monitoring.

[0045] In one embodiment, the deployment policy generated by the third deployment decision component is sent to the resource platform, where it is parsed and converted into resource orchestration description information recognizable by the container orchestration engine. This description information includes at least the image identifier of the microservice task module, the number of instance replicas, the target edge computing node type and specific node identifier, CPU / GPU / NPU computing power quota, memory and storage quota, network bandwidth limit, priority level, and other parameters. Subsequently, the container orchestration engine performs resource binding and containerization deployment within the edge cluster based on this orchestration description information to improve the system's fault tolerance and operational reliability. After containerization deployment is completed, the system enters the continuous operation monitoring and control management phase. In this phase, the resource platform, in collaboration with the container orchestration engine and each edge computing node, continuously collects the status information of each microservice task module during operation to evaluate the actual operational performance and resource utilization efficiency of the microservice task modules. When monitoring results show that the actual resource utilization efficiency of a certain microservice task module deviates from its expected business synapse performance, the resource platform triggers a control and management process. This process includes, but is not limited to, adjusting container resource quotas, increasing or decreasing the number of instance replicas, migrating container instances to other edge computing nodes, or reorganizing the business structure. For example, for critical business modules with persistently high loads or excessive latency, resource quotas are increased or replica instances are added; for modules with low resource utilization, resource quotas are reduced or instances are merged; and for abnormal operation or decreased node health, container instance restart, migration, or redeployment operations are triggered. Through the above-mentioned control and management under continuous operation monitoring, dynamic optimization and long-term stability assurance of multi-service workloads of urban rail trains in the edge computing environment are achieved.

[0046] Furthermore, this application provides resource binding and containerized deployment based on the aforementioned deployment strategy, and performs control and management under continuous operation monitoring, including:

[0047] The deployment strategy is compiled into resource orchestration instructions, and a container orchestration engine is used to perform resource binding and containerized deployment. After deployment is completed, the synaptic performance continuous monitoring and dynamic adjustment loop of the business synapse is activated to continuously monitor the actual resource utilization efficiency of each microservice task module in the running process, and perform business synapse pruning and regeneration management.

[0048] Preferably, the deployment strategy output by the third deployment decision component describes the mapping relationship between microservice task modules and computing nodes in the business structure in an abstract form. The resource platform parses this deployment strategy and compiles it into resource orchestration instructions that the container orchestration engine can directly execute. These resource orchestration instructions include, but are not limited to, container image pull instructions, instance creation instructions, instance replica quantity configuration instructions, computing resource quota configuration instructions, storage mounting instructions, network bandwidth and priority configuration instructions, and node affinity and anti-affinity constraint instructions. Through this compilation process, the transformation from policy-level description to execution-level instructions is achieved. Subsequently, the container orchestration engine receives these resource orchestration instructions and performs resource binding and containerized deployment within the edge cluster. Specifically, the container orchestration engine reserves and binds the corresponding computing, storage, and network resources on the target vehicle-mounted, station-based, or railside edge computing nodes according to the instructions. After the resource binding is completed, it pulls the corresponding microservice container image, creates and starts the container instance, enabling each microservice task module to run in a containerized form on the specified node. When the deployment strategy includes replica deployment or redundancy requirements, the container orchestration engine synchronously completes the distributed creation and startup of multiple instances, and configures load balancing and failover between instances. After containerized deployment is completed and enters a stable operating state, the resource platform activates a continuous monitoring and dynamic adjustment loop for synapse performance based on business synapses. This loop periodically or in real-time collects the actual operating metrics of each microservice task module during its running process, such as CPU / GPU / NPU utilization, memory and storage usage, network bandwidth utilization, end-to-end processing latency, throughput, and business success rate. The collected operating metrics are compared and analyzed with the preset weight parameters and activation thresholds in the business synapses to evaluate the actual discharge efficiency of the business synapses, i.e., the degree of matching between resource input and business output. When monitoring results indicate that a certain business synapse is inefficient for an extended period, the dynamic adjustment loop triggers business synapse pruning management. The corresponding microservice task module will perform operations such as resource reclamation, instance reduction, or function merging to reduce resource waste. When monitoring results indicate that a certain business synapse is consistently efficient or its workload increases significantly, the dynamic adjustment loop triggers business synapse regeneration management. This is achieved by increasing synapse weight, increasing the number of instance replicas, or introducing new computing nodes into the business structure to positively enhance resource capabilities. Through the continuous monitoring and dynamic adjustment loop of synapse performance, the multi-service workload of urban rail trains can achieve self-optimization, self-adaptation, and stable collaboration during long-term operation in an edge computing environment.

[0049] Furthermore, this application provides a method to dynamically fine-tune the resource weight allocation of each business synapse based on the deviation between the actual discharge efficiency and the preset performance threshold. The actual discharge efficiency is defined based on the throughput-latency ratio. For consistently high-efficiency synapses, the resource allocation priority of the corresponding microservice task module is increased to form positive reinforcement. For inefficient synapses, a resource renegotiation or instance reconstruction process is triggered to perform local performance self-optimization.

[0050] Optionally, during the operation of the microservice task module, the resource platform continuously collects operational metrics corresponding to business synapses to characterize business throughput and end-to-end processing latency from service request access to output result. Based on these operational metrics, according to preset calculation rules, the actual discharge efficiency of each business synapse is calculated. This actual discharge efficiency is the ratio of business throughput metrics to business latency metrics, used to reflect the business processing capacity under unit latency conditions, thus forming a quantifiable performance evaluation result. Subsequently, the resource platform compares the calculated actual discharge efficiency with the pre-set performance threshold in the corresponding business synapse, calculating the deviation between the two. When the actual discharge efficiency is higher than the performance threshold and remains stable, the business synapse is determined to be in a high-efficiency state; when the actual discharge efficiency is lower than the performance threshold or shows a continuous downward trend, the business synapse is determined to be in an inefficient state. To avoid misjudgments caused by short-term fluctuations, the resource platform can perform sliding window statistics or weighted average analysis on the deviation over multiple continuous monitoring periods to ensure the stability of adjustment decisions.

[0051] When a synapse is determined to be consistently efficient, the resource platform triggers a positive reinforcement adjustment process. This process dynamically fine-tunes the resource weight allocation parameters of the synapse, increasing its priority in resource scheduling. For example, it increases the weight coefficient of CPU, GPU, or bandwidth resources, lowers the resource preemption threshold, or relaxes replica expansion restrictions. Simultaneously, at the deployment level, it allocates more stable computing nodes or increases the number of instance replicas to the corresponding microservice task module to enhance its consistently efficient operation capabilities, thus forming a positive reinforcement mechanism based on operational performance. When a synapse is determined to be inefficient, the resource platform triggers a resource renegotiation or instance reconstruction process. The resource renegotiation process includes reassessing the resource demand intensity and actual occupancy of the microservice task module, dynamically reducing its resource weight, compressing resource quotas, or adjusting its running nodes to reduce resource waste. The instance reconstruction process includes merging, splitting, or migrating microservice instances, reorganizing their position in the business structure, and, if necessary, re-triggering the business structure self-organization and deployment decision process. Through these localized adjustment methods, inefficient business synapses can achieve performance self-optimization without affecting overall business continuity. Ultimately, by continuously and iteratively executing the above-mentioned discharge efficiency calculation, deviation analysis, and resource weight adjustment processes, the resource allocation strategy of each service synapse can dynamically evolve with the changes in the urban rail train service load. This ensures the stable operation of high-priority services while improving the overall utilization efficiency of edge computing resources and system performance.

[0052] Furthermore, this application provides a method to generate a removal instruction when the first task synapse is detected to be in an inefficient state, with business logic continuity as a rigid constraint, to remove the microservice task module corresponding to the inefficient task synapse; and to perform structural point rematching and module instantiation within the task structure based on synapse weight and historical success patterns.

[0053] Optionally, during continuous monitoring, the resource platform periodically evaluates the actual discharge efficiency of each business synapse. When it detects that the first task synapse is consistently below its preset efficiency threshold for multiple consecutive monitoring periods, and remains stably inefficient even after sliding window smoothing, it marks the first task synapse as a persistently inefficient synapse and triggers an exception handling process. Subsequently, the resource platform analyzes and verifies the role of the microservice task module corresponding to the first task synapse in the current business structure to determine whether it belongs to a business critical path or a safety critical module. If the module has upstream and downstream dependencies, it uses dependency graph analysis to confirm whether there are alternative module instances or redundant processing paths to ensure that its removal will not cause interruptions to core businesses such as train operation control, signal linkage, or safety monitoring. Only when the business logic continuity constraint is met will the resource platform generate a removal instruction for the inefficient task synapse. After successful verification, the resource platform issues a removal command to the container orchestration engine, performing an ordered removal operation on the microservice task modules corresponding to inefficient task synapses. This ordered removal includes stopping data access for the module instance, completing in-transit data processing, releasing the computing and network resources it occupies, and ultimately terminating the corresponding container instance. During the removal process, the resource platform synchronously updates the business structure and synapse mapping relationship to prevent the continued distribution of business data to the removed modules during subsequent scheduling. After the inefficient module removal is completed, the resource platform performs a rematching of structure points and module instantiation based on the current task structure. Specifically, the resource platform re-evaluates the carrying capacity of each computing structure node based on the weight parameters of the remaining business synapses, and combines successful deployment patterns and efficient synapse combinations recorded in historical operations to select structure points with higher adaptability as new module carrying locations. Then, the corresponding microservice task modules are re-instantiated and deployed on the selected structure points, including determining the new deployment nodes, the number of instances, and resource quotas. By introducing historical successful patterns as reference constraints, the deployment of new instances is made more in line with past stable operating experience, thereby improving the stability and performance of the reconstructed business structure. Ultimately, through the aforementioned inefficient task synapse removal and structural rematching process, the self-repair and optimization evolution of the business structure can be achieved without disrupting the continuity and security of urban rail train business logic, ensuring the robustness and resource utilization efficiency of the edge computing system in long-term operation.

[0054] In summary, the embodiments of this application have at least the following technical effects:

[0055] This application first uses microservice task modules as the business submission method to submit multi-threaded business data to the resource platform. Then, an intelligent deployment engine is developed in the resource platform. By abstracting business data into weighted business synapses, pulse-coded business functions and performance requirements are used to drive business thresholds to perform topology self-organization based on pulse pattern characteristics. Module instantiation deployment decisions are made within this topology to determine the deployment strategy. Finally, a container orchestration engine is used to perform resource binding and containerized deployment based on the deployment strategy, and to execute control and management under continuous operation monitoring. These technical effects collectively solve the technical problems of low resource utilization efficiency and rigid deployment decisions caused by large differences in multi-service load types and dynamic changes in business requirements in edge computing scenarios. It achieves the technical effect of dynamically and accurately generating and continuously optimizing deployment strategies through neural-inspired pulse coding and self-organization mechanisms, improving edge resource utilization, and ensuring service quality and real-time performance of multi-service mixed loads.

[0056] Example 2, based on the same inventive concept as the multi-service load integration control deployment method for edge computing in the foregoing examples, such as... Figure 2 As shown, this application provides a multi-service load integration control and deployment system for edge computing. The system includes: a data submission unit 11, which submits multi-threaded business data to a resource platform in the form of microservice task modules; a strategy decision unit 12, which develops an intelligent deployment engine in the resource platform, abstracts business data into weighted business synapses, performs pulse-based encoding of business functions and performance requirements, drives business thresholds to perform topology self-organization based on pulse pattern characteristics, makes module instantiation deployment decisions in the topology, and determines the deployment strategy; and a control and management unit 13, which uses a container orchestration engine to perform resource binding and containerized deployment based on the deployment strategy, and performs control and management under continuous operation monitoring.

[0057] Furthermore, the strategy decision-making unit 12 is also configured to perform the following method:

[0058] By using synaptic business modeling, each microservice task module is abstracted into a plastic business synapse. The weights dynamically represent the preference intensity and activation threshold of the microservice task module for different types of computing resources. Through intent pulse sequence encoding, business requirements are encoded into digital pulse sequences with spatiotemporal characteristics. High-priority, low-latency businesses generate high-frequency synchronous pulses, while batch computing businesses generate low-frequency asynchronous pulses. The pulse pattern drives the resource request behavior of the synapses.

[0059] Furthermore, the strategy decision-making unit 12 is also configured to perform the following method:

[0060] For each edge computing node in the edge cluster, a service threshold defined by the deployment function is set. The service threshold includes a hardware abstraction layer, a resource scheduling layer, and an internal bus layer. The hardware abstraction layer is used to identify service pulse patterns, the resource scheduling layer is used to constrain computing, storage, and bandwidth resources, and the internal bus layer is used to determine the direction and efficiency of data processing flow. An intelligent deployment engine is composed of a first task encoding component based on digital pulse sequences, a second service organization component based on service thresholds, and a third deployment decision component based on service synapses.

[0061] Furthermore, the strategy decision-making unit 12 is also configured to perform the following method:

[0062] The first task encoding component receives multi-threaded business data, performs encoding based on digital sequence pulses, and determines the business pulse sequence. When the business pulse sequence reaches the edge cluster, it triggers the second business organization component. The business threshold performs hierarchical state awareness through lightweight metadata exchange, performs business structure self-organization based on pulse pattern characteristics, and generates a business structure.

[0063] Furthermore, the strategy decision-making unit 12 is also configured to perform the following method:

[0064] If the pulse pattern is characterized by high real-time business, the business structure is a star-shaped processing path centered on a strong computing layer; if the pulse pattern is characterized by inference pipeline business, the business structure is a tree-like distributed processing topology; if the pulse pattern is characterized by data-intensive business, the business structure is a multi-layered cache and preprocessing enclosing layer topology.

[0065] Furthermore, the strategy decision-making unit 12 is also configured to perform the following method:

[0066] After obtaining the business structure, the resource demand intensity of each microservice task module is determined by parsing the weight parameters of the business synapses. Based on the resource demand intensity, business synapse mapping relationship and real-time resource status, a deployment strategy is determined, with the deployment of each abstract microservice task module in the computing nodes of the business structure serving as the decision guide.

[0067] Furthermore, the control and management unit 13 is also used to perform the following method:

[0068] The deployment strategy is compiled into resource orchestration instructions, and a container orchestration engine is used to perform resource binding and containerized deployment. After deployment is completed, the synaptic performance continuous monitoring and dynamic adjustment loop of the business synapse is activated to continuously monitor the actual resource utilization efficiency of each microservice task module in the running process, and perform business synapse pruning and regeneration management.

[0069] Furthermore, the control and management unit 13 is also used to perform the following method:

[0070] Based on the deviation between the actual discharge efficiency of each business synapse and the preset performance threshold, the resource weight allocation is dynamically fine-tuned. The actual discharge efficiency is defined based on the throughput-latency ratio. For consistently high-efficiency synapses, the resource allocation priority of the corresponding microservice task module is increased to form positive reinforcement. For inefficient synapses, resource renegotiation or instance reconstruction process is triggered to perform local performance self-optimization.

[0071] Furthermore, the control and management unit 13 is also used to perform the following method:

[0072] When the first task synapse is detected to be in an inefficient state, a removal instruction is generated with business logic continuity as a rigid constraint to remove the microservice task module corresponding to the inefficient task synapse; based on the synapse weight and historical success pattern, structural point rematching and module instantiation are performed within the task structure.

[0073] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this specification. The processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are possible or may be advantageous.

[0074] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0075] This specification and accompanying drawings are merely illustrative examples of this application and are intended to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from its scope. Therefore, if such modifications and modifications fall within the scope of this application and its equivalents, this application intends to include such modifications and modifications.

Claims

1. A multi-service load integration control deployment method for edge computing, characterized in that, The method includes: Using microservice task modules as the business submission method, multi-threaded business data is submitted to the resource platform; Develop an intelligent deployment engine in the resource platform. By abstracting business data into weighted business synapses, pulse-encode business function and performance requirements, drive business thresholds to perform topology self-organization based on pulse pattern characteristics, and make module instantiation deployment decisions in the topology to determine the deployment strategy. A container orchestration engine is used to perform resource binding and containerized deployment based on the deployment strategy, and to perform control and management under continuous operation monitoring. Prior to developing the intelligent deployment engine in the resource platform, the following steps were taken: By using synaptic business modeling, each microservice task module is abstracted into a plastic business synapse, where the weights dynamically represent the strength of the microservice task module's preference for different types of computing resources and the activation threshold. By using intent pulse sequence encoding, business requirements are encoded into digital pulse sequences with spatiotemporal characteristics. High-priority, low-latency services generate high-frequency synchronous pulses, while batch computing services generate low-frequency asynchronous pulses. The pulse pattern drives the resource request behavior of the synapse. Among these, the development of an intelligent deployment engine in the resource platform includes: For each edge computing node in the edge cluster, a service threshold defined by the deployment function is set. The service threshold includes a hardware abstraction layer, a resource scheduling layer, and an internal bus layer. The hardware abstraction layer is used to identify service pulse patterns, the resource scheduling layer is used to constrain computing, storage, and bandwidth resources, and the internal bus layer is used to determine the direction and efficiency of data processing flow. The intelligent deployment engine is composed of a first task encoding component based on digital pulse sequences, a second business organization component based on business thresholds, and a third deployment decision component based on business synapses. Among them, the topological self-organization based on pulse pattern characteristics includes: The first task encoding component receives multi-threaded service data, performs encoding based on digital sequence pulses, and determines the service pulse sequence; When the business pulse sequence reaches the edge cluster, it triggers the second business organization component. The business threshold performs hierarchical state awareness through lightweight metadata exchange, executes business structure self-organization based on pulse pattern characteristics, and generates a business structure.

2. The multi-service load integration control deployment method for edge computing as described in claim 1, characterized in that, If the pulse pattern is characterized as a high real-time service type, the service structure is a star-shaped processing path centered on a strong computing layer; If the pulse pattern characteristic is an inference pipeline business type, the business structure is a tree-like distributed processing topology; If the pulse pattern is characterized as a data-intensive business type, the business structure is a multi-layered cache and preprocessing enclosing layer topology.

3. The multi-service load integration control deployment method for edge computing as described in claim 2, characterized in that, Decisions on module instantiation and deployment are made within the topology to determine the deployment strategy, including: After obtaining the business structure, the resource demand intensity of each microservice task module is determined by parsing the weight parameters of the business synapses. Based on the resource demand intensity, business synapse mapping relationship and real-time resource status, a deployment strategy is determined, with the deployment of each abstract microservice task module on the computing nodes in the business structure serving as the decision guide.

4. The multi-service load integration control deployment method for edge computing as described in claim 1, characterized in that, Perform resource binding and containerized deployment based on the aforementioned deployment strategy, and implement control and management under continuous operation monitoring, including: The deployment strategy is compiled into resource orchestration instructions, and a container orchestration engine is used to perform resource binding and containerized deployment. Once deployment is complete, the synaptic performance monitoring and dynamic adjustment loop of the activated business synapses will be continuously monitored to ensure the actual resource utilization efficiency of each microservice task module during operation, and business synapse pruning and regeneration management will be performed.

5. The multi-service load integration control deployment method for edge computing as described in claim 4, characterized in that, Based on the deviation between the actual discharge efficiency of each service synapse and the preset performance threshold, the resource weight allocation is dynamically fine-tuned, wherein the actual discharge efficiency is defined based on the throughput-to-latency ratio. Specifically, for consistently efficient synapses, the resource allocation priority of the corresponding microservice task module is increased to form positive reinforcement; for inefficient synapses, resource renegotiation or instance reconstruction process is triggered to perform local performance self-optimization.

6. The multi-service load integration control deployment method for edge computing as described in claim 5, characterized in that, When the first task synapse is detected to be in an inefficient state, a removal instruction is generated with business logic continuity as a rigid constraint to remove the microservice task module corresponding to the inefficient task synapse. Based on synaptic weights and historical success patterns, perform re-matching of structural points and module instantiation within the task structure.

7. A multi-service load balancing control and deployment system for edge computing, characterized in that, The system is used to execute the multi-service load integration control and deployment method for edge computing as described in any one of claims 1-6, the system comprising: Data submission unit: Using microservice task modules as the business submission method, multi-threaded business data is submitted to the resource platform; Strategy Decision Unit: Develops an intelligent deployment engine in the resource platform. By abstracting business data into weighted business synapses, it performs pulse-based coding of business functions and performance requirements, drives business thresholds to perform topology self-organization based on pulse pattern characteristics, and makes module instantiation deployment decisions in the topology to determine the deployment strategy. Control and management unit: It uses a container orchestration engine to perform resource binding and containerized deployment based on the deployment strategy, and performs control and management under continuous operation monitoring.

Images