Distributed application runtime system with edge-cloud collaboration

Abstract

This invention proposes a distributed application runtime system with edge-cloud collaboration. The system includes at least the following components at the device, edge, and cloud levels: a resource proxy; an executor resource pool containing at least one executor, each configured with a corresponding resource proxy and interacting with it; the at least one executor generates computational tasks during runtime; and upon receiving a computational task offloading request, the resource proxy relocates the corresponding computational task execution schedule. This system proactively adapts to real-time changes in application resource requirements, improving the stability of the computing platform's performance and service quality.

Description

Technical Field

[0001] This invention belongs to the field of distributed computing technology, specifically relating to a distributed application runtime system that integrates edge-cloud collaboration. Background Technology

[0002] With the advent of the era of the Internet of Things (IoT), terminal devices are gradually becoming deeply integrated into human life. Simultaneously, the rapid development of artificial intelligence is leading to the emergence of new intelligent application scenarios that integrate with the physical world, such as vehicle-to-everything (V2X) and autonomous driving, and smart homes. This has spurred the development of numerous new intelligent applications embedded in terminal devices, such as mobile video editing, VR game 3D generation, and autonomous driving object detection. Because these applications use complex algorithms such as neural networks, graph operations, and vector operations, they typically have high computing power requirements. This means that an increasing number of high-computing-power applications will run on IoT systems.

[0003] Thanks to advancements in computing technology, the application of computers has expanded from desktops and mainframes to a wide range of mobile and embedded devices, including surveillance cameras, environmental sensors, GPS navigation systems, smartphones, VR headsets, autonomous robots, and self-driving cars. These devices are typically limited by environmental factors such as power consumption and size. For example, smartphone power consumption is limited by battery power, and VR headsets are constrained by device weight. Consequently, the processors, storage, and other components in these devices often have relatively weak performance and limited resources.

[0004] As application computing power demands continue to increase, and users increasingly demand device portability, the contradiction between the computing power requirements of complex programs and the availability of limited resources is widening. To alleviate this contradiction, offloading computing power is widely adopted as an effective means to improve performance and reduce power consumption. Offloading computing power refers to migrating computing tasks originally performed on physical devices to remote devices or servers for execution. Traditional cloud computing paradigms divide applications into thin clients and servers, with clients initiating RPC or REST network requests to call specific methods on the server side within the cloud data center. However, with the explosive growth of terminal devices, massive computing tasks are being initiated from the network edge, representing an order-of-magnitude increase compared to the traditional internet, posing a significant challenge to programming paradigms and information infrastructure. Simultaneously, the real-time requirements of terminal applications are constantly increasing, and the traditional centralized computing paradigm of cloud computing can no longer meet the real-time processing needs of applications.

[0005] As more resource-constrained edge devices connect to the network and new application scenarios place higher demands on computing power, the contradiction between computing power demand and limited resources is intensifying. The edge-cloud collaborative computing paradigm meets the computing power and real-time requirements of edge intelligent applications by offloading high-computing-power-demand processes from edge or cloud environments to resource-rich locations. However, current edge-cloud collaborative computing systems often cannot proactively adapt to real-time changes in application resource demands, nor can they allocate computing resources to computational requests that generate resource demands. This leads to a mismatch between resource allocation and resource demand, resulting in decreased computing platform performance and unstable service quality. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention proposes a distributed application runtime system for edge-cloud collaboration in a cloud-edge distributed environment. This system solves the problem that current edge-cloud collaborative computing systems cannot proactively adapt to real-time changes in application resource requirements and cannot allocate computing resources to computing requests that generate resource demands, resulting in a mismatch between resource allocation and resource demand, which leads to a decline in computing platform performance and unstable service quality.

[0007] To achieve the above objectives, the present invention provides a distributed application runtime system for edge-cloud collaboration, wherein the device, edge, and cloud are each configured with at least:

[0008] Resource proxy,

[0009] An executor resource pool contains at least one executor, which is configured with a corresponding resource agent and interacts with the resource agent.

[0010] At least one executor generates computational tasks during runtime;

[0011] After receiving a request to unload a computing task, the resource agent will schedule and migrate the corresponding computing task.

