A service scheduling method, apparatus, device, and medium

Abstract

The application discloses a service scheduling method and device in the computer technology field, and equipment and medium. After receiving a node allocation request sent by a user end, a target node is selected, and a data structure in a target state corresponding to the target node is determined. The data structure is used for recording node information of the target node and a target service currently scheduled. The node information is returned to the user end, so that the user end establishes a connection with the target node according to the node information, and uses the target service in the target node. The scheme records the node information and the target service currently scheduled by using the data structure, so that the nodes and the corresponding data structures can be uniformly managed, available nodes can be selected for users, and the nodes currently serving the users can be tracked and controlled in real time.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a service scheduling method, apparatus, device and medium. Background Technology

[0002] Currently, network services are typically provided by clusters of multiple nodes. Often, personal, idle computer devices can also be included in the cluster as nodes providing network services. However, the stability of these nodes in running network services is highly unpredictable, with frequent switching between online and offline states, making it difficult to determine the real-time status of each node and thus difficult to allocate available service nodes to users.

[0003] Therefore, how to allocate available service nodes to users is a problem that needs to be solved by those skilled in the art. Summary of the Invention

[0004] The main purpose of this application is to provide a service scheduling method, apparatus, device and medium, which aims to solve the technical problem of difficult management of service nodes.

[0005] To achieve the above objectives, this application provides a service scheduling method applied at a scheduling end, comprising:

[0006] Receive node allocation requests sent by the user client;

[0007] Select a target node and determine the data structure corresponding to the target node in the target state; the data structure is used to record the node information of the target node and the currently scheduled target service;

[0008] The node information is returned to the user terminal so that the user terminal can establish a connection with the target node based on the node information and use the target service in the target node.

[0009] Optionally, before receiving the node allocation message sent by the user terminal, the method further includes:

[0010] Select a pooled node from the set of idle nodes based on the node pooling message;

[0011] Create the data structure corresponding to the pooling node that is in the pooling state;

[0012] If the pooling node reports a running status after starting the target service within the timeout period, the data structure corresponding to the pooling node is changed from the pooling state to the pooled state; otherwise, the data structure corresponding to the pooling node is changed from the pooling state to the destruction state, and the data structure corresponding to the pooling node in the destruction state is deleted.

[0013] Optionally, selecting a target node and determining the data structure corresponding to the target node in the target state includes:

[0014] Select the pooling node as the target node, and determine the data structure corresponding to the pooling node that is in a pooled state;

[0015] Change the data structure corresponding to the pooled node from the pooled state to the running state.

[0016] Optionally, selecting a target node and determining the data structure corresponding to the target node in the target state includes:

[0017] Select an idle node as the target node, and create the corresponding data structure for the target node in the state of about to run.

[0018] Optionally, it also includes:

[0019] If the target node reports a running status after starting the target service within the timeout period, the data structure corresponding to the target node is changed from the "about to run" status to the "currently running" status; otherwise, the data structure corresponding to the target node is changed from the "about to run" status to the "timeout" status.

[0020] Optionally, it also includes:

[0021] If a release notification sent by the user terminal and the idle status reported by the released node corresponding to the release notification are received, then the data structure corresponding to the released node is deleted.

[0022] Optionally, the step of deleting the data structure corresponding to the released node if a release notification sent by the user terminal and the idle status reported by the released node corresponding to the release notification are received includes:

[0023] If the release notification is received from the user terminal after disconnecting from the released node, the data structure corresponding to the released node is changed to the releasing state; wherein, after the user terminal disconnects from the released node, the released node changes its own state from the running state to the idle state.

[0024] If an idle status is reported by the released node within the timeout period, the data structure corresponding to the released node that is in the process of being released is deleted.

[0025] Optionally, it also includes:

[0026] Receive the idle status reported by each node, collect the nodes in the idle state, and obtain the idle node set;

[0027] Accordingly, selecting the target node includes:

[0028] Select the target node from the set of idle nodes.

