Blockchain-based resource scheduling methods, devices, electronic equipment, and storage media

Abstract

This application discloses a resource scheduling method, apparatus, electronic device, and storage medium based on blockchain. The method includes: responding to a resource scheduling request, polling multiple consensus nodes in the blockchain, determining a broadcast node from among the consensus nodes, where each consensus node corresponds to a service cluster; determining multiple target consensus nodes from among the other consensus nodes based on the broadcast node, where the target consensus nodes are determined by the broadcast node according to the amount of pending tasks and response time corresponding to each other consensus node, and the response time is the duration for the corresponding other consensus node to respond to the broadcast message sent by the broadcast node; and scheduling service resources in multiple service clusters based on the broadcast node and the multiple target consensus nodes. The solution provided in this application reduces the management pressure of resource scheduling and improves the efficiency of resource scheduling.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology, and in particular relates to a blockchain-based resource scheduling method, device, electronic device and storage medium. Background Technology

[0002] Cloud computing services, also known as cloud services, are cloud computing products that can be provided as a service. With the rapid development of cloud computing services, various cloud services, such as public cloud, private cloud, and edge cloud, exist in the market. The existence of these multiple types of cloud services creates a need for resource scheduling among them.

[0003] In related technologies, dedicated cloud management platforms are typically used to schedule cloud service resources in multi-cloud collaboration. However, as the size of service clusters and the number of servers increase, cloud management platforms face increasing management and scheduling pressure, and the response speed of resource scheduling decreases exponentially. Furthermore, centralized cloud management platforms have poor horizontal scalability; when the pressure of resource scheduling reaches a certain limit, the backlog of scheduling tasks may cause system lag or even crashes, thereby reducing the efficiency of the cloud management platform in managing and scheduling cloud service resources. Summary of the Invention

[0004] This application provides a blockchain-based resource scheduling method, apparatus, electronic device, and storage medium, which can reduce the management pressure of resource scheduling and improve the efficiency of resource scheduling.

[0005] In a first aspect, embodiments of this application provide a resource scheduling method based on blockchain. The method includes: responding to a resource scheduling request, polling multiple consensus nodes in the blockchain to determine a broadcast node from among the multiple consensus nodes, wherein one consensus node corresponds to one service cluster; determining multiple target consensus nodes from among multiple other consensus nodes based on the broadcast node, wherein the multiple other consensus nodes are consensus nodes other than the broadcast node, and the multiple target consensus nodes are consensus nodes determined by the broadcast node from among the multiple other consensus nodes based on the amount of pending tasks and response time corresponding to each other consensus node, the response time being the duration for the corresponding other consensus node to respond to a broadcast message sent by the broadcast node; and scheduling service resources in multiple service clusters based on the broadcast node and the multiple target consensus nodes.

[0006] Secondly, embodiments of this application provide a blockchain-based resource scheduling device, comprising: a polling module, configured to respond to resource scheduling requests, poll multiple consensus nodes of the blockchain, and determine a broadcast node from among the multiple consensus nodes, wherein one consensus node corresponds to one service cluster; a node selection module, configured to determine multiple target consensus nodes from among multiple other consensus nodes based on the broadcast node, wherein the multiple other consensus nodes are consensus nodes other than the broadcast node, and the multiple target consensus nodes are consensus nodes determined by the broadcast node from among the multiple other consensus nodes according to the amount of pending tasks and response time corresponding to each other consensus node, and the response time is the duration for the corresponding other consensus node to respond to the broadcast message sent by the broadcast node; and a resource scheduling module, configured to schedule service resources in multiple service clusters based on the broadcast node and the multiple target consensus nodes.

[0007] Thirdly, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the blockchain-based resource scheduling method as described in the first aspect.

[0008] Fourthly, embodiments of this application provide a computer storage medium storing computer program instructions, which, when executed by a processor, implement the blockchain-based resource scheduling method as described in the first aspect.

[0009] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform the blockchain-based resource scheduling method as described in the first aspect.

[0010] This application employs a resource scheduling method based on the selection of a consensus node to determine other consensus nodes. After responding to a resource scheduling request, a polling operation is performed on multiple consensus nodes in the blockchain to determine a broadcast node. Then, the broadcast node determines multiple target consensus nodes from the multiple other consensus nodes based on the amount of pending tasks and response time corresponding to each other consensus node. Finally, service resources in multiple service clusters are scheduled based on the broadcast node and the multiple target consensus nodes. Here, the multiple other consensus nodes are the consensus nodes other than the broadcast node, and the response time is the duration for the corresponding other consensus node to respond to the broadcast message sent by the broadcast node.

[0011] As can be seen from the above, in this application, multiple consensus nodes are first polled to obtain broadcast nodes, and then target consensus nodes are selected for resource scheduling based on the broadcast nodes. Thus, in this application, not all consensus nodes participate in resource scheduling, but only a small number of consensus nodes participate in resource scheduling. This avoids the problem of high resource scheduling management pressure caused by managing and scheduling all consensus nodes through a cloud management platform in related technologies, thereby improving the efficiency of resource scheduling.

[0012] In addition, in this application, after the broadcast node is determined, the target consensus node is selected through the broadcast node for resource scheduling, which relieves the pressure on the network layer of the multi-cloud collaborative network. As a result, the multi-cloud collaborative network can have more service capabilities to respond to users' resource scheduling requests, thereby improving the response speed of resource scheduling requests and further improving the efficiency of resource scheduling.

[0013] Therefore, the solution provided in this application solves the problem of low resource scheduling efficiency in related technologies, reduces the management pressure of resource scheduling, and improves the efficiency of resource scheduling. Attached Figure Description