[0012] In one embodiment, each executor corresponds to a container instance, and the container instance is used to achieve isolation of the execution environment.

[0013] In one embodiment, based on the type of resource agent, executors are divided into two categories: executors created by the primary resource agent and executors created by the secondary resource agent.

[0014] For an executor created by the main resource broker, the container instance corresponding to the executor starts executing the main logic function and begins processing the application's business logic. This container instance is responsible for maintaining the entire application's lifecycle. When the container exits, the entire application execution ends.

[0015] For an executor created by a resource agent, the container instance corresponding to the executor enters the event loop after startup, continuously waiting for the resource agent to initiate the unloading of computing tasks to the executor.

[0016] In one embodiment, after receiving the computing task offload request, QoS requirements are extracted from the summary information of the computing task;

[0017] Based on the QoS requirements of the computation task and the resource agent status view, all resource agents are screened and selected for the best one.

[0018] Select a resource proxy that meets the QoS requirements as the target resource proxy, and offload the computing task to the target resource proxy.

[0019] In one embodiment, if no resource proxy meets the QoS requirement, a new resource proxy is created; and during the initialization of the new resource proxy, it is continuously observed whether other resource proxies meet the QoS requirement. If so, the computing task is directly unloaded to the resource proxy that meets the QoS requirement.

[0020] In one embodiment, the resource agent queues each computing task submitted to it in the order of submission and determines the estimated waiting time for a newly added computing task. The estimated waiting time is the sum of the estimated execution time of all computing tasks in the queue except for the newly added computing task and the estimated remaining time of the currently executing computing task.

[0021] In one embodiment, the task flow adopts an overall bottom-up unloading approach from the device to the cloud. The device can be unloaded to the edge and the cloud, the edge can be unloaded to the edge and the cloud, and the cloud can only be unloaded to the cloud.

[0022] The state flow is only the synchronization of its own state from the edge to the object and with the edge;

[0023] Data flows freely from the device, the edge, and the cloud.

[0024] In one embodiment, when scheduling computing tasks from the device to the edge,

[0025] Based on the QoS requirements of the computing task, target resource proxies that meet the QoS requirements are selected from the existing set of resource proxies at the edge.

[0026] If the target resource agent exists, the computing task is directly submitted to the corresponding target resource agent, which then receives the computing task and executes the unloading process.

[0027] If the target resource proxy does not exist, it will attempt to select a suitable node from the edge to apply for the creation of a new resource proxy. After the application is initiated, it will not wait for the new resource proxy to be created, but will directly throw the computing task to the resource proxy in the cloud to perform the unloading process.

[0028] In one embodiment, when scheduling a computing task, if it is found that the waiting time from the submission of the computing task to the present exceeds the QoS tolerance time of the computing task, the computing task is directly thrown to the cloud resource agent to perform the unloading process.

[0029] In one embodiment, if a resource agent at the edge receives a computing task and, when attempting to insert it into the task queue, finds that the current resource agent can no longer meet the QoS requirements of the computing task, it will re-initiate a scheduling request.

[0030] In one embodiment, the device, edge, and cloud are further configured with:

[0031] The interface server, which communicates with the resource broker, contains multiple types of function processors that receive computation task offloading requests.

[0032] In one embodiment, the device, edge, and cloud are further configured with: a resource proxy manager that communicates with the interface server, a resource proxy, and an executor resource pool, for creating or destroying the resource proxy and the executor resource pool.

[0033] In one embodiment, the device, edge, and cloud are further configured with: a cluster status cache, which communicates with the interface server and a resource proxy, for receiving device resource status information and resource proxy status information.

[0034] In one embodiment, the device, edge, and cloud are further configured with: a processor manager, which communicates with the interface server and a resource agent, to be responsible for local physical resource management, including the creation and recycling of processors.

[0035] As can be seen from the above solutions, the advantages of the present invention are:

[0036] This invention discloses a distributed application runtime system with edge-cloud collaboration. Addressing the mismatch between resource demand and allocation, it sets the basic granularity of resource allocation to computational requests that generate resource demands, and provides a spatiotemporally isolated execution environment. Resource allocation employs a QoS-aware proactive adaptation approach, with resource proxies dynamically adapting to received computational tasks, enabling dynamic on-demand expansion of application resource space. This system proactively adapts to real-time changes in application resource demands, improving the stability of computing platform performance and service quality. Attached Figure Description

