Resource allocation method, electronic device and computer readable storage medium

Abstract

The present disclosure relates to the technical field of computer technology and cloud computing. Disclosed are a resource allocation method, an electronic device and a computer readable storage medium. The method comprises: acquiring tag information, wherein the tag information is used for characterizing behavior attributes of a target object; determining a target virtual resource view associated with the tag information, wherein the target virtual resource view is used for displaying a virtual resource management relationship in a target application scenario; on the basis of a preset scheduling policy and the target virtual resource view, selecting a target physical server corresponding to the tag information, wherein the preset scheduling policy is used for determining scheduling relationships between different physical servers; and using the target physical server to allocate a corresponding target cloud server instance to the tag information. The present disclosure solves the technical problems in the related art of waste of resources and reduction of service stability and response speed caused by mutual contention of virtual resources between instances.

Description

[0001]TECHNICAL FIELD The present disclosure relates to the fields of computer technology and cloud computing technology, and more specifically, to a resource allocation 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 resource allocated to a user. An instance can be a virtual machine (VM), a container, or the like. Using virtualization technology, a physical machine divides its resources into multiple virtual resources, which can be allocated to different virtual machine instances. Currently, when a user's task demands exceed the corresponding virtual resources, instance contention occurs. Instances compete for each other's resources, resulting in wasted and unutilized resources, impacting service stability and responsiveness. This also increases the risk of user services being damaged, impacting user service operations. Currently, no effective solutions have been proposed to address the aforementioned issues. SUMMARY OF THE INVENTION Embodiments of the present disclosure provide a resource allocation method, electronic device, and computer-readable storage medium to at least address the technical issues in related technologies where instances compete for virtual resources, resulting in wasted resources and reduced service stability and responsiveness. According to one aspect of an embodiment of the present disclosure, a resource allocation method is provided, comprising: obtaining tag information, wherein the tag information is used to characterize behavioral attributes of a target object; determining a target virtual resource view associated with the tag information, wherein the target virtual resource view is used to display virtual resource management relationships in a target application scenario; selecting a target physical server corresponding to the tag information based on a preset scheduling policy and the target virtual resource view, wherein the preset scheduling policy is used to determine scheduling relationships between different physical servers; and using the target physical server to allocate a target cloud server instance corresponding to the tag information.According to another aspect of an embodiment of the present disclosure, a resource allocation method is further provided, comprising: obtaining a cloud server instance purchase request through a first application programming interface, wherein request data carried in the cloud server instance purchase request includes: tag information, where the tag information is used to characterize behavioral attributes of a target object; and returning a cloud server instance purchase response through a second application programming interface, wherein response data carried in the cloud server instance purchase response includes: a target cloud server instance, where the target cloud server instance is allocated using the tag information as a target physical server, where the target physical server is selected based on a preset scheduling policy and a target virtual resource view, where the preset scheduling policy is used to determine a scheduling relationship between different physical servers, where the target virtual resource view is determined by the tag information, and where the target virtual resource view is used to display the virtual resource management relationship in the target application scenario. According to another embodiment of the present disclosure, a resource allocation method is provided, comprising: obtaining a currently input cloud server instance purchase dialog request, wherein the information carried in the cloud server instance purchase dialog request includes tag information, which is used to characterize the behavioral attributes of the target object; returning a cloud server instance purchase dialog reply in response to the cloud server instance purchase dialog request, wherein the information carried in the cloud server instance purchase dialog reply includes a target cloud server instance, wherein the target cloud server instance is assigned using the tag information of the target physical server, wherein the target physical server is selected based on a preset scheduling policy and a target virtual resource view, wherein the preset scheduling policy is used to determine the scheduling relationship between different physical servers, and the target virtual resource view is determined by the tag information, wherein the target virtual resource view is used to display the virtual resource management relationship in the target application scenario; and displaying the target cloud server instance in a graphical user interface. According to another 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 allocation 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 allocation methods.In the embodiments of the present disclosure, tag information describing the behavior attributes of a target object is obtained. Based on the target object's behavior, a target virtual resource view to be displayed to the target object is determined. Then, based on a preset scheduling policy and the target virtual view representing the virtual resource management relationship in the target application scenario, a target physical server corresponding to the tag information is selected. This means a target physical machine that meets the needs of the target object and can provide better services for these needs is selected. Finally, based on the selected target physical server, a corresponding target cloud server instance (i.e., a corresponding cloud server product) is assigned to the behavior of the target object. This achieves the goal of rationally allocating cloud server instances based on tag information. By virtualizing physical resources into multiple virtual resource views to meet the resource requirements of different objects, instance contention is avoided, thereby achieving the technical effect of avoiding resource waste and improving service stability and responsiveness. This further addresses the technical problem in related technologies where instances compete for virtual resources, resulting in resource waste and reduced service stability and responsiveness. It should be noted that the general description above and the detailed description that follow are merely illustrative and illustrative of the present disclosure and do not constitute a limitation of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS The drawings described herein are used 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 used to explain the present disclosure and do not constitute an improper limitation on the present disclosure. In the accompanying drawings: Figure 1 is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a resource allocation method according to Example 1 of the present disclosure; Figure 2 is a flow chart of a resource allocation method according to Example 1 of the present disclosure; Figure 3 is a schematic diagram of dividing a virtual resource view according to Example 1 of the present disclosure; Figure 4 is a schematic diagram of a scheduling system interaction according to Example 1 of the present disclosure; Figure 5 is a schematic diagram of a user purchase process according to Example 1 of the present disclosure; Figure 6 is a correspondence diagram of an application scenario, inventory view and resource pool according to Example 1 of the present disclosure; Figure 7 is a flow chart of a resource allocation method according to Example 2 of the present disclosure; Figure 8 is a flow chart of a resource allocation method according to Example 3 of the present disclosure; Figure 9 is a structural schematic diagram of a resource allocation device according to Example 4 of the present disclosure; Figure 10 is a structural schematic diagram of another resource allocation device according to Example 4 of the present disclosure; Figure 11 is a structural schematic diagram of yet another resource allocation device according to Example 4 of the present disclosure; Figure 12 is a structural block diagram 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 following will provide a clear and complete description of the technical solutions in the embodiments of the present disclosure, in conjunction with the accompanying drawings. It should be noted that 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 such terms are interchangeable where appropriate, such 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 expressly listed, but may include other steps or units not expressly listed or inherent to such process, method, product, or apparatus. First, some nouns or terms used in describing the embodiments of this disclosure are subject to the following interpretations: Resource view: refers to a resource-centric information display method or interface used to express resource management relationships in different usage scenarios. Virtual resource technology: abstracts physical resources to enable the virtualization of a single physical resource into multiple resource views. Sales inventory: refers to the remaining quantity of a product specification visible to customers on the console page. Physical server: physical machine hardware, including independent resources such as the central processing unit (CPU), memory, and disk. Combined with the deployment of a software environment, a physical server can provide various basic resources for cloud servers and serves as the cloud server operating environment. Cloud server: a computing service provided by cloud computing, represented as a simulated server on which customers can install and run operating systems and applications. Cloud server product: cloud servers are categorized based on different characteristics such as performance, price, and configuration to meet different customer business usage scenarios. Related technologies that display resource library inventory status through inventory views have the following drawbacks. Defect 1: Instance contention causes some resources to be wasted and underutilized, impacting service stability and responsiveness. This also increases the risk of user service disruption and impacts user operations. Prior to this disclosure, no effective solution had been proposed to address this defect.Embodiment 1 According to an embodiment of the present disclosure, a resource allocation 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 allocation 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) (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, it 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." This data processing circuitry may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuitry may be a single, independent processing module, or may be fully or partially integrated into any of the other components of the computer terminal 10 (or mobile device). As described in the embodiments of the present disclosure, this data processing circuitry serves as a processor control (for example, selecting a variable resistor terminal path connected to an interface). The memory 104 may be used to store software programs and modules of application software, such as program instructions / data storage devices corresponding to the resource allocation method in the embodiments of the present disclosure. The processor 102 executes the software programs and modules stored in the memory 104 to execute various functional applications and data processing, thereby implementing the resource allocation method described above. The memory 104 may include a high-speed random access memory (RAM) and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory.In some examples, memory 104 may further include memory remotely located relative to processor 102, and these remote memories may be connected to computer terminal 10 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. Transmission device 106 is used to receive or send data via a network. Specific examples of such networks 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 above operating environment, the present disclosure provides a resource allocation method as shown in FIG2 . FIG2 is a flow chart of a resource allocation method according to Example 1 of the present disclosure. As shown in Figure 2, the method may include the following steps: Step S21: Acquire tag information, where the tag information is used to characterize the behavioral attributes of the target object; Step S22: Determine the target virtual resource view associated with the tag information, where the target virtual resource view is used to display the virtual resource management relationship in the target application scenario; Step S23: Select the target physical server corresponding to the tag information based on a preset scheduling policy and the target virtual resource view, where the preset scheduling policy is used to determine the scheduling relationship between different physical servers; Step S24: Use the target physical server to assign the target cloud server instance corresponding to the tag information. In the disclosed embodiment, the tag information is used to characterize the behavioral attributes of the target object. If the target object is a user, the tag information is used to characterize the user's behavioral attributes, which may include information such as the user's characteristics, behavior, preferences, and interests, which can be understood as a user profile. For example, the tag information may include historical user purchase behavior information and current user purchase behavior information, such as historical user purchase instance information and current user purchase instance behavior information, but this is not limited here. The target application scenario can be understood as an application scenario associated with the behavior attributes of the target object. For example, the corresponding target application scenario can be determined based on the purchase behavior of the target object.For example, based on user purchasing behavior, target application scenarios can be categorized into short-term scenarios, emergency scenarios, and daily scenarios, without limitation. Taking instance purchase as an example, a short-term scenario indicates that the target user uses the purchased instance for a short period of time, requiring the instance to provide services for a short period of time, rather than a long-term or continuous need. For example, if a user purchases a Spot Instance (SPOT) product, the corresponding scenario can be determined as a short-term scenario based on the user's purchasing behavior. An emergency scenario indicates that the user purchases an instance in a sudden or emergency situation and requires the instance to address a specific user's immediate needs. A daily scenario indicates that the purchased instance requires long-term or continuous service. The disclosed embodiments propose virtual resource views, which divide and virtualize a physical resource into multiple virtual resource views. Different virtual resource views are used to meet the different resource needs of the target object. It is understood that the target object's purchasing behavior can reflect its resource needs. The target virtual resource view is used to display the virtual resource management relationships within the target application scenario, namely, to display the virtual resources that can meet the target object's needs. Virtual resource management relationships can be understood as the management relationships of virtual resources derived from underlying physical resources through virtualization technology. In the disclosed embodiments, different virtual resources are used to provide services in different application scenarios. Different virtual resource management relationships in different application scenarios are displayed through different virtual resource views to meet the varying resource requirements of target objects. Virtual resource views may include virtual resources derived from virtualization technology, such as central processing units (CPUs), memory (MEMs), graphics processing units (GPUs), and disk storage (DISKs), though this is not a limitation. In the disclosed embodiments, different target object requirements correspond to different virtual resource views. For example, if a user purchases a SPOT product, the associated target application scenario is a short-term scenario, so the corresponding target virtual resource view is determined to be View A. It can be understood that users who purchase the SPOT product will only see View A, which displays the virtual resource view that meets their needs. It is understandable that if many instances are running on physical machine B and the load pressure on physical machine B is too high, the load pressure on physical machine B can be reduced by migrating the instances to other physical machine C with less load pressure.The preset scheduling policy is used to determine the scheduling relationship between different physical machines (i.e., physical servers). Based on this preset scheduling policy, the physical machine that can best provide a service among multiple physical machines can be determined, that is, the physical machine that is prioritized can be determined. For example, the target physical machine for providing services can be determined based on the preset scheduling policy and the target virtual resource view when an instance is first created. If a physical machine experiences excessive load during service provision, a target physical machine with a lower load to which the instance should be migrated can also be determined based on the preset scheduling policy and the target virtual resource view. The target physical machine can be understood as the physical machine that can best provide services, as determined based on the preset scheduling policy and the target virtual resource view. In the disclosed embodiments, the preset scheduling policy and the virtual resource management relationship for the target application scenario corresponding to the tag information displayed by the target virtual resource view can be used to determine the target physical machine that can best run the virtual resource based on the preset scheduling policy and the virtual resources displayed in the target virtual resource view. This target physical machine can then be selected to assign the target cloud server instance corresponding to the tag information. In the disclosed embodiments, tag information describing the behavior attributes of a target object is obtained. Based on the target object's behavior, a target virtual resource view to be presented to the target object is determined. Then, based on a preset scheduling policy and the target virtual view representing the virtual resource management relationship in the target application scenario, a target physical server corresponding to the tag information is selected. This means that the target physical machine is suitable for the target object's needs and can provide better services for those needs. Finally, based on the selected target physical server, a corresponding target cloud server instance (i.e., a corresponding cloud server product) is assigned to the target object's behavior. This allows different virtual resource views to be presented to different target objects based on the target object's behavior attributes, thereby meeting the resource needs of the different target objects. Furthermore, because target objects with different behavior attributes correspond to different virtual resource views, and therefore different target physical machines for providing services, instance contention can be avoided, resource waste is minimized, and service stability and responsiveness are improved. The resource allocation methods provided in the embodiments of the present disclosure can be applied, but are not limited to, to application scenarios involving instance purchases in fields such as e-commerce services, educational services, legal services, medical services, conference services, social networking services, financial product services, logistics services, and navigation services. For example, these scenarios include instances purchased for e-commerce services, instances purchased for educational services, and instances purchased for medical services, and are not limited here. Furthermore, the methods provided in the present disclosure can be applied in scenarios including, but not limited to, public clouds and private clouds, and are not limited here.According to the disclosed embodiments, tag information describing the behavior attributes of a target object is obtained. Based on the target object's behavior, a target virtual resource view to be displayed to the target object is determined. Then, based on a preset scheduling policy and the target virtual view representing the virtual resource management relationship in the target application scenario, a target physical server corresponding to the tag information is selected. In other words, a target physical machine that meets the needs of the target object and can provide better services for these needs is selected. Finally, based on the selected target physical server, a target cloud server instance corresponding to the behavior of the target object, i.e., a corresponding cloud server product, is assigned. This achieves the goal of rationally allocating cloud server instances based on tag information. By virtualizing physical resources into multiple virtual resource views to meet the resource requirements of different objects, instance contention is avoided, thereby achieving the technical effect of avoiding resource waste and improving service stability and responsiveness. This further addresses the technical problem in related technologies where instances compete for virtual resources, resulting in resource waste and reduced service stability and responsiveness. In an optional embodiment, obtaining tag information in step S21 includes the following method steps: Step S211: Displaying an inventory view for the target application scenario, wherein the inventory view is used to display the remaining inventory of resources to be traded, and the inventory view includes at least one of a basic inventory view and an inventory view provided by a virtual resource; Step S212: Responding to a trigger operation based on the inventory view, obtaining tag information from the portrait parameter carried in the cloud server instance purchase request. The inventory view is used to display the remaining inventory of resources to be traded, which can be understood as displaying the remaining inventory of instances that can be purchased by the target object. The inventory view can include a basic inventory view and other inventory views. The basic inventory view can be understood as the default view, while the other inventory views can include inventory views provided by virtual resources or inventory views provided by other means, without limitation. In the disclosed embodiment, the physical resource view of a physical resource is divided and virtualized into multiple virtual resource views to meet the different resource requirements of users. Therefore, the inventory view can be a basic inventory view, an inventory view provided by a virtual resource, or a combination of a basic inventory view and an inventory view provided by a virtual resource. The basic inventory view can be understood as a view displaying basic resources, such as general resources such as CPU resources, GPU resources, and memory resources. The inventory view provided by virtual resources can be understood as a view of virtual resources divided for different application scenarios. For example, if the application scenario is a short-term scenario, the inventory view provided by virtual resources is a view of virtual resources for that short-term scenario.In the disclosed embodiments, when acquiring tag information, when a target subject performs a purchase, a corresponding target application scenario can be determined based on the target subject's purchase behavior. Exemplarily, a profile tag can be assigned to each purchase. After determining the target application scenario, an inventory view for that target application scenario can be displayed to the target subject, specifically, the remaining inventory of the resource to be traded. The target subject can purchase instances based on the inventory view. Upon receiving a cloud server instance purchase request initiated by the target subject based on the inventory view, i.e., upon receiving a trigger operation based on the inventory view, tag information is obtained from the profile parameter carried in the cloud server instance purchase request. Exemplarily, a key can be selected from the profile parameter carried in the cloud server instance purchase request as a parameter value for the scheduling profile, and tag information is determined based on this parameter value. Exemplarily, the scheduling profile can include a scheduling policy profile and a resource profile, without limitation herein. The scheduling policy profile can be understood as a model that analyzes and describes the scheduling policy based on factors such as scheduling requirements, resource availability, and time constraints. A resource profile can be understood as a model that describes and analyzes resources based on their attributes, type, status, and other information. In an optional embodiment, the resource allocation method further includes the following steps: Step S25: Performing resource abstraction on the physical resource to be processed to obtain multiple virtual resources, wherein the physical resource to be processed is a physical resource provided by at least one physical server; Step S26: Obtaining virtual resource views based on the multiple virtual resources, wherein the multiple virtual resource views are used to respectively display virtual resource management relationships in different application scenarios, each corresponding to different resource requirements; Step S27: Establishing associations between different tag information and the multiple virtual resource views, wherein the tag information is associated with the target virtual resource view. In the disclosed embodiment, resource abstraction can be performed on the physical resource to be processed to obtain multiple virtual resources. It is understood that the physical resource to be processed can be a physical resource provided by at least one physical server. Information about the abstracted virtual resources is then displayed to create multiple virtual resource views. Specifically, these virtual resource views represent virtual resource management relationships in different application scenarios, thereby virtualizing physical resources into multiple virtual resource views to meet the diverse resource requirements of target users. For example, the physical resources to be processed can be abstracted into 10 virtual resources, each corresponding to a resource requirement in a different application scenario. These 10 virtual resource views are then used to represent these different application scenarios, achieving the technical effect of meeting diverse user resource requirements through different virtual resource views.After obtaining multiple virtual resource views, associations can be established between different pieces of tag information and the multiple virtual resource views. The tag information can be associated with the virtual resource views corresponding to the application scenario. This allows the virtual resource view corresponding to the tag information to be pre-determined. When multiple target objects have the same target object behavior attributes, the same virtual resource view can be reused, and the target virtual resource view corresponding to the tag information can be quickly determined based on the pre-determined associations. In an optional embodiment, determining the target virtual resource view associated with the tag information in step S22 includes the following method steps: Step S221: Determining the target virtual resource view corresponding to the tag information based on the pre-established associations. In the disclosed embodiment, when determining the target virtual resource view associated with the tag information, the target virtual resource view corresponding to the tag information can be determined based on the pre-established associations. This allows the target virtual resource view corresponding to the tag information to be quickly determined based on the pre-determined associations, thereby improving response time. In an optional embodiment, in step S23, based on a preset scheduling policy and a target virtual resource view, a target physical server corresponding to the tag information is selected, including the following method steps: Step S231: Obtaining a candidate physical server corresponding to the tag information using the target virtual resource view; Step S232: Selecting a target physical server corresponding to the tag information from the candidate physical servers based on the preset scheduling policy. In the disclosed embodiment, when selecting a target physical server corresponding to the tag information based on the preset scheduling policy and the target virtual resource view, the target virtual resource view associated with the tag information can be used to obtain the candidate physical server corresponding to the tag information. Exemplarily, the candidate physical server may include at least one physical server. It is understood that the candidate physical server is a server that can meet the user's resource requirements. After determining the candidate physical servers, the target physical server corresponding to the tag information is selected from the candidate physical servers based on the preset scheduling policy, i.e., the target physical server that can better provide the service is selected from the multiple physical servers. Exemplarily, a physical server scorer can be used to score the multiple candidate physical servers, and the physical server with the highest score can be selected as the target physical server based on each physical server's score, although this is not a limitation herein. In an optional embodiment, in step S231, obtaining candidate physical servers corresponding to tag information using the target virtual resource view includes the following method steps: Step S2311: Determining a resource production source using the target virtual resource view; Step S2312: Loading candidate physical servers based on the resource production source. It is understood that different resources may have different resource production sources, i.e., different resource production methods may be different.Exemplarily, resource production sources may include normal deployment, mixed production, reused production, and other sources, which are not limited herein. In embodiments of the present disclosure, when using a target virtual resource view to obtain candidate physical servers corresponding to tag information, the target virtual resource view associated with the tag information may be used to determine the resource production source. It is understood that the target virtual resource view may include multiple virtual resources, each of which may correspond to multiple resource production sources. After determining the resource production source, the corresponding candidate physical server may be loaded based on the resource production source. In an optional embodiment, the resource allocation method further includes the following method steps: Step S2313: Based on the different resource production sources of the physical resources to be processed, the physical resources to be processed are divided into multiple resource pools, wherein the multiple resource pools correspond to different application scenarios, and different application scenarios correspond to different resource requirements. In embodiments of the present disclosure, the physical resources to be processed may also be divided into multiple resource pools based on their different resource production sources. It is understood that one resource pool corresponds to one virtual resource obtained by division, and different resource pools correspond to different application scenarios to meet different resource requirements of users. Exemplarily, the multiple resource pools may include normal resource pools, mixed pools, reuse pools, and other resource pools, which are not limited herein. The resources in a normal resource pool are produced through normal deployment, while the resources in a mixed pool are produced through mixed production. These pools can be understood as resource pools that manage and allocate different types of resources together, allowing for flexible deployment and allocation as needed to meet diverse requirements. The resources in a reuse pool are produced through reuse, while the resources in other resource pools are produced through other production methods. These pools can be understood as resource pools that reuse and recycle resources. Resources in a reuse pool can be used and allocated multiple times to maximize resource utilization and efficiency, reduce resource waste and consumption, and improve sustainable resource utilization. In an optional embodiment, in step S2312, candidate physical servers are loaded based on the resource production source, including the following method steps: Step S23121: Determine a target resource pool corresponding to the resource production source from multiple resource pools; Step S23122: Load candidate physical servers based on the target resource pool. In the embodiment of the present disclosure, when loading candidate physical servers based on resource production sources, a target resource pool corresponding to the resource production source may be determined from the multiple resource pools obtained by division.It is understood that the resource production source is determined based on the target virtual resource view associated with the tag information. Therefore, the target resource pool corresponding to the resource production source is the resource pool associated with the tag information, and thus the candidate physical server can be loaded based on this target resource pool. It is understood that the target resource pool may include at least one resource pool, for example, only normal resource pools, only mixed resource pools, or both normal resource pools and mixed resource pools, depending on actual circumstances and not limited herein. In an optional embodiment, the available resource range corresponding to the target virtual resource view is equal to the available resource range corresponding to the inventory view in the target application scenario. The target virtual resource view is visible to a first target object and invisible to a second target object. The first target object is the target object corresponding to the tag information, and the second target object is the target object corresponding to tag information other than the tag information. In this embodiment of the present disclosure, the available resource range corresponding to the target virtual resource view displayed to the target object is equal to the available resource range corresponding to the inventory view. That is, the inventory view seen by the target object in the console and application programming interface (API) is the same as the resource view encountered during the final scheduling, achieving a "what you see is what you get" technical effect for the target object's resource inventory. In this embodiment of the present disclosure, the target virtual resource view only displays the first target object associated with the target virtual resource view, that is, only the first target object corresponding to the tag information associated with the target virtual resource view is displayed. This can also be understood as only displaying the first target object in the target application scenario displayed by the target virtual resource view, while second target objects outside the target application scenario are invisible to the target virtual resource view. Figure 3 is a schematic diagram of partitioning virtual resource views according to Embodiment 1 of the present disclosure. For underlying physical resources, virtual resource technology can be used to abstract the underlying physical resources, virtualize the underlying physical resource view into multiple virtual resource views, and present them to the user in the form of virtual resource views. As shown in Figure 3, the physical resource view of the CPU, GPU, MEM, and disk (DISK) is abstracted into four virtual resource views based on different application scenarios through virtualization technology: a restricted supply view, a resource reuse view, an O&M backup view, and a regular resource view. The virtual resource sizes of the CPU, GPU, MEM, and DISK allocated in each of the abstracted virtual resource views vary.Target application scenarios can be determined based on user behavior. Users matching short-term scenarios will be presented with a restricted supply view and resource reuse view; users matching emergency scenarios will be presented with an operation and maintenance guarantee view; and users matching daily scenarios will be presented with a regular resource view. Figure 4 is a schematic diagram of a scheduling system interaction according to Example 1 of the present disclosure. As shown in Figure 4, after a user makes a purchase, the console determines tag information based on the user's purchase behavior. Based on this tag information and other information such as the product the user is purchasing, the console determines the target application scenario. The console then transmits the user's profile parameters to the scheduling system, which performs inventory scheduling based on these profile parameters and displays the remaining inventory to the user. The scheduling system then determines the corresponding target virtual resource view based on the tag information, identifies candidate physical servers based on the corresponding resource pool, and loads a preset scheduling policy based on the tag information. Finally, based on the preset scheduling policy and the candidate physical servers, a target physical server is determined. A target cloud server instance is allocated based on this target physical server to meet the user's service needs. Figure 5 is a schematic diagram of a user purchase process according to Example 1 of the present disclosure. As shown in Figure 5, the user's application scenario is a short-term scenario. After a user makes a purchase, they see the corresponding inventory view: the basic inventory view and the temporary mixed inventory view for short-term scenarios. The user then initiates a purchase based on the inventory level they see, creating an instance. After receiving the user's purchase request, the scheduling system determines the associated target virtual resource view based on the tag information and displays it to the user. Using a pre-set table for recording resource pools corresponding to different application scenarios, the scheduling system obtains the resource production source corresponding to the tag information, namely, the normal resource pool and the mixed pool for short-term scenarios. The scheduling system then loads available physical machines, or candidate physical servers, based on the resource production source. For example, NCI, NC2, NC3, and NC4 are loaded. Finally, based on the pre-set scheduling policy and the target virtual resource view, the scheduling system selects NC1 as the target physical server from NCI, NC2, NC3, and NC4. Based on this target physical server, the scheduling system allocates the target cloud server instance to meet the user's service needs.FIG6 is a diagram illustrating the relationship between application scenarios, inventory views, and resource pools according to Example 1 of the present disclosure. As shown in FIG6 , application scenarios may include, for example, scenarios with normal user demand, operations and maintenance migration, scenarios with short-term resource demand, scenarios with short-term resource demand from Elastic Compute Infrastructure (ECI) / SPOT, and various other resource demand scenarios (e.g., the Other Resource Demand 3 scenario and the Other Resource Demand n scenario in FIG6 ). Users in different application scenarios can view different inventory views. For example, users in the normal user demand scenario can view the default view, i.e., the basic inventory view. Users in the operations and maintenance migration scenario can view the default view and a temporary mixed view. Users in the short-term resource demand scenario can view the default view, the reused view, and a temporary mixed view. Users in the ECI / SPOT short-term resource demand scenario can view the default view and the reused view. Users in the Other Resource Demand 3 scenario can view View-3 and View-4. Users in the Other Resource Demand n scenario can view View-n. For example, the correspondence between resources and resource pools in the inventory view can be: the default view corresponds to the normal resource pool; the temporary mixed view corresponds to the temporary mixed pool; the reuse view corresponds to the reuse pool; view-3 corresponds to resource pool 4; views-4 and 5 correspond to resource pool 5; and view-n corresponds to resource pools 6 and n. The normal resource pool's resources are produced through normal deployment; the temporary mixed pool's resources are produced through mixed production; the reuse pool's resources are produced through reuse production; resource pool 4's resources are produced through source 4; resource pool 5's resources are produced through source 5; resource pool 6's resources are produced through source 6; and resource pool n's resources are produced through source n. As can be seen, according to the solution provided by the embodiments of the present disclosure, physical resources are virtualized into multiple virtual resources using virtual resource technology, and these multiple virtual resources are virtualized into multiple virtual resource views to meet different user usage scenarios. By establishing an association between the user-visible inventory and the underlying resource view, the virtual view, sales inventory, and scheduling system are linked—that is, the user-visible view, the scheduling decision system, and the resource view management—to achieve what users see is what they get. Furthermore, this disclosure can improve resource turnover and achieve resource reuse by using time-sharing to reuse unfulfilled or idle resources.Furthermore, based on the present disclosure, the fragmented resources caused by product isolation can be provided to short-term users through mixed operation, thus avoiding idle waste of resources and not affecting the sale of the original product. In addition, higher-cost resources can be used for bottom-up scheduling and operation and maintenance scenarios. Although they cannot be generally supplied, they can solve the urgent needs of specific customers. At the same time, the present disclosure sells products in a fully mixed manner, providing limited mixed resources to customers who need them most, thereby maximizing the value of resources. It is easy to understand that the beneficial effects of the resource allocation method provided by the present disclosure include the following points. Beneficial effect (1) avoids the phenomenon of instances competing for virtual resources, saves resources, and improves service stability and response speed. Beneficial effect (2) enables users to achieve what they see is what they get for resource inventory, that is, the inventory view seen by users in the console and API interface is the same as the resource view faced by the final scheduling. Beneficial effect (3) realizes resource reuse and maximizes the value of resources. 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, etc.) 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 the 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 the sake of simplicity, 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 can be performed in a different order or simultaneously according to this disclosure. Furthermore, those skilled in the art should also understand 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 necessary general-purpose hardware platform, or alternatively, hardware. Based on this understanding, the technical solution of the present 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 a number of 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 the present disclosure.Example 2 In the operating environment of Example 1, the present disclosure provides a resource allocation method as shown in Figure 7. Figure 7 is a flowchart of a resource allocation method according to Example 2 of the present disclosure. As shown in Figure 7, the method includes: Step S71, obtaining a cloud server instance purchase request through a first application programming interface, wherein the request data carried in the cloud server instance purchase request includes: tag information, and the tag information is used to characterize the behavior attributes of the target object; Step S72, returning a cloud server instance purchase response through a second application programming interface, wherein the response data carried in the cloud server instance purchase response includes: a target cloud server instance, and the target cloud server instance is obtained by allocating the tag information using the target physical server, and the target physical server is selected based on a preset scheduling policy and a target virtual resource view, and the preset scheduling policy is used to determine the scheduling relationship between different physical servers, and the target virtual resource view is determined by the tag information, and the target virtual resource view is used to display the virtual resource management relationship in the target application scenario. A cloud server instance purchase request can be understood as a user-initiated request to purchase a cloud server instance. The request data carried in the cloud server instance purchase request includes tag information, which is used to characterize the behavioral attributes of the target object. If the target object is a user, the tag information is used to characterize the user's behavioral attributes and may include information such as the user's characteristics, behavior, preferences, and interests, which can be understood as a user profile. Exemplarily, the tag information may include historical and current user purchase behavior information, such as historical and current instance purchase information, though this is not a limitation. A cloud server instance purchase response can be understood as feedback to the user regarding the purchased target cloud server instance. The response data carried in the cloud server instance purchase response includes the target cloud server instance. The target physical server is selected based on a preset scheduling policy and a target virtual resource view, and the target cloud server instance is assigned using the tag information for the target physical server. In the disclosed embodiments, a target application scenario can be understood as an application scenario associated with the target object's behavioral attributes. For example, the corresponding target application scenario can be determined based on the user's purchase behavior. For example, based on user purchasing behavior, target application scenarios can be categorized into short-term scenarios, emergency scenarios, and daily scenarios, among others, without limitation. A short-term scenario refers to a user's use of the purchased instance for a short period of time, meaning that the user requires the instance to provide services for a short period of time, rather than a long-term or continuous need. For example, if a user purchases a Spot Instance (SPOT) product, the corresponding scenario can be determined as a short-term scenario based on the user's purchasing behavior.The emergency scenario involves a user purchasing an instance in an unexpected or emergency situation, requiring the instance to address a specific user's immediate needs. The daily scenario involves a user purchasing an instance requiring long-term or continuous service. The disclosed embodiments propose virtual resource views, which divide and virtualize a physical resource into multiple virtual resource views. Different virtual resource views are used to meet the varying resource needs of target users. It is understood that the target user's purchasing behavior can reflect their resource needs. The target virtual resource view displays the virtual resource management relationships within the target application scenario, specifically the virtual resources that can meet the target user's needs. Virtual resource management relationships can be understood as the management relationships between virtual resources derived from underlying physical resources through virtualization technology. In the disclosed embodiments, different virtual resources are used to provide services in different application scenarios. Different virtual resource views are used to display the virtual resource management relationships within these application scenarios, thereby meeting the varying resource needs of users. The virtual resource view may include virtual resources obtained through virtualization technology, such as a central processing unit (CPU), memory (MEM), graphics processing unit (GPU), and disk storage (DISK), without limitation. In the disclosed embodiments, different target object requirements correspond to different virtual resource views. For example, if a user purchases a SPOT product, the associated target application scenario is a short-term scenario, so the corresponding target virtual resource view is determined to be View A. It can be understood that users who purchase the SPOT product can only see View A, which displays the virtual resource view that meets their needs. It can be understood that if physical machine B is running many instances and experiencing excessive load, the load on physical machine B can be reduced by migrating instances to physical machine C, which has a lower load. The preset scheduling policy is used to determine the scheduling relationship between different physical machines (i.e., physical servers). Based on this preset scheduling policy, the physical machine that can best provide services among multiple physical machines can be determined, that is, the physical machine to be prioritized can be determined. For example, the target physical machine that provides services when the instance is first created can be determined based on the preset scheduling policy and the target virtual resource view. If excessive load pressure occurs during the process of providing services on a certain physical machine, the target physical machine with less load pressure to which the instance is to be migrated can also be determined based on the preset scheduling policy and the target virtual resource view.The target physical machine can be understood as a physical machine that can better provide the service, determined based on the preset scheduling policy and the target virtual resource view. In the disclosed embodiments, the preset scheduling policy and the virtual resource management relationship in the target application scenario corresponding to the tag information displayed in the target virtual resource view are used to determine the target physical machine that can best run the virtual resource based on the preset scheduling policy and the virtual resources displayed in the target virtual resource view. This target physical machine is then selected to assign the target cloud server instance corresponding to the tag information. In the disclosed embodiments, a cloud server instance purchase request is obtained via a first application programming interface. The request data carried in the cloud server instance purchase request includes tag information, which is used to characterize the behavioral attributes of the target object. A cloud server instance purchase response is then returned via the second application programming interface. The response data carried in the cloud server instance purchase response includes the target cloud server instance, which is assigned using the target physical server tag information. The target physical server is selected based on a preset scheduling policy and a target virtual resource view. The preset scheduling policy determines the scheduling relationship between different physical servers. The target virtual resource view is determined by the tag information and is used to display the virtual resource management relationship in the target application scenario. This allows different virtual resource views to be displayed to different target objects based on their behavioral attributes, thereby meeting the resource needs of different target objects. Furthermore, because target objects with different behavioral attributes correspond to different virtual resource views, i.e., different target physical machines for providing services, instance contention can be avoided, resource waste is minimized, and service stability and responsiveness are improved. The resource allocation method provided in the embodiments of the present disclosure can be applied, but is not limited to, to application scenarios involving instance purchases in fields such as e-commerce services, educational services, legal services, medical services, conference services, social networking services, financial product services, logistics services, and navigation services. For example, scenarios involving instance purchases for e-commerce services, educational services, and medical services are not limited here. Furthermore, the method provided in the present disclosure can be applied in scenarios including, but not limited to, public clouds and private clouds. In the embodiments of the present disclosure, a cloud server instance purchase request is obtained through a first application programming interface. The request data carried in the cloud server instance purchase request includes tag information, which is used to characterize the behavioral attributes of the target object.A cloud server instance purchase response is then returned via the second application programming interface. The response data carried in the cloud server instance purchase response includes: the target cloud server instance, which is allocated using the target physical server tag information. The target physical server is selected based on a preset scheduling policy and a target virtual resource view. The preset scheduling policy is used to determine the scheduling relationship between different physical servers. The target virtual resource view is determined by the tag information. The target virtual resource view is used to display the virtual resource management relationship in the target application scenario. This achieves the goal of rationally allocating cloud server instances based on tag information. By virtualizing physical resources into multiple virtual resource views to meet different object resource requirements, instance contention is avoided, thereby achieving the technical effect of avoiding resource waste and improving service stability and response speed. This further solves the technical problem in related technologies where instances compete for virtual resources, resulting in resource waste and reduced service stability and response speed. 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 of Example 1, the present disclosure provides a resource allocation method as shown in Figure 8. FIG8 is a flowchart of a resource allocation method according to Embodiment 3 of the present disclosure. As shown in FIG8 , the method includes: step S81, obtaining a currently input cloud server instance purchase dialogue request, wherein the portrait parameters carried in the cloud server instance purchase dialogue request include: tag information, and the tag information is used to characterize the behavior attributes of the target object; step S82, in response to the cloud server instance purchase dialogue request, returning a cloud server instance purchase dialogue reply, wherein the information carried in the cloud server instance purchase dialogue reply includes: a target cloud server instance, and the target cloud server instance is obtained by assigning the tag information using the target physical server, and the target physical server is selected based on a preset scheduling policy and a target virtual resource view, and the preset scheduling policy is used to determine the scheduling relationship between different physical servers, and the target virtual resource view is determined by the tag information, and the target virtual resource view is used to display the virtual resource management relationship in the target application scenario; step S83, displaying the target cloud server instance in a graphical user interface. A cloud server instance purchase dialog request can be understood as a user-initiated dialog request to purchase a cloud server instance. The profile parameters carried in the cloud server instance purchase dialog request include: tag information. The tag information is used to characterize the behavioral attributes of the target object. If the target object is a user, the tag information is used to characterize the user's behavioral attributes, which can include user characteristics, behaviors, preferences, interests, and other information, which can be understood as a user profile.For example, tag information may include historical user purchase behavior information and current user purchase behavior information, such as historical information about user instance purchases and current instance purchase behavior information, though this is not limited here. A cloud server instance purchase conversation reply may be a cloud server instance purchase conversation reply provided to the user. Information carried in the cloud server instance purchase conversation reply includes: a target cloud server instance, where the target cloud server instance is assigned using the target physical server as tag information. In embodiments of the present disclosure, a target application scenario can be understood as an application scenario associated with the behavioral attributes of a target object. For example, a corresponding target application scenario can be determined based on the target object's purchase behavior. For example, based on the user's purchase behavior, target application scenarios can be categorized into short-term scenarios, emergency scenarios, and daily scenarios, though this is not limited here. A short-term scenario indicates that the user's use of the purchased instance is short-term, meaning that the instance's services are required for a short period of time, rather than for a long-term or ongoing need. For example, if a user purchases a Spot Instance (SPOT) product, the corresponding scenario can be determined as a short-term scenario based on the user's purchase behavior. The emergency scenario involves a user purchasing an instance in an emergency or urgent situation, requiring the instance to address a specific user's immediate needs. The daily scenario involves a user purchasing an instance requiring long-term or continuous service. The disclosed embodiments propose virtual resource views, which divide and virtualize a physical resource into multiple virtual resource views. Different virtual resource views are used to meet the varying resource requirements of target users. It is understood that the purchasing behavior of a target user can reflect their resource requirements. The target virtual resource view displays the virtual resource management relationships within the target application scenario, specifically the virtual resources that can meet the target user's needs. Virtual resource management relationships can be understood as the management relationships between virtual resources derived from underlying physical resources through virtualization technology. In the disclosed embodiments, different virtual resources are used to provide services in different application scenarios. Different virtual resource views are used to display the virtual resource management relationships in different application scenarios, thereby meeting the varying resource requirements of the target user. The virtual resource view may include virtual resources obtained through virtualization technology, such as the Central Processing Unit (CPU), Memory (MEM), Graphics Processing Unit (GPU), and Disk Storage (DISK), and is not limited here.In the disclosed embodiments, different target object requirements correspond to different virtual resource views. For example, if a user purchases a SPOT product, the associated target application scenario is a short-term scenario, so the corresponding target virtual resource view is determined to be View A. It can be understood that users who purchase the SPOT product will only see View A, which displays the virtual resource view that meets their needs. It can be understood that if physical machine B is running many instances and experiencing excessive load, the load on physical machine B can be reduced by migrating instances to physical machine C, which has a lower load. The preset scheduling policy is used to determine the scheduling relationship between different physical machines (i.e., physical servers). Based on this preset scheduling policy, the physical machine that can best provide services among multiple physical machines can be determined, i.e., the physical machine that is prioritized can be determined. For example, the preset scheduling policy and the target virtual resource view can be used to determine the target physical machine that provides services when an instance is first created. If a physical machine experiences excessive load while providing services, the preset scheduling policy and the target virtual resource view can also be used to determine the target physical machine with a lower load to which the instance should be migrated. The target physical machine can be understood as a physical machine that can better provide the service, determined based on the preset scheduling policy and the target virtual resource view. In the disclosed embodiments, the preset scheduling policy and the virtual resource management relationship in the target application scenario corresponding to the tag information displayed in the target virtual resource view are used to determine the target physical machine that can best run the virtual resource based on the preset scheduling policy and the virtual resources displayed in the target virtual resource view. This target physical machine is then selected to assign the target cloud server instance corresponding to the tag information. In the disclosed embodiments, during a human-computer interaction, a currently input cloud server instance purchase request is obtained. The information carried in the cloud server instance purchase request includes tag information, which is used to characterize user behavior attributes. Then, in response to the cloud server instance purchase dialog request, a cloud server instance purchase dialog reply is returned. The cloud server instance purchase dialog reply includes the target cloud server instance. The target cloud server instance is assigned using the target physical server tag information. The target physical server is selected based on a preset scheduling policy and a target virtual resource view. The preset scheduling policy determines the scheduling relationship between different physical servers. The target virtual resource view is determined by the tag information and displays the virtual resource management relationship in the target application scenario. Finally, after the target cloud server instance is determined, it is displayed in the graphical user interface to provide feedback to the user.Thus, different virtual resource views can be presented to different users based on their behavioral attributes, thereby meeting their diverse resource needs. Furthermore, since users with different behavioral attributes correspond to different virtual resource views, i.e., different target physical machines for providing services, instance contention can be avoided, resource waste can be avoided, and service stability and responsiveness can be improved. The resource allocation method provided in the embodiments of the present disclosure can be applied, but is not limited to, to application scenarios involving instance purchases in fields such as e-commerce services, educational services, legal services, medical services, conference services, social networking services, financial product services, logistics services, and navigation services. For example, instances purchased for e-commerce services, instances purchased for educational services, and instances purchased for medical services, etc., without limitation here. Furthermore, the methods provided in the present disclosure can be applied in scenarios including, but not limited to, public clouds and private clouds, etc., without limitation here. Using the embodiments of the present disclosure, a currently input cloud server instance purchase dialog request is obtained, wherein the profile parameters carried in the cloud server instance purchase dialog request include tag information, which is used to characterize the behavioral attributes of the target object. Then, in response to the cloud server instance purchase dialog request, a cloud server instance purchase dialog reply is returned. The cloud server instance purchase dialog reply carries information including: the target cloud server instance, which is assigned using the target physical server tag information. The target physical server is selected based on a preset scheduling policy and a target virtual resource view. The preset scheduling policy is used to determine the scheduling relationship between different physical servers. The target virtual resource view is determined by the tag information, and the target virtual resource view is used to display the virtual resource management relationship in the target application scenario. Finally, after the target cloud server instance is determined, the target cloud server instance is displayed in a graphical user interface to provide user feedback. This achieves the goal of rationally allocating cloud server instances based on tag information. By virtualizing physical resources into multiple virtual resource views to meet different object resource requirements, instance contention is avoided, thereby achieving the technical effect of avoiding resource waste and improving service stability and response speed. This further solves the technical problem in related technologies where instances compete for virtual resources, resulting in resource waste and reduced service stability and response speed. 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. Embodiment 4 According to an embodiment of the present disclosure, a device embodiment for implementing the above-mentioned resource allocation method is also provided.FIG9 is a schematic diagram of the structure of a resource allocation device according to Embodiment 4 of the present disclosure. As shown in FIG9 , the device includes: a first acquisition module 901 configured to acquire tag information, wherein the tag information is used to characterize user behavior attributes; a determination module 902 configured to determine a target virtual resource view associated with the tag information, wherein the target virtual resource view is used to display virtual resource management relationships in a target application scenario; a selection module 903 configured to select a target physical server corresponding to the tag information based on a preset scheduling policy and the target virtual resource view, wherein the preset scheduling policy is used to determine scheduling relationships between different physical servers; and an allocation module 904 configured to use the target physical server to allocate a target cloud server instance corresponding to the tag information. Optionally, the first acquisition module 901 is further configured to: display an inventory view in the target application scenario, wherein the inventory view is used to display the remaining inventory of resources to be traded, and the inventory view includes at least one of a basic inventory view and an inventory view provided by the virtual resource; and, in response to a trigger operation based on the inventory view, obtain tag information from a profile parameter carried in a cloud server instance purchase request. Optionally, the system further includes a processing module configured to: perform resource abstraction on a physical resource to be processed to obtain multiple virtual resources, wherein the physical resource to be processed is a physical resource provided by at least one physical server; obtain multiple virtual resource views based on the multiple virtual resources, wherein the multiple virtual resource views are used to respectively display virtual resource management relationships in different application scenarios, wherein the different application scenarios correspond to different resource requirements; and establish associations between different tag information and the multiple virtual resource views, wherein the tag information is associated with a target virtual resource view. Optionally, the determination module 902 is further configured to: determine a target virtual resource view corresponding to the tag information based on the pre-established associations. Optionally, the selection module 903 is further configured to: obtain a candidate physical server corresponding to the tag information using the target virtual resource view; and select the target physical server corresponding to the tag information from the candidate physical servers based on a preset scheduling policy. Optionally, the selection module 903 is further configured to: determine a resource production source using the target virtual resource view; and load the candidate physical server based on the resource production source. Optionally, it further includes: a division module, which is configured to: divide the physical resources to be processed into multiple resource pools based on different resource production sources of the physical resources to be processed, wherein the multiple resource pools correspond to different application scenarios, and different application scenarios correspond to different resource requirements.Optionally, the selection module 903 is further configured to: determine a target resource pool corresponding to a resource production source from multiple resource pools; and load a candidate physical server based on the target resource pool. Optionally, the available resource range corresponding to the target virtual resource view is equal to the available resource range corresponding to the inventory view in the target application scenario. The target virtual resource view is visible to a first user and invisible to a second user. The first user is the user corresponding to the tag information, and the second user is the user corresponding to the remaining tag information except the tag information. According to the disclosed embodiments, tag information describing the behavior attributes of a target object is obtained. Based on the target object's behavior, a target virtual resource view to be displayed to the target object is determined. Then, based on a preset scheduling policy and the target virtual view representing the virtual resource management relationship in the target application scenario, a target physical server corresponding to the tag information is selected. In other words, a target physical machine that meets the needs of the target object and can provide better services for these needs is selected. Finally, based on the selected target physical server, a target cloud server instance corresponding to the behavior of the target object, i.e., a corresponding cloud server product, is assigned. This achieves the goal of rationally allocating cloud server instances based on tag information. By virtualizing physical resources into multiple virtual resource views to meet the resource requirements of different objects, instance contention is avoided, thereby achieving the technical effect of avoiding resource waste and improving service stability and responsiveness. This further addresses the technical problem in related technologies where instances compete for virtual resources, resulting in resource waste and reduced service stability and responsiveness. It should be noted that the first acquisition module 901, determination module 902, selection module 903, and allocation module 904 described above correspond to steps S21 to S24 in Example 1. The examples and application scenarios implemented by these four 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 allocation method is also provided.Figure 10 is a structural diagram of another resource allocation device according to Example 4 of the present disclosure. As shown in Figure 10, the device includes: a second acquisition module 1001, configured to obtain a cloud server instance purchase request through a first application programming interface, wherein the request data carried in the cloud server instance purchase request includes: tag information, and the tag information is used to characterize user behavior attributes; a first return module 1002, configured to return a cloud server instance purchase response through a second application programming interface, wherein the response data carried in the cloud server instance purchase response includes: a target cloud server instance, and the target cloud server instance is obtained by assigning the tag information using the target physical server, and the target physical server is selected based on a preset scheduling policy and a target virtual resource view, and the preset scheduling policy is used to determine the scheduling relationship between different physical servers, and the target virtual resource view is determined by the tag information, and the target virtual resource view is used to display the virtual resource management relationship in the target application scenario. In an embodiment of the present disclosure, a cloud server instance purchase request is obtained through a first application programming interface (API). The request data carried in the cloud server instance purchase request includes tag information, which is used to characterize the behavioral attributes of the target object. A cloud server instance purchase response is then returned through a second application programming interface (API). The response data carried in the cloud server instance purchase response includes a target cloud server instance, which is assigned using the tag information of the target physical server. The target physical server is selected based on a preset scheduling policy and a target virtual resource view. The preset scheduling policy is used to determine the scheduling relationship between different physical servers. The target virtual resource view is determined by the tag information and is used to display the virtual resource management relationship in the target application scenario. This achieves the goal of rationally allocating cloud server instances based on tag information. By virtualizing physical resources into multiple virtual resource views to meet the resource requirements of different objects, instance contention is avoided, thereby achieving the technical effect of avoiding resource waste and improving service stability and response speed. This further solves the technical problem in related technologies where instances compete for virtual resources, resulting in resource waste and reduced service stability and response speed. It should be noted that the second acquisition module 1001 and the first return module 1002 correspond to step S71 and step S72 in Example 2. The examples and application scenarios implemented by the two modules and the corresponding steps are the same, but are not limited to the contents 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 a device and run in the computer terminal 10 provided in Example 1. According to an embodiment of the present disclosure, another embodiment of a device for implementing the above resource allocation method is also provided. 11 is a schematic structural diagram of another resource allocation device according to Embodiment 4 of the present disclosure. As shown in FIG11 , the device includes: a third acquisition module 1101, configured to acquire a currently input cloud server instance purchase dialogue request, wherein the portrait parameters carried in the cloud server instance purchase dialogue request include: tag information, which is used to characterize user behavior attributes; a second return module 1102, configured to respond to the cloud server instance purchase dialogue request and return a cloud server instance purchase dialogue reply, wherein the information carried in the cloud server instance purchase dialogue reply includes: a target cloud server instance, wherein the target cloud server instance is obtained by assigning the tag information using the target physical server, and the target physical server is selected based on a preset scheduling policy and a target virtual resource view, wherein the preset scheduling policy is used to determine the scheduling relationship between different physical servers, and the target virtual resource view is determined by the tag information, and the target virtual resource view is used to display the virtual resource management relationship in the target application scenario; and a display module 1103, configured to display the target cloud server instance in a graphical user interface. According to an embodiment of the present disclosure, a currently input cloud server instance purchase dialog request is obtained, wherein the profile parameters carried in the cloud server instance purchase dialog request include tag information, which is used to characterize user behavior attributes. Then, in response to the cloud server instance purchase dialog request, a cloud server instance purchase dialog reply is returned, wherein the cloud server instance purchase dialog reply includes a target cloud server instance, which is assigned using the target physical server tag information. The target physical server is selected based on a preset scheduling policy and a target virtual resource view. The preset scheduling policy is used to determine the scheduling relationship between different physical servers. The target virtual resource view is determined by the tag information and is used to display the virtual resource management relationship in the target application scenario.After the target cloud server instance is finally determined, it is displayed within the graphical user interface to provide user feedback. This achieves the goal of rationally allocating cloud server instances based on tag information. By virtualizing physical resources into multiple virtual resource views to meet different object resource requirements, instance contention is avoided, thereby achieving the technical effect of avoiding resource waste and improving service stability and responsiveness. This further addresses the technical problem in related technologies where instances compete for virtual resources, resulting in resource waste and reduced service stability and responsiveness. It should be noted that the third acquisition module 1101, second return module 1102, and display module 1103 described above correspond to steps S51 to S83 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-mentioned 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-mentioned modules may also be part of a device and run in the computer terminal 10 provided in Example 1. It should be noted that the preferred implementation schemes involved in the above-mentioned embodiments of the present disclosure are the same as the solution provided in Example 1, as well as the application scenarios and implementation processes, but are not limited to the solution provided in Example 1. Example 5 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-mentioned computer terminal may be replaced by a terminal device such as a mobile terminal. Optionally, in this embodiment, the above-mentioned computer terminal may be located in at least one of multiple network devices in a computer network. In this embodiment, the computer terminal can execute program code for the following steps in the resource allocation method: obtaining tag information, where the tag information is used to characterize the behavioral attributes of the target object; determining a target virtual resource view associated with the tag information, where the target virtual resource view is used to display the virtual resource management relationship in the target application scenario; selecting a target physical server corresponding to the tag information based on a preset scheduling policy and the target virtual resource view, where the preset scheduling policy is used to determine the scheduling relationship between different physical servers; and using the target physical server to assign a target cloud server instance corresponding to the tag information. Optionally, Figure 12 is a block diagram of the structure of a computer terminal according to an embodiment of the present disclosure.As shown in FIG12 , the computer terminal 12 may include one or more processors 1202 (only one is shown), a memory 1204, a storage controller, and a peripheral interface. The peripheral interface is connected to a radio frequency module, an audio module, and a display. The memory may be used to store software programs and modules, such as program instructions / modules corresponding to the resource allocation 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 allocation method described above. The memory may 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 may further include memory located remotely from the processor, which may be connected to the computer terminal 12 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 access information and applications stored in the memory through a transmission device to perform the following steps: obtaining tag information, wherein the tag information is used to characterize the behavioral attributes of a target object; determining a target virtual resource view associated with the tag information, wherein the target virtual resource view is used to display virtual resource management relationships in a target application scenario; selecting a target physical server corresponding to the tag information based on a preset scheduling policy and the target virtual resource view, wherein the preset scheduling policy is used to determine scheduling relationships between different physical servers; and using the target physical server to assign a target cloud server instance corresponding to the tag information. Optionally, the processor can also execute program code for the following steps: displaying an inventory view in the target application scenario, wherein the inventory view is used to display the remaining inventory of resources to be traded, and the inventory view includes at least one of a basic inventory view and an inventory view provided by the virtual resource; and, in response to a trigger operation based on the inventory view, obtaining tag information from a profile parameter carried in a cloud server instance purchase request. Optionally, the processor may further execute program code for the following steps: performing resource abstraction on the physical resources to be processed to obtain multiple virtual resources, wherein the physical resources to be processed are physical resources provided by at least one physical server; obtaining multiple virtual resource views based on the multiple virtual resources, wherein the multiple virtual resource views are used to respectively display virtual resource management relationships under different application scenarios, and different application scenarios correspond to different resource requirements; establishing association relationships between different tag information and the multiple virtual resource views, wherein there is an association between the tag information and the target virtual resource view.Optionally, the processor may further execute program code for the following steps: determining a target virtual resource view corresponding to the tag information based on a pre-established association relationship. Optionally, the processor may further execute program code for the following steps: obtaining a candidate physical server corresponding to the tag information using the target virtual resource view; and selecting a target physical server corresponding to the tag information from the candidate physical servers based on a preset scheduling policy. Optionally, the processor may further execute program code for the following steps: determining a resource production source using the target virtual resource view; and loading candidate physical servers based on the resource production source. Optionally, the processor may further execute program code for the following steps: dividing the physical resources to be processed into multiple resource pools based on their different resource production sources, wherein the multiple resource pools correspond to different application scenarios, and the different application scenarios correspond to different resource requirements. Optionally, the processor may further execute program code for the following steps: determining a target resource pool corresponding to the resource production source from the multiple resource pools; and loading candidate physical servers based on the target resource pool. Optionally, the available resource range corresponding to the target virtual resource view is equal to the available resource range corresponding to the inventory view in the target application scenario, wherein the target virtual resource view is visible to the first target object, and the target virtual resource view is invisible to the second target object, the first target object is the target object corresponding to the tag information, and the second target object is the target object corresponding to the remaining tag information except the tag information. According to the disclosed embodiments, tag information describing the behavior attributes of a target object is obtained. Based on the target object's behavior, a target virtual resource view to be displayed to the target object is determined. Then, based on a preset scheduling policy and the target virtual view representing the virtual resource management relationship in the target application scenario, a target physical server corresponding to the tag information is selected. In other words, a target physical machine that meets the needs of the target object and can provide better services for these needs is selected. Finally, based on the selected target physical server, a target cloud server instance corresponding to the behavior of the target object, i.e., a corresponding cloud server product, is assigned. This achieves the goal of rationally allocating cloud server instances based on tag information. By virtualizing physical resources into multiple virtual resource views to meet the resource requirements of different objects, instance contention is avoided, thereby achieving the technical effect of avoiding resource waste and improving service stability and responsiveness. This further addresses the technical problem in related technologies where instances compete for virtual resources, resulting in resource waste and reduced service stability and responsiveness.Those skilled in the art will appreciate that the structure shown in FIG12 is merely illustrative, and the computer terminal 12 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. FIG12 does not limit the structure of the aforementioned electronic devices. For example, the computer terminal 12 may include more or fewer components (such as a network interface, a display device, etc.) than those shown in FIG12 , or may have a configuration different from that shown in FIG12 . 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 can 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 6 The embodiments of the present disclosure also provide a computer-readable storage medium. Optionally, in this embodiment, the computer-readable storage medium may be used to store the program code executed by the resource allocation method provided in Example 1 above. 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 tag information, wherein the tag information is used to characterize the behavioral attributes of a target object; determining a target virtual resource view associated with the tag information, wherein the target virtual resource view is used to display virtual resource management relationships in a target application scenario; selecting a target physical server corresponding to the tag information based on a preset scheduling policy and the target virtual resource view, wherein the preset scheduling policy is used to determine scheduling relationships between different physical servers; and assigning a target cloud server instance corresponding to the tag information using the target physical server. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: displaying an inventory view in a target application scenario, wherein the inventory view is used to display the remaining inventory of resources to be traded, and the inventory view includes at least one of a basic inventory view and an inventory view provided by a virtual resource; and in response to a triggering operation based on the inventory view, obtaining tag information from a portrait parameter carried in a cloud server instance purchase request.Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: obtaining multiple virtual resources based on a physical resource to be processed, wherein the physical resource to be processed is a physical resource provided by at least one physical server; displaying information about the multiple virtual resources to obtain multiple virtual resource views, wherein the multiple virtual resource views are used to respectively display virtual resource management relationships in different application scenarios, wherein the different application scenarios correspond to different resource requirements; and establishing associations between different tag information and the multiple virtual resource views, wherein the tag information is associated with a target virtual resource view. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: determining a target virtual resource view corresponding to the tag information based on a pre-established association. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: obtaining candidate physical servers corresponding to the tag information using the target virtual resource view; and selecting a target physical server corresponding to the tag information from the candidate physical servers based on a preset scheduling policy. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: determining a resource production source using a target virtual resource view; and loading candidate physical servers based on the resource production source. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: dividing the physical resources to be processed into multiple resource pools based on their different resource production sources, wherein the multiple resource pools correspond to different application scenarios, and the different application scenarios correspond to different resource requirements. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: determining a target resource pool corresponding to the resource production source from the multiple resource pools; and loading candidate physical servers based on the target resource pool. Optionally, the available resource range corresponding to the target virtual resource view is equal to the available resource range corresponding to the inventory view in the target application scenario. The target virtual resource view is visible to a first target object and invisible to a second target object. The first target object is the target object corresponding to the tag information, and the second target object is the target object corresponding to the remaining tag information except the tag information. 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-mentioned embodiments of the present disclosure, the descriptions of each embodiment are given with emphasis. For portions not described in detail in one embodiment, reference can be made to the relevant descriptions of other embodiments.In the several embodiments provided in this disclosure, it should be understood that the disclosed technical content 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 forms. 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 this 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. The aforementioned integrated units can be implemented in either hardware or software functional units. If implemented as software functional units and sold or used as standalone products, the integrated units 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 enabling 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 media include 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 be considered within the scope of protection of the present disclosure.