[0029] To achieve the above objectives, this application further provides a service scheduling apparatus, applied at a scheduling terminal, comprising:

[0030] The receiving module is used to receive node allocation requests sent by the user client;

[0031] The selection module is used to select a target node and determine the data structure corresponding to the target node in the target state; the data structure is used to record the node information of the target node and the currently scheduled target service;

[0032] The return module is used to return the node information to the user terminal, so that the user terminal can establish a connection with the target node based on the node information and use the target service in the target node.

[0033] To achieve the above objectives, this application further provides an electronic device, comprising:

[0034] Memory, used to store computer programs;

[0035] A processor is used to execute the computer program to implement the aforementioned disclosed service scheduling method.

[0036] Preferably, the electronic device is a node that makes up a CDN network or a blockchain network.

[0037] To achieve the above objectives, this application further provides a readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the aforementioned disclosed service scheduling method.

[0038] To achieve the above objectives, this application further provides a computer program product, including computer instructions that, when run on a computer, enable the computer to execute the aforementioned disclosed service scheduling method.

[0039] As can be seen from the above scheme, this application provides a service scheduling method applied to a scheduling terminal, including: receiving a node allocation request sent by a user terminal; selecting a target node and determining a data structure corresponding to the target node in a target state; the data structure is used to record the node information of the target node and the currently scheduled target service; returning the node information to the user terminal, so that the user terminal can establish a connection with the target node based on the node information and use the target service in the target node.

[0040] As can be seen, this application, in response to a node allocation request sent by the user terminal, can determine the target node and the corresponding data structure in the target state, thereby obtaining the node information of the target node. The scheduling end then returns the node information to the user terminal, enabling the user terminal to establish a connection with the target node based on the node information and use the target service provided by the target node. This scheme utilizes a data structure to record node information and the currently scheduled target service, thereby enabling unified management of nodes and their corresponding data structures. This allows users to select available nodes and also enables real-time tracking and control of nodes currently serving users.

[0041] Correspondingly, the service scheduling device, equipment, readable storage medium, and computer program product provided in this application also have the above-mentioned technical effects. Attached Figure Description

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

[0043] Figure 1 This is a flowchart of a service scheduling method disclosed in this application;

[0044] Figure 2 This is a schematic diagram of the state transition under a pooling process disclosed in this application;

[0045] Figure 3 This is a schematic diagram of node allocation under a pooling process disclosed in this application;

[0046] Figure 4 This is a schematic diagram of state transitions under a non-pooling process disclosed in this application;

[0047] Figure 5 This is a schematic diagram of node allocation under a non-pooling process disclosed in this application;

[0048] Figure 6 This is a schematic diagram of a service scheduling device disclosed in this application;

[0049] Figure 7 This is a schematic diagram of an electronic device disclosed in this application;

[0050] Figure 8 This is a schematic diagram of another electronic device disclosed in this application.

[0051] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0053] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0054] It should be noted that the use of terms such as "first" and "second" in this application is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of those features. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, such a combination of technical solutions should be considered non-existent and not within the scope of protection claimed in this application.

[0055] See Figure 1 , Figure 1 This is a flowchart of a service scheduling method disclosed in this application. In this embodiment, the method is applied to a scheduling terminal and includes:

[0056] S101, Receive node allocation request sent by user terminal.

[0057] S102. Select the target node and determine the data structure corresponding to the target node in the target state.

[0058] The data structure is used to record node information of the target node and the currently scheduled target service. For example, the data structure can record: node ID, session ID of the node allocation request, and ID of the currently scheduled target service. The data structure can be a pod data structure.

[0059] In this embodiment, each node corresponds to a data structure, and changes in the node's state will cause changes in the state of its corresponding data structure. This facilitates unified management of nodes and their corresponding data structures, and allows for real-time tracking and control of nodes serving users. To facilitate the management of various node states and the states of their corresponding data structures, this embodiment sets the state of nodes that have not started the target service to an idle state, and sets the state of nodes that have started the target service to a running state. Each node periodically reports its own state to the scheduling terminal, so that the scheduling terminal controls the state of the data structure to change accordingly with these two node states. It should be noted that the specific state changes differ between the node pooling process and the node non-pooling process.