[0037] Figure 1The overall architecture diagram of the distributed application runtime system with edge-cloud collaboration is shown.

[0038] Figure 2 The loading methods for the primary and secondary resource proxies are shown.

[0039] Figure 3 This diagram illustrates the principle of QoS-aware task scheduling.

[0040] Figure 4 The system edge-cloud communication flow diagram is shown;

[0041] Figure 5 A schematic diagram of edge-cloud deployment is shown;

[0042] Figure 6 The average end-to-end latency for each platform is shown;

[0043] Figure 7 The 95th percentile values ​​of end-to-end latency for each platform are shown;

[0044] Figure 8 The standard deviation of end-to-end latency for each platform is shown.

[0045] In the attached figures, the following labels are used:

[0046] A1-Object Terminal

[0047] A2-Edge

[0048] A3-Cloud

[0049] 10-Interface Server

[0050] 20-Resource Proxy Manager

[0051] 30-Cluster State Cache

[0052] 40-Processor Manager

[0053] 41-Processor

[0054] 50-Actuator Resource Pool

[0055] 51-Actuator

[0056] 60-Resource Agent

[0057] 71 - Container Example. Detailed Implementation

[0058] To make the above features and effects of the present invention clearer and easier to understand, specific embodiments are described below, and detailed descriptions are provided in conjunction with the accompanying drawings.

[0059] See Figures 1-8 As shown, Figure 1This diagram illustrates the overall architecture of a distributed application runtime system that integrates edge-cloud collaboration. Figure 2 This illustrates the loading methods for the primary and secondary resource proxies. Figure 3 This diagram illustrates the principle of QoS-aware task scheduling. Figure 4 The system edge-cloud communication flow diagram is shown. Figure 5 A schematic diagram of edge-cloud deployment is shown. Figure 6 The average end-to-end latency for each platform is shown. Figure 7 The 95th percentile values ​​of end-to-end latency for each platform are shown. Figure 8 The standard deviation of end-to-end latency for each platform is shown.

[0060] Please see Figure 1 As shown, a distributed application runtime system with end-edge-cloud collaboration is configured with the following components at the device A1, edge A2, and cloud A3: interface server 10, resource proxy manager 20, cluster state cache 30, processor manager 40, executor resource pool 50, and resource proxy 60. Among them:

[0061] Interface server 10 includes multiple function processors such as StubHdlr, StubMgrHdlr, and ClsStatMgrHdlr, which are used to receive computing task unloading requests, data acquisition requests, etc.

[0062] The resource proxy manager 20 interacts with the StubMgrHdlr function processor, resource proxy 60, and executor resource pool 50 of the interface server 10 to create or destroy resource proxies and executor resource pools.

[0063] The cluster state cache 30 communicates with the ClsStatMgrHdlr function processor of the interface server 10 and the resource agent 60 to receive device resource status information and resource agent status information.

[0064] The processor manager 40 communicates with the interface server 10 and the resource agent 60 to manage local physical resources, including the creation and recycling of processors. A processor 41 points to a cgroup, which contains available CPU cores, etc.

[0065] The executor resource pool 50 contains at least one executor 51, which is configured with a corresponding resource agent 60 and interacts with the resource agent 60. It supports the resource agent in requesting and returning executors to the executor, thus enabling executor reuse.

[0066] Resource agent 60 communicates with the StubHdlr function processor, resource agent manager 20, cluster state cache 30, processor manager 40, and executor resource pool 50 of the interface server 10 to receive task unloading, execute computing tasks, and respond with computing results.

[0067] In this embodiment, executor 51 provides an isolated execution environment for the application. One executor corresponds to one container instance 71, meaning that the system achieves execution environment isolation through container instances. Furthermore, each executor has its own resource agent within the distributed application runtime environment and continuously interacts with this resource agent to perform functions such as unloading computational tasks and acquiring data. In other words, the container and the system communicate through two Linux message queues. Container images are used to encapsulate, publish, and deploy the application, and Cgroups are used to implement resource isolation and limitation. Distributed applications need to run on different devices and platforms; using container technology to encapsulate the application allows it to have a consistent execution environment in a distributed environment, reducing the cost of maintaining the system environment.

