Resource scheduling method, electronic device, and computer-readable storage medium

Abstract

The present disclosure relates to the fields of computer technologies and cloud computing technologies, and provides a resource scheduling method, an electronic device, and a computer-readable storage medium. The method comprises: acquiring instance performance data, wherein the instance performance data is performance index data which is obtained by performing performance data acquisition on a plurality of cloud server instances created on at least one physical server; generating label information on the basis of the instance performance data, wherein the label information comprises target object labels and instance labels, the target object labels are used for describing target object behavior attributes, and the instance labels are used for describing instance performance; determining a target resource inventory by means of the label information; and using the label information and the target resource inventory to perform resource scheduling to obtain a scheduling result. The present disclosure solves the technical problems in the related art of resource waste and affected user service operation caused by the use of subsequent governance solutions such as performance throttling and online splitting failing to completely avoid the occurrence of instance performance contention events.

Description

[0001]TECHNICAL FIELD The present disclosure relates to the fields of computer technology and cloud computing technology, and more specifically, to a resource scheduling method, electronic device, and computer-readable storage medium. Background: A physical machine (Network Computer, NC) is an actual hardware device that provides computing, storage, and network resources. An instance is a virtual computing resource allocated to a user and can be a virtual machine (VM), container, or the like. Using virtualization technology, a physical machine divides its resources into multiple virtual computing resources, which can be allocated to different virtual machine instances. When a user's task demands exceed the corresponding virtual computing resources, instance performance contention occurs. Instances compete for each other's resources, resulting in wasted resources and underutilization. Currently, addressing instance performance contention typically involves subsequent governance solutions, such as performance suppression and online sharding, to ensure performance balance and reduce instance contention. However, these solutions cannot resolve instance performance contention when suppression capacity is insufficient or instance load is excessive, and they cannot completely prevent instance performance contention. Furthermore, when instance performance contention occurs, the aforementioned solutions are unable to promptly and effectively resolve the instance contention, resulting in a high risk of user service damage and impacting user service operations. Currently, no effective solution has been proposed to address the aforementioned issues. SUMMARY OF THE INVENTION The present disclosure provides a resource scheduling method, electronic device, and computer-readable storage medium to at least address the technical issue in related technologies where subsequent management solutions such as performance suppression and online sharding cannot completely prevent instance performance contention, leading to resource waste and impacting user service operations. According to one aspect of an embodiment of the present disclosure, a resource scheduling method is provided, comprising: obtaining instance performance data, wherein the instance performance data is performance indicator data obtained by collecting performance data of multiple cloud server instances created on at least one physical server; generating tag information based on the instance performance data, wherein the tag information includes: a target object tag and an instance tag, wherein the target object tag is used to describe target object behavior attributes, and the instance tag is used to describe instance performance; determining a target resource inventory based on the tag information, wherein the target resource inventory is the resource inventory currently available for scheduling; and performing resource scheduling using the tag information and the target resource inventory to obtain a scheduling result, wherein the scheduling result is used to adjust the remaining performance resource amount on the at least one physical server.According to another aspect of an embodiment of the present disclosure, a resource scheduling method is further provided, including: obtaining a cloud service instance scheduling request through a first application programming interface, wherein request data carried in the cloud service instance scheduling request includes: tag information, the tag information is generated based on instance performance data, the instance performance data is performance indicator data obtained by collecting performance data of multiple cloud server instances created on at least one physical server, the tag information includes: a target object tag and an instance tag, the target object tag is used to describe target object behavior attributes, and the instance tag is used to describe instance performance; returning a cloud service instance scheduling response through a second application programming interface, wherein response data carried in the cloud service instance scheduling response includes: a scheduling result, the scheduling result is obtained by performing resource scheduling using the tag information and a target resource inventory, the scheduling result is used to adjust the remaining performance resource amount on the at least one physical server, the target resource inventory amount is determined by the tag information, and the target resource inventory amount is the resource inventory amount currently available for scheduling. According to another aspect of an embodiment of the present disclosure, a resource scheduling method is provided, comprising: obtaining a currently input cloud service instance scheduling dialog request, wherein information carried in the cloud service instance scheduling dialog request includes tag information, the tag information being generated based on instance performance data, the instance performance data being performance indicator data obtained by collecting performance data of multiple cloud server instances created on at least one physical server, and the tag information including a target object tag and an instance tag, wherein the target object tag is used to describe target object behavior attributes, and the instance tag is used to describe instance performance; responding to the cloud service instance scheduling dialog request, returning a cloud service instance scheduling dialog reply, wherein information carried in the cloud service instance scheduling dialog reply includes a scheduling result, the scheduling result being obtained by performing resource scheduling using the tag information and a target performance resource amount, the scheduling result being used to adjust the remaining performance resource amount on the at least one physical server, the target resource inventory amount being determined by the tag information, and the target resource inventory amount being the resource inventory amount currently available for scheduling; and displaying the scheduling result in a graphical target object interface.According to another aspect of an embodiment of the present disclosure, a resource scheduling system is provided, comprising: a data collection server for collecting instance performance data from multiple cloud server instances created on at least one physical server and reporting the instance performance data to a data storage server via log data delivery; a data storage server for receiving the instance performance data reported by the data collection server and persistently storing the instance performance data; a performance profiling server for acquiring the instance performance data and generating tag information based on the instance performance data, wherein the tag information includes a target object tag and an instance tag, wherein the target object tag describes the target object's behavioral attributes, and the instance tag describes the instance's performance; a resource scheduling server for determining a target performance resource amount based on the tag information, and performing resource scheduling using the tag information and the target resource inventory to obtain a scheduling result, wherein the target resource inventory is the current resource inventory available for scheduling, and the scheduling result is used to adjust the remaining performance resource amount on at least one physical server. According to another aspect of an embodiment of the present disclosure, an electronic device is provided, comprising: a memory storing an executable program; and a processor for executing the program, wherein when the program executes, any one of the aforementioned resource scheduling methods is executed. According to another aspect of an embodiment of the present disclosure, a computer-readable storage medium is further provided. The computer-readable storage medium includes a stored executable program, wherein when the executable program runs, the device where the computer-readable storage medium is located is controlled to execute any one of the above-mentioned resource scheduling methods. In the disclosed embodiments, instance performance data corresponding to instances assigned to target objects is obtained. Tag information, including a target object tag capable of predicting the target object's future behavior and an instance tag for predicting the instance's future performance, is then generated based on the instance performance data. The generated tag information is then used to determine the current inventory of target resources available for scheduling. Finally, resource scheduling is performed using the tag information and the current inventory of target resources available for scheduling. The remaining performance resources on the source and target physical servers are appropriately adjusted to obtain a scheduling result. This achieves the goal of predicting target object behavior and instance performance, and appropriately performing online instance performance resource scheduling based on the predicted results. This effectively prevents instance performance contention, avoids instance performance contention, avoids resource waste, ensures the normal operation of target object services, and improves service stability. This addresses the technical issue in related technologies where subsequent governance solutions such as performance suppression and online sharding cannot completely prevent instance performance contention, resulting in resource waste and impacting user service operations.It should be noted that the general description above and the detailed description that follows are merely examples and explanations of the present disclosure and do not constitute limitations on the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS The drawings described herein are intended to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The illustrative embodiments of the present disclosure and their descriptions are intended to explain the present disclosure and do not constitute undue limitations on the present disclosure. In the accompanying drawings: FIG1 is a hardware block diagram of a computer terminal (or mobile device) for implementing a resource scheduling method according to Example 1 of the present disclosure; FIG2 is a flow chart of a resource scheduling method according to Example 1 of the present disclosure; FIG3 is a flow chart of instance performance data collection and reporting according to Example 1 of the present disclosure; FIG4 is a flow chart of target object classification according to Example 1 of the present disclosure; FIG5 is a flow chart of instance tag classification according to Example 1 of the present disclosure; FIG6 is a schematic diagram of a resource management module according to Example 1 of the present disclosure; FIG7 is a schematic diagram of the relationship between target objects and inventory information according to Example 1 of the present disclosure; FIG8 is a flow chart of inventory view classification according to Example 1 of the present disclosure; FIG9 is a schematic diagram of instance scheduling according to Example 1 of the present disclosure; FIG10 is a schematic diagram of linkage according to Example 1 of the present disclosure; FIG11 is a system framework diagram according to Example 1 of the present disclosure; FIG12 is a flow chart of a resource scheduling method according to Example 2 of the present disclosure; FIG13 is a flow chart of a resource scheduling method according to Example 3 of the present disclosure; FIG14 is a schematic diagram of the structure of a resource scheduling system according to Example 4 of the present disclosure; FIG15 is a schematic diagram of the structure of a resource scheduling device according to Example 5 of the present disclosure; Figure 16 is a schematic diagram of the structure of another resource scheduling device according to Example 5 of the present disclosure; Figure 17 is a schematic diagram of the structure of yet another resource scheduling device according to Example 5 of the present disclosure; and Figure 18 is a block diagram of the structure of a computer terminal according to an embodiment of the present disclosure. DETAILED DESCRIPTION: To help those skilled in the art better understand the present disclosure, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the described embodiments represent only a portion of the embodiments of the present disclosure, and are not exhaustive. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present disclosure without inventive effort should fall within the scope of protection of the present disclosure. It should be noted that the terms "first," "second," and so on, in the specification and claims of the present disclosure, and in the accompanying drawings, are used to distinguish similar objects and are not necessarily used to describe a specific order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of the present disclosure described herein can be implemented in an order other than that illustrated or described herein.Furthermore, the terms "including," "having," and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to the steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to the process, method, product, or apparatus. First, some nouns or terms appearing in the description of the embodiments of the present disclosure are subject to the following interpretations: Performance contention: In the embodiments of the present disclosure, performance contention can be understood as a situation in which multiple target objects or tasks simultaneously compete for the same computing resources in a cloud computing environment. This competition may result in resource contention, preventing some target objects or tasks from obtaining sufficient computing resources to meet their needs, thereby affecting their performance and service quality. Instance performance: This refers to the performance of a virtual machine instance on a cloud computing platform when executing computing tasks, such as computing power, storage performance, and network performance. Profile: In the embodiments of the present disclosure, a profile is a collection of information used to describe the characteristics, attributes, and behaviors of a target object or instance. By analyzing and utilizing this tag information, personalized, accurate, and efficient service and resource scheduling can be achieved. Machine templates: These templates describe different models of equipment or machines, describing their characteristics, specifications, and performance. In the manufacturing industry, each machine model has its own corresponding NC program, and the performance resources provided by each NC program vary. In cloud computing, instances are virtual computing resources allocated to users, such as virtual machines and containers. Virtualization provides resource isolation between different instances, preventing them from interfering with or accessing each other's resources, thereby ensuring security and performance. However, certain resources, such as the last-level cache (LLC), are designed as shared storage areas between multiple cores to improve data access efficiency. Consequently, different cores compete for LLC cache space, and virtualization cannot fully isolate these resources. Furthermore, in multi-tenant cloud computing, the platform typically provides the ability for multiple users or tasks to run concurrently. Therefore, when user or task demands exceed available resources, instance performance contention can still occur. Currently, subsequent governance solutions are commonly used to address instance performance contention, such as performance suppression policies. When contention occurs, the virtualization platform uses its resource suppression capabilities to control the performance resource allocation of the customer instance. However, performance suppression policies are limited by the virtualization platform's suppression capabilities and the instance load. If the virtualization's suppression capabilities are insufficient or ineffective, instance performance contention cannot be resolved.Furthermore, in proactive operations, the operations team triggers online hot migration of instances based on performance contention alerts, distributing the load on physical machines through online sharding strategies. However, when instance loads are excessive or inventory is insufficient, instance hot migration cannot be successful, resulting in an inability to resolve instance performance contention. This governance model clearly has limitations. Related technologies that address instance performance contention through subsequent governance methods such as performance suppression and online sharding have the following drawbacks: Defect 1: Inability to resolve instance performance contention when suppression capabilities are insufficient or instance loads are excessive; Defect 2: Inability to completely prevent performance contention; Defect 3: When contention actually occurs, the contention cannot be promptly and effectively resolved, resulting in wasted resources, increasing the risk of user service damage, and impacting user operations. Prior to the present disclosure, no effective solutions to these drawbacks had been proposed. Embodiment 1 According to an embodiment of the present disclosure, a resource scheduling method is provided. It should be noted that the steps illustrated in the flowcharts of the accompanying drawings can be executed in a computer system, such as a set of computer-executable instructions. Furthermore, although the flowcharts illustrate a logical sequence, in some cases, the steps illustrated or described may be executed in a different order than shown. The method embodiment provided in Embodiment 1 of the present disclosure can be executed in a mobile terminal, a computer terminal, or a similar computing device. Figure 1 is a hardware block diagram of a computer terminal (or mobile device) for implementing the resource scheduling method according to Embodiment 1 of the present disclosure. As shown in Figure 1, the computer terminal 10 (or mobile device) may include one or more processors 102 (illustrated as 102a, 102b, 102n in the figure) (the processor 102 may include, but is not limited to, a processing device such as a microprocessor (MCU) or a programmable logic device (FPGA), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, the computer terminal 10 may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS), a network interface, a power supply, and / or a camera. Those skilled in the art will appreciate that the structure shown in FIG1 is merely illustrative and does not limit the structure of the electronic device. For example, the computer terminal 10 may include more or fewer components than shown in FIG1 , or have a configuration different from that shown in FIG1 . It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuitry."The data processing circuit can be embodied in whole or in part as software, hardware, firmware, or any other combination. Furthermore, the data processing circuit can be a single, independent processing module, or fully or partially integrated into any other component of the computer terminal 10 (or mobile device). As described in the embodiments of the present disclosure, the data processing circuit acts as a processor control (e.g., selecting a variable resistor terminal path connected to an interface). Memory 104 can be used to store software programs and modules of application software, such as the program instruction / data storage device corresponding to the resource scheduling method in the embodiments of the present disclosure. Processor 102 executes the software programs and modules stored in memory 104 to perform various functional applications and data processing, thereby implementing the aforementioned resource scheduling method. Memory 104 can include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, memory 104 may further include memory located remotely from processor 102, which can be connected to computer terminal 10 via a network. Examples of the aforementioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof. Transmission device 106 is used to receive or send data via a network. Specific examples of the aforementioned network may include a wireless network provided by the communications provider of computer terminal 10. In one example, transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In one example, transmission device 106 may be a radio frequency (RF) module for wireless communication with the Internet. The display may be, for example, a touchscreen liquid crystal display (LCD), which enables a user to interact with the user interface of computer terminal 10 (or mobile device). In the aforementioned operating environment, the present disclosure provides a resource scheduling method as shown in FIG2 . FIG2 is a flow chart of a resource scheduling method according to Embodiment 1 of the present disclosure.As shown in Figure 2, the method may include the following steps: Step S21: Acquire instance performance data, where the instance performance data is performance indicator data obtained by collecting performance data from multiple cloud server instances created on at least one physical server; Step S22: Generate tag information based on the instance performance data, where the tag information includes a target object tag and an instance tag, where the target object tag is used to describe the target object's behavioral attributes, and the instance tag is used to describe the instance's performance; Step S23: Determine a target resource inventory based on the tag information, where the target resource inventory is the current resource inventory available for scheduling; Step S24: Perform resource scheduling using the tag information and the target resource inventory to obtain a scheduling result, where the scheduling result is used to adjust the remaining performance resources on the at least one physical server. It is understood that a physical machine can run multiple virtual machine instances simultaneously. The physical machine uses virtualization technology to partition its resources into multiple virtual computing resources, which are then allocated to different virtual machine instances. In the disclosed embodiments, the physical server is a physical machine (NC), and the cloud server instance is a virtual machine instance (VM). Instance performance data is performance indicator data collected from multiple cloud server instances created on at least one physical server. This refers to real-time performance indicator data collected from multiple virtual machine instances on a physical server. Performance indicator data may include metrics such as central processing unit (CPU) utilization, memory utilization, disk input / output (I / O), and network bandwidth, without limitation. For example, instance performance data can be real-time instance performance data collected for executing target object services, namely, instance performance data corresponding to instances assigned to target objects, such as instances assigned to users. A target object label can be understood as a profile of the target object, such as a user profile. A target object label describes the behavioral attributes of a target object. This label can be established by analyzing information such as the target object's characteristics, behaviors, preferences, and interests, thereby enabling a better understanding and prediction of the target object's behaviors and preferences. In the embodiments of the present disclosure, the target object's business behavior and business preferences can be better understood and predicted based on the target object's label, so that more personalized services and products can be provided to the target object to better meet the target object's business needs.An instance tag can be understood as an instance profile. It describes the instance's performance, specifically the performance and capabilities of a virtual machine instance when executing computing tasks. The instance tag may include information about the instance's processing power, storage capacity, network performance, security performance, and other aspects. For example, the instance tag can be determined based on the instance's historical performance. In the disclosed embodiments, instance tags can be used to better predict the instance's future performance, thereby enabling better resource scheduling and avoiding instance performance contention. The target resource inventory is the current available resource inventory for scheduling and can be understood as the remaining available virtual computing resources. It is understood that during system operation, to balance system load and improve system performance and stability, a virtual machine instance currently executing the target service can be migrated from one physical server to another while maintaining the instance's operational status. This instance migration process can be understood as resource scheduling. The physical server where the virtual machine instance resides before migration is the source physical server. It is understood that since the virtual machine instance on the source physical server has been migrated out, the remaining performance resources on the source physical server will increase, meaning that the performance resources of the source physical server need to be returned. The physical server where the virtual machine instance resides after migration is the target physical server. It is understood that since the virtual machine instance has been migrated to the target physical server, the remaining performance resources on the target physical server will decrease, meaning that the performance resources of the source physical server need to be deducted. In the disclosed embodiments, the scheduling result is used to adjust the remaining performance resources on at least one physical server, that is, to perform the return and deduction operations on the remaining performance resources on the source and target physical servers during resource scheduling. By way of example, the source and target physical servers can be one or more, determined based on actual circumstances and not limited herein.In embodiments of the present disclosure, instance performance data corresponding to instances assigned to a target object can be obtained. Tag information including a target object tag capable of predicting the target object's future behavior and an instance tag for predicting the instance's future performance can then be generated based on the instance performance data. The generated tag information is then used to determine the current inventory of target resources available for scheduling. Finally, resource scheduling is performed using the tag information and the current inventory of target resources available for scheduling, and the remaining performance resources on the source and target physical servers are appropriately adjusted to ultimately obtain a scheduling result. This allows for the use of instance performance data corresponding to the target object instances collected in real time to predict the scheduling behavior of the target object instances in advance, preventing potential issues before they occur. This prevents contention events from occurring, reduces the occurrence of contention events, and ensures the normal operation of the target object services. As can be seen, the present disclosure generates target object tags and instance tags to predict target object behavior and instance performance, and predicts target object instance scheduling behavior in advance. This allows for the appropriate online scheduling of instance resources allocated to the target object based on the prediction results, effectively preventing instance performance contention events and avoiding the occurrence of instance performance contention. In other words, the present disclosure optimizes instance scheduling logic based on real-time load conditions, rationally allocates and manages resources, and can proactively intercept instance performance contention events, thereby reducing the occurrence of instance performance contention events, ensuring the normal operation of target services, avoiding resource waste, and improving service stability. The resource scheduling methods provided in the embodiments of the present disclosure can be applied, but are not limited to, to application scenarios involving resource scheduling in fields such as e-commerce services, education services, legal services, medical services, conference services, social networking services, financial product services, logistics services, and navigation services, for example, resource scheduling for e-commerce services, education services, and medical services, without limitation herein.According to the disclosed embodiments, instance performance data corresponding to instances assigned to target objects is obtained. Tag information is then generated based on the instance performance data, including a target object tag that can predict the target object's future behavior and an instance tag for predicting the instance's future performance. The generated tag information is then used to determine the current inventory of target resources available for scheduling. Finally, resource scheduling is performed using the tag information and the current inventory of target resources available for scheduling. The remaining performance resources on the source and target physical servers are appropriately adjusted to obtain a scheduling result. This achieves the goal of predicting target object behavior and instance performance, and appropriately scheduling instance performance resources online based on the prediction results. This effectively prevents instance performance contention, avoids instance performance contention, avoids resource waste, ensures the normal operation of target object services, and improves service stability. This addresses the technical issue in related technologies where subsequent governance solutions such as performance suppression and online sharding cannot completely prevent instance performance contention, resulting in resource waste and impacting user service operations. In an optional embodiment, obtaining instance performance data in step S21 includes the following method steps: Step S211: Obtaining instance performance data from a data storage server, wherein the data storage server is configured to receive instance performance data reported by a data collection server and persistently store the instance performance data. The data collection server is configured to collect instance performance data from multiple cloud server instances created on at least one physical server and report the instance performance data to the data storage server via log data delivery. The data storage server is configured to receive instance performance data reported by the data collection server and persistently store the instance performance data. Exemplarily, it may be a persistent storage system for persistently storing and managing data. The data collection server is configured to collect instance performance data from multiple cloud server instances created on at least one physical server and report the instance performance data to the data storage server via log data delivery. Exemplarily, it may be a collection component deployed on the physical server responsible for performance data collection. In the disclosed embodiments, when obtaining instance performance data, the instance performance data may be obtained from the data storage server. FIG3 is a flowchart of performance data collection and reporting according to Example 1 of the present disclosure. As shown in FIG3 , performance indicator data of multiple VMs on the NC can be collected in real time by a collection component deployed on the NC, including but not limited to computing performance, storage performance, and network performance, without limitation herein.The real-time collected performance indicator data is stored in the NC's local file system and synchronized in real time to a log system external to the NC. The performance indicator data in the log system is then delivered to a persistent storage system via a time-series mechanism, thereby achieving persistent recording of the performance data. In an optional embodiment, in step S22, generating a target object label based on the instance performance data includes the following method steps: Step S221: Determining target object behavior characteristics based on the instance performance data; Step S222: Processing the target object behavior characteristics using a target object label model to obtain a target object label. The target object label model is used to classify target objects based on target object behavior characteristics. Target object labels include common target object labels and special target object labels. Common target object labels have lower instance performance requirements than special target object labels. Target object behavior characteristics may include, but are not limited to, re-protection, contention, and long-short cycle characteristics. Based on the target object behavior characteristics, the target object's business behavior and business preferences can be predicted. Here, "re-protection" can be understood as the target object's business behavior typically reserving resources for the virtual machine instance, ensuring that the instance has sufficient resources when needed and preventing resources from being preempted by other instances, thereby improving the reliability and stability of the virtual machine instance. "Contentment" can be understood as the business behavior of multiple virtual machine instances competing for resources. "Long-short cycle characteristics" can be understood as the resource demand characteristics of the target virtual machine instance at different time scales. Long-cycle characteristics typically refer to resource demand trends over longer periods of time and can be used for resource forecasting and planning, while short-cycle characteristics typically refer to resource demand changes over shorter periods of time and can be used for dynamic resource scheduling and management. In the disclosed embodiments, target objects can be classified based on their target object behavior characteristics. Specifically, target object labels are classified based on the target object's virtual machine instance performance requirements, with target object labels being divided into common target object labels and special target object labels. Common target object labels correspond to common target objects, indicating that the business of these common target objects has no special requirements for instance performance. Special target object labels correspond to performance-contention target objects, indicating that the business of these performance-contention target objects is sensitive to instance performance, i.e., target objects requiring performance guarantees. This can be understood as follows: instances of common target objects have lower performance requirements and are generally not subject to performance contention. However, instances of performance-contention target objects have higher performance requirements. Therefore, when resources are limited, instance performance contention may occur. In other words, common target objects do not have specific instance performance requirements, while performance-contention target objects require stronger performance guarantees.The target object labeling model is used to predict and obtain corresponding target object labels based on target object behavior characteristics. Exemplarily, the target object labeling model can be a regression model, or other machine learning or deep learning models. For example, models such as decision trees, logistic regression, or neural networks can be used, though this is not a limitation here. In embodiments of the present disclosure, when generating target object labels based on instance performance data, target object behavior characteristics, such as re-protection, contention, and long-short cycle characteristics, can be determined based on the instance performance data. The target object labeling model is then used to perform feature processing on the determined target object behavior characteristics to obtain a target object label, thereby determining the target object's instance performance requirements. This allows for personalized services to be provided to the target object based on different instance performance requirements. Furthermore, this can help optimize resource allocation and performance management to meet the performance requirements of performance-contention target objects and provide stronger performance guarantees for performance-contention target objects. Optionally, performance-contention target objects can be further categorized based on special target object labels, for example, into network performance-contention target objects and last-level cache (LLC) performance-contention target objects, though this is not a limitation here. FIG4 is a flow chart of target object classification according to Example 1 of the present disclosure. As shown in FIG4 , taking a user as the target object, information such as the user's retained instance performance, user service type, whether performance-related work orders have been filed, and whether the user is a re-retention user can be determined based on the user's user behavior characteristics, without limitation. A target object labeling model can then be used to classify the user based on this information to determine whether the user is a normal user or a performance-focused user. Furthermore, if the user is a performance-focused user, the above information can also be used to determine whether the user is a network performance-focused user, an LLC performance-focused user, or another performance-focused user. Thus, users can be more finely classified based on information such as user service behavior type and preferences to better meet the needs of different users and provide personalized services. In an optional embodiment, in step S22, generating an instance label based on the instance performance data includes the following method steps: step S223, determining instance features based on the instance performance data; step S224, performing feature processing on the instance features using an instance label model to obtain an instance label, wherein the instance label model is used to classify instances based on instance features, and the instance labels include: existing instance labels and newly created instance labels, wherein the existing instance labels are used to predict and adjust the performance of existing instances, and the newly created instance labels are used to provide performance references for newly created instances.Instance characteristics may include business characteristics, performance characteristics, and specification characteristics, which are not limited here. Based on instance characteristics, the performance and capabilities of the instance when executing computing tasks can be predicted. Business characteristics may include the target object's application type and purpose, such as database server, application server, etc.; the target object's business load characteristics, such as CPU, memory, storage, and network requirements; and the target object's business cycle and fluctuation characteristics, such as daily, weekly, or monthly business activity patterns, which are not limited here. Performance characteristics may include the target object's virtual machine instance performance requirements, such as CPU, memory, storage, and network bandwidth requirements; the target object's application performance indicators, such as instance response time, throughput, and concurrency requirements; and the target object's service level agreement (SLA) requirements, such as availability, stability, and performance guarantees, which are not limited here. Specification characteristics may include the target object's virtual machine instance specifications, such as the number of virtual CPU cores, memory size, storage capacity, and network bandwidth; the target object's virtual machine instance operating system and software environment specifications, such as the operating system version and application software version; and the target object's security and compliance specifications, such as data encryption, access control, and compliance standards, without limitation. In embodiments of the present disclosure, instances can be categorized based on the target object's instance characteristics. Specifically, instance tags are categorized based on the target object's virtual machine instance performance, with instance tags divided into existing instance tags and newly created instance tags. Existing instance tags are used to predict and adjust the performance of existing instances. Existing instance tags can be modeled and predicted based on the instance's historical performance. New instance tags are used to provide a performance reference for newly created instances. Existing instance tags can be modeled and predicted based on the historical performance of instances with the same specifications in the same availability zone as the target object. It is understood that, since existing instances already exist, the future performance of the instance can be directly predicted based on the historical performance of the instance. Because a newly created instance does not yet exist, it can only be modeled and predicted based on the historical behavior of the target object. However, the number of instances of different specification families in different availability zones and resource pool sizes of different specification families in different availability zones vary, which means that instance performance can vary significantly under different circumstances. Therefore, it is necessary to model and predict the historical performance of instances of the same specification in the same availability zone that already have the target object to obtain the new instance label.The instance labeling model is used to predict corresponding instance labels based on instance features. Exemplarily, the instance labeling model can be a regression model, or other machine learning or deep learning models. For example, models such as decision trees, logistic regression, or neural networks can be used, though this is not a limitation. In the disclosed embodiments, when generating instance labels based on instance performance data, instance features, such as business features, performance features, and specification features, can be determined based on the instance performance data. The instance labeling model is then used to perform feature processing on the determined instance features to obtain instance labels. This allows for a better understanding of the instance's performance characteristics and resource requirements, enabling more accurate resource allocation and performance management. It is understood that existing instance labels can be used to predict and optimize the performance of existing instances, while newly created instance labels can provide a performance reference for selecting specifications and availability zones for target objects. FIG5 is a flowchart of instance label classification, i.e., instance profile classification, according to Example 1 of the present disclosure. As shown in FIG5 , virtual server instances in a cloud computing environment, i.e., cloud instances, include existing instances and newly created instances. An instance label model can be used to perform feature processing on instance features corresponding to existing and newly created instances, thereby obtaining existing and newly created instance profiles. When training the instance label model, data processing can be performed on target object information and instance information to remove dirty and abnormal data. Feature extraction can then be performed on target object behavior features and instance features. The contribution and relevance of each classification feature to instance performance can be evaluated through simulation. An appropriate regression or classification model can be selected for model training and evaluation. Algorithm parameters can be iteratively evolved based on historical instance behavior data. This allows for accurate prediction of future instance performance through continuous model optimization. In an optional embodiment, the resource scheduling method further includes the following method steps: Step S25: Quantify the performance resources of at least one physical server according to a preset machine model template to obtain a resource quantification result. The preset machine model template is used to configure basic performance resources for the at least one physical server. The preset model template is used to configure the basic performance resources of at least one physical server, i.e., to uniformly configure the basic performance resources of at least one physical server. Basic performance resources may include LLC cache, network resources, power consumption resources, memory bandwidth resources, and so on, without limitation. Physical server resources can be understood as the performance resources that a physical server can provide, which are determined by the hardware architecture. In the embodiments of the present disclosure, model templates can also be used to manage physical server resources. It is understood that the performance resource provision for physical servers corresponding to different model templates may vary.The present disclosure enables the unified configuration of basic performance resource values ​​for at least one physical server using a preset machine model template, thereby achieving quantitative management of the performance resources of at least one physical server. Furthermore, by effectively managing different machine model templates, resources can be allocated and optimized as needed. Specifically, performance resources of at least one physical server can be quantified according to the preset machine model template, resulting in a resource quantification result, i.e., the resource allocation result for the physical server. Furthermore, resource deductions and returns for instances on at least one physical server are recorded, and corresponding billing records are generated, achieving full resource tracking while ensuring resource data consistency. Figure 6 is a schematic diagram of a resource management module according to Example 1 of the present disclosure. As shown in Figure 6, the resource management module of the present disclosure can achieve the technical effects of performance resource quantification, NC resource quantification, machine model template management, resource billing records, resource link tracking, and resource data consistency. In an optional embodiment, in step S23, determining the target resource inventory based on tag information includes the following method steps: Step S231: Determining a target performance resource based on the target object tag, where the target performance resource is the performance resource required by the current cloud server instance; Step S232: Performing a performance resource calculation on the resource quantification result using the target performance resource to obtain the target resource inventory. The target performance resource can be understood as the performance resource required by the current cloud server instance, where the current cloud server instance can be an existing instance or a newly created instance, without limitation. The target resource inventory can be understood as the resource inventory that meets the business requirements of the target object. In this embodiment of the present disclosure, when determining the target resource inventory based on tag information, the performance resource required by the current cloud server instance can be determined based on the target object tag. Then, a performance resource calculation (i.e., inventory calculation) is performed on the resource allocation results of the physical server using the performance resource required by the current cloud server instance to obtain the target resource inventory. It is understood that inventory calculation is used to calculate how many VMs can be created on the NC. For example, if the NC has 128 CPUs and each VM requires 4 CPUs, then 32 VMs can be created. The requirement of 4 CPUs per VM is based on the performance metrics of the VMs collected under the target object identifier (UID), availability zone, and specifications. The algorithm then calculates the number of performance resources required by the VM under these dimensions, for example, 4.Specifically, the historical performance tags (i.e., historical performance performance) of instances of this specification for this target object in this availability zone are quantified into performance resources, which are used to control the number of instances that can be created on the NC. If the number of instances exceeds this limit, the resources required by all VMs on the NC will exceed the resources the NC can provide, resulting in contention and damage to the target object's services. Figure 7 illustrates the relationship between target objects and inventory information according to Embodiment 1 of the present disclosure. As shown in Figure 7, taking the target object as a user as an example, different types of users can see different inventory information based on user classification. The visible NC inventory of ordinary users is the entire NC inventory, meaning ordinary users can see the entire NC inventory. The visible NC inventory of performance-focused users is the NC inventory without performance risks, meaning performance-focused users can only see NC inventory without performance risks. Under more refined user classification, network-focused users can only see NC inventory without network performance risks, LLC-focused users can only see NC inventory without LLC performance risks, and both network-focused and LLC-focused users can only see NC inventory without performance risks. Resource calculation to obtain a target resource inventory includes the following method steps: Step S2321: In response to the target object tag being a common target object tag, a performance resource calculation is performed on common resource items in the resource quantification results using the performance resource quantities corresponding to the common target object tag to obtain a target resource inventory. Step S2322: In response to the target object tag being a special target object tag, a performance resource calculation is performed on common resource items in the resource quantification results and on contention resource items corresponding to the special target object tag in the resource quantification results using the performance resource quantities corresponding to the special target object tag to obtain a target resource inventory. Common resource items may include common resources such as CPU, memory (MEM), and graphics processing unit (GPU). Contention resource items can be understood as resources determined corresponding to target objects of different contention types. In performing inventory calculation, embodiments of the present disclosure may perform different calculations for different performance resources based on different target object categories to provide different target resource inventories for different target objects. If the target object tag is a common target object tag, performance resource calculation is performed on the common resource items in the resource quantification results using the performance resource amounts corresponding to the common target object tag to obtain the target resource inventory. This means that if the target object is a common target object, only the common resource items corresponding to the specifications need to be calculated. For example, common inventory calculations are performed on resources such as CPU, MEM, and GPU to determine the target resource inventory corresponding to the common target object. If the target object tag is a special target object tag, performance resource calculation is performed on the common resource items in the resource quantification results and the contention resource items corresponding to the special target object tag in the resource quantification results using the performance resource amounts corresponding to the special target object tag to obtain the target resource inventory. This also means that if the target object is a performance contention target object, it is necessary to classify the target object according to its different contention types and perform corresponding inventory calculations. For example, if the target object is a network contention target object, both common inventory calculations and network resource inventory calculations are required. If the target object is an LLC contention target object, both common inventory calculations and LLC resource inventory calculations are required. If the target object is a network contention or LLC contention target object, general inventory calculation, network resource inventory calculation, and LLC resource inventory calculation are required. In an optional embodiment, the resource scheduling method further includes the following method steps: Step S26: Displaying an inventory view based on the target resource inventory, where different target object tags correspond to different inventory views.In embodiments of the present disclosure, inventory views can also be displayed based on target resource inventory. Specifically, the target resource inventory can be visualized so that target objects can see the target resource inventory. Furthermore, in different inventory calculation modes, different target objects can see different inventory views, meaning different target object labels correspond to different inventory views. Figure 8 is a flowchart of inventory view classification according to Embodiment 1 of the present disclosure. As shown in Figure 8 , depending on the target object classification, inventory views include a normal inventory view displayed to normal target objects and a performance inventory view displayed to performance-focused target objects. Depending on the performance-focused target object classification, performance inventory views include a network performance inventory view displayed to network performance-focused target objects, an LLC performance inventory view displayed to LLC performance-focused target objects, and other performance inventory views displayed to other performance-focused target objects. It will be appreciated that the performance inventory views can be determined by performing performance resource calculation on the normal inventory views. In an optional embodiment, in step S24, resource scheduling is performed using tag information and target resource inventory to obtain a scheduling result, including the following method steps: Step S241: Determine a target physical server using the target object tag and target resource inventory; Step S242: Perform resource scheduling on the target physical server based on the instance tag to obtain a scheduling result. It will be appreciated that during resource scheduling, it is necessary to determine the target physical server to which the virtual machine instance is to be migrated, thereby migrating the virtual machine instance from its current source physical server to the target physical server. That is, in the disclosed embodiment, when performing resource scheduling using tag information and target resource inventory, the target physical server can first be determined using the target object tag and target resource inventory, and then resource scheduling can be performed on the target physical server based on the instance tag, migrating the virtual machine instance from its current source physical server to the target physical server. This returns resources to the source physical server and deducts resources from the target physical server to obtain a scheduling result. In an optional embodiment, in step S241, the target physical server is determined using the target object tag and the target resource inventory, including the following method steps: Step S2411, in response to the instance scheduling request, select a candidate physical server from at least one physical server based on a preset matching mechanism, wherein the preset matching mechanism is used to determine the matching relationship between the identifier of at least one physical server and the identifiers of different instances; Step S2412, select the target physical server from the candidate physical servers using the target object tag and the target resource inventory.The preset matching mechanism is used to determine the matching relationship between the identifier of at least one physical server and the identifiers of different instances. This can be understood as a tag matching mechanism for NCs and VMs. It is understood that VMs are associated with various information, such as specifications, availability zones, optimization, network type, product, and model. To accelerate the NC selection logic, this information is pre-cached in a corresponding NC list. This allows for rapid matching and acquisition of candidate NCs when VMs are scheduled, thereby improving scheduling efficiency. In the disclosed embodiment, when determining a target physical server using the target object tag and target resource inventory, upon receiving an instance scheduling request, a candidate physical server (i.e., a candidate NC) can be selected from the at least one physical server based on the preset matching mechanism. The target object tag and target resource inventory are then used to select a target physical server (i.e., a target NC) from the candidate physical servers. In an optional embodiment, in step S2412, a target physical server is selected from candidate physical servers using the target object tag and the target resource inventory, including the following method steps: step S24121, filtering some servers from the candidate physical servers using the target object tag and the target resource inventory to obtain a filtering result; step S24122, performing weighted scoring on the filtering result to obtain a scoring result; step S24123, selecting the target physical server based on the scoring result. In embodiments of the present disclosure, when selecting a target physical server from candidate physical servers using the target object tag and the target resource inventory, some servers can be filtered out based on the target object tag. For example, if the target object tag is a standard target object tag, the performance resource item is not a restriction, so no filtering is performed. However, if the target object tag is a special target object tag, the corresponding performance resources on the NC are verified based on the performance contention type of the target object. If the resource quantity is insufficient, the NC is filtered out, thereby obtaining a filtering result, i.e., the NCs retained after filtering. After obtaining the filtering result, the retained NCs are weighted and scored to obtain a scoring result, and then the target physical server is selected based on the scoring result. For example, the retained NCs can be weighted and scored, and the NC with the highest score is selected as the target NC. It is understandable that there are many NC scorers, such as the optimal packaging scorer, the large-scale protection scorer, the healthy NC scorer, the physical hazard NC avoidance scorer, etc. The final NC score can be determined comprehensively based on the scores of the above-mentioned multiple scorers, which is not limited here.In an optional embodiment, in step S242, resource scheduling is performed on the target physical server based on the instance tag to obtain a scheduling result. The method includes the following steps: Step S2421: Determine the instance scheduling scenario using the instance tag, where the instance scheduling scenario is used to determine the resource scheduling operation type; Step S2422: Perform resource scheduling on the target physical server based on the instance scheduling scenario to obtain a scheduling result. Resource scheduling operations include resource deduction and resource return operations. The instance scheduling scenario is used to determine the resource scheduling operation type, namely, resource deduction and resource return operations. It is understood that during the primary scheduling process (i.e., when creating an instance), the target NC can be directly selected and then the resource deduction operation can be performed on the target NC. During the secondary scheduling process (i.e., when migrating an instance from a source NC to a target NC), resources on the source NC need to be released, a resource return operation is performed on the source NC, and then resources are deducted from the target NC (i.e., a resource deduction operation is performed on the target NC). In other words, primary scheduling involves only deduction operations, while secondary scheduling involves both deduction and return operations. In this embodiment of the present disclosure, when scheduling resources for a target physical server based on instance tags, the instance tags can be used to determine the instance scheduling scenario, namely, whether it is a primary or secondary scheduling scenario. Resource scheduling is then performed on the target physical server based on the instance scheduling scenario, namely, the corresponding deduction or return operations are performed, thereby obtaining a scheduling result. Figure 9 is a schematic diagram of instance scheduling according to Embodiment 1 of the present disclosure. As shown in Figure 9, taking the target object as a user as an example, when an instance scheduling request is received, tag information is first obtained. Specifically, the scheduling instance obtains information such as the instance profile (i.e., instance tag) and the user profile (i.e., target object tag). For example, based on the instance scheduling scenario, if it is a primary scheduling scenario (i.e., a new instance profile), the newly created instance profile is obtained; if it is a secondary scheduling scenario, the existing instance profile is obtained. Then, based on the user profile and the tag matching mechanism between NCs and VMs, a batch of candidate NCs is retrieved. Next, NCs are filtered based on the user profile. For example, if the user profile is normal, performance resources are not considered a constraint. For special user profiles, the corresponding performance resources on the NC are verified based on the user's performance contention type. If insufficient resources are available, the NC is filtered out. The remaining NCs are then weighted and scored, and the NC with the highest score is selected as the target NC. After the target NC is determined, the remaining performance resources on the target NC are deducted based on the performance profile resources required by the instance. Furthermore, in secondary scheduling scenarios, performance resources from the source NC must be returned.Finally, the resource bill is recorded, completing the entire scheduling process. Furthermore, this embodiment of the present disclosure supports scheduling and sales linkage. Figure 10 is a schematic diagram of this linkage according to Example 1 of the present disclosure. As shown in Figure 10, taking a user as the target object, upon receiving a user request, the system performs inventory calculation based on the user's profile classification and the corresponding resource inventory. This inventory calculation determines the user's visible inventory based on the user's availability zone and specification family. This inventory calculation corresponds to the inventory resources visible to the user. Simultaneously, the inventory calculation results are synchronized to the sales instance, displaying the inventory resources to the user through the inventory view. After viewing the inventory resources, the user purchases an instance. Then, based on the instance scheduling request, the system executes the instance scheduling process to perform operations such as target NC selection and resource scheduling. Furthermore, the system performs inventory calculations and links resource links, promptly updating the inventory view, thereby achieving a closed-loop linkage between sales, scheduling, and inventory management. Figure 11 is a system framework diagram according to Example 1 of the present disclosure. As shown in Figure 11, the system can be mainly divided into four parts: storage, inventory scheduling, performance profiling algorithm modeling, and physical machine and cloud server performance data collection. The physical machine and cloud server performance data collection part includes modules such as data collection, real-time diagnosis and health monitoring, computing, storage, network, process, and kernel, and is used to upload real-time collected instance performance data to the system's storage. The performance profiling algorithm modeling part includes modules such as aggregation computing, dimension association, algorithm modeling, features, dimensions, rules, and models. The storage part and the performance profiling algorithm modeling part communicate through data backflow, enabling the performance profiling algorithm modeling part to perform performance profiling based on real-time collected instance performance data, thereby determining instance profiles (i.e., instance labels) and user profiles (i.e., target object labels). The inventory scheduling component includes modules such as inventory sales, instance scheduling, inventory calculation, and NC resource management. The inventory sales component includes modules for portrait consumption, view selection, and sales-inventory linkage. The instance scheduling module includes modules for portrait consumption, scheduling decisions, and refined scheduling. The inventory calculation module includes modules for available inventory, inventory view generation, and view overlay. NC resource management includes modules for performance resourceization, performance resource initialization, and custom resource configuration. The system's storage component sends data such as user profiles and instance profiles to the inventory scheduling component for inventory resource scheduling. As can be seen from the above, the disclosed embodiments provide a strong isolation mechanism for performance-focused target objects. Through the unified linkage of scheduling, inventory, and sales, performance-focused target objects can only see NC resources without performance risks and cannot see NC resources with performance risks, thus achieving strong isolation between performance-risk NC resources and performance-focused target objects.Furthermore, the disclosed embodiment achieves the advance prediction of the scheduling behavior of the target object instance, quantitatively controls the contention behavior index, avoids the aggregation of contention instances in one scheduling, and can prevent problems before they occur, intercept contention events in advance, and thus reduce the occurrence of contention events. In addition, the disclosed embodiment achieves resource quantification of instance performance profile data, that is, profile analysis of contention behavior indicators and resource quantitative control, and applies it to the online scheduling business process. By refining the inventory view classification, it achieves the advance interception of performance contention risks, predicts the scheduling behavior of the target object instance in advance, and optimizes the instance scheduling logic according to the real-time load situation, reasonably allocates and manages resources, thereby reducing the occurrence of performance contention and providing a more reliable cloud service. It is easy to understand that the beneficial effects of the resource scheduling method provided by the disclosed invention include the following points. Beneficial effect (1): It achieves performance resource quantification, applies the performance resources generated based on the profile to the actual online scheduling business, controls the user instance scheduling to the NC without performance risk, and achieves a better scheduling packing strategy. Beneficial effect (2): The inventory view supports multi-dimensional refined inventory calculation. Different inventory views are visible to users with different performance. The high degree of refinement enables scheduling inventory management based on user, availability zone, and specification dimensions, and point-to-point control of performance risks. Beneficial effect (3): User profile classification is implemented. Ordinary users always see the maximum inventory, ensuring supply. In addition, refined classification is made for performance-competing users. Overall performance constraints will not be used as a shortcoming to limit inventory. Performance-competing users with no sensitive performance items will not be used as scheduling restrictions for users, reducing the risk of supply interruption. Beneficial effect (4): The sales scheduling inventory resource model is linked to the high-performance user profile. The user's visible NC inventory is the corresponding performance safety inventory, thereby achieving maximum performance scheduling guarantee. It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. The collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or reject. Furthermore, it should be noted that for simplicity of description, the aforementioned method embodiments are described as a series of actions. However, those skilled in the art should understand that this disclosure is not limited by the order of the actions described, as certain steps may be performed in a different order or simultaneously according to this disclosure.Secondly, those skilled in the art should also be aware that the embodiments described in this specification are preferred embodiments, and the actions and modules involved are not necessarily required by this disclosure. Through the above description of the embodiments, those skilled in the art will clearly understand that the methods according to the above embodiments can be implemented using software and a required general-purpose hardware platform, or of course, hardware. Based on this understanding, the technical solution of this disclosure, or the portion that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk) and includes instructions for enabling a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in various embodiments of this disclosure. Example 2 In the operating environment of Example 1, the present disclosure provides a resource scheduling method as shown in Figure 12. Figure 12 is a flowchart of a resource scheduling method according to Example 2 of the present disclosure. As shown in Figure 12, the method includes: Step S121, obtaining a cloud service instance scheduling request through a first application programming interface, wherein the request data carried in the cloud service instance scheduling request includes: tag information, the tag information is generated based on instance performance data, the instance performance data is performance indicator data obtained by collecting performance data of multiple cloud server instances created on at least one physical server, and the tag information includes: target object tags and instance tags, the target object tags are used to describe target object behavior attributes, and the instance tags are used to describe instance performance. Step S122, returning a cloud service instance scheduling response through a second application programming interface, wherein the response data carried in the cloud service instance scheduling response includes: a scheduling result, the scheduling result is obtained by performing resource scheduling using the tag information and the target resource inventory, the scheduling result is used to adjust the remaining performance resource amount on the at least one physical server, the target resource inventory amount is determined by the tag information, and the target resource inventory amount is the resource inventory amount currently available for scheduling. A cloud service instance scheduling request can be understood as a request for instance scheduling. It carries tag information, including target object tags and instance tags. The target object tag can be understood as a profile of the target object, such as a user profile. The target object tag describes the target object's behavioral attributes. By analyzing the target object's characteristics, behaviors, preferences, interests, and other information, the target object tag can be established, enabling a better understanding and prediction of the target object's behaviors and preferences.In the embodiments of the present disclosure, target object tags can be used to better understand and predict the target object's business behavior and preferences, thereby providing more personalized services and products to the target object and better meeting its business needs. Instance tags can be understood as instance profiles. Instance tags describe instance performance, specifically the performance and capabilities of a virtual machine instance when executing computing tasks. Instance tags can include information about the instance's processing power, storage capacity, network performance, and security performance. For example, the instance tag can be determined based on the instance's historical performance. In the embodiments of the present disclosure, instance tags can be used to better predict the instance's future performance, thereby enabling better resource scheduling and avoiding instance performance contention. Tag information is generated based on instance performance data. Instance performance data is performance indicator data collected from multiple cloud server instances created on at least one physical server, specifically, performance indicator data collected in real time from multiple virtual machine instances on the physical server. Performance indicator data may include central processing unit (CPU) utilization, memory utilization, disk input / output (I / O), network bandwidth, and other indicators, without limitation. A cloud service instance scheduling response can be understood as a scheduling response corresponding to a cloud service instance scheduling request. The cloud service instance scheduling response carries a scheduling result. The scheduling result is obtained by performing resource scheduling using tag information and target resource inventory. The scheduling result is used to adjust the remaining performance resources on at least one physical server. Specifically, it is used to return and deduct remaining performance resources on the source and target physical servers during resource scheduling. The target resource inventory is determined by tag information and represents the current inventory of resources available for scheduling. It can be understood as the currently remaining, available virtual computing resources. In an embodiment of the present disclosure, a cloud service instance scheduling request is obtained through a first application programming interface. The request data carried in the cloud service instance scheduling request includes tag information. The tag information is generated based on instance performance data. The instance performance data is performance indicator data obtained by collecting performance data of multiple cloud server instances created on at least one physical server. The tag information includes a target object tag and an instance tag. The target object tag is used to describe target object behavior attributes, and the instance tag is used to describe instance performance.A cloud service instance scheduling response is then returned via the second application programming interface. The response data carried in the cloud service instance scheduling response includes a scheduling result, obtained by performing resource scheduling using the tag information and the target resource inventory. The scheduling result is used to adjust the remaining performance resources on at least one physical server. The target resource inventory is determined by the tag information and represents the current resource inventory available for scheduling. This allows for the real-time acquisition of instance performance data corresponding to the target object instance to predict the scheduling behavior of the target object instance in advance, preventing potential problems before they occur. This prevents contention events from occurring and thereby ensures the normal operation of the target object service. The resource scheduling method provided in the embodiments of the present disclosure can be applied, but is not limited to, to application scenarios involving resource scheduling in fields such as e-commerce services, education services, legal services, medical services, conference services, social network services, financial product services, logistics services, and navigation services, such as resource scheduling for e-commerce services, education services, and medical services, though this is not a limitation here. According to an embodiment of the present disclosure, a cloud service instance scheduling request is obtained through a first application programming interface. The request data carried in the cloud service instance scheduling request includes tag information, where the tag information is generated based on instance performance data. The instance performance data is performance indicator data obtained by collecting performance data of multiple cloud server instances created on at least one physical server. The tag information includes a target object tag and an instance tag. The target object tag is used to describe target object behavior attributes, and the instance tag is used to describe instance performance. A cloud service instance scheduling response is then returned via the second application programming interface. The response data carried in the cloud service instance scheduling response includes a scheduling result, which is obtained by performing resource scheduling using the tag information and the target resource inventory. The scheduling result is used to adjust the remaining performance resources on at least one physical server. The target resource inventory is determined based on the tag information and represents the currently available resource inventory. This achieves the goal of predicting target object behavior and instance performance, and rationally scheduling instance performance resources online based on the prediction results. This effectively prevents instance performance contention, avoids instance performance contention, avoids resource waste, ensures normal operation of target object services, and improves service stability. This addresses the technical issue in related technologies where subsequent governance solutions such as performance suppression and online sharding cannot completely prevent instance performance contention, resulting in resource waste and impacting user service operations. It should be noted that the preferred implementation of this embodiment can be found in the relevant description of Example 1 and will not be repeated here.Example 3 In the operating environment as in Example 1, the present disclosure provides a resource scheduling method as shown in FIG13. FIG13 is a flowchart of a resource scheduling method according to Embodiment 3 of the present disclosure. As shown in FIG13 , the method includes: step S131, obtaining a currently input cloud service instance scheduling dialogue request, wherein information carried in the cloud service instance scheduling dialogue request includes: tag information, which is generated based on instance performance data. The instance performance data is performance indicator data obtained by collecting performance data of multiple cloud server instances created on at least one physical server. The tag information includes: a target object tag and an instance tag, wherein the target object tag is used to describe target object behavior attributes, and the instance tag is used to describe instance performance. Step S132, in response to the cloud service instance scheduling dialogue request, returning a cloud service instance scheduling dialogue reply, wherein information carried in the cloud service instance scheduling dialogue reply includes: a scheduling result, which is obtained by performing resource scheduling using the tag information and a target performance resource amount. The scheduling result is used to adjust the remaining performance resource amount on the at least one physical server. The target resource inventory amount is determined by the tag information, and the target resource inventory amount is the resource inventory amount currently available for scheduling. Step S133, displaying the scheduling result in a graphical target object interface. A cloud service instance scheduling dialog request can be understood as a dialog request input by a target object for instance scheduling. The information carried in the cloud service instance scheduling dialog request includes tag information, including a target object tag and an instance tag. The target object tag can be understood as a profile of the target object, such as a user profile. The target object tag describes the target object's behavioral attributes, specifically, its behavior and preferences. The target object tag can be established by analyzing information such as the target object's characteristics, behavior, preferences, and interests, thereby enabling better understanding and prediction of the target object's behavior and preferences. In embodiments of the present disclosure, the target object tag enables better understanding and prediction of the target object's business behavior and preferences, enabling the provision of more personalized services and products to the target object, better meeting its business needs. The instance tag can be understood as an instance profile. The instance tag describes the instance's performance, specifically, the performance and capabilities of a virtual machine instance when executing computing tasks. The instance tag can include information about the instance's processing power, storage capacity, network performance, security performance, and other aspects. For example, the instance tag of the instance can be determined based on the instance's historical performance. In the embodiments of the present disclosure, future performance of instances can be better predicted based on instance tags, thereby better implementing resource scheduling and avoiding instance performance contention.Tag information is generated based on instance performance data. Instance performance data is performance indicator data collected from multiple cloud server instances created on at least one physical server, specifically, performance indicator data collected in real time for multiple virtual machine instances on a physical server. Performance indicator data may include metrics such as central processing unit (CPU) utilization, memory utilization, disk input / output (I / O), and network bandwidth, without limitation. A cloud service instance scheduling dialogue reply can be understood as a dialogue reply corresponding to a cloud service instance scheduling dialogue request. The cloud service instance scheduling dialogue reply carries a scheduling result, which is obtained by performing resource scheduling using tag information and target resource inventory. The scheduling result is used to adjust the remaining performance resources on at least one physical server, specifically to return and deduct remaining performance resources on the source and target physical servers during resource scheduling. The target resource inventory is determined by tag information and represents the current available resource inventory for scheduling, which can be understood as the remaining, available virtual computing resources. After determining the scheduling result, it can be displayed in the graphical target object interface, thereby providing feedback to the target object. In this disclosed embodiment, a currently input cloud service instance scheduling dialog request is obtained. The information carried in the cloud service instance scheduling dialog request includes tag information, which is generated based on instance performance data. The instance performance data is performance indicator data obtained by collecting performance data from multiple cloud server instances created on at least one physical server. The tag information includes target object tags and instance tags. The target object tags describe the target object's behavioral attributes, while the instance tags describe the instance's performance. Then, in response to the cloud service instance scheduling dialog request, a cloud service instance scheduling dialog reply is returned. The information carried in the cloud service instance scheduling dialog reply includes a scheduling result, which is obtained by performing resource scheduling using the tag information and the target performance resource quantity. The scheduling result is used to adjust the remaining performance resource quantity on the at least one physical server. The target resource inventory quantity is determined by the tag information and represents the current resource inventory quantity available for scheduling. Finally, the scheduling result is displayed in the graphical target object interface to provide feedback to the target object. Therefore, the instance performance data corresponding to the target object instance collected in real time can be used to predict the target object instance scheduling behavior in advance, prevent problems before they occur, intercept contention events in advance, reduce the occurrence of contention events, and thus ensure the normal operation of the target object business.The resource scheduling method provided in the embodiments of the present disclosure can be applied, but is not limited to, to application scenarios involving resource scheduling in fields such as e-commerce services, education services, legal services, medical services, conference services, social networking services, financial product services, logistics services, and navigation services. For example, resource scheduling for e-commerce services, education services, and medical services, etc., are not limited here. In the embodiments of the present disclosure, a currently input cloud service instance scheduling dialog request is obtained. The information carried in the cloud service instance scheduling dialog request includes tag information. The tag information is generated based on instance performance data. The instance performance data is performance indicator data obtained by collecting performance data from multiple cloud server instances created on at least one physical server. The tag information includes a target object tag and an instance tag. The target object tag describes the target object's behavioral attributes, and the instance tag describes the instance's performance. Then, in response to the cloud service instance scheduling dialog request, a cloud service instance scheduling dialog reply is returned. The cloud service instance scheduling dialog reply carries information including: a scheduling result, obtained by performing resource scheduling using tag information and target performance resources. The scheduling result is used to adjust the remaining performance resources on at least one physical server. The target resource inventory is determined by the tag information and represents the current available resource inventory. Finally, the scheduling result is displayed within the graphical target object interface to provide feedback to the target object. This achieves the goal of predicting target object behavior and instance performance, and rationally scheduling instance performance resources online based on the prediction results. This effectively prevents instance performance contention, avoids instance performance contention, avoids resource waste, ensures normal operation of the target object's services, and improves service stability. This addresses the technical issue in related technologies where subsequent governance solutions such as performance suppression and online sharding cannot completely prevent instance performance contention, resulting in resource waste and impacting user services. It should be noted that the preferred implementation of this embodiment can refer to the relevant description in Example 1, which will not be repeated here. Example 4 According to the embodiment of the present disclosure, a system embodiment for implementing the above resource scheduling method is also provided.FIG14 is a schematic structural diagram of a resource scheduling system according to Embodiment 4 of the present disclosure. As shown in FIG14 , the apparatus includes: a data acquisition server 1401, configured to collect instance performance data from multiple cloud server instances created on at least one physical server and report the instance performance data to a data storage server via log data delivery; a data storage server 1402, configured to receive the instance performance data reported by the data acquisition server and persistently store the instance performance data; a performance profiling server 1403, configured to obtain the instance performance data and generate tag information based on the instance performance data, wherein the tag information includes a target object tag and an instance tag, wherein the target object tag is used to describe the target object's behavioral attributes, and the instance tag is used to describe the instance's performance; and a resource scheduling server 1404, configured to determine a target performance resource amount based on the tag information, and perform resource scheduling using the tag information and the target resource inventory to obtain a scheduling result, wherein the target resource inventory is the resource inventory currently available for scheduling, and the scheduling result is used to adjust the remaining performance resource amount on the at least one physical server. In the disclosed embodiments, data collection server 1401 can be understood as the performance data collection portion in Figure 11 , data storage server 1402 can be understood as the storage portion in Figure 11 , performance profile server 1403 can be understood as the performance profile algorithm modeling portion in Figure 11 , and resource scheduling server 1404 can be understood as the resource scheduling portion in Figure 11 . Data collection server 1401 is configured to collect instance performance data from multiple cloud server instances created on at least one physical server and report the instance performance data to data storage server 1402 via log data delivery. Exemplarily, data collection server 1401 can be a collection component deployed on a physical server responsible for performance data collection. It is understood that a physical machine can simultaneously run multiple virtual machine instances. Using virtualization technology, a physical machine's resources are divided into multiple virtual computing resources, which are then allocated to different virtual machine instances. In the disclosed embodiments, a physical server is a physical machine (NC), and a cloud server instance is a virtual machine (VM). Instance performance data is performance metrics collected from multiple cloud server instances created on at least one physical server. This refers to real-time performance metrics collected from multiple virtual machine instances on a physical server. Performance metrics can include central processing unit (CPU) utilization, memory utilization, disk input / output (I / O), network bandwidth, and other metrics, without limitation.Exemplarily, instance performance data may be real-time collected instance performance data used to execute the target object's services, i.e., instance performance data corresponding to the instance assigned to the target object. The data storage server 1402 is configured to receive the instance performance data reported by the data collection server and persistently store the instance performance data. Exemplarily, the data storage server 1402 may be a persistent storage system for persistently storing and managing data. The performance profiling server 1403 is configured to obtain the instance performance data and generate tag information based on the instance performance data. The tag information includes a target object tag and an instance tag. The target object tag describes the target object's behavioral attributes, namely, the target object's behavior and preferences. The target object tag can be established by analyzing the target object's characteristics, behavior, preferences, interests, and other information, thereby enabling a better understanding and prediction of the target object's behavior and preferences. In the disclosed embodiments, the target object tag enables a better understanding and prediction of the target object's business behavior and preferences, thereby enabling the provision of more personalized services and products to the target object, better meeting the target object's business needs. Instance tags are used to describe instance performance, specifically the performance and capabilities of a virtual machine instance when executing computing tasks. Instance tags may include information about the instance's processing power, storage capacity, network performance, security performance, and other aspects. For example, the instance tag can be determined based on the instance's historical performance. In embodiments of the present disclosure, instance tags can better predict the instance's future performance, thereby enabling better resource scheduling and avoiding instance performance contention. Resource scheduling server 1404 is configured to determine target performance resource amounts based on tag information and perform resource scheduling using the tag information and target resource inventory to obtain a scheduling result. The target resource inventory is the current resource inventory available for scheduling, which can be understood as the remaining available virtual computing resources. The scheduling result is used to adjust the remaining performance resource amount on at least one physical server, specifically to return and deduct remaining performance resource amounts on the source and target physical servers during resource scheduling. The resource scheduling system provided by the embodiments of the present disclosure can be applied to, but is not limited to, application scenarios involving resource scheduling in the fields of e-commerce services, educational services, legal services, medical services, conference services, social network services, financial product services, logistics services, and navigation services. For example, query requests for e-commerce services, query requests for academic interpretations, query requests for medical methods, etc. are not limited here.In an embodiment of the present disclosure, resource scheduling is performed using a resource scheduling system comprising a data collection server, a data storage server, a performance profiling server, and a resource scheduling server. The data collection server collects instance performance data from multiple cloud server instances created on at least one physical server and reports the instance performance data to the data storage server via log data delivery. The data storage server receives the instance performance data reported by the data collection server and persistently stores the instance performance data. The performance profiling server acquires the instance performance data and generates tag information based on the instance performance data. The tag information includes target object tags and instance tags. The target object tags describe the target object's behavioral attributes, and the instance tags describe the instance's performance. The resource scheduling server is configured to determine the target performance resource amount based on tag information and perform resource scheduling using the tag information and the target resource inventory to obtain a scheduling result. The target resource inventory is the current resource inventory available for scheduling, and the scheduling result is used to adjust the remaining performance resource amount on at least one physical server. This achieves the goal of predicting target object behavior and instance performance, and rationally performing online scheduling of instance performance resources based on the prediction results. This effectively prevents instance performance contention, avoids instance performance contention, and avoids resource waste, ensuring the normal operation of target object services and improving service stability. This solves the technical problem in related technologies where subsequent management solutions such as performance suppression and online sharding cannot completely prevent instance performance contention, resulting in resource waste and impacting user service operations. In an optional embodiment, the resource scheduling server is further configured to determine a target physical server using the target object tag and the target resource inventory, and perform resource scheduling on the target physical server based on the instance tag to obtain a scheduling result. It is understood that during resource scheduling, it is necessary to determine the target physical server to which the virtual machine instance is to be migrated, thereby migrating the virtual machine instance from its current source physical server to the target physical server. The resource scheduling server may also first determine the target physical server using the target object tag and the target resource inventory, and then perform resource scheduling on the target physical server based on the instance tag, migrating the virtual machine instance from its current source physical server to the target physical server. This will thereby return the resources of the source physical server and deduct the resources of the target physical server to obtain the scheduling result. It should be noted that the preferred implementation of this embodiment can be found in the relevant description of Example 1 and will not be repeated here. Example 5 According to an embodiment of the present disclosure, an embodiment of an apparatus for implementing the above-mentioned resource scheduling method is also provided.Figure 15 is a structural diagram of a resource scheduling device according to Example 5 of the present disclosure. As shown in Figure 15, the device includes: a first acquisition module 1501, which is configured to obtain instance performance data, wherein the instance performance data is performance indicator data obtained by collecting performance data of multiple cloud server instances created on at least one physical server; a generation module 1502, which is configured to generate tag information based on the instance performance data, wherein the tag information includes: a target object tag and an instance tag, wherein the target object tag is used to describe the behavior attributes of the target object, and the instance tag is used to describe the performance of the instance; a determination module 1503, which is configured to determine the target resource inventory through the tag information, wherein the target resource inventory is the resource inventory currently available for scheduling; and a scheduling module 1504, which is configured to perform resource scheduling using the tag information and the target resource inventory to obtain a scheduling result, wherein the scheduling result is used to adjust the remaining performance resource amount on the at least one physical server. Optionally, the first acquisition module 1501 is further configured to: acquire instance performance data from a data storage server, wherein the data storage server is configured to receive the instance performance data reported by the data collection server and persistently store the instance performance data, and the data collection server is configured to collect instance performance data from multiple cloud server instances created on at least one physical server and report the instance performance data to the data storage server via log data delivery. Optionally, the generation module 1502 is further configured to: determine target object behavior characteristics based on the instance performance data; and perform feature processing on the target object behavior characteristics using a target object label model to obtain a target object label. The target object label model is configured to classify target objects based on the target object behavior characteristics. Target object labels include common target object labels and special target object labels, wherein the instance performance requirement for the common target object label is lower than the instance performance requirement for the special target object label. Optionally, the generation module 1502 is further configured to: determine instance characteristics based on instance performance data; and perform feature processing on the instance characteristics using an instance labeling model to obtain instance labels. The instance labeling model is used to classify instances based on instance characteristics. Instance labels include existing instance labels and newly created instance labels. Existing instance labels are used to predict and adjust the performance of existing instances, while newly created instance labels are used to provide performance references for newly created instances. Optionally, the generation module 1502 further includes a quantification module configured to quantify the performance resources of at least one physical server according to a preset model template to obtain resource quantification results. The preset model template is used to configure basic performance resources of the at least one physical server.Optionally, the determination module 1503 is further configured to: determine a target performance resource amount based on the target object tag, wherein the target performance resource amount is the performance resource amount required by the current cloud server instance; and perform a performance resource calculation on the resource quantification result using the target performance resource amount to obtain a target resource inventory amount. Optionally, the determination module 1503 is further configured to: in response to the target object tag being a common target object tag, perform a performance resource calculation on common resource items in the resource quantification result using the performance resource amount corresponding to the common target object tag to obtain a target resource inventory amount; and in response to the target object tag being a special target object tag, perform a performance resource calculation on common resource items in the resource quantification result and competing resource items in the resource quantification result corresponding to the special target object tag using the performance resource amount corresponding to the special target object tag to obtain a target resource inventory amount. Optionally, the system further includes: a first display module configured to display an inventory view based on the target resource inventory amount, wherein different target object tags correspond to different inventory views. Optionally, the scheduling module 1504 is further configured to: determine a target physical server using the target object tag and the target resource inventory; perform resource scheduling on the target physical server based on the instance tag to obtain a scheduling result. Optionally, the scheduling module 1504 is further configured to: select a candidate physical server from at least one physical server based on a preset matching mechanism in response to the instance scheduling request, wherein the preset matching mechanism is used to determine a matching relationship between the identifier of the at least one physical server and the identifiers of different instances; and select a target physical server from the candidate physical servers using the target object tag and the target resource inventory. Optionally, the scheduling module 1504 is further configured to: filter some servers from the candidate physical servers using the target object tag and the target resource inventory to obtain a filtering result; perform weighted scoring on the filtering result to obtain a scoring result; and select a target physical server based on the scoring result. Optionally, the scheduling module 1504 is further configured to: determine an instance scheduling scenario using the instance tag, wherein the instance scheduling scenario is used to determine a resource scheduling operation category; and perform resource scheduling on the target physical server based on the instance scheduling scenario to obtain a scheduling result.According to the disclosed embodiments, instance performance data corresponding to instances assigned to target objects is obtained. Tag information is then generated based on the instance performance data, including a target object tag that can predict the target object's future behavior and an instance tag for predicting the instance's future performance. The generated tag information is then used to determine the current inventory of target resources available for scheduling. Finally, resource scheduling is performed using the tag information and the current inventory of target resources available for scheduling. The remaining performance resources on the source and target physical servers are appropriately adjusted to obtain a scheduling result. This achieves the goal of predicting target object behavior and instance performance, and appropriately scheduling instance performance resources online based on the prediction results. This effectively prevents instance performance contention, avoids instance performance contention, avoids resource waste, ensures the normal operation of target object services, and improves service stability. This addresses the technical issue in related technologies where subsequent governance solutions such as performance suppression and online sharding cannot completely prevent instance performance contention, resulting in resource waste and impacting user service operations. It should be noted that the first acquisition module 1501, generation module 1502, determination module 1503, and scheduling module 1504 described above correspond to steps S21 to S24 in Example 1. These four modules and the corresponding steps implement the same examples and application scenarios, but are not limited to the content disclosed in Example 1. It should be noted that the above modules or units may be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, 102n). The above modules may also be part of an apparatus and run in the computer terminal 10 provided in Example 1. According to an embodiment of the present disclosure, another apparatus embodiment for implementing the above resource scheduling method is also provided.FIG16 is a schematic structural diagram of another resource scheduling device according to Embodiment 5 of the present disclosure. As shown in FIG16 , the device includes: a second obtaining module 1601, configured to obtain a cloud service instance scheduling request through a first application programming interface, wherein the request data carried in the cloud service instance scheduling request includes: tag information, the tag information is generated based on instance performance data, the instance performance data is performance indicator data obtained by collecting performance data of multiple cloud server instances created on at least one physical server, the tag information includes: a target object tag and an instance tag, the target object tag is used to describe target object behavior attributes, and the instance tag is used to describe instance performance; a first returning module 1602, configured to return a cloud service instance scheduling response through a second application programming interface, wherein the response data carried in the cloud service instance scheduling response includes: a scheduling result, the scheduling result is obtained by performing resource scheduling using the tag information and a target resource inventory, the scheduling result is used to adjust the remaining performance resource amount on the at least one physical server, the target resource inventory amount is determined by the tag information, and the target resource inventory amount is the resource inventory amount currently available for scheduling. According to an embodiment of the present disclosure, a cloud service instance scheduling request is obtained through a first application programming interface. The request data carried in the cloud service instance scheduling request includes tag information, where the tag information is generated based on instance performance data. The instance performance data is performance indicator data obtained by collecting performance data of multiple cloud server instances created on at least one physical server. The tag information includes a target object tag and an instance tag. The target object tag is used to describe target object behavior attributes, and the instance tag is used to describe instance performance. A cloud service instance scheduling response is then returned via the second application programming interface. The response data carried in the cloud service instance scheduling response includes a scheduling result, which is obtained by performing resource scheduling using the tag information and the target resource inventory. The scheduling result is used to adjust the remaining performance resources on at least one physical server. The target resource inventory is determined based on the tag information and is the currently available resource inventory. This achieves the goal of predicting target object behavior and instance performance, and rationally scheduling instance performance resources online based on the prediction results. This effectively prevents instance performance contention, avoids instance performance contention, avoids resource waste, ensures the normal operation of target object services, and improves service stability. This addresses the technical issue in related technologies where subsequent governance solutions such as performance suppression and online fragmentation cannot completely prevent instance performance contention, resulting in resource waste and impacting user service operations.It should be noted that the second acquisition module 1601 and the first return module 1602 correspond to steps S121 and S124 in Example 2. The examples and application scenarios implemented by these two modules and the corresponding steps are the same, but are not limited to the content disclosed in Example 1. It should be noted that the above modules or units may be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, 102n). The above modules may also be part of an apparatus and run in the computer terminal 10 provided in Example 1. According to an embodiment of the present disclosure, another apparatus embodiment for implementing the above resource scheduling method is also provided. FIG17 is a schematic structural diagram of another resource scheduling device according to Embodiment 5 of the present disclosure. As shown in FIG17 , the device includes: a third acquisition module 1701, configured to acquire a currently input cloud service instance scheduling dialogue request, wherein the information carried in the cloud service instance scheduling dialogue request includes: tag information, which is generated based on instance performance data. The instance performance data is performance indicator data obtained by collecting performance data of multiple cloud server instances created on at least one physical server. The tag information includes: a target object tag and an instance tag. The target object tag is used to describe the behavior attributes of the target object, and the instance tag is used to describe the performance of the instance; a second return module 1702, configured to respond to the cloud service instance scheduling dialogue request and return a cloud service instance scheduling dialogue reply, wherein the information carried in the cloud service instance scheduling dialogue reply includes: a scheduling result, which is obtained by performing resource scheduling using the tag information and the target performance resource amount. The scheduling result is used to adjust the remaining performance resource amount on the at least one physical server. The target resource inventory amount is determined by the tag information. The target resource inventory amount is the resource inventory amount currently available for scheduling; and a second display module 1703. The system is configured to display scheduling results within a graphical target object interface. In an embodiment of the present disclosure, a currently input cloud service instance scheduling dialog request is obtained. The information carried in the cloud service instance scheduling dialog request includes tag information, which is generated based on instance performance data. The instance performance data is performance indicator data collected from multiple cloud server instances created on at least one physical server. The tag information includes a target object tag and an instance tag. The target object tag describes the target object's behavioral attributes, while the instance tag describes the instance's performance.Then, in response to the cloud service instance scheduling dialog request, a cloud service instance scheduling dialog reply is returned. The cloud service instance scheduling dialog reply carries information including: a scheduling result, obtained by performing resource scheduling using tag information and target performance resources. The scheduling result is used to adjust the remaining performance resources on at least one physical server. The target resource inventory is determined by the tag information and represents the current available resource inventory. Finally, the scheduling result is displayed within the graphical target object interface to provide feedback to the target object. This achieves the goal of predicting target object behavior and instance performance, and rationally scheduling instance performance resources online based on the prediction results. This effectively prevents instance performance contention, avoids instance performance contention, avoids resource waste, ensures normal operation of the target object's services, and improves service stability. This addresses the technical issue in related technologies where subsequent governance solutions such as performance suppression and online sharding cannot completely prevent instance performance contention, resulting in resource waste and impacting user services. It should be noted that the third acquisition module 1701, second return module 1702, and second display module 1703 described above correspond to steps S131 to S133 in Example 3. The examples and application scenarios implemented by these three modules and the corresponding steps are the same, but are not limited to the content disclosed in Example 1. It should be noted that the above modules or units may be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, 102n). The above modules may also be part of an apparatus and run in the computer terminal 10 provided in Example 1. It should be noted that the preferred implementation schemes involved in the above embodiments of the present disclosure are the same as the schemes, application scenarios, and implementation processes provided in Example 1, but are not limited to the schemes provided in Example 1. Example 6: The embodiments of the present disclosure may provide a computer terminal, which may be any computer terminal device in a computer terminal group. Optionally, in this embodiment, the above computer terminal may be replaced with a terminal device such as a mobile terminal. Optionally, in this embodiment, the computer terminal may be located in at least one network device among multiple network devices of the computer network.In this embodiment, the computer terminal can execute program code for the following steps in the resource scheduling method: obtaining instance performance data, where the instance performance data is performance indicator data obtained by collecting performance data from multiple cloud server instances created on at least one physical server; generating tag information based on the instance performance data, where the tag information includes a target object tag and an instance tag, where the target object tag describes the target object's behavioral attributes, and the instance tag describes the instance's performance; determining a target resource inventory based on the tag information, where the target resource inventory is the current resource inventory available for scheduling; and performing resource scheduling using the tag information and the target resource inventory to obtain a scheduling result, where the scheduling result is used to adjust the remaining performance resources on the at least one physical server. Optionally, FIG18 is a block diagram of a computer terminal according to an embodiment of the present disclosure. As shown in FIG18 , the computer terminal A may include one or more processors 1802 (only one is shown), a memory 1804, a storage controller, and a peripheral interface, where the peripheral interface is connected to a radio frequency module, an audio module, and a display. The memory can be used to store software programs and modules, such as program instructions / modules corresponding to the resource scheduling method and apparatus in the embodiments of the present disclosure. The processor executes the stored software programs and modules to execute various functional applications and data processing, thereby implementing the resource scheduling method described above. The memory can include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory can further include memory remotely located from the processor, and such remote memory can be connected to the computer terminal A via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof. The processor can call the information and application stored in the memory through the transmission device to perform the following steps: obtaining instance performance data, wherein the instance performance data is performance indicator data obtained by collecting performance data of multiple cloud server instances created on at least one physical server; generating tag information based on the instance performance data, wherein the tag information includes: a target object tag and an instance tag, wherein the target object tag is used to describe the behavior attributes of the target object, and the instance tag is used to describe the performance of the instance; determining the target resource inventory through the tag information, wherein the target resource inventory is the resource inventory currently available for scheduling; performing resource scheduling using the tag information and the target resource inventory to obtain a scheduling result, wherein the scheduling result is used to adjust the remaining performance resource amount on the at least one physical server.Optionally, the processor may further execute program code for the following steps: obtaining instance performance data from a data storage server, wherein the data storage server is configured to receive instance performance data reported by a data collection server and persistently store the instance performance data; and the data collection server is configured to collect instance performance data from multiple cloud server instances created on at least one physical server and report the instance performance data to the data storage server via log data delivery. Optionally, the processor may further execute program code for the following steps: determining target object behavior characteristics based on the instance performance data; and performing feature processing on the target object behavior characteristics using a target object label model to obtain a target object label. The target object label model is configured to classify target objects based on the target object behavior characteristics. The target object labels include common target object labels and special target object labels, wherein the instance performance requirement for the common target object label is lower than the instance performance requirement for the special target object label. Optionally, the processor may further execute program code for the following steps: determining instance characteristics based on instance performance data; performing feature processing on the instance characteristics using an instance labeling model to obtain instance labels, wherein the instance labeling model is used to classify instances based on instance characteristics, and instance labels include existing instance labels and newly created instance labels. Existing instance labels are used to predict and adjust the performance of existing instances, and newly created instance labels are used to provide performance references for newly created instances. Optionally, the processor may further execute program code for the following steps: performing performance resource quantification on at least one physical server according to a preset model template to obtain a resource quantification result, wherein the preset model template is used to configure basic performance resources for the at least one physical server. Optionally, the processor may further execute program code for the following steps: determining a target performance resource amount based on a target object label, wherein the target performance resource amount is the performance resource amount required by the current cloud server instance; and performing performance resource calculation on the resource quantification result using the target performance resource amount to obtain a target resource inventory. Optionally, the processor may further execute program code for the following steps: in response to the target object tag being a common target object tag, performing performance resource calculation on common resource items in the resource quantification result using the performance resource amount corresponding to the common target object tag to obtain a target resource inventory amount; in response to the target object tag being a special target object tag, performing performance resource calculation on common resource items in the resource quantification result and competing resource items corresponding to the special target object tag in the resource quantification result using the performance resource amount corresponding to the special target object tag to obtain a target resource inventory amount.Optionally, the processor may further execute program code for the following steps: displaying an inventory view based on the target resource inventory, wherein different target object tags correspond to different inventory views. Optionally, the processor may further execute program code for the following steps: determining a target physical server using the target object tag and the target resource inventory; performing resource scheduling on the target physical server based on the instance tag to obtain a scheduling result. Optionally, the processor may further execute program code for the following steps: in response to an instance scheduling request, selecting a candidate physical server from at least one physical server based on a preset matching mechanism, wherein the preset matching mechanism is configured to determine a matching relationship between the identifier of the at least one physical server and identifiers of different instances; selecting a target physical server from the candidate physical servers using the target object tag and the target resource inventory. Optionally, the processor may further execute program code for the following steps: filtering a portion of the candidate physical servers using the target object tag and the target resource inventory to obtain a filtering result; weighting the filtering result to obtain a scoring result; and selecting a target physical server based on the scoring result. Optionally, the processor may further execute program code of the following steps: determining an instance scheduling scenario using the instance tag, wherein the instance scheduling scenario is used to determine a resource scheduling operation category; and performing resource scheduling on the target physical server based on the instance scheduling scenario to obtain a scheduling result. According to the disclosed embodiments, instance performance data corresponding to instances assigned to target objects is obtained. Tag information is then generated based on the instance performance data, including a target object tag that can predict the target object's future behavior and an instance tag for predicting the instance's future performance. The generated tag information is then used to determine the current inventory of target resources available for scheduling. Finally, resource scheduling is performed using the tag information and the current inventory of target resources available for scheduling. The remaining performance resources on the source and target physical servers are appropriately adjusted to obtain a scheduling result. This achieves the goal of predicting target object behavior and instance performance, and appropriately scheduling instance performance resources online based on the prediction results. This effectively prevents instance performance contention, avoids instance performance contention, avoids resource waste, ensures the normal operation of target object services, and improves service stability. This addresses the technical issue in related technologies where subsequent governance solutions such as performance suppression and online sharding cannot completely prevent instance performance contention, resulting in resource waste and impacting user service operations.Those skilled in the art will appreciate that the structure shown in FIG18 is merely illustrative, and that computer terminal A may also be a smartphone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile internet device (MID), a PAD, or other terminal device. FIG18 does not limit the structure of the aforementioned electronic devices. For example, computer terminal A may include more or fewer components (such as a network interface, a display device, etc.) than those shown in FIG18 , or may have a configuration different from that shown in FIG18 . Those skilled in the art will appreciate that all or part of the steps in the various methods of the above embodiments can be completed by a program instructing the hardware associated with the terminal device. The program may be stored in a computer-readable storage medium, which may include a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. Example 7 The present disclosure also provides a computer-readable storage medium. Optionally, in this embodiment, the computer-readable storage medium may be used to store program code executed by the resource scheduling method provided in the first embodiment. Optionally, in this embodiment, the computer-readable storage medium may be located in any computer terminal in a computer terminal group in a computer network, or in any mobile terminal in a mobile terminal group. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: obtaining instance performance data, wherein the instance performance data is performance indicator data obtained by collecting performance data from multiple cloud server instances created on at least one physical server; generating tag information based on the instance performance data, wherein the tag information includes: a target object tag and an instance tag, wherein the target object tag is used to describe the behavior attributes of the target object, and the instance tag is used to describe the performance of the instance; determining a target resource inventory based on the tag information, wherein the target resource inventory is the current inventory of resources available for scheduling; and performing resource scheduling using the tag information and the target resource inventory to obtain a scheduling result, wherein the scheduling result is used to adjust the remaining performance resources on the at least one physical server.Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: obtaining instance performance data from a data storage server, wherein the data storage server is configured to receive the instance performance data reported by the data collection server and persistently store the instance performance data, and the data collection server is configured to collect instance performance data from multiple cloud server instances created on at least one physical server and report the instance performance data to the data storage server via log data delivery. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: determining target object behavior characteristics based on the instance performance data; and performing feature processing on the target object behavior characteristics using a target object label model to obtain a target object label, wherein the target object label model is configured to classify target objects based on the target object behavior characteristics, and the target object labels include common target object labels and special target object labels, wherein the instance performance requirement of the common target object label is lower than the instance performance requirement of the special target object label. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: determining instance characteristics based on instance performance data; performing feature processing on the instance characteristics using an instance labeling model to obtain instance labels, wherein the instance labeling model is used to classify instances based on instance characteristics, and instance labels include existing instance labels and newly created instance labels. Existing instance labels are used to predict and adjust the performance of existing instances, and newly created instance labels are used to provide performance references for newly created instances. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: performing performance resource quantification on at least one physical server according to a preset model template to obtain a resource quantification result, wherein the preset model template is used to configure basic performance resources for the at least one physical server. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: determining a target performance resource amount based on a target object label, wherein the target performance resource amount is the performance resource amount required by the current cloud server instance; and performing performance resource calculation on the resource quantification result using the target performance resource amount to obtain a target resource inventory amount.Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: in response to the target object tag being a common target object tag, performing performance resource calculations on common resource items in the resource quantification results using the performance resource amounts corresponding to the common target object tag to obtain a target resource inventory amount; in response to the target object tag being a special target object tag, performing performance resource calculations on common resource items in the resource quantification results and competing resource items corresponding to the special target object tag in the resource quantification results to obtain a target resource inventory amount. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: displaying an inventory view based on the target resource inventory amount, where different target object tags correspond to different inventory views. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: determining a target physical server using the target object tag and the target resource inventory amount; and performing resource scheduling on the target physical server based on the instance tag to obtain a scheduling result. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: in response to an instance scheduling request, selecting a candidate physical server from at least one physical server based on a preset matching mechanism, wherein the preset matching mechanism is used to determine a matching relationship between the identifier of the at least one physical server and the identifiers of different instances; and selecting a target physical server from the candidate physical servers using the target object tag and the target resource inventory. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: filtering a portion of the candidate physical servers using the target object tag and the target resource inventory to obtain a filtering result; weighting the filtering result to obtain a scoring result; and selecting a target physical server based on the scoring result. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: determining an instance scheduling scenario using the instance tag, wherein the instance scheduling scenario is used to determine a resource scheduling operation category; and performing resource scheduling on the target physical server based on the instance scheduling scenario to obtain a scheduling result. The serial numbers of the above-mentioned embodiments of the present disclosure are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments. In the above-described embodiments of the present disclosure, the descriptions of each embodiment are given with emphasis. For portions not described in detail in a particular embodiment, reference can be made to the relevant descriptions of other embodiments. It should be understood that the disclosed technical content of the several embodiments provided in the present disclosure can be implemented in other ways.The device embodiments described above are merely illustrative. For example, the division of units is merely a logical functional division. In actual implementation, other divisions may be employed. For example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not implemented. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be through interfaces, or indirect couplings or communication connections between units or modules, and may be electrical or other. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, i.e., they may be located in one location or distributed across multiple network units. Some or all of these units may be selected to achieve the objectives of the present embodiments based on actual needs. Furthermore, the functional units in the various embodiments of the present disclosure may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. These integrated units may be implemented in either hardware or software functional units. If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present disclosure, or the portion that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product, stored in a storage medium, includes instructions for causing a computer device (such as a personal computer, server, or network device) to perform all or part of the steps of the methods described in the various embodiments of the present disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memories (ROMs), random access memories (RAMs), removable hard drives, magnetic disks, or optical disks. The above description is merely a preferred embodiment of the present disclosure. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present disclosure, and such improvements and modifications should also be considered within the scope of protection of the present disclosure.

Claims

Claims 1. A resource scheduling method, comprising: Obtain instance performance data, wherein the instance performance data is performance indicator data obtained by collecting performance data of multiple cloud server instances created on at least one physical server; generate tag information based on the instance performance data, wherein the tag information includes: a target object tag and an instance tag, wherein the target object tag is used to describe target object behavior attributes, and the instance tag is used to describe instance performance; determine a target resource inventory through the tag information, wherein the target resource inventory is the resource inventory currently available for scheduling; use the tag information and the target resource inventory to perform resource scheduling to obtain a scheduling result, wherein the scheduling result is used to adjust the remaining performance resource amount on the at least one physical server.

2. The resource scheduling method according to claim 1, wherein: Obtaining the instance performance data includes: obtaining the instance performance data from a data storage server, wherein the data storage server is used to receive the instance performance data reported by a data acquisition server and persistently store the instance performance data, and the data acquisition server is used to collect the instance performance data from the multiple cloud server instances created on the at least one physical server and report the instance performance data to the data storage server via log data delivery.

3. The resource scheduling method according to claim 1, wherein: Generating the target object label based on the instance performance data includes: determining target object behavior characteristics based on the instance performance data; using a target object label model to perform feature processing on the target object behavior characteristics to obtain the target object label, wherein the target object label model is used to classify the target object according to the target object behavior characteristics, and the target object label includes: a common target object label and a special target object label, and the instance performance requirement of the common target object label is lower than the instance performance requirement of the special target object label.

4. The resource scheduling method according to claim 1, wherein: Generating the instance label based on the instance performance data includes: determining instance characteristics based on the instance performance data; and performing feature processing on the instance characteristics using an instance label model to obtain the instance label, wherein the instance label model is used to classify instances based on the instance characteristics, and the instance label includes: an existing instance label and a newly created instance label, wherein the existing instance label is used to predict and adjust the performance of an existing instance, and the newly created instance label is used to provide a performance reference for a newly created instance.

5. The resource scheduling method according to claim 1, wherein: The resource scheduling method further includes: quantifying the performance resources of the at least one physical server according to a preset model template to obtain a resource quantification result, wherein the preset model template is used to configure basic performance resources of the at least one physical server.

6. The resource scheduling method according to claim 5, wherein: Determining the target resource inventory through the tag information includes: determining a target performance resource based on the target object tag, wherein the target performance resource is the performance resource required by the current cloud server instance; performing performance resource calculation on the resource quantification result through the target performance resource to obtain the target resource inventory.

7. The resource scheduling method according to claim 6, wherein: Performing performance resource calculation on the resource quantification result through the target performance resource amount to obtain the target resource inventory amount includes: in response to the target object tag being a common target object tag, performing performance resource calculation on the common resource item in the resource quantification result through the performance resource amount corresponding to the common target object tag to obtain the target resource inventory amount; in response to the target object tag being a special target object tag, performing performance resource calculation on the common resource item in the resource quantification result and the competing resource item corresponding to the special target object tag in the resource quantification result through the performance resource amount corresponding to the special target object tag to obtain the target resource inventory amount.

8. The resource scheduling method according to claim 1, wherein: The resource scheduling method further includes: displaying an inventory view based on the target resource inventory, wherein different target object tags correspond to different inventory views.

9. The resource scheduling method according to claim 1, wherein: Performing resource scheduling using the tag information and the target resource inventory to obtain the scheduling result includes: determining a target physical server using the target object tag and the target resource inventory; and performing resource scheduling on the target physical server based on the instance tag to obtain the scheduling result.

10. The resource scheduling method according to claim 9, wherein: Determining the target physical server using the target object tag and the target resource inventory includes: selecting a candidate physical server from the at least one physical server based on a preset matching mechanism in response to an instance scheduling request, wherein the preset matching mechanism is used to determine a matching relationship between an identifier of the at least one physical server and identifiers of different instances; selecting the target physical server from the candidate physical servers using the target object tag and the target resource inventory. Select the physical server.

11. The resource scheduling method according to claim 10, wherein: Selecting the target physical server from the candidate physical servers using the target object tag and the target resource inventory includes: filtering some servers from the candidate physical servers using the target object tag and the target resource inventory to obtain a filtering result; performing weighted scoring on the filtering result to obtain a scoring result; and selecting the target physical server based on the scoring result.

12. The resource scheduling method according to claim 9, wherein: Performing resource scheduling on the target physical server based on the instance tag to obtain the scheduling result includes: determining an instance scheduling scenario using the instance tag, wherein the instance scheduling scenario is used to determine a resource scheduling operation category; and performing resource scheduling on the target physical server based on the instance scheduling scenario to obtain the scheduling result.

13. A resource scheduling method, comprising: A cloud service instance scheduling request is obtained through a first application programming interface, wherein request data carried in the cloud service instance scheduling request includes: tag information, where the tag information is generated based on instance performance data, where the instance performance data is performance indicator data obtained by collecting performance data of multiple cloud server instances created on at least one physical server, and the tag information includes: a target object tag and an instance tag, where the target object tag is used to describe target object behavior attributes, and the instance tag is used to describe instance performance. A cloud service instance scheduling response is returned through a second application programming interface, wherein response data carried in the cloud service instance scheduling response includes: a scheduling result, where the scheduling result is obtained by performing resource scheduling using the tag information and a target resource inventory, where the scheduling result is used to adjust the remaining performance resource amount on the at least one physical server, where the target resource inventory amount is determined by the tag information, and the target resource inventory amount is the resource inventory amount currently available for scheduling.

14. A resource scheduling method, comprising: Obtain a currently input cloud service instance scheduling dialogue request, wherein the information carried in the cloud service instance scheduling dialogue request includes: tag information, wherein the tag information is generated based on instance performance data, wherein the instance performance data is performance indicator data obtained by collecting performance data of multiple cloud server instances created on at least one physical server, and the tag information includes: a target object tag and an instance tag, wherein the target object tag is used to describe target object behavior attributes, and the instance tag is used to describe instance performance performance; in response to the cloud service instance scheduling dialogue request, return a cloud service instance scheduling dialogue reply, wherein the The information carried in the cloud service instance scheduling dialogue reply includes: a scheduling result, which is obtained by performing resource scheduling using the tag information and the target performance resource amount, and the scheduling result is used to adjust the remaining performance resource amount on the at least one physical server, and the target resource inventory amount is determined by the tag information, and the target resource inventory amount is the resource inventory amount currently available for scheduling; and the scheduling result is displayed in the graphical target object interface.

15. A resource scheduling system, comprising: a data collection server configured to collect instance performance data from multiple cloud server instances created on at least one physical server and report the instance performance data to a data storage server by means of log data delivery; the data storage server configured to receive the instance performance data reported by the data collection server and persistently store the instance performance data; A performance profiling server is configured to obtain the instance performance data and generate label information based on the instance performance data, wherein the label information includes: a target object label and an instance label, wherein the target object label is used to describe the target object behavior attributes, and the instance label is used to describe the instance performance; a resource scheduling server is configured to determine the target performance resource amount through the label information, and perform resource scheduling using the label information and the target resource inventory to obtain a scheduling result, wherein the target resource inventory amount is the resource inventory amount currently available for scheduling, and the scheduling result is used to adjust the remaining performance resource amount on the at least one physical server.

16. The resource scheduling system according to claim 15, wherein: The resource scheduling server is further configured to determine a target physical server using the target object tag and the target resource inventory, and perform resource scheduling on the target physical server based on the instance tag to obtain the scheduling result.

17. An electronic device, comprising: a memory storing an executable program; A processor is configured to run the program, wherein the program executes the resource scheduling method according to any one of claims 1 to 14 when running.

18. A computer-readable storage medium comprising a stored executable program, wherein: When the executable program is running, the device where the computer-readable storage medium is located is controlled to execute the resource scheduling method according to any one of claims 1 to 14.

Images