An edge cluster scheduling method based on multi-device collaboration

Abstract

The present invention discloses an edge cluster scheduling method based on multi-device collaboration, which uses an intrusive method to start and update the APP, and at the same time uses an intrusive method to verify whether the APP is started normally before executing the task, to ensure that the detection task performed is meaningful. In addition, the invention uses non-intrusive robotic arm operations to complete some privacy operations that cannot be completed by intrusive methods, thereby improving the fault tolerance of edge execution tasks.

Description

Technical Field

[0001] The present invention relates to an edge cluster scheduling method based on multi-device collaboration, and belongs to the field of computer technology software. Background Art

[0002] With the rapid development of the Internet, the number of mobile applications has grown rapidly. The number of APPs and the diverse user groups have posed a huge challenge to the speed, efficiency and automation of APP detection. Therefore, there is a lack of an edge cluster that can manage multiple devices to perform large-scale, unattended APP detection tasks. At the same time, in the field of cross-platform and cross-model APP detection on test machines, there is a lack of a more universal solution to perform unified detection of APPs on different platforms and different models of mobile phones. The present invention has made great efforts in all the above aspects to manage and schedule large-scale edge clusters, reduce manpower participation, and adapt to different host systems with different test mobile phone models.

[0003] The current APP detection system, due to the different APP startup methods of different systems, mostly places the specified APP in the specified location, and then uses the robotic arm to click the specific coordinates to start the APP. However, this non-invasive method has the following problems: (1) Since the mobile phone screen is very small, the accuracy of the robotic arm's movement parameters and click parameters is very high. Once the robotic arm is disturbed by external factors and causes the robotic arm to shift, it will not be able to start the APP normally to perform the task. (2) The robotic arm can click the coordinates to try to start the APP, but it cannot check whether the APP has started normally. (3) If the task requires the use of the latest version of the APP, the robotic arm cannot complete the complex update operation. Summary of the Invention

[0004] The present invention aims to solve the problem that APP detection tasks in the existing technology cannot be scaled up and cannot be separated from human participation, and proposes an edge cluster scheduling method based on multi-device collaboration.

[0005] The present invention uses an intrusive method to start and update the APP, and also uses an intrusive method to verify whether the APP is started normally before executing the task, to ensure that the detection task is meaningful. In addition, the invention uses a non-intrusive robotic arm operation method to complete some privacy operations that cannot be completed by the intrusive method, thereby improving the fault tolerance of edge execution tasks.

[0006] Specifically, the present invention provides an edge cluster scheduling method based on multi-device collaboration, which includes:

[0007] S1: The edge refers to the unit consisting of a test phone, a robotic arm, and a computer host that is used to perform specific app testing tasks;

[0008] S2: APP detection task is to detect APPs on mobile phones and determine whether they comply with certain rules. The rules include but are not limited to: barrier-free use rules, aging-friendly rules, etc.

[0009] S3: An edge cluster is a unit consisting of multiple edge devices used to perform batch app detection tasks.

[0010] S4: The cloud refers to the server side. App detection tasks are created by the cloud and sent to the scheduling system.

[0011] S5: The front end refers to the client, which is used to visualize data on a computer for users or administrators to view;

[0012] S6: The pending task queue is a database. App detection tasks sent from the cloud are temporarily stored in the task queue. When there is an idle edge in the edge cluster, the scheduling system will select eligible App detection tasks from the task queue through a specific scheduling algorithm and send them to the idle edge for execution.

[0013] S7: The scheduling system is an automated task management center. It receives and saves app detection tasks sent from the cloud, monitors the status of the edge in the edge cluster and performs corresponding processing. It selects eligible app detection tasks from the pending task queue through a scheduling algorithm and sends them to the edge. At the same time, it sends the status and progress of the app detection tasks, the health status of each edge in the edge cluster, and resource usage to the front end for visualization.

[0014] S8: After the client program is started on the edge, the edge will register with the scheduling system with its own mobile phone type, mobile phone model, host resource information, and edge name. After registration, the edge will join the cluster and accept the unified management of the scheduling system;

[0015] S9: After joining the cluster, the edge will periodically send heartbeat information to the scheduling system through HTTP requests to report its status and task status;

[0016] S91: The edge is idle and only reports its own resource information.

[0017] S92: The edge is executing a task. While reporting its own resource usage information, the edge also reports the status of the task it is executing.