[0068] Based on the type of resource agent, executors are divided into two categories: executors created by the primary resource agent and executors created by the secondary resource agent. The container instances of executors correspond to two startup states, such as... Figure 2 The executor created by the main resource broker, after its container instance starts, executes the main logic function `main` to begin processing application business logic. This container instance is responsible for maintaining the entire application's lifecycle; when the container exits, the entire application execution ends. The executor created by the resource broker, after its container instance starts, enters an event loop, continuously waiting for its parent resource broker to initiate the unloading of computation tasks. In this state, the container instance only receives and executes computation tasks, without actively performing any calculations. Therefore, when there are no computation tasks, this type of container instance can be suspended or destroyed by the resource broker to reduce resource consumption.

[0069] In the actual implementation, three environment variables are configured when the container is created: MODE, which indicates the container's startup state; IN_MQ, which specifies the message queue from the background to the application container; and OUT_MQ, which specifies the message queue from the application container to the background. After the container starts, it executes the run function. In this function, it first constructs a message queue object based on the IN_MQ and OUT_MQ environment variables for subsequent interaction with the background. Then, it executes the init function. After initialization, it enters different startup states based on the MODE environment variable.

[0070] In this embodiment, the executor generates computational tasks during runtime. The application runtime schedules these tasks to resource proxies, which then handle the migration and provide a fine-grained, strongly isolated environment for the computational tasks in terms of both the processor and the executor. Specifically, QoS-aware scheduling decisions are made from the request side, limiting the number of tasks received by a single resource proxygen agent and achieving higher quality of service guarantees. Achieving proactive QoS-aware task scheduling requires two conditions: 1) known task QoS requirements and expected execution status; 2) the current service status of the receiving carrier. In this embodiment, these two conditions are achieved through computational tasks and resource proxies.

[0071] When a user initiates a compute offload, the executor encapsulates the compute process to be offloaded, the required compute resources, the estimated execution time, and QoS requirements, along with request parameters, into a complete compute task. This task is then submitted to the resource broker for subsequent scheduling and offload. Therefore, the resource broker can make better decisions based on the compute task's QoS requirements during task scheduling. Compared to offload methods such as microservices, the application-system collaborative scheduling model makes it easier to obtain task-provided information at the time of offload initiation and monitors the performance information of the compute task throughout the entire process from offload initiation to completion.

[0072] The resource broker abstraction includes a task queue for receiving and consuming computation tasks in an orderly manner. The resource broker queues each computation task submitted to it in the order of submission and determines the estimated waiting time for a newly added computation task. This estimated waiting time is the sum of the estimated execution time of all computation tasks in the queue except for the newly added computation task and the estimated remaining time of the currently executing computation task.

[0073] Furthermore, multiple resource agents may be offloading computations within the cluster, meaning that multiple resource agents might simultaneously make scheduling decisions to the same resource agent, preventing the target resource agent from meeting the QoS requirements of all submitted computation tasks. To avoid this, cascading scheduling is supported. This means that after receiving a computation task, a resource agent only adds it to its own task queue if it determines that it can meet the task's QoS requirements; otherwise, it re-initiates the scheduling process.

[0074] Specifically, when making scheduling decisions for computing tasks, the resource broker, upon receiving a task offloading request, extracts QoS requirements from the task's summary information. Based on the QoS requirements and the resource broker's status view, it filters and selects the best resource broker from all available ones. It then selects a resource broker that meets the QoS requirements as the target resource broker and offloads the computing task to that target resource broker. If no resource broker meets the QoS requirements, indicating insufficient application resource space, a new resource broker is created. During the initialization of the new resource broker, it continuously monitors whether other resource brokers meet the QoS requirements. If so, the computing task is directly offloaded to the resource broker that meets the QoS requirements. This scheduling method ensures that scheduling decisions are not made to resource brokers in the local view that cannot meet the QoS requirements, thus improving service quality assurance capabilities.