[0060] For example, for corresponding nodes and data structures, when the scheduler learns that a node is in a running state, it also changes the state of the data structure accordingly. In the node pooling process, when the scheduler learns that a node is in a running state, it changes the state of the data structure from "pooling in progress" to "pooled." The initial state of the newly created data structure in the node pooling process is "pooling in progress." In the non-pooling process, when the scheduler learns that a node is in a running state, it changes the state of the data structure from "about to run" to "running." The initial state of the newly created data structure in the non-pooling process is "about to run."

[0061] Typically, after a user initiates a network service on their client-side device, the client sends a node allocation request to the scheduling terminal, which then allocates a node to provide network services to the user. The scheduling terminal is usually controlled by the service provider. To improve the quality of the target service, the service provider can pre-start the target service on certain nodes, meaning these nodes are already in a running state. After receiving the node allocation request from the client, the scheduling terminal prioritizes allocating nodes with the already enabled target service to the client. This process of starting and running the target service on certain nodes before the client sends the allocation request is called node pooling, and the nodes that start the service first are called pooled nodes (i.e., already pooled nodes).

[0062] In one implementation, before receiving the node allocation message sent by the user terminal, the method further includes: selecting a pooling node from the set of idle nodes based on the node pooling message; creating a data structure corresponding to the pooling node that is in a pooling state; if, within the timeout period, the pooling node reports its running status after starting the target service, then the data structure corresponding to the pooling node is changed from a pooling state to a pooled state; otherwise, the data structure corresponding to the pooling node is changed from a pooling state to a destruction state, and the data structure corresponding to the pooling node that is in a destruction state is deleted. In one implementation, selecting a target node and determining the data structure corresponding to the target node in the target state includes: selecting a pooling node as the target node and determining the data structure corresponding to the pooling node that is in a pooled state; changing the data structure corresponding to the pooling node from a pooled state to a running state.

[0063] Of course, the scheduler can also prevent the target service on a node from starting in advance, making the startup of the target service on the node controlled by the communication connection between the user and the node. When a user connects to a node, the target service on that node starts and runs, and the node enters the running state; when no user connects to a node, the target service on that node does not start, and the node is in an idle state. This process is called the node non-pooling process, and the node that has not started the service in advance is called the unpooled node.

[0064] In one implementation, selecting a target node and determining the data structure corresponding to the target node in the target state includes: selecting an idle node as the target node and creating a data structure corresponding to the target node in the "about to run" state. In another implementation, if a running status reported by the target node after starting the target service is received within the timeout period, the data structure corresponding to the target node is changed from the "about to run" state to the "running" state; otherwise, the data structure corresponding to the target node is changed from the "about to run" state to the "timeout" state.

[0065] In one implementation, the process of constructing the idle node set includes: receiving idle status reports from each node to collect nodes in an idle state, thereby obtaining an idle node set; correspondingly, selecting a target node includes: selecting a target node from the idle node set. It is evident that the scheduler can collect all idle nodes to allocate idle pooled or unpooled nodes to the user terminal.

[0066] S103. Return node information to the user terminal so that the user terminal can establish a connection with the target node based on the node information and use the target service in the target node.

[0067] After a user establishes a communication connection with a node, the target service on that node can be used. If the user closes the target service on the user's end, the user automatically disconnects from the node and sends a release notification to the scheduler to inform it which node is being released. The node whose communication connection has been disconnected will change its state from running to idle. Therefore, if the scheduler receives a release notification from the user and the idle state reported by the released node, it indicates that the target service on that node has stopped running, and thus the data structure corresponding to the released node is deleted.