[0014] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 This is a schematic diagram of the resource scheduling structure of a cloud management platform in related technologies;

[0016] Figure 2 This is a flowchart illustrating the resource scheduling process in related technologies;

[0017] Figure 3 This is a schematic diagram of a multi-cloud collaborative network provided in one embodiment of this application;

[0018] Figure 4 This is a schematic flowchart of a blockchain-based resource scheduling method provided in one embodiment of this application;

[0019] Figure 5 This is a flowchart illustrating a blockchain-based resource scheduling method provided in one embodiment of this application;

[0020] Figure 6 This is a schematic diagram of the structure of a blockchain-based resource scheduling device provided in another embodiment of this application;

[0021] Figure 7 This is a schematic diagram of the structure of an electronic device provided in another embodiment of this application. Detailed Implementation

[0022] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0023] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0024] To facilitate understanding, before explaining the solutions provided in the embodiments of this application, the background of the solutions provided in this application will be explained.

[0025] With the rapid development of cloud computing services, various cloud services such as public cloud, private cloud, and edge cloud exist in the market. The existence of these diverse cloud services creates a need for resource scheduling among them. In related technologies, cloud management platforms are typically used to schedule cloud resources in multi-cloud collaboration. The resource scheduling structure of a cloud management platform is as follows: Figure 1 As shown.

[0026] Depend on Figure 1 It is known that in related technologies, cloud management platforms deploy proxy services in different types of cloud services (such as private cloud, public cloud, and edge cloud). The cloud management platform can interact with cloud resource clusters in each cloud service through these proxy services. Specifically, the proxy service can be used to monitor and collect cloud resource service information of the cloud resource clusters within its respective cloud service. This information may include resource type, name, specifications, resource usage, service operation status, and other details.

[0027] In addition, by Figure 1It is understood that the cloud management platform can provide resource information collection services, resource scheduling services, access control services, resource application services, and resource information display services to various cloud services. Among these, the resource information collection service controls the proxy services within each cloud service to collect information at a certain frequency. The proxy services then transmit the collected information back to the cloud management platform, which compares the collected information with existing data and updates and saves any changed data. This data forms the foundation for the cloud management platform's resource scheduling.

[0028] Figure 2 It shows the basis Figure 1 The flowchart shown illustrates the resource scheduling process performed by the cloud management platform. Figure 2 As shown, the process includes the following steps:

[0029] S20: The resource requester initiates a cloud resource request containing cloud resource requirements to the cloud management platform. The cloud management platform receives the cloud resource request and parses it to determine the resource type, specifications, quantity, etc. required by the resource requester.

[0030] S21, the cloud management platform searches for available resources among the remaining resources of various types of cloud services based on the cloud resource request, performs resource scheduling, and then sends scheduling instructions to the agent service in the relevant cloud service.

[0031] S22. After receiving the scheduling instruction, the agent service performs corresponding cloud resource deployment initialization and other operations to generate the cloud resources required by the resource requester.

[0032] S23, the cloud management platform collects all cloud resource generation information and provides feedback on the access and usage information of the corresponding cloud resources to the resource requesters through platform messages, emails, and other means.

[0033] S24, the resource requester accesses cloud resources and develops subsequent business functions.

[0034] As can be seen from steps S20 to S24 above, in related technologies, cloud resource scheduling in multi-cloud collaboration is handled by a centralized cloud management platform, relying on the platform for statistics, matching, and scheduling of various cloud service resources under its jurisdiction. With the growth of service cluster size and the number of servers, the cloud management platform will become a bottleneck for cloud resource scheduling in multi-cloud collaboration.

[0035] To address the aforementioned problems, this application proposes a blockchain-based resource scheduling method, apparatus, electronic device, and storage medium, wherein the method is applied to... Figure 3 In the multi-cloud collaborative network shown.

[0036] Depend on Figure 3It is known that the multi-cloud collaboration network consists of various types of multi-cloud scheduling smart contracts and multi-cloud collaboration chains. Among them, the multi-cloud collaboration chain consists of a multi-cloud scheduling consensus algorithm and a multi-cloud profile ledger. The multi-cloud profile ledger is used to record the configuration information and service deployment information of service clusters in various cloud services. The information recorded in the multi-cloud profile ledger is the basis for multi-cloud resource scheduling.

[0037] Furthermore, it should be noted that in this application, the nodes in the blockchain include at least ledger nodes and consensus nodes. Each service cluster corresponds to at least one ledger node and one consensus node. That is, the ledger nodes in the blockchain are distributed across different service clusters of various cloud services. A small number of consensus nodes select suitable cluster resources by executing a multi-cloud scheduling consensus algorithm. The ledger nodes on the selected service clusters execute the corresponding multi-cloud scheduling smart contracts, which execute cluster deployment according to the scheduling transaction strategy. By leveraging the ledger data sharing characteristic of blockchain nodes, information of different types of cloud services is synchronized in the multi-cloud collaboration chain, and a multi-cloud computing consensus scheduling algorithm is used to schedule the resources of each cloud service, thereby improving the scheduling efficiency of service resources.

[0038] The following section introduces the blockchain-based resource scheduling method provided in this application.

[0039] Figure 4 A flowchart illustrating a blockchain-based resource scheduling method according to an embodiment of this application is shown. Figure 4 As shown, the method includes the following steps:

[0040] Step S401: In response to the resource scheduling request, poll the multiple consensus nodes of the blockchain to determine the broadcast node from among the multiple consensus nodes.

[0041] In step S401, the resource scheduling request is a request message sent by the resource requester to the multi-cloud collaborative network. The resource scheduling request includes at least the resource requirement information of the resource requester and the service scenario of the required resource (e.g., big data service scenario, artificial intelligence service scenario, network application service scenario, database service scenario, etc.).

[0042] Additionally, in step S401, a consensus node corresponds to a service cluster, wherein the consensus node is used to execute a multi-cloud scheduling consensus algorithm to select a suitable service cluster from multiple service clusters for resource scheduling.

[0043] In one example, after receiving a resource scheduling request from a resource requester, the multi-cloud collaboration network parses the resource scheduling request to obtain information such as the resource requirements of the resource requester and the corresponding service scenarios. Then, based on the resource requirement information, the multi-cloud collaboration network polls multiple consensus nodes of the blockchain to select a broadcast node that corresponds to the resource requirement information from the multiple consensus nodes.

[0044] As an example, a multi-cloud collaborative network can poll multiple consensus nodes according to certain rules. For instance, it can determine the broadcast node from multiple consensus nodes based on the distance between the service cluster corresponding to the consensus node and the resource demander; or it can determine the broadcast node from multiple consensus nodes based on the remaining resource information of the service cluster corresponding to the consensus node; or it can determine the broadcast node from multiple consensus nodes by combining the distance between the service cluster and the resource demander, as well as the remaining resource information of the service cluster.

[0045] It should be noted that by step S401, a broadcast node is selected from multiple consensus nodes. This broadcast node can be used for the selection of subsequent consensus nodes and resource scheduling, thereby dispersing the resource scheduling pressure of the multi-cloud collaborative network.

[0046] Step S402: Determine multiple target consensus nodes from multiple other consensus nodes based on the broadcast node.

[0047] In step S402, the multiple other consensus nodes are consensus nodes other than the broadcast node among the multiple consensus nodes.

[0048] In one example, after determining the broadcast node from multiple consensus nodes, the broadcast node can determine multiple target consensus nodes from the other consensus nodes based on the amount of pending tasks and response time corresponding to each other consensus node, where the response time is the duration for the corresponding other consensus nodes to respond to the broadcast message sent by the broadcast node.

[0049] Specifically, the broadcast node broadcasts a message "recruiting" a target consensus node to other consensus nodes. Upon receiving this message, other consensus nodes report their current number of pending tasks to the broadcast node. The broadcast node records the number of pending tasks reported by other consensus nodes and the response time of each node in response to the broadcast message. Based on the number of pending tasks and the response time, the broadcast node scores the other consensus nodes, allowing it to select candidate consensus nodes. Further, after identifying candidate consensus nodes, the broadcast node sends a confirmation message to them to participate in the task. If a candidate consensus node replies with a confirmation message, the broadcast node designates that candidate node as the target consensus node; otherwise, it does not.

[0050] Furthermore, after selecting the target consensus node from other consensus nodes, the broadcast node and the target consensus node together constitute the consensus processing cluster for subsequent sorting and block production operations of this resource scheduling request.

[0051] In one example, when scoring other consensus nodes based on the amount of pending tasks and response time, the broadcast node can set weights based on the task volume range within which the pending tasks fall. Different task volume ranges correspond to different weights; the more pending tasks, the smaller the corresponding weight. Similarly, the broadcast node can set weights based on the response time range within which the response time falls. Different response time ranges correspond to different weights; the longer the response time, the smaller the corresponding weight. Based on these rules, the broadcast node can score other consensus nodes, with higher scores indicating a greater likelihood of that node being used for resource scheduling. Furthermore, based on these scores, the broadcast node can select consensus nodes with low load pressure and fast response speeds as target consensus nodes.

[0052] In another example, the broadcast node can select the target consensus node not through scoring, but through other methods. Specifically, the broadcast node first determines whether the response times of other consensus nodes exceed a time threshold, and then selects one or more consensus nodes with the fewest pending tasks as the target consensus node from among the consensus nodes that have not exceeded the time threshold.

[0053] It should be noted that after the broadcast node is determined, the target consensus node is selected through the broadcast node for resource scheduling. There is no need for the multi-cloud collaborative network to select a consensus node, thereby relieving the pressure on the multi-cloud collaborative network at the network layer. The multi-cloud collaborative network can have more service capabilities to respond to users' resource scheduling requests, thereby improving the response speed of resource scheduling requests and further improving the efficiency of resource scheduling.

[0054] Step S403: Schedule service resources in multiple service clusters based on broadcast nodes and multiple target consensus nodes.

[0055] In step S403, after determining the broadcast node and multiple target consensus nodes, the broadcast node and multiple target consensus nodes can perform resource scheduling on multiple service clusters. It is noteworthy that in this application, not all consensus nodes participate in resource scheduling; instead, a small number of consensus nodes that meet the resource scheduling requirements participate. This avoids the problem of high resource scheduling management pressure caused by managing and scheduling all consensus nodes through a cloud management platform in related technologies, thereby improving the efficiency of resource scheduling.

[0056] Based on the scheme defined in steps S401 to S403 above, it can be understood that this application adopts a method of determining other consensus nodes based on the selected consensus node for resource scheduling. After responding to the resource scheduling request, a polling operation is performed on multiple consensus nodes of the blockchain to determine a broadcast node from among them. Then, the broadcast node determines multiple target consensus nodes from among the multiple other consensus nodes based on the amount of pending tasks and response time corresponding to each other consensus node. Finally, service resources in multiple service clusters are scheduled based on the broadcast node and the multiple target consensus nodes. Here, the multiple other consensus nodes are consensus nodes other than the broadcast node among the multiple consensus nodes, and the response time is the duration for the corresponding other consensus node to respond to the broadcast message sent by the broadcast node.

[0057] As can be seen from the above, in this application, multiple consensus nodes are first polled to obtain broadcast nodes, and then target consensus nodes are selected for resource scheduling based on the broadcast nodes. Thus, in this application, not all consensus nodes participate in resource scheduling, but only a small number of consensus nodes participate in resource scheduling. This avoids the problem of high resource scheduling management pressure caused by managing and scheduling all consensus nodes through a cloud management platform in related technologies, thereby improving the efficiency of resource scheduling.

[0058] In addition, in this application, after the broadcast node is determined, the target consensus node is selected through the broadcast node for resource scheduling, which relieves the pressure on the network layer of the multi-cloud collaborative network. As a result, the multi-cloud collaborative network can have more service capabilities to respond to users' resource scheduling requests, thereby improving the response speed of resource scheduling requests and further improving the efficiency of resource scheduling.

[0059] Therefore, the solution provided in this application solves the problem of low resource scheduling efficiency in related technologies, reduces the management pressure of resource scheduling, and improves the efficiency of resource scheduling.

[0060] The following combination Figure 4This application provides an explanation of the blockchain-based resource scheduling method.

[0061] Depend on Figure 4 It can be seen that after receiving the resource scheduling request, the multi-cloud collaborative network executes step S401, which is to poll multiple consensus nodes of the blockchain to determine the broadcast node from among the multiple consensus nodes.

[0062] Specifically, the multi-cloud collaborative network detects the distance between the requester initiating the resource scheduling request and the service cluster corresponding to each consensus node; it then sorts the multiple consensus nodes based on the distance, obtaining a ranking result; and finally, it performs a round-robin operation on the multiple consensus nodes based on the ranking result to determine the broadcast node. The broadcast node is the consensus node corresponding to the target service cluster, which is the first service cluster among the multiple service clusters that can satisfy the resource requirement information corresponding to the resource scheduling request.

[0063] In one example, the multi-cloud collaborative network can first detect the distance between each service cluster and the resource demander, and sort the consensus nodes corresponding to the service clusters in order of distance from nearest to farthest; then, it can determine the first consensus node corresponding to the service cluster that can perform resource scheduling from the sorted consensus nodes, which is the broadcast node mentioned above.

[0064] It should be noted that the above method of determining broadcast nodes allows distributed consensus nodes to assume the responsibility of resource scheduling nearby, which can significantly improve the timeliness of resource scheduling and the upper limit of the load that the scheduling system can bear.

[0065] Furthermore, such as Figure 4 As shown, after the broadcast node is determined, it determines the target consensus node based on the number of tasks to be processed and the response time of the consensus node, i.e., step S402 is executed. Then, step S403 is executed in the multi-cloud collaboration network, which is to schedule service resources in multiple service clusters based on the broadcast node and multiple target consensus nodes.

[0066] Specifically, the multi-cloud collaborative network parses resource scheduling requests based on broadcast nodes and multiple target consensus nodes to obtain resource demand information and service scenarios corresponding to the resource scheduling requests. Then, based on the resource demand information and the multi-cloud profile ledger, candidate clusters are determined from multiple service clusters, and target smart contract algorithms corresponding to the service scenarios are determined. Finally, service resources in the candidate clusters are scheduled based on the target smart contract algorithm.

[0067] It should be noted that the aforementioned multi-cloud profile ledger contains resource information for service clusters corresponding to different types of cloud services. This resource information includes at least resource configuration information and transaction information. Specifically, resource configuration information may include, but is not limited to, cloud service category, cluster name, cluster service address, resource region, resource type, total amount of resources such as CPU cores, memory, and storage, remaining total amount of resources such as CPU cores, memory, and storage, and total resource details (CPU cores, remaining resource details for CPU cores, memory, and storage).

[0068] Transaction information is used to record transaction information generated on the multi-cloud collaboration chain during resource scheduling. This transaction information is a detailed record of resource usage in the multi-cloud collaboration network and also serves as the basis for information changes in the multi-cloud profile ledger. Transaction information may include, but is not limited to, transaction identifier, transaction time, transaction initiator, and transaction details. Among these, transaction details may include, but are not limited to, resource specifications (e.g., number of CPU cores, memory size, storage size), resource quantity, requested resource type, deployment medium, deployment server, deployment strategy, and scheduling type.

[0069] In one example, a multi-cloud collaborative network can collect resource configuration information and transaction information corresponding to multiple service clusters by executing corresponding smart contract algorithms, and generate a multi-cloud profile ledger based on the resource configuration information and transaction information of multiple service clusters.

[0070] It should be noted that the cloud services corresponding to the above-mentioned service clusters are at least partially different. For example, the cloud service corresponding to service cluster 1 is a private cloud, while the cloud service corresponding to service cluster 2 is a public cloud.

[0071] In addition, in related technologies, there is a lack of effective means of collaboration between cloud services, and cloud services cannot synchronize their own resource status in a timely manner. The resource scheduling of cloud services relies heavily on a centralized cloud management platform, which cannot meet the business needs in cross-cloud service scenarios. That is, in related technologies, when scheduling resources, only resources from one type of cloud service can be scheduled.

[0072] It is noteworthy that, since the cloud service types corresponding to the multiple service clusters in this application are at least partially different, the resource information in the multi-cloud profile ledger comes from different types of cloud services. Therefore, resource scheduling based on this multi-cloud profile ledger can achieve cross-cloud service resource scheduling; that is, resource scheduling can be performed on service clusters of different types of cloud services. Furthermore, this application can achieve cross-cloud service resource scheduling solely through the multi-cloud profile ledger, simplifying the execution process and effectively improving the efficiency of resource scheduling in cross-cloud service scenarios.

[0073] In one example, after determining the broadcast node and multiple target consensus nodes through steps S401 and S402, the multi-cloud collaborative network parses the resource scheduling request based on the broadcast node and multiple target consensus nodes to obtain the resource demand information corresponding to the resource scheduling request and the service scenario corresponding to the resource scheduling request.

[0074] Specifically, after receiving a resource scheduling request from a resource requester, the broadcast node and multiple target consensus nodes execute a multi-cloud scheduling consensus algorithm to parse the request and obtain resource requirement information, such as specifications, quantity, cloud service type, geographic requirements, and service exclusivity requirements. They can also obtain the service scenario corresponding to the resource scheduling request, such as artificial intelligence or big data services. In other words, before sending a resource scheduling request to the multi-cloud collaboration network, the resource requester can specify the application scenario of the resources to be invoked from various service scenarios.

[0075] Furthermore, after determining the resource demand information of the resource demanders, the multi-cloud scheduling consensus algorithm is executed in the multi-cloud collaboration network to determine candidate clusters from multiple service clusters based on the resource demand information and the multi-cloud profile ledger.

[0076] Specifically, the multi-cloud collaboration network identifies target resource information that matches resource demand information from the resource information contained in the multi-cloud profile ledger, and identifies the service clusters corresponding to the target resource information as candidate clusters. That is, the multi-cloud collaboration network executes a multi-cloud scheduling consensus algorithm to select suitable service clusters from the resource information in the multi-cloud profile ledger for use. The matching of target resource information with resource demand information indicates that the target resource information can meet the resource scheduling requirements corresponding to the resource demand information.

[0077] It should be noted that the candidate clusters identified by the above method can belong to the same type of cloud service as the service cluster where the resource demander is located, for example, both belong to private cloud; or they can belong to different types of cloud services than the service cluster where the resource demander is located, for example, the candidate cluster belongs to private cloud while the service cluster where the resource demander is located belongs to public cloud.

[0078] Furthermore, after identifying candidate clusters from multiple service clusters, the multi-cloud collaborative network determines the target smart contract algorithm corresponding to the service scenario.

[0079] It should be noted that, by Figure 3It is known that multi-cloud collaborative networks deploy different types of multi-cloud scheduling smart contracts, which undertake responsibilities such as service deployment, cluster access, and the collection and updating of profile ledger information. To adapt to the different deployment requirements of various services in the cloud environment, multi-cloud scheduling smart contracts are differentiated into different types for different scenarios. For example, there are smart contract algorithms suitable for artificial intelligence service scenarios, smart contract algorithms suitable for big data service scenarios, smart contract algorithms suitable for network application service scenarios, and smart contract algorithms suitable for database service scenarios. Among these, the required request resources, request resource types, deployment media, and deployment strategies may differ between different types of multi-cloud scheduling smart contracts during deployment.

[0080] In addition, when the service scenario corresponding to the resource scheduling request is not an existing service scenario in the multi-cloud collaboration network, the multi-cloud collaboration network can also write new smart contracts according to the unified multi-cloud scheduling smart contract data structure to adapt to the new service deployment requirements (i.e., service scenarios).

[0081] In one example, a multi-cloud collaboration network can send scheduling requests to a multi-cloud scheduling smart contract through a unified data structure. This data structure describes the process or steps by which the multi-cloud scheduling smart contract executes the scheduling and deployment tasks of service resources. This data structure may include, but is not limited to, the requested resource quantity, requested resource type, deployment medium, deployment server, deployment strategy, and scheduling type. Specifically, the requested resource quantity describes information related to the service resources required for service deployment, such as resource specifications (e.g., number of CPU cores, memory size, storage size) and the quantity of resources; the requested resource type describes the method of providing the service resources, such as whether the service resources are provided via virtual machines or containers; the deployment medium describes the installation package and image used during service deployment; the deployment server describes the service cluster used during service deployment and the servers within the service cluster; the deployment strategy describes the scripts, startup commands, etc., used during service deployment; and the scheduling type describes the type of scheduling action, which includes, but is not limited to, cluster access actions, resource acquisition actions, service deployment actions, resource scaling actions, and exception scheduling actions.

[0082] In addition, the multi-cloud scheduling smart contract includes contract methods, which include, but are not limited to, cluster access methods, resource acquisition methods, deployment transaction methods, resource scaling methods, and abnormal scheduling methods.

[0083] For the cluster access method, this method is executed when a new service cluster is added to the cloud environment to register and authorize the newly added service cluster, and then deploy an accounting node in the service cluster. This accounting node is added to the multi-cloud collaboration chain.

[0084] The resource collection method is used to periodically collect resource configuration information and service deployment information of the service cluster, and update the collected information to the multi-cloud profile ledger in a timely manner. The accounting nodes in different service clusters can use this smart contract method to collect relevant information of the service cluster and aggregate the collected information into the multi-cloud collaboration chain.

[0085] The deployment transaction method is used to deploy services based on scheduling transaction requests in a multi-cloud collaboration network and update relevant information about the service cluster after deployment to the multi-cloud profile ledger.

[0086] The resource scaling method is used to scale up or down the resources used by the service cluster. The method can perform corresponding resource expansion or reduction actions according to transaction parameters. After the scaling operation is completed, the relevant information on the multi-cloud profile ledger is updated synchronously.

[0087] The abnormal scheduling method is used to reschedule and deploy service resources that are abnormal and cannot operate normally. The accounting node submits a profile ledger update transaction request. Based on the original deployment information such as the requested resource quantity, requested resource type, deployment medium, and deployment strategy on the multi-cloud profile ledger, the service resource is rescheduled to other normal service clusters for deployment. After successful deployment, the multi-cloud profile ledger is updated.

[0088] In one example, after determining the target smart contract algorithm, the multi-cloud collaborative network can schedule service resources in candidate clusters based on the target smart contract algorithm. To ensure that service resources in candidate clusters can be scheduled, the multi-cloud collaborative network also verifies the candidate clusters before scheduling them based on the target smart contract algorithm.

[0089] Specifically, the multi-cloud collaborative network verifies the cluster status and resource information of the candidate clusters based on the accounting nodes of the candidate clusters, and obtains the verification results. If the verification results indicate that the cluster status and resource information of the candidate clusters meet the transaction requirements corresponding to the resource scheduling request, endorsement information corresponding to the verification results is generated.

[0090] It should be noted that the cluster status mentioned above includes, but is not limited to, the availability status of the service cluster (including available and unavailable status), remaining memory, etc. The endorsement information above indicates successful verification and that the transaction is legitimate.

[0091] As an example, the ledger nodes in the candidate cluster can run a multi-cloud scheduling smart contract to verify the cluster status and resource information of the candidate cluster to confirm whether the candidate cluster can meet the resource scheduling requirements. For example, it can verify whether the candidate cluster is available and whether the remaining memory of the candidate cluster is sufficient to meet the scheduling requirements. If the candidate cluster is available and / or the remaining memory of the candidate cluster is sufficient to meet the scheduling requirements, the candidate cluster verification is successful. At this point, endorsement information is generated and returned to the broadcast node and multiple target consensus nodes.

[0092] After generating endorsement information corresponding to the verification results, the multi-cloud collaborative network generates transaction blocks based on the endorsement information and sends the block data of the transaction blocks to the accounting nodes of multiple service clusters so that the accounting nodes of multiple service clusters can update the multi-cloud profile ledger.

[0093] As an example, broadcast nodes and multiple target consensus nodes in a multi-cloud collaboration network generate transaction blocks based on received endorsement information. These transaction blocks include current resource scheduling transactions and endorsement information. The block data (e.g., the block's deployment location) is then sent to all ledger nodes in the multi-cloud collaboration network, enabling each ledger node to record the block data and update the multi-cloud profile ledger.

[0094] After the block data is recorded, the multi-cloud scheduling smart contract executes service deployment according to the deployment strategy, calls the corresponding resource interface in this cloud service to perform resource allocation, initialization and other operations, and comprehensively determines the service resources to be scheduled based on the requirements such as region and service mutual exclusion included in the resource scheduling request.

[0095] This concludes the explanation of the blockchain-based resource scheduling method provided in this application. As an example, Figure 5 The overall flowchart of the blockchain-based resource scheduling method is shown. Figure 5 It can be seen that the method includes the following steps:

[0096] Step S50: The multi-cloud collaborative network receives a resource scheduling request initiated by the resource requester.

[0097] In step S51, the multi-cloud collaborative network polls multiple consensus nodes to determine the broadcast node, and then the broadcast node determines the target consensus node based on the amount of pending tasks and response time of other consensus nodes.

[0098] In step S52, the broadcast node and the target consensus node parse the resource scheduling requirements to determine the resource scheduling requirements of the resource requester.

[0099] In step S53, the broadcast nodes and target consensus nodes in the multi-cloud collaborative network determine candidate clusters from multiple service clusters based on resource scheduling requirements and the multi-cloud profile ledger.

[0100] In step S54, the accounting node of the candidate cluster verifies the candidate cluster, and if the verification is successful, generates endorsement information and returns the endorsement information to the broadcast node and the target consensus node.

[0101] In step S55, the broadcast node and the target consensus node generate transaction blocks based on the endorsement information and send the block data of the transaction blocks to all accounting nodes.

[0102] In step S56, all accounting nodes record block data and update the multi-cloud profile ledger.

[0103] Step S57: Execute service deployment according to the deployment strategy.

[0104] As described above, in this application, the multi-cloud collaboration network consists of multiple blockchain nodes distributed across various cloud service clusters. The ledger nodes in the blockchain are pre-deployed in each service cluster of the cloud service. The multi-cloud scheduling smart contract in the ledger nodes can monitor and collect resource configuration information and service operation information of their respective service clusters and record it on the blockchain. Since the blockchain nodes share ledger data through a multi-cloud profile ledger, the information collected by all ledger nodes together constitutes the multi-cloud profile ledger of each cloud service. When a new service cluster is detected, the multi-cloud collaboration chain deploys blockchain nodes in the new service cluster and incorporates it into the management and scheduling scope of the multi-cloud collaboration network. This effectively addresses the management and scheduling pressure caused by the expansion of service cluster size in related technologies, thereby improving the efficiency of resource scheduling. Furthermore, the multi-cloud collaboration chain nodes are distributed across different cloud service environments, effectively meeting cross-cloud computing business needs. Distributed consensus nodes assume resource scheduling responsibility locally, significantly improving the timeliness of resource scheduling and the upper limit of the scheduling system's load capacity.

[0105] Therefore, the solution provided in this application creatively realizes a blockchain-based multi-cloud collaboration network based on actual production needs. It adopts a decentralized design and utilizes blockchain nodes to collect configuration and operation information of different cloud service clusters. Each scheduling task involves only a small number of consensus nodes in selecting the service cluster, which can improve the efficiency of information collection and sharing in cross-cloud service scenarios, effectively alleviate the resource management pressure of centralized cloud management platform solutions in related technologies, significantly improve the service cluster scale and scheduling response speed in cross-cloud service scenarios, meet the business needs of cross-cloud computing, and has strong practicality.

[0106] This application also provides a blockchain-based resource scheduling device, such as... Figure 6As shown, the device includes: a polling module 601, a node selection module 602, and a resource scheduling module 603.

[0107] The polling module 601 is used to respond to resource scheduling requests, poll multiple consensus nodes of the blockchain, and determine the broadcast node from the multiple consensus nodes. Each consensus node corresponds to a service cluster.

[0108] The node selection module 602 is used to determine multiple target consensus nodes from multiple other consensus nodes based on the broadcast node. The multiple other consensus nodes are consensus nodes other than the broadcast node. The multiple target consensus nodes are consensus nodes determined by the broadcast node from multiple other consensus nodes according to the amount of pending tasks and response time corresponding to each other consensus node. The response time is the duration for the corresponding other consensus node to respond to the broadcast message sent by the broadcast node.

[0109] The resource scheduling module 603 is used to schedule service resources in multiple service clusters based on broadcast nodes and multiple target consensus nodes.

[0110] As can be seen from the above, in this application, multiple consensus nodes are first polled to obtain broadcast nodes, and then target consensus nodes are selected for resource scheduling based on the broadcast nodes. Thus, in this application, not all consensus nodes participate in resource scheduling, but only a small number of consensus nodes participate in resource scheduling. This avoids the problem of high resource scheduling management pressure caused by managing and scheduling all consensus nodes through a cloud management platform in related technologies, thereby improving the efficiency of resource scheduling.

[0111] In addition, in this application, after the broadcast node is determined, the target consensus node is selected through the broadcast node for resource scheduling, which relieves the pressure on the network layer of the multi-cloud collaborative network. As a result, the multi-cloud collaborative network can have more service capabilities to respond to users' resource scheduling requests, thereby improving the response speed of resource scheduling requests and further improving the efficiency of resource scheduling.

[0112] Therefore, the solution provided in this application solves the problem of low resource scheduling efficiency in related technologies, reduces the management pressure of resource scheduling, and improves the efficiency of resource scheduling.

[0113] In one example, the polling module includes a distance detection module, a sorting module, and a node determination module. The distance detection module detects the distance between the requester initiating the resource scheduling request and the service cluster corresponding to each consensus node. The sorting module sorts the multiple consensus nodes based on distance to obtain a sorting result. The node determination module polls the multiple consensus nodes based on the sorting result to determine the broadcast node from among them. The broadcast node is the consensus node corresponding to the target service cluster, which is the first service cluster among the multiple service clusters that can satisfy the resource requirements information corresponding to the resource scheduling request.

[0114] In one example, the resource scheduling module includes: a request parsing module, a first cluster determination module, a contract determination module, and a resource scheduling submodule. The request parsing module parses resource scheduling requests based on broadcast nodes and multiple target consensus nodes to obtain the resource requirement information and the service scenario corresponding to the resource scheduling request. The first cluster determination module determines candidate clusters from multiple service clusters based on resource requirement information and a multi-cloud profile ledger. The multi-cloud profile ledger contains resource information for service clusters corresponding to different types of cloud services, including at least resource configuration information and transaction information. The contract determination module determines the target smart contract algorithm corresponding to the service scenario. The resource scheduling submodule schedules service resources in the candidate clusters based on the target smart contract algorithm.

[0115] In one example, the first cluster determination module includes a resource determination module and a second cluster determination module. The resource determination module is used to determine target resource information that matches the resource demand information from the resource information contained in the multi-cloud profile ledger; the second cluster determination module is used to determine the service cluster corresponding to the target resource information as a candidate cluster.

[0116] In one example, the blockchain-based resource scheduling device further includes a cluster verification module and an endorsement generation module. The cluster verification module verifies the cluster status and resource information of the candidate cluster based on the accounting nodes of the candidate cluster before scheduling service resources in the candidate cluster according to the target smart contract algorithm, thus obtaining a verification result. The endorsement generation module generates endorsement information corresponding to the verification result, provided that the verification result indicates that the cluster status and resource information of the candidate cluster meet the transaction requirements corresponding to the resource scheduling request.

[0117] In one example, the blockchain-based resource scheduling device also includes a block generation module and a ledger update module. The block generation module generates transaction blocks based on the endorsement information corresponding to the verification results. The ledger update module sends the block data of the transaction blocks to the accounting nodes of multiple service clusters, enabling the accounting nodes of the multiple service clusters to update the multi-cloud profile ledger.

[0118] In one example, the blockchain-based resource scheduling device further includes an information collection module and a ledger generation module. The information collection module is used to collect resource configuration information and transaction information corresponding to multiple service clusters, wherein the types of cloud services corresponding to the multiple service clusters are at least partially different. The ledger generation module is used to generate a multi-cloud profile ledger based on the resource configuration information and transaction information of the multiple service clusters.

[0119] The blockchain-based resource scheduling device provided in this application embodiment can realize the various processes implemented in the aforementioned method embodiments. To avoid repetition, it will not be described again here.

[0120] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0121] Figure 7 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0122] The electronic device may include a processor 701 and a memory 702 storing computer program instructions.

[0123] Specifically, the processor 701 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0124] Memory 702 may include mass storage for data or instructions. For example, and not limitingly, memory 702 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 702 may include removable or non-removable (or fixed) media. Where appropriate, memory 702 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 702 is non-volatile solid-state memory.

[0125] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to one aspect of this application.

[0126] The processor 701 reads and executes computer program instructions stored in the memory 702 to implement any of the blockchain-based resource scheduling methods in the above embodiments.

[0127] In one example, the electronic device may also include a communication interface 703 and a bus 710. For example, Figure 7 As shown, the processor 701, memory 702, and communication interface 703 are connected through bus 710 and complete communication with each other.

[0128] The communication interface 703 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0129] Bus 710 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 710 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0130] Furthermore, in conjunction with the blockchain-based resource scheduling methods described in the above embodiments, this application embodiment can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the blockchain-based resource scheduling methods described in the above embodiments.

[0131] Furthermore, in conjunction with the blockchain-based resource scheduling method described in the above embodiments, this application embodiment can provide a computer program product for implementation. When the instructions in this computer program product are executed by the processor of an electronic device, the electronic device performs any of the blockchain-based resource scheduling methods described in the above embodiments.

[0132] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0133] The functional modules shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0134] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0135] The aspects of this application have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0136] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A resource scheduling method based on blockchain, characterized in that, include: In response to a resource scheduling request, a polling operation is performed on multiple consensus nodes of the blockchain to determine a broadcast node from among the multiple consensus nodes, wherein one consensus node corresponds to one service cluster; Based on the broadcast node, multiple target consensus nodes are determined from multiple other consensus nodes. The multiple other consensus nodes are consensus nodes other than the broadcast node. The multiple target consensus nodes are consensus nodes determined by the broadcast node from the multiple other consensus nodes according to the amount of pending tasks and response time corresponding to each other consensus node. The response time is the duration for the corresponding other consensus node to respond to the broadcast message sent by the broadcast node. Service resources in multiple service clusters are scheduled based on the broadcast node and the multiple target consensus nodes. Specifically, the resource scheduling request is parsed using the broadcast node and the multiple target consensus nodes to obtain the resource requirement information and the service scenario corresponding to the resource scheduling request. Based on the resource requirement information and a multi-cloud profile ledger, candidate clusters are determined from the multiple service clusters. The multi-cloud profile ledger contains resource information for service clusters corresponding to different types of cloud services. The resource information includes at least resource configuration information and transaction information. A target smart contract algorithm corresponding to the service scenario is determined, and service resources in the candidate clusters are scheduled based on the target smart contract algorithm.

2. The resource scheduling method according to claim 1, characterized in that, A polling operation is performed on multiple consensus nodes in the blockchain to determine the broadcast node from among the multiple consensus nodes, including: Detect the distance between the requester initiating the resource scheduling request and the service cluster corresponding to each consensus node; The consensus nodes are sorted based on the distance to obtain the sorting result; Based on the sorting result, a polling operation is performed on the plurality of consensus nodes to determine the broadcast node from the plurality of consensus nodes. The broadcast node is the consensus node corresponding to the target service cluster, and the target service cluster is the first service cluster among the plurality of service clusters that can satisfy the resource requirement information corresponding to the resource scheduling request.

3. The resource scheduling method according to claim 1, characterized in that, Based on the resource demand information and the multi-cloud profile ledger, candidate clusters are determined from the multiple service clusters, including: Target resource information that matches the resource demand information is determined from the resource information contained in the multi-cloud profile ledger; The service cluster corresponding to the target resource information is identified as the candidate cluster.

4. The resource scheduling method according to claim 1, characterized in that, Before scheduling service resources in the candidate cluster based on the target smart contract algorithm, the method further includes: The cluster status and resource information of the candidate cluster are verified based on the accounting nodes of the candidate cluster, and the verification results are obtained. If the verification result indicates that the cluster status of the candidate cluster and the resource information of the candidate cluster meet the transaction requirements corresponding to the resource scheduling request, endorsement information corresponding to the verification result is generated.

5. The resource scheduling method according to claim 4, characterized in that, After generating the endorsement information corresponding to the verification result, the method further includes: A transaction block is generated based on the endorsement information; The block data of the transaction block is sent to the accounting nodes of the multiple service clusters so that the accounting nodes of the multiple service clusters can update the multi-cloud profile ledger.

6. The resource scheduling method according to any one of claims 1 to 5, characterized in that, The method further includes: Collect resource configuration information and transaction information corresponding to the multiple service clusters, wherein the types of cloud services corresponding to the multiple service clusters are at least partially different; The multi-cloud profile ledger is generated based on the resource configuration information and transaction information of the multiple service clusters.

7. A resource scheduling device based on blockchain, characterized in that, include: The polling module is used to respond to resource scheduling requests, poll multiple consensus nodes of the blockchain, and determine the broadcast node from the multiple consensus nodes. Each consensus node corresponds to a service cluster. A node selection module is used to determine multiple target consensus nodes from multiple other consensus nodes based on the broadcast node. The multiple other consensus nodes are consensus nodes other than the broadcast node. The multiple target consensus nodes are consensus nodes determined by the broadcast node from the multiple other consensus nodes according to the amount of pending tasks and response time corresponding to each other consensus node. The response time is the duration for the corresponding other consensus node to respond to the broadcast message sent by the broadcast node. The resource scheduling module is used to schedule service resources in multiple service clusters based on the broadcast node and the multiple target consensus nodes. Specifically, it parses the resource scheduling request based on the broadcast node and the multiple target consensus nodes to obtain resource requirement information and the service scenario corresponding to the resource scheduling request. Based on the resource requirement information and a multi-cloud profile ledger containing resource information of service clusters corresponding to different types of cloud services, the module determines a target smart contract algorithm corresponding to the service scenario and schedules service resources in the candidate clusters based on the target smart contract algorithm.

8. An electronic device, characterized in that, Electronic devices include: processors and memory storing computer program instructions; When the processor executes the computer program instructions, it implements the blockchain-based resource scheduling method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, A computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the blockchain-based resource scheduling method as described in any one of claims 1-6.

Images