[0075] like Figure 3 As shown, Figure 3 The diagram illustrates a QoS-aware task scheduling example. The cluster consists of nodes Node1, Node2, and Node3. Node1 hosts a resource proxy Stub1 with three computation tasks in its task queue. Stub1's wait time is 150ms. Node2 hosts resource proxies Stub2 and Stub3. Stub2's task queue contains two computation tasks with a wait time of 100ms. Stub2's task queue contains no computation tasks, meaning its wait time is 0ms. Node3 hosts a resource proxy Stub4 with a current computation task's QoS requirement of 70ms. Therefore, in this example, resource proxy Stub3 can be identified as the target resource proxy.

[0076] By making QoS-aware scheduling decisions from the request side, the task load of a single resource proxy is limited. Furthermore, even when a resource proxy unexpectedly receives an excessive number of computational tasks, it can continue to forward them, rather than relying on Knative's strategy of queuing after establishing a request connection. This approach better utilizes the cluster's computing power. The resource proxy can proactively add or remove application resource proxies across the cluster based on the application's concurrency requirements, the QoS requirements of computational tasks, and the current load pressure of all proxies. This enables dynamic, on-demand expansion of the application resource space, achieving higher service quality guarantees. Simultaneously, when it detects excessive load pressure on the application resource space, it proactively expands it by creating resource proxies to meet the application's real-time changing resource needs.

[0077] Furthermore, edge-cloud environments have distinct characteristics, and existing computing platforms often treat all devices in a cluster equally, making them unsuitable for the complexities of edge-cloud environments. Therefore, this invention redesigns the architecture to address the environmental characteristics of edge-cloud, particularly computing power and network features. This invention is based on three main assumptions: 1) Device resources are highly limited; 2) The cloud possesses virtually unlimited resources; and 3) Edge-cloud network communication latency is significantly higher than edge communication latency.

[0078] Starting from the first assumption, since the resources of the device are very limited, the device does not receive task unloading, but only initiates task unloading. Therefore, the device does not need to synchronize its own resource status with other devices, thereby reducing the load pressure on the device.

[0079] Based on the second assumption, since the cloud has almost unlimited resources, it can be used as a resource pool for edge backup executors. When edge resources are insufficient, there is no need to confirm whether the cloud has sufficient resources; the computing task can be submitted directly to the cloud. Therefore, cloud devices do not need to synchronize their resource status with other devices.

[0080] Based on the third assumption, due to the high latency of edge-cloud communication, it is difficult to meet the timeliness requirement for the edge to synchronize its status with the cloud. Therefore, the cloud cannot be offloaded to the edge, and the edge cannot synchronize its status information with the cloud.

[0081] Finally, based on the above three assumptions, the constraints on the system in terms of task flow, state flow, and data flow are as follows: Figure 4 As shown: The task flow adopts an overall bottom-up unloading approach from the device to the cloud. The device can unload to the edge and the cloud, and the edge can unload to the edge and the cloud. The cloud can only unload to the cloud. The state flow is only the synchronization of its own state from the edge to the device and between the edge and the device. The data flow is free to flow from the device, the edge, and the cloud.

[0082] Therefore, this embodiment designs a scheduling mechanism based on the assumptions that 1) the cloud has almost unlimited computing resources and 2) the edge and device resources are limited. Different resource scheduling ranges are adopted at the device, edge and cloud to optimize the scheduling process, reduce the scheduling overhead of the device and edge, and improve the quality of task service by adopting the above-mentioned QoS-based proactive scheduling mechanism.

[0083] Specifically, when scheduling computing tasks from the device to the edge, a target resource proxy that meets the QoS requirements of the computing task is selected from the existing set of resource proxies at the edge. If such a target resource proxy exists, the computing task is directly submitted to the corresponding target resource proxy, which then performs the unloading process. If the target resource proxy does not exist, an attempt is made to select a suitable node from the edge to request the creation of a new resource proxy. After the request is initiated, the computing task is directly sent to the cloud resource proxy for unloading without waiting for the new resource proxy to be created. This single-pass scheduling design aims to reduce the scheduling pressure on the device and edge computing devices, reduce the scheduling latency of individual computing tasks, and improve the overall system's computing efficiency. Since the resource proxy creation time is uncertain and the initialization latency may be long, while the edge-cloud communication latency is usually within 100ms, directly sending the task to the cloud when no suitable resource proxy is available can significantly reduce the execution waiting time of the computing task.