[0068] In one implementation, if a release notification sent by the user terminal and an idle state reported by the released node corresponding to the release notification are received, the data structure corresponding to the released node is deleted, including: if a release notification sent by the user terminal after disconnecting from the released node is received, the data structure corresponding to the released node is changed to a releasing state; wherein, after the user terminal disconnects from the released node, the released node changes its own state from a running state to an idle state; if an idle state reported by the released node is received within the timeout period, the data structure corresponding to the released node in the releasing state is deleted.

[0069] As can be seen, this embodiment, in response to a node allocation request sent by the user terminal, can determine the target node and the corresponding data structure in the target state, thereby obtaining the node information of the target node. The scheduling terminal then returns the node information to the user terminal, enabling the user terminal to establish a connection with the target node based on the node information and use the target service provided by the target node. This scheme utilizes a data structure to record node information and the currently scheduled target service, thereby enabling unified management of nodes and their corresponding data structures. This allows users to select available nodes and also enables real-time tracking and control of nodes currently serving users.

[0070] This application is applicable to various types of network services such as games, search, and e-commerce, facilitating unified management of related service nodes. When managing nodes in a game scenario according to this application, it is easier to meet the high concurrency and low latency requirements of game services. For example, after a game version update, a large number of users typically update their client simultaneously. This application demonstrates good coordination and management capabilities for such high-concurrency scenarios, ensuring the stability of game services under these conditions. The following section uses a game service as an example to introduce an exemplary implementation scheme of this application.

[0071] First, we will introduce the node allocation schemes under the pooling process and the non-pooling process in detail. In this embodiment, the console and the scheduling terminal are controlled by the game service provider; the user terminal is implemented based on the SDK; the scheduling terminal manages all nodes and collects the node status reported by the nodes at regular intervals.

[0072] Please see Figure 2 In the pooling process, nodes have two states: running and idle. The data structure has several states: pooling, pooled, running, releasing, and destroying. (See reference...) Figure 2 The state transitions under the pooling process shown are as follows: Figure 3 As shown.

[0073] exist Figure 3 In the process, when a node is idle, it reports "idle" to the scheduler. The scheduler collects the status of all nodes. The console sends a node pooling message to the scheduler to inform it which game needs to be started in advance, thus triggering the pooling process. Then, based on this message, the scheduler selects several nodes, creates the corresponding pod structure (i.e., pod data structure) for the nodes, sets the initial state of the pod structure to "pooling", starts the specified game service on the node, and then returns a successful pooling message to the console, thus completing the pooling process.

[0074] Please see Figure 2 The newly created pod structure is initially in a pooling state. Once the designated game service on the node starts, the node's state changes from idle to running. If the scheduler learns that the node's state is running before a timeout (e.g., within 2 minutes), it changes the corresponding pod structure's state from pooling to pooled. Otherwise, it changes the corresponding pod structure's state from pooling to destroying and deletes the pod structure. Therefore, in the pooling process, the initial state of a node is idle, and the initial state of a pod structure is pooling. If a node fails to start the game service normally within 2 minutes, it is considered to have timed out and is directly recycled. Thus, the state of the corresponding pod structure is changed from pooling to destroying, and the pod structure is deleted. When a node reports running before a timeout, the state of the corresponding pod structure is changed from pooling to pooled, indicating successful pooling.

[0075] Subsequently, when the client requests node allocation from the scheduler, the scheduler prioritizes pooled nodes and allocates them to the client. At this point, the status of the selected node's pod structure is changed from "pooled" to "running," and the scheduler returns the selected node information for the client to connect to. The client then establishes a communication connection with the selected node and uses the game service on that node.

[0076] If a user stops playing the game, the client sends a stop game command to the node, disconnects the communication connection with the node, and calls the Release interface to release the pod. A release notification is also sent to the scheduler to inform it which node has been disconnected, causing the scheduler to change the state of the released node's pod structure from running to releasing. If the scheduler then receives an idle status report from the released node, it considers the pod structure's lifecycle complete and deletes it. Specifically, after the client disconnects the node, the node changes its own state from running to idle.