[0018] S10: After receiving the heartbeat information from the edge, the scheduling system analyzes the heartbeat content and makes the next response based on the analysis results;

[0019] S101: The scheduling system analyzes that the edge is idle, reads the test phone model, phone type, and resource information of the edge, and traverses all tasks in the queue at the same time. According to a specific scheduling algorithm, an APP detection task is selected and sent to the edge. The requirements here include: the phone type and model are consistent with the phone and model specified in the APP detection task, the APP detection task has the highest priority, and the APP detection task is added to the queue at the earliest time; the APP detection task priority will decrease as the number of APP detection task anomalies increases. The purpose of this is to prevent abnormal tasks from frequently occupying the edge, causing the edge to be unable to execute normal tasks for a long time; the earliest condition for the APP detection task to be added to the queue is to prevent some tasks from not being responded to for a long time, resulting in starvation.

[0020] S102: The scheduling system analyzes the tasks being executed by the edge and responds accordingly based on the task status.

[0021] S1021: The scheduling system detects that the task status is running, finds the progress of the task, and saves the progress;

[0022] S1022: The scheduling system detects that the task is in an interrupted state. The scheduling system reads the task's retry count. If the retry count does not reach the threshold, the task is resent and the retry count is recorded again. If the retry count reaches the threshold, the task is marked as an error state and will no longer be executed. The task sender is notified through an HTTP request that the task cannot be completed normally.

[0023] S1023: If the scheduling system detects that the task status is an error, it will mark the task as an error and notify the task sender through an HTTP request that the task cannot be completed normally;

[0024] S1024: The scheduling system detects that the task status is normal completion, saves the task progress, and feeds back the task result to the task sender.

[0025] S11: If an edge does not send a heartbeat to the scheduling system for a long time, the scheduling system will mark the edge as unhealthy and delete the edge information from the edge cluster information maintained by the scheduling system. The edge will no longer be managed.

[0026] S12: When the edge receives a task assigned by the scheduling system, it parses the installation package information of the APP required for the task from a local file or downloaded from the network, launches the APP on the test phone at the edge in an intrusive manner, and simultaneously starts the APP installation package and installation package information caching operation;

[0027] S121: Mark the APP installation package with a unique identifier and store it in a local file on the edge;

[0028] S122: Send the parsed APP installation package information to the scheduling system, and then store it in the database of the scheduling system;

[0029] S13: After a series of operations in S6, the edge can start executing the app detection task;

[0030] S14: The scheduling system opens a series of interfaces, including the task progress viewing interface and the edge cluster status information viewing interface. The purpose is to provide data to the front-end for data visualization, so that administrators can more intuitively monitor the progress of tasks and the status of clusters.

[0031] Specifically, the test phone in step S1 can be an Android phone, an IOS phone, or a variety of mainstream models; the host can be a Linux system or a Windows system. Multiple different combination detection methods are supported to improve compatibility.

[0032] Specifically, the registration in step S8 refers to sending a message to an interface specified by the scheduling system through an HTTP request. Only registered hosts can communicate with the scheduling system.

[0033] Specifically, the edge status in step S9 includes but is not limited to: online; offline; large network delay; insufficient resources. The task status in step S9 includes but is not limited to: whether the current task is running normally; whether the current task has an error, is interrupted, or has been completed.

[0034] Specifically, the heartbeat content described in step S10 includes but is not limited to: whether a task exists; the progress of the task; the status of the task; the host system at the edge; the type of test mobile phone at the edge; the model of the test mobile phone at the edge; and the resource usage of the host and test mobile phone at the edge.

[0035] Specifically, the specific scheduling algorithm described in step S101 uses a combination of a very classic and efficient multi-level feedback queue algorithm and a first-come, first-served algorithm in the CPU scheduling algorithm, and is an algorithm suitable for non-interruptible tasks: the algorithm sets the priority of the task to the highest when saving the task to the queue, but when the task execution fails or is abnormal, the priority of the task will be lowered to the lowest. The purpose of this is to prevent abnormal tasks from frequently occupying the edge, causing the edge to be unable to execute normal tasks for a long time, affecting the efficiency of the cluster; at the same time, the algorithm that enters the queue earliest will be selected from the APP detection tasks of the same priority. The purpose of this is to prevent some tasks from not receiving a response for a long time, resulting in starvation and affecting the user experience.