[0084] Furthermore, when scheduling a computing task, if it is found that the waiting time from the submission of the computing task to the present exceeds the QoS tolerance time of the computing task, the computing task will be directly thrown to the cloud resource agent to perform the offloading process, thereby reducing the consumption of edge resources.

[0085] If a resource broker at the edge receives a computing task and, upon attempting to insert it into the task queue, finds that the current resource broker can no longer meet the QoS requirements of the computing task, it will re-initiate a scheduling request. Furthermore, the cloud typically possesses abundant computing resources; therefore, resource brokers for cloud applications execute computing tasks directly upon receiving them without secondary scheduling.

[0086] To verify the effectiveness of this invention, it will be compared with related technologies below:

[0087] Four application frameworks—Bare Metal, KubeEdge edge computing system, Ray general-purpose distributed computing framework, and the edge-cloud distributed application runtime system of this invention—were evaluated, and their computational performance was statistically analyzed. The physical environment consisted of seven heterogeneous computing devices, as shown in Table 1. Multiple application frameworks were deployed on these devices, and the frameworks were compared and evaluated by running the YOLOX object detection computation task.

[0088]

[0089] Table 1. Experimental Equipment Configuration

[0090] All three devices are deployed in an intranet environment. Using the ping command, the initial RTT latency between any two devices was less than 1ms, with a bandwidth of 1000Mbps. To simulate an edge-cloud network environment, the Linux command-line tool tc was used to limit the latency of the cloud devices, adding a 50ms latency and a 5ms fluctuation to the initial latency.

[0091] Based on this physical device, four application frameworks—KubeEdge, Ray, Bare Metal, and the present invention—were built for comparative experiments. The edge-cloud environment architecture used was as follows: Figure 5 As shown. The application workload selected was a YOLOX object detection computation task implemented in Python, which is a computationally intensive application. All workloads performed object detection on the same image, with resource requirements set to 2 CPU cores. To measure the basic execution performance of the workload on each device, it was executed serially 300 times on each device, and the computation latency was statistically analyzed. The results showed that Edge 1 had the best single-core performance and the lowest computation latency, followed by the cloud device. The latency of executing the computation task on the Raspberry Pi was more than 10 times that of other devices. The cloud device had the largest standard deviation of latency.

[0092] In the distributed application experiment, 10 different compute offload frequencies were set, ranging from 5 frames per second to 50 frames per second at intervals of 5, to fully test the execution performance of different application frameworks under different load pressures. This paper uses three Raspberry Pis as clients to launch the application and initiates compute offload for one minute at the aforementioned different frequencies. The compute offload process and system events are recorded for subsequent statistical analysis.

[0093] When using this invention as a computing platform, the application workload is implemented based on a developed Python language dependency library and encapsulated into an application container. One application is launched on each device; the application resource spaces of the three applications are isolated from each other and do not share resources, while the three applications as a whole share the entire cluster resource space.

[0094] Test results are as follows Figure 6 , Figure 7 , Figure 8 As shown, where: Figure 6 The average end-to-end latency for each platform is shown. Figure 7 The 95th percentile values ​​of end-to-end latency for each platform are shown. Figure 8 The standard deviation of end-to-end latency for each platform is shown. Figure 6 , Figure 7 , Figure 8As can be seen, compared to the KubeEdge groups and the bare metal group, this invention exhibits orders-of-magnitude advantages in average latency, 95th percentile latency, and latency standard deviation when RPS is above 20. When RPS is less than or equal to 20, it is comparable to the best-performing KubeEdge-full group. Compared to the best-performing Actor-40 group among the Ray groups, the average latency, 95th percentile latency, and latency standard deviation are reduced by an average of 47.03%, 43.93%, and 31.46%, respectively. In terms of throughput, its peak throughput is more than twice that of other computing platforms.