Claims

Claims 1. A resource allocation method, comprising: Obtain tag information, wherein the tag information is used to characterize the behavioral attributes of the target object; determine a target virtual resource view associated with the tag information, wherein the target virtual resource view is used to display the virtual resource management relationship under the target application scenario; based on a preset scheduling policy and the target virtual resource view, select a target physical server corresponding to the tag information, wherein the preset scheduling policy is used to determine the scheduling relationship between different physical servers; use the target physical server to assign a corresponding target cloud server instance to the tag information.

2. The resource allocation method according to claim 1, wherein: Obtaining the tag information includes: displaying an inventory view in the target application scenario, wherein the inventory view is used to display the remaining inventory of resources to be traded, and the inventory view includes at least one of a basic inventory view and an inventory view provided by virtual resources; and in response to a trigger operation based on the inventory view, obtaining the tag information from a portrait parameter carried in the cloud server instance purchase request.

3. The resource allocation method according to claim 1, wherein: The resource allocation method further includes: performing resource abstraction on the physical resources to be processed to obtain multiple virtual resources, wherein the physical resources to be processed are physical resources provided by at least one physical server; obtaining multiple virtual resource views based on the multiple virtual resources, wherein the multiple virtual resource views are used to respectively display virtual resource management relationships under different application scenarios, and different application scenarios correspond to different resource requirements; and establishing association relationships between different tag information and the multiple virtual resource views, wherein there is an association between the tag information and the target virtual resource view.