[0077] Please see Figure 4 In non-pooled processes, nodes have two states: running and idle. The data structure has four states: pending, running, releasing, and timeout. (See reference...) Figure 4 The state transitions under the pooling process shown are as follows: Figure 5 As shown.

[0078] exist Figure 4 In the process, when a node is idle, it reports "idle" to the scheduler, which collects the status of all nodes. When a client requests node allocation from the scheduler, the scheduler selects a non-pooled node and assigns it to the client. At this time, the scheduler also creates a pending pod structure and returns the selected node information for the client to connect to. The client then establishes a communication connection with the selected node, starts the game service on the node, and after startup, the node reports "running" to the scheduler within 2 minutes (within a timeout period). The scheduler then changes the status of the corresponding pod structure from "pending" to "running." The client then uses the game service on the node. If the node times out and does not report "running," the scheduler sets the pod structure's status from "pending" to "timeout." As can be seen, in the non-pooled process, the initial state of the node is idle, and the initial state of the pod structure is pending. If the node fails to start the game service normally for more than 2 minutes, it is considered to have timed out, and the state of the pod structure is changed to timeout. After another minute, it is released. When the node reports running without timeout, the state of the corresponding pod structure is changed from pending to running, which means that the game has started successfully and is in service.

[0079] If a user stops playing the game, the client sends a stop game command to the node, disconnects the communication connection with the node, and calls the Release interface to release the pod. A release notification is also sent to the scheduler to inform it which node has been disconnected, causing the scheduler to change the state of the released node's pod structure from running to releasing. If the scheduler then receives an idle status report from the released node, it considers the pod structure's lifecycle complete and deletes it. Specifically, after the client disconnects the node, the node changes its own state from running to idle.

[0080] As can be seen, the scheduling client in this embodiment, as the core service of cloud gaming, is responsible for managing node states. It provides allocation and release interfaces externally and uses a pod data structure internally to maintain allocated nodes. The implementation is further divided into non-pooled and pooled scenarios. Specifically, the scheduling client can uniformly schedule nodes and their corresponding pod structures, ensuring that the lifecycle of a pod structure begins with node allocation and ends with node reclamation. Furthermore, during the pod lifecycle, the scheduling client maintains the pod structure's state based on the status reported by the nodes, thus facilitating node resource management.

[0081] The following describes a service scheduling device provided in an embodiment of this application. The service scheduling device described below and the service scheduling method described above can be referred to each other.

[0082] See Figure 6 , Figure 6 This is a schematic diagram of a service scheduling device disclosed in this application. In this embodiment, the device is applied to a scheduling terminal and includes:

[0083] The receiving module 601 is used to receive node allocation requests sent by the user terminal;

[0084] Selection module 602 is used to select a target node and determine the data structure corresponding to the target node in the target state; the data structure is used to record the node information of the target node and the target service currently scheduled;

[0085] The return module 603 is used to return node information to the user terminal so that the user terminal can establish a connection with the target node based on the node information and use the target service in the target node.

[0086] In one implementation, it further includes:

[0087] The pooling module is used to select pooled nodes from the set of idle nodes based on the node pooling message before receiving the node allocation message sent by the user; create a data structure corresponding to the pooled node that is in the pooling state; if the running status reported by the pooled node after starting the target service is received within the timeout period, the data structure corresponding to the pooled node is changed from the pooling state to the pooled state; otherwise, the data structure corresponding to the pooled node is changed from the pooling state to the destruction state, and the data structure corresponding to the pooled node in the destruction state is deleted.

[0088] In one implementation, the selection module is specifically used for:

[0089] Select the pooling node as the target node, and determine the data structure corresponding to the pooling node that is in the pooled state;

[0090] Change the data structure corresponding to the pooled node from the pooled state to the running state.

[0091] In one implementation, the selection module is specifically used for:

[0092] Select an idle node as the target node and create the corresponding data structure for the target node that is about to run.

[0093] In one implementation, it further includes:

[0094] The update module is used to change the data structure corresponding to the target node from the "about to run" state to the "currently running" state if it receives a report of the running status from the target node after starting the target service within the timeout period; otherwise, it changes the data structure corresponding to the target node from the "about to run" state to the "timeout" state.

[0095] In one implementation, it further includes:

[0096] The release module is used to delete the data structure corresponding to the released node if it receives a release notification sent by the user and the idle status reported by the released node corresponding to the release notification.

[0097] In one implementation, the release module is specifically used for:

[0098] If a release notification is received from the client after disconnecting from the node being released, the data structure corresponding to the node being released will be changed to the releasing state; in this case, after the client disconnects from the node being released, the node being released will change its own state from the running state to the idle state.

[0099] If an idle status is reported by the released node within the timeout period, the data structure corresponding to the released node that is in the process of being released is deleted.

[0100] In one implementation, it further includes:

[0101] The collection module is used to receive the idle status reported by each node, so as to collect the nodes in the idle state and obtain the idle node set;

[0102] Accordingly, the selection module is specifically used for:

[0103] Select the target node from the set of idle nodes.

[0104] For more detailed information on the working process of each module and unit in this embodiment, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0105] As can be seen, this embodiment provides a service scheduling device that uses data structures to record node information and the target service currently being scheduled. This allows for unified management of nodes and corresponding data structures, enabling users to select available nodes and also allowing for real-time tracking and control of nodes serving users.

[0106] The following describes an electronic device provided in an embodiment of this application. The electronic device described below can be referred to in conjunction with the service scheduling method and apparatus described above.

[0107] See Figure 7 , Figure 7 This is a schematic diagram of an electronic device disclosed in this application. In this embodiment, the device includes:

[0108] Memory 701 is used to store computer programs;

[0109] The processor 702 is configured to execute the computer program to implement the service scheduling method disclosed in any of the above embodiments.

[0110] In this embodiment, the electronic device can be a PC (Personal Computer), or a smartphone, tablet computer, handheld computer, portable computer, smart router, mining machine, network storage device terminal device.

[0111] The electronic device can be a node that makes up a CDN (Content Delivery Network) network or a blockchain network.

[0112] See Figure 8 , Figure 8 This is a schematic diagram of another electronic device disclosed in this application. The electronic device may include a memory 11, a processor 12, and a bus 13.

[0113] The memory 11 includes at least one type of readable storage medium, such as flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 11 can be an internal storage unit of an electronic device, such as the hard disk of the electronic device. In other embodiments, the memory 11 can also be an external storage device of the electronic device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. Furthermore, the memory 11 can include both internal and external storage units of the electronic device. The memory 11 can be used not only to store application software and various types of data installed on the electronic device, such as service scheduler code, but also to temporarily store data that has been output or will be output.

[0114] In some embodiments, processor 12 may be a central processing unit (CPU), controller, microcontroller, microprocessor or other data processing chip, used to run program code stored in memory 11 or process data, such as executing a service scheduler.

[0115] This bus 13 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0116] Furthermore, the electronic device may also include a network interface, which may optionally include a wired interface and / or a wireless interface (such as a Wi-Fi interface, a Bluetooth interface, etc.), typically used to establish communication connections between the device and other electronic devices.

[0117] Optionally, the device may also include a user interface, which may include a display, an input unit such as a keyboard, and optionally, a standard wired interface or a wireless interface. Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen, etc. The display may also be appropriately referred to as a screen or display unit, used to display information processed in the device and to display a visual user interface.

[0118] Figure 8 Only electronic devices with components 11-13 are shown; it will be understood by those skilled in the art that... Figure 8 The structure shown does not constitute a limitation on the device and may include fewer or more components than shown, or combine certain components, or have different component arrangements.

[0119] The following describes a readable storage medium provided in an embodiment of this application. The readable storage medium described below can be referred to in conjunction with the service scheduling method, apparatus, device and medium described above.

[0120] A readable storage medium is provided for storing a computer program, wherein the computer program, when executed by a processor, implements the service scheduling method disclosed in the foregoing embodiments. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0121] The following describes a computer program product provided in an embodiment of this application. The computer program product described below can be referred to in conjunction with the service scheduling method, apparatus, device and medium described above.

[0122] A computer program product includes computer instructions that, when run on a computer, enable the computer to execute the service scheduling method disclosed in the foregoing embodiments. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0123] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0124] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of readable storage medium known in the art.

[0125] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A service scheduling method, characterized in that, Applied to the scheduling end, including: Receive node allocation requests sent by the user client; Select a target node and determine the data structure corresponding to the target node in the target state; the data structure is used to record the node information of the target node and the currently scheduled target service; The node information is returned to the user terminal so that the user terminal can establish a connection with the target node based on the node information and use the target service in the target node; In the non-pooling process, selecting a target node and determining the data structure corresponding to the target node in the target state includes: selecting an idle node as the target node and creating a data structure corresponding to the target node in the state of about to run; correspondingly, if the target node reports a running state after starting the target service within the timeout period, the data structure corresponding to the target node is changed from the about to run state to the running state.

2. The service scheduling method according to claim 1, characterized in that, Before receiving the node allocation message sent by the user terminal, the process also includes: Select a pooled node from the set of idle nodes based on the node pooling message; Create the data structure corresponding to the pooling node that is in the pooling state; If the pooling node reports a running status after starting the target service within the timeout period, the data structure corresponding to the pooling node is changed from the pooling state to the pooled state; otherwise, the data structure corresponding to the pooling node is changed from the pooling state to the destruction state, and the data structure corresponding to the pooling node in the destruction state is deleted.

3. The service scheduling method according to claim 2, characterized in that, The step of selecting a target node and determining the data structure corresponding to the target node in the target state includes: Select the pooling node as the target node, and determine the data structure corresponding to the pooling node that is in a pooled state; Change the data structure corresponding to the pooled node from the pooled state to the running state.

4. The service scheduling method according to claim 1, characterized in that, Also includes: If the target node does not report its running status after starting the target service within the timeout period, the data structure corresponding to the target node will be changed from the soon-to-be-running status to the timeout status.

5. The service scheduling method according to claim 1, characterized in that, Also includes: If a release notification sent by the user terminal and the idle status reported by the released node corresponding to the release notification are received, then the data structure corresponding to the released node is deleted.

6. The service scheduling method according to claim 5, characterized in that, If a release notification is received from the user terminal and the idle status reported by the released node corresponding to the release notification is received, then the data structure corresponding to the released node is deleted, including: If the release notification is received from the user terminal after disconnecting from the released node, the data structure corresponding to the released node is changed to the releasing state; wherein, after the user terminal disconnects from the released node, the released node changes its own state from the running state to the idle state. If an idle status is reported by the released node within the timeout period, the data structure corresponding to the released node that is in the process of being released is deleted.

7. The service scheduling method according to any one of claims 1 to 6, characterized in that, Also includes: Receive the idle status reported by each node, collect the nodes in the idle state, and obtain the idle node set; Accordingly, selecting the target node includes: Select the target node from the set of idle nodes.

8. A service scheduling device, characterized in that, Applied to the scheduling end, including: The receiving module is used to receive node allocation requests sent by the user client; The selection module is used to select a target node and determine the data structure corresponding to the target node in the target state; the data structure is used to record the node information of the target node and the currently scheduled target service; The return module is used to return the node information to the user terminal, so that the user terminal can establish a connection with the target node based on the node information and use the target service in the target node; The selection module is used to: select an idle node as the target node in a non-pooling process, and create a data structure corresponding to the target node in an upcoming running state; correspondingly, the update module is used to change the data structure corresponding to the target node from the upcoming running state to the running state if it receives a running status reported by the target node after starting the target service within the timeout period.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the service scheduling method as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that, Used to store a computer program, wherein the computer program, when executed by a processor, implements the service scheduling method as described in any one of claims 1 to 7.

Images