[0095] In summary, the edge-cloud collaborative distributed application runtime system disclosed in this invention addresses the mismatch between resource demand and resource allocation by setting the basic granularity of resource allocation to computational requests that generate resource demands, and providing a spatiotemporally isolated execution environment. Resource allocation employs a QoS-aware proactive adaptation approach, with resource proxies dynamically adapting to received computational tasks, enabling dynamic on-demand expansion of application resource space. This system proactively adapts to real-time changes in application resource demands, improving the stability of computing platform performance and service quality. Furthermore, considering the environmental characteristics of edge-cloud, the entire distributed system is constrained and deconstructed from a network flow graph perspective. A consistent scheduling model and programming abstraction are adopted at the core system abstraction level, resulting in a tighter overall system integration. This enhances the application of edge-cloud computing power, enabling edge devices to complete more complex applications.

[0096] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A distributed application runtime system with edge-cloud collaboration, characterized in that, At least the following should be configured at the device, edge, and cloud: Resource proxy, An executor resource pool contains at least one executor, which is configured with a corresponding resource agent and interacts with the resource agent. Based on the type of resource agent, executors are divided into two categories: executors created by the main resource agent and executors created by the secondary resource agent. For executors created by the main resource agent, the container instance corresponding to the executor executes the main logic function after startup and begins processing application business logic. This container instance is responsible for maintaining the entire application's lifecycle; when the container exits, the entire application execution ends. For executors created by the secondary resource agent, the container instance corresponding to the executor enters an event loop after startup, continuously waiting for the secondary resource agent to initiate the unloading of computational tasks to the executor. The interface server communicates with the resource broker and contains multiple types of function processors that receive computation task offloading requests. The resource proxy manager communicates with the interface server, resource proxies, and executor resource pools, and is used to create or destroy resource proxies and executor resource pools. Cluster status cache, which communicates with the interface server and resource agent communication, is used to receive device resource status information and resource agent status information; The processor manager communicates with the interface server and the resource agent to manage local physical resources, including the creation and recycling of processors. Among them, at least one executor generates computational tasks during runtime; After receiving a computing task unloading request, the resource agent will schedule and migrate the corresponding computing task. The task flow adopts an overall bottom-up unloading from the device to the cloud. The device can unload to the edge and the cloud, the edge can unload to the edge and the cloud, and the cloud can only unload to the cloud. The state flow is only the synchronization of its own state from the edge to the device and between the edge and the edge. The data flow is free to flow from the device, the edge, and the cloud. When scheduling computing tasks from the physical device to the edge, Based on the QoS requirements of the computing task, target resource proxies that meet the QoS requirements are selected from the existing set of resource proxies at the edge. If the target resource agent exists, the computing task is directly submitted to the corresponding target resource agent, which then receives the computing task and executes the unloading process. If the target resource proxy does not exist, it will attempt to select a suitable node from the edge to apply for the creation of a new resource proxy. After the application is initiated, it will not wait for the new resource proxy to be created, but will directly throw the computing task to the resource proxy in the cloud to perform the unloading process.

2. The system according to claim 1, characterized in that, Each executor corresponds to a container instance, and the container instance is used to achieve isolation of the execution environment.

3. The system according to claim 1, characterized in that, Upon receiving the request to unload the computing task, extract the QoS requirements from the summary information of the computing task; Based on the QoS requirements of the computation task and the resource agent status view, all resource agents are screened and selected for the best one. Select a resource proxy that meets the QoS requirements as the target resource proxy, and offload the computing task to the target resource proxy.

4. The system according to claim 3, characterized in that, If no resource proxy meets the QoS requirement, a new resource proxy will be created; and during the initialization of the new resource proxy, it will be continuously observed whether other resource proxies meet the requirement. If QoS requirements exist, the computing task will be directly offloaded to the resource agent that meets the QoS requirements.

5. The system according to claim 1, characterized in that, The resource agent queues each computation task submitted to it in the order of submission and determines the estimated waiting time for newly added computation tasks. The estimated waiting time is the sum of the estimated execution time of all computation tasks in the queue except for the newly added computation task and the estimated remaining time of the currently executing computation task.

6. The system according to claim 1, characterized in that, When scheduling a computing task, if it is found that the waiting time from the submission of the computing task to the present exceeds the QoS tolerance time of the computing task, the computing task is directly thrown to the cloud resource agent to perform the unloading process.

7. The system according to claim 1, characterized in that, If a resource agent at the edge receives a computing task and, when attempting to insert it into the task queue, finds that the current resource agent can no longer meet the QoS requirements of the computing task, it will re-initiate the scheduling request.

Images