[0036] Specifically, the installation package information described in step S12 includes the app's version number, app name, app package name, and app launch page name for Android installation packages; and includes the app's version, app name, and app Bundle ID for iOS installation packages. The code-based launch of the app described in step S6 utilizes the Android Debug Bridge for Android phones and tidevice for iOS phones.

[0037] Specifically, the unique identifier in step S121 refers to a character string formed by concatenating the name and version of the APP.

[0038] The working principle of the present invention is:

[0039] The present invention realizes the automatic distribution, execution and fault tolerance of large-scale, unattended APP detection tasks by unified management of edge clusters composed of multiple devices and combining scheduling algorithms for multiple interruptible tasks to form a set of scheduling algorithms for non-interruptible tasks.

[0040] The present invention combines the two methods of operating a mobile phone with a robot arm and controlling a mobile phone with a code through a combination of software and hardware, solving the problem that the degree of automation is not high enough due to the inability to completely eliminate human intervention by using a robot arm or code control alone.

[0041] The advantages of the present invention are:

[0042] The present invention can automatically distribute, execute, and fault-tolerate large-scale, non-interruptible APP detection tasks, and provide timely feedback to task managers.

[0043] The present invention can uniformly manage and schedule edge clusters composed of multiple devices, so that the edge devices in the edge cluster can process APP detection tasks efficiently and promptly.

[0044] The present invention achieves a high degree of automation and can completely eliminate human involvement, so that edge clusters and APP detection tasks can be scaled up, with higher availability and commercial value. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 This is an architectural diagram of the edge cluster scheduling method based on multi-device collaboration provided by an embodiment of the present invention.

[0046] Figure 2 It is a task execution flow chart of the edge cluster scheduling method based on multi-device collaboration provided by the implementation of the present invention.

[0047] Figure 3It is a connection diagram of each device in the edge of the edge cluster scheduling method based on multi-device collaboration provided by the implementation of the present invention. DETAILED DESCRIPTION

[0048] The technical solution of the present invention is described in detail below with reference to the accompanying drawings.

[0049] When developing the edge cluster scheduling method, the inventors found that the existing edge cluster management system was unable to scale up and highly automate the cluster due to problems such as the difficulty of solving APP startup and APP update problems using non-invasive robotic arms, low compatibility between hosts of different systems and different types of mobile phones, and the need for manual confirmation of whether the task is normal.

[0050] Therefore, the present invention addresses these issues by using invasive code control as the primary method and non-invasive robotic arm operation as the supplementary method. This ensures timely task dispatch, solves the problem of automatic app startup and update during task preparation, and ensures that errors are handled and repaired promptly during task execution. This enables large-scale and highly automated clustering.

[0051] The present invention will now be described in further detail with reference to the accompanying drawings, which are simplified schematic diagrams that illustrate the basic structure of the present invention in a schematic manner.

[0052] A multi-device collaborative edge cluster scheduling method, including:

[0053] S1: The edge refers to the unit consisting of a test phone, a robotic arm, and a computer host that is used to perform specific app testing tasks;

[0054] S2: APP detection task is to detect APPs on mobile phones and determine whether they comply with certain rules. The rules include but are not limited to: barrier-free use rules, aging-friendly rules, etc.

[0055] S3: An edge cluster is a unit consisting of multiple edge devices used to perform batch app detection tasks.

[0056] S4: The cloud refers to the server side. App detection tasks are created by the cloud and sent to the scheduling system.

[0057] S5: The front end refers to the client, which is used to visualize data on a computer for users or administrators to view;

[0058] S6: The pending task queue is a database where app detection tasks sent from the cloud are temporarily stored. When an idle edge becomes available in the edge cluster, the scheduling system selects eligible app detection tasks from the task queue and sends them to the idle edge for execution.

[0059] S7: The scheduling system is an automated task management center that manages app detection tasks and edge clusters.

[0060] S8: After the client program is started on the edge, the edge registers with the scheduling system with its device information and edge name. After registration, the edge joins the cluster and is managed by the scheduling system.

[0061] S9: After joining the cluster, the edge will periodically send heartbeat information to the scheduling system through requests and report its own status and task status;

[0062] S91: The edge is idle and only reports its own resource information.

[0063] S92: The edge is executing a task. While reporting its own resource usage information, the edge also reports the status of the task it is executing.

[0064] S10: After receiving the heartbeat information from the edge, the scheduling system analyzes the heartbeat content and makes the next response based on the analysis results;

[0065] S101: The scheduling system analyzes the idle edge and reads the test equipment and resource information of the edge. It also traverses all tasks in the queue and selects a qualified app detection task based on a specific scheduling algorithm and sends it to the edge.

[0066] S102: The scheduling system analyzes the tasks being executed by the edge and responds accordingly based on the task status.

[0067] S1021: The scheduling system detects that the task status is running, finds the progress of the task, and saves the progress;

[0068] S1022: The scheduling system detects that the task status is interrupted. The scheduling system reads the number of retries for the task and makes further responses based on whether the number of retries reaches a threshold.

[0069] S1023: If the scheduling system detects that the task status is an error, it will mark the task as an error;

[0070] S1024: The scheduling system detects that the task status is normal completion, and the scheduling system saves the progress of the task;

[0071] S11: If an edge fails to send a heartbeat to the scheduling system for a long period of time, the scheduling system will mark the edge as unhealthy and will no longer manage the edge.

[0072] S12: When the edge receives a task assigned by the scheduling system, it parses the installation package information of the APP required for the task from a local file or downloaded from the network, launches the APP on the test phone at the edge in an intrusive manner, and simultaneously starts the APP installation package and installation package information caching operation;

[0073] S121: Mark the APP installation package with a unique identifier and store it in a local file on the edge;

[0074] S122: Send the parsed APP installation package information to the scheduling system;

[0075] S13: After a series of operations in S6, the edge can start executing the app detection task;

[0076] S14: The scheduling system opens a series of interfaces, including the task progress viewing interface and the edge cluster status information viewing interface. The purpose is to provide data to the front-end for data visualization, so that administrators can more intuitively monitor the progress of tasks and the status of clusters.

[0077] Furthermore, based on the above-described preferred embodiments of the present invention, and in accordance with the above description, relevant personnel may make various changes and modifications without departing from the technical scope of the present invention. The technical scope of the present invention is not limited to the contents of the specification and must be determined according to the scope of the claims.

Claims

1. A multi-device collaborative edge cluster scheduling method, comprising: S1: The edge refers to the unit consisting of a test phone, a robotic arm, and a computer host that is used to perform specific app testing tasks; S2: APP detection task refers to detecting APPs on mobile phones to determine whether they comply with certain rules, including but not limited to: accessibility rules and aging-friendly rules; S3: An edge cluster is a unit consisting of multiple edge devices used to perform batch app detection tasks. S4: The cloud refers to the server side. App detection tasks are created by the cloud and sent to the scheduling system. S5: The front end refers to the client, which is used to visualize data on a computer for users or administrators to view; S6: The pending task queue is a database where app detection tasks sent from the cloud are temporarily stored. When an idle edge becomes available in the edge cluster, the scheduling system uses a specific scheduling algorithm to select eligible app detection tasks from the task queue and send them to the idle edge for execution. S7: The scheduling system is an automated task management center. It receives and saves app detection tasks sent from the cloud, monitors the status of the edge devices in the edge cluster, and performs corresponding processing. It uses a scheduling algorithm to select eligible app detection tasks from the pending task queue and dispatch them to the edge devices. It also sends the status and progress of the app detection tasks, as well as the health status and resource usage of each edge device in the edge cluster, to the front-end for visualization. S8: After the client program is started on the edge, the edge will register with the scheduling system with its own mobile phone type, mobile phone model, host resource information, and edge name. After registration, the edge will join the cluster and accept the unified management of the scheduling system; S9: After joining the cluster, the edge will periodically send heartbeat information to the scheduling system through HTTP requests to report its status and task status; S91: The edge is idle and only reports its own resource information. S92: The edge is executing a task. While reporting its own resource usage information, the edge also reports the status of the task it is executing. S10: After receiving the heartbeat information from the edge, the scheduling system analyzes the heartbeat content and makes the next response based on the analysis results; S101: The scheduling system analyzes that the edge is idle, reads the test phone model, phone type, and resource information of the edge, and traverses all tasks in the queue at the same time. According to a specific scheduling algorithm, an APP detection task is selected and sent to the edge. The requirements here include: the phone type and model are consistent with the phone and model specified in the APP detection task, the APP detection task has the highest priority, and the APP detection task is added to the queue at the earliest time; the APP detection task priority will decrease as the number of APP detection task anomalies increases. The purpose of this is to prevent abnormal tasks from frequently occupying the edge, causing the edge to be unable to execute normal tasks for a long time; the earliest condition for the APP detection task to be added to the queue is to prevent some tasks from not being responded to for a long time, resulting in starvation. S102: The scheduling system analyzes the tasks being executed by the edge and responds accordingly based on the task status. S1021: The scheduling system detects that the task status is running, finds the progress of the task, and saves the progress; S1022: The scheduling system detects that the task is in an interrupted state. The scheduling system reads the task's retry count. If the retry count does not reach the threshold, the task is resent and the retry count is recorded again. If the retry count reaches the threshold, the task is marked as an error state and will no longer be executed. The task sender is notified through an HTTP request that the task cannot be completed normally. S1023: If the scheduling system detects that the task status is an error, it will mark the task as an error and notify the task sender through an HTTP request that the task cannot be completed normally; S1024: The scheduling system detects that the task status is normal completion, saves the task progress, and feeds back the task result to the task sender. S11: If an edge does not send a heartbeat to the scheduling system for a long time, the scheduling system will mark the edge as unhealthy and delete the edge information from the edge cluster information maintained by the scheduling system. The edge will no longer be managed. S12: When the edge receives a task assigned by the scheduling system, it parses the installation package information of the APP required for the task from a local file or downloaded from the network, launches the APP on the test phone at the edge in an intrusive manner, and simultaneously starts the APP installation package and installation package information caching operation; S121: Mark the APP installation package with a unique identifier and store it in a local file on the edge; S122: Send the parsed APP installation package information to the scheduling system, and then store it in the database of the scheduling system; S13: After a series of operations in S6, the edge can start executing the app detection task; S14: The scheduling system opens a series of interfaces, including the task progress viewing interface and the edge cluster status information viewing interface. The purpose is to provide data to the front-end for data visualization, so that administrators can more intuitively monitor the progress of tasks and the status of clusters.

2. The edge cluster scheduling method based on multi-device collaboration according to claim 1, characterized in that: The test mobile phone described in step S1 is selected from one of the following mobile phones: Android mobile phone, IOS mobile phone, and other mainstream models of mobile phones; the host computer uses Linux system or Windows system.

3. The edge cluster scheduling method based on multi-device collaboration according to claim 1, characterized in that: The registration in step S8 refers to sending a message to the interface specified by the scheduling system through an HTTP request. Only registered hosts can communicate with the scheduling system.

4. The edge cluster scheduling method based on multi-device collaboration according to claim 1, characterized in that: The edge status described in step S9 includes but is not limited to: online; offline; large network delay; insufficient resources; the task status in step S9 includes but is not limited to: whether the current task is running normally; whether the current task is erroneous, interrupted, or completed.

5. The edge cluster scheduling method based on multi-device collaboration according to claim 1, characterized in that: The heartbeat content described in step S10 includes but is not limited to: whether a task exists; the progress of the task; the status of the task; the host system at the edge; the type of test mobile phone at the edge; the model of the test mobile phone at the edge; and the resource usage of the host and test mobile phone at the edge.

6. The edge cluster scheduling method based on multi-device collaboration according to claim 1, characterized in that: The specific scheduling algorithm described in step S101 uses a combination of a very classic and efficient multi-level feedback queue algorithm and a first-come, first-served algorithm in the CPU scheduling algorithm. It is an algorithm suitable for non-interruptible tasks: the algorithm sets the priority of the task to the highest when saving the task to the queue, but when the task execution fails or is abnormal, the priority of the task will be lowered to the lowest. The purpose of this is to prevent abnormal tasks from frequently occupying the edge, causing the edge to be unable to execute normal tasks for a long time, affecting the efficiency of the cluster; at the same time, the algorithm that enters the queue earliest will be selected from the APP detection tasks of the same priority. The purpose of this is to prevent some tasks from not receiving a response for a long time, resulting in starvation and affecting the user experience.

7. The edge cluster scheduling method based on multi-device collaboration according to claim 1, characterized in that: The installation package information in step S12 includes the APP version number, APP name, APP package name, and APP startup page name for Android; and the APP version, APP name, and APP BundleID for IOS.

8. The edge cluster scheduling method based on multi-device collaboration according to claim 1, characterized in that: The step S12 of launching the APP in the test phone at the edge in an intrusive manner refers to launching the code in the APP in a code manner. For Android phones, Android Debug Bridge is used, and for IOS phones, tidevice is used.

9. The edge cluster scheduling method based on multi-device collaboration according to claim 1, characterized in that: The unique identifier in step S121 refers to a character string formed by concatenating the name and version of the APP.

Images