4. The resource allocation method according to claim 3, wherein: Determining the target virtual resource view associated with the tag information includes: determining the target virtual resource view corresponding to the tag information based on the pre-established association relationship.

5. The resource allocation method according to claim 1, wherein: Based on the preset scheduling policy and the target virtual resource view, selecting the target physical server corresponding to the tag information includes: 27 The target virtual resource view is used to obtain candidate physical servers corresponding to the tag information; and the target physical server corresponding to the tag information is selected from the candidate physical servers based on the preset scheduling policy.

6. The resource allocation method according to claim 5, wherein: Acquiring the candidate physical server corresponding to the tag information by using the target virtual resource view includes: determining a resource production source by using the target virtual resource view; and loading the candidate physical server based on the resource production source.

7. The resource allocation method according to claim 6, wherein: The resource allocation method further includes: dividing the physical resources to be processed into multiple resource pools based on different resource production sources of the physical resources to be processed, wherein the multiple resource pools correspond to different application scenarios, and different application scenarios correspond to different resource requirements.

8. The resource allocation method according to claim 7, wherein: Loading the candidate physical server based on the resource production source includes: determining a target resource pool corresponding to the resource production source from the multiple resource pools; and loading the candidate physical server based on the target resource pool.

9. The resource allocation method according to claim 7, wherein: The available resource range corresponding to the target virtual resource view is equal to the available resource range corresponding to the inventory view in the target application scenario, wherein the target virtual resource view is visible to a first target object and invisible to a second target object, the first target object being the target object corresponding to the tag information, and the second target object being the target object corresponding to the remaining tag information except the tag information.

10. A resource allocation method, comprising: A cloud server instance purchase request is obtained through a first application programming interface, wherein request data carried in the cloud server instance purchase request includes: tag information, wherein the tag information is used to characterize the behavior attributes of the target object; a cloud server instance purchase response is returned through a second application programming interface, wherein response data carried in the cloud server instance purchase response includes: a target cloud server instance, wherein the target cloud server instance is obtained by allocating the tag information using a target physical server, wherein the target physical server is selected based on a preset scheduling policy and a target virtual resource view, wherein the preset scheduling policy is used to determine the scheduling relationship between different physical servers, wherein the target virtual resource view is determined by the tag information, and wherein the target virtual resource view is used to display Virtual resource management relationships in the target application scenario.

11. A resource allocation method, comprising: Obtain a currently input cloud server instance purchase dialogue request, wherein the portrait parameters carried in the cloud server instance purchase dialogue request include: tag information, wherein the tag information is used to characterize the behavioral attributes of the target object; in response to the cloud server instance purchase dialogue request, return a cloud server instance purchase dialogue reply, wherein the information carried in the cloud server instance purchase dialogue reply includes: a target cloud server instance, wherein the target cloud server instance is obtained by allocating the tag information using a target physical server, wherein the target physical server is selected based on a preset scheduling policy and a target virtual resource view, wherein the preset scheduling policy is used to determine the scheduling relationship between different physical servers, wherein the target virtual resource view is determined by the tag information, and wherein the target virtual resource view is used to display the virtual resource management relationship under the target application scenario; and display the target cloud server instance in a graphical user interface.

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

13. 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 allocation method according to any one of claims 1 to 11.

Images