Server resource configuration method and device, equipment, medium and program product

Abstract

The invention provides a server resource configuration method which can be applied to the technical field of cloud computing. The method comprises the following steps: acquiring a server load caused by a transaction request, wherein the transaction request comprises a conventional transaction request and an operation transaction request; in response to the condition that the server load meets a first preset condition, expanding the capacity of the standby cluster to a first scale, distributing the conventional transaction request to the common cluster, and distributing the operation transaction request to the standby cluster, the server resource quantity of the common cluster being the first scale, and the standby cluster being preset independent of the common cluster; or, in response to the fact that the server load meets a second preset condition, the standby cluster is expanded to a second scale, and the transaction request is distributed to the common cluster and the standby cluster based on a preset proportion, the second scale is smaller than or equal to the first scale, and the second scale is a positive number larger than the first scale. The invention further provides a server resource configuration device and equipment, a storage medium and a program product.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cloud computing, and more particularly to a server resource configuration method, device, equipment, medium and program product. BACKGROUND

[0002] With the rapid development of financial technology, financial institutions often carry out various operation activities, resulting in a continuous increase in the frequency of operation-related transactions of related application programs, and a significant increase in user access and transaction size.

[0003] Operation transactions and regular transactions differ significantly in traffic characteristics. Operation transactions have the characteristic of short-time traffic surge, that is, the transaction request volume sharply rises in a short time at the moment of the start of the operation activity. The transaction traffic of regular transactions is relatively stable, and is directly related to the user basic service experience and business normal operation.

[0004] At present, the background servers of application programs generally adopt a hybrid deployment architecture, that is, operation transactions and regular transactions share the same set of server resources. In order to cope with the possible traffic surge of operation transactions, the existing technology usually adopts server elasticity scaling, transaction flow limiting and fusing and other schemes for traffic bearing and control. However, when operation transactions have a sudden traffic surge, especially when the traffic surge triggers a system abnormal branch error, it will directly cause abnormal fluctuations in the core resources (such as central processor usage and memory usage) of the server where the operation transactions are located. Since operation transactions and regular transactions share server resources, such abnormalities will quickly spread to the regular transaction processing link, causing server resource contention, and thus causing the application program to face a major risk of global systematic and overall failure, seriously affecting the service availability and user experience of the application program, and being unable to effectively guarantee the parallel stable processing of operation transactions and regular transactions. SUMMARY

[0005] In view of the above problems, the present application provides a server resource configuration method, device, equipment, medium and program product capable of guaranteeing the parallel stable processing of operation transactions and regular transactions.

[0006] According to a first aspect of the present application, a server resource configuration method is provided, comprising: obtaining a server load caused by a transaction request, the transaction request including a regular transaction request and an operation transaction request; in response to the server load satisfying a first preset condition, expanding a standby cluster to a first scale, and distributing the regular transaction request to a commonly used cluster and the operation transaction request to the standby cluster, wherein the server resource amount of the commonly used cluster is the first scale, and the standby cluster is a cluster set in advance independently of the commonly used cluster; or, in response to the server load satisfying a second preset condition, expanding the standby cluster to a second scale, and distributing the regular transaction request to the commonly used cluster and the operation transaction request to the standby cluster based on a preset ratio : Transaction requests are distributed to the primary cluster and the backup cluster, where the second cluster is smaller than or equal to the first cluster. , All are positive numbers and > The first preset condition is the load triggering condition of abnormal server load in the commonly used cluster, and the second preset condition is the load triggering condition of resource shortage on the server of the commonly used cluster.

[0007] According to an embodiment of this application, pre-setting a backup cluster includes: obtaining a preset ratio based on historical peak load data of operational transaction requests, expected business scale, and cloud cluster resource pool capacity; and dividing the cloud cluster resource pool into a common cluster and a backup cluster based on the preset ratio, at which point the server resource quantity of the backup cluster is the initial scale.

[0008] According to an embodiment of this application, after expanding the backup cluster, the method further includes: in response to the server load meeting a third preset condition, shrinking the backup cluster to its initial size, where the third preset condition is the normal load triggering condition of the server in the commonly used cluster; and allocating transaction requests to the commonly used cluster and the backup cluster based on a preset ratio.

[0009] According to an embodiment of this application, expanding the standby cluster includes: creating compute instances and storage volumes for operational transaction requests, and mounting storage volumes to the compute instances; configuring corresponding application nodes for the compute instances, and adding the application nodes to the standby cluster; and performing network configuration and security verification on the application nodes.

[0010] According to an embodiment of this application, scaling down a standby cluster includes: modifying the load balancing strategy of operational transaction requests so that the target computing instance of the operational transaction request stops receiving operational transaction requests, wherein the target computing instance is the computing instance with the latest creation time corresponding to the operational transaction request; deleting the application node on the target computing instance from the standby cluster; configuring the network to disconnect the target computing instance from the business network and performing data backup; unloading the storage volume for the target computing instance and reclaiming the corresponding server resources.

[0011] According to an embodiment of this application, setting the first preset condition includes: within a first preset time window, the CPU load is greater than a first threshold; and / or, within the first preset time window, the memory load is greater than a second threshold; and / or, within the first preset time window, the transaction processing load is greater than a third threshold.

[0012] According to an embodiment of this application, setting the second preset condition includes: within a second preset time window, the central processing unit load is greater than a fourth threshold; and / or, within a second preset time window, the memory load is greater than a fifth threshold; and / or, within a second preset time window, the transaction processing load is greater than a sixth threshold; wherein, the second preset time window is greater than the first preset time window, the fourth threshold is less than the first threshold, the fifth threshold is less than the second threshold, and the sixth threshold is less than the third threshold.

[0013] A second aspect of this application provides a server resource configuration apparatus, comprising: an acquisition module for acquiring server load triggered by transaction requests, the transaction requests including regular transaction requests and operational transaction requests; a first response module for, in response to a server load meeting a first preset condition, expanding a backup cluster to a first scale and allocating regular transaction requests to a primary cluster and operational transaction requests to the backup cluster, wherein the server resource volume of the primary cluster is the first scale, and the backup cluster is pre-configured independently of the primary cluster; or, a second response module for, in response to a server load meeting a second preset condition, expanding the backup cluster to a second scale and, based on a preset ratio... : Transaction requests are distributed to the primary cluster and the backup cluster, where the second cluster is smaller than or equal to the first cluster. , All are positive numbers and > The first preset condition is the load triggering condition of abnormal server load in the commonly used cluster, and the second preset condition is the load triggering condition of resource shortage on the server of the commonly used cluster.

[0014] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0015] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0016] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0017] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0018] Figure 1 The illustrations depict application scenarios of server resource configuration methods, apparatuses, devices, media, and program products according to embodiments of this application.

[0019] Figure 2 A flowchart illustrating a server resource configuration method according to an embodiment of this application is shown schematically.

[0020] Figure 3 This illustration schematically shows a pre-configured backup cluster according to an embodiment of the present application;

[0021] Figure 4 This illustration schematically shows a flowchart of scaling up a backup cluster according to an embodiment of this application;

[0022] Figure 5 This schematically illustrates a flowchart of the expansion of the standby cluster according to an embodiment of this application;

[0023] Figure 6 This illustration schematically shows a flowchart of scaling down a backup cluster according to an embodiment of this application;

[0024] Figure 7 This schematically illustrates a structural block diagram of a server resource configuration apparatus according to an embodiment of the present application; and

[0025] Figure 8 A block diagram schematically illustrates an electronic device suitable for implementing a server resource configuration method according to an embodiment of this application. Detailed Implementation

[0026] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0027] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0028] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0029] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0030] Embodiments of this application provide a server resource allocation method, comprising: acquiring server load triggered by transaction requests, the transaction requests including regular transaction requests and operational transaction requests; in response to the server load meeting a first preset condition, expanding a standby cluster to a first scale, and allocating regular transaction requests to a primary cluster and operational transaction requests to the standby cluster, wherein the server resource volume of the primary cluster is the first scale, and the standby cluster is pre-configured independently of the primary cluster; or, in response to the server load meeting a second preset condition, expanding the standby cluster to a second scale, and based on a preset ratio... : Transaction requests are distributed to the primary cluster and the backup cluster, where the second cluster is smaller than or equal to the first cluster. , All are positive numbers and > The first preset condition is the load triggering condition of abnormal server load in the commonly used cluster, and the second preset condition is the load triggering condition of resource shortage on the server of the commonly used cluster.

[0031] According to the embodiments of this application, by dynamically adjusting the size of the backup cluster and the request allocation strategy based on the server load caused by transaction requests and according to two types of preset conditions, fault isolation and business diversion can be achieved when the main cluster is abnormal, avoiding the spread of faults that could paralyze both transaction types. When the main cluster is under resource pressure, precise load distribution and resource consumption control can be achieved. By sharing some of the operational transaction pressure through the backup cluster, it can ensure that the server can respond normally to regular transaction requests and operational transaction requests. In addition, the entire configuration process is based on dynamic load triggering and requires no manual intervention. It can ensure that the resource size and request handling range of the backup cluster are accurately matched with the load status of the main cluster, ensuring that regular transactions and operational transactions can be stably handled under different load scenarios, while also achieving efficient utilization of server resources, avoiding resource idleness or overload, and ultimately improving the fault tolerance and elastic adaptability of the overall architecture.

[0032] Figure 1 The diagram illustrates an application scenario of the server resource configuration method according to an embodiment of this application.

[0033] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0034] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0035] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0036] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0037] It should be noted that the server resource configuration method provided in this application embodiment can generally be executed by server 105. Correspondingly, the server resource configuration device provided in this application embodiment can generally be located in server 105. The server resource configuration method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the server resource configuration device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0038] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0039] The following will be based on Figure 1 The described scene, through Figures 2-6 The server resource configuration method according to the embodiments of this application will be described in detail.

[0040] Figure 2 A flowchart illustrating a server resource configuration method according to an embodiment of this application is shown.

[0041] like Figure 2 As shown, the server resource configuration method in this embodiment includes operations S210 to S230.

[0042] When operating S210, the server load caused by transaction requests is obtained, including regular transaction requests and operational transaction requests.

[0043] According to embodiments of this application, routine transaction requests refer to core transaction requests initiated by users to meet daily business needs, characterized by high frequency, high stability, and high priority. Examples include user account balance inquiries, fund transfers, order payments (non-promotional scenarios), utility bill payments, and credit card repayments. These requests are directly related to users' core rights and the basic operation of the business, placing extremely high demands on server response stability and data consistency. Furthermore, the daily request volume is stable, making them the core carriers of commonly used clusters.

[0044] According to embodiments of this application, operational transaction requests refer to non-core transaction requests initiated to support enterprise marketing activities, characterized by temporariness, high volatility, and low priority. Examples include coupon redemption, limited-time flash sales, exclusive event redemption, and points-based lotteries. These requests are strongly tied to specific operational activities, meaning that concurrency surges at the start of the activity and drops sharply after it ends, with peak fluctuations reaching 10-100 times the daily average. This results in significant instantaneous consumption of server resources, but a higher tolerance for response latency compared to regular transactions.

[0045] According to embodiments of this application, the server load caused by transaction requests is obtained, including Central Processing Unit (CPU) load, memory load, and transaction processing load. CPU load is the computational pressure borne by the server CPU when processing transaction requests. In this embodiment, it can be quantified by CPU utilization, which directly depends on the concurrency and computational complexity of transactions, and is a core hardware indicator for judging whether server resources are strained. Memory load is the storage pressure borne by the server memory when caching transaction-related data. In this embodiment, it can be quantified by memory utilization. The high-frequency data caching requirements of regular transactions and the instantaneous data burst requirements of operational transactions both increase memory load. If the memory load is too high, data reading will shift from memory to disk, significantly extending transaction response time. Transaction processing load refers to the processing pressure and health status of the server at the business level when accepting transaction requests. In this embodiment, it can be evaluated by the transaction failure rate, which directly reflects the efficiency and correctness of transaction processing and is a core business indicator for judging whether the server has experienced substantial abnormalities.

[0046] In operation S220, in response to the server load meeting the first preset condition, the standby cluster is expanded to the first size, and regular transaction requests are allocated to the common cluster, while operational transaction requests are allocated to the standby cluster.

[0047] According to the embodiments of this application, the primary cluster is a core computing resource cluster built to support users' daily core business and operating stably for a long time. It handles regular transaction requests and has fixed and sufficient hardware resources. Resource configuration is based on meeting peak loads from regular transactions and reserving 20%-30% redundancy. It is not easily expanded or reduced in size to ensure long-term operational stability. In this embodiment, the server resources of the primary cluster are at the first scale. The backup cluster is a supplementary computing resource cluster with elastic scaling capabilities built to cope with anomalies in the primary cluster or to handle temporary high-fluctuation business. It handles operational transaction requests, and its resource configuration is elastic. Reclaimed resources can be returned to the cloud cluster resource pool for subsequent reuse. Before expanding the backup cluster, the server resources of the backup cluster are less than those of the primary cluster.

[0048] According to the embodiments of this application, the first preset condition is the abnormal load triggering condition of the server of the commonly used cluster. That is, when the commonly used cluster causes a substantial failure of the core business due to the load exceeding the limit threshold, or the core hardware resources are in an extreme overload state, and this state continues to reach the first preset time window, the load judgment standard for triggering the intervention of the backup cluster is established.

[0049] According to embodiments of this application, setting a first preset condition includes: within a first preset time window, the CPU load exceeds a first threshold, and / or the memory load exceeds a second threshold, and / or the transaction processing load exceeds a third threshold. The first preset time window, the first threshold, the second threshold, and the third threshold can be set according to actual needs. For example, the first preset time window can be set to 5 minutes. Within 5 minutes, if the CPU utilization of the commonly used cluster consistently exceeds 90% (assuming the first threshold is set to 90%), and / or the memory utilization of the commonly used cluster consistently exceeds 95% (assuming the second threshold is set to 95%), and / or the transaction failure rate consistently exceeds 5% (assuming the third threshold is set to 5%), the first preset condition is triggered, requiring the operational transaction requests to be switched to the backup cluster. By setting the first preset condition, the actual abnormal scenarios of the server cluster can be comprehensively captured, different abnormal types can be flexibly adapted, the risk of missing a single indicator can be prevented, and subsequent emergency measures can be accurately triggered when a substantial failure occurs in the commonly used cluster, providing a reliable preliminary judgment basis for fault isolation and uninterrupted business operations.

[0050] According to an embodiment of this application, when the server load meets a first preset condition, a computing instance is created for operational transaction requests to expand the backup cluster to the same server resource volume as the primary cluster, i.e., a first scale. After expansion, the application status of the computing instance is detected through a service probe, and it is confirmed that the backup cluster has reached the first scale and has the capacity to handle the load. Next, by adjusting the routing rules of the load balancer, the isolation and allocation of regular transaction requests and operational transaction requests are achieved. For regular transaction requests, the routing direction remains unchanged; for operational transaction requests, their routes are switched entirely to the backup cluster. After the switch, all operational transaction traffic flows to the backup cluster. Through this step, it is ensured that the backup cluster can handle the operational transaction pressure, achieving independent flow of the two types of transaction traffic, completely isolating the operational transaction traffic from the primary cluster. In scenarios where the primary cluster may experience anomalies, it ensures both the stable operation of regular transactions and the full and stable handling of operational transactions by the backup cluster.

[0051] In operation S230, in response to the server load meeting the second preset condition, the standby cluster is expanded to the second size, and based on a preset ratio. : Distribute transaction requests to the primary cluster and the backup cluster. , All are positive numbers and > .

[0052] According to the embodiments of this application, the second preset condition is a load triggering condition of server resource shortage in the commonly used cluster. In other words, this condition is a judgment criterion used to identify resource pressure in advance and trigger the elastic supplementation of the backup cluster when the commonly used cluster has not experienced any substantial business failure, but the core hardware resources (CPU, memory) are already running at a high level, or the transaction processing load shows a continuous growth trend and is about to approach the resource carrying capacity limit.

[0053] According to embodiments of this application, setting the second preset condition includes: within a second preset time window, the CPU load is greater than a fourth threshold, and / or the memory load is greater than a fifth threshold, and / or the transaction processing load is greater than a sixth threshold. The second preset time window, the fourth threshold, the fifth threshold, and the sixth threshold can be set according to actual needs, and the second preset time window is longer than the first preset time window, the fourth threshold is less than the first threshold, the fifth threshold is less than the second threshold, and the sixth threshold is less than the third threshold. On the one hand, a longer second preset time window can filter instantaneous resource fluctuations, ensuring that resource shortages are only determined when resource levels remain high, avoiding accidental triggering of backup cluster expansion due to short-term fluctuations, and reducing resource waste; on the other hand, lower fourth, fifth, and sixth thresholds can provide early warnings before the commonly used cluster reaches extreme overload or business failures, achieving differentiated management, ensuring that regular transaction requests are always in a stable operating range, and avoiding excessive expansion of backup clusters or accidental activation of emergency measures, balancing business stability and resource utilization. For example, the second preset time window is set to 10 minutes. Within 10 minutes, if the CPU utilization of the frequently used cluster remains above 80% (assuming the fourth threshold is set to 80%), and / or the memory utilization of the frequently used cluster remains above 90% (assuming the fifth threshold is set to 90%), and / or the transaction failure rate remains above 2% (assuming the sixth threshold is set to 2%), the second preset condition is triggered. By setting the second preset condition, different types of resource stress scenarios can be comprehensively identified, ensuring that no scenario is missed. Ultimately, this provides a reliable basis for triggering appropriate expansion of the backup cluster and proportional allocation of transaction requests, alleviating the pressure on the frequently used cluster in advance without affecting the stability of regular transactions, and preventing resource stress from escalating into server failure.

[0054] According to an embodiment of this application, when the server load meets a second preset condition, a computing instance is created for the operational transaction request to expand the standby cluster to a second size, where the second size is less than or equal to the first size. After the expansion is completed, the application status of the computing instance is detected through a service probe, and it is confirmed that the standby cluster has reached the second size and has the capacity to handle the load. Then, the routing rules of the load balancer are adjusted based on a preset ratio. : Distribute transaction requests to the primary cluster and the backup cluster, so that A proportion of transaction requests flow to commonly used service clusters. A proportion of transaction requests are redirected to the backup cluster. , All are positive numbers and > During this process, the load balancer randomly distributes regular transaction requests and operational transaction requests to either the primary cluster or the backup cluster. The primary cluster handles more traffic, while the backup cluster handles less. By allocating traffic in a differentiated manner, some transaction pressure is transferred to the backup cluster, quickly alleviating the resource strain on the primary cluster while preventing the backup cluster from becoming idle, thus improving overall resource utilization.

[0055] Figure 3 A schematic diagram of a pre-configured backup cluster according to an embodiment of this application is shown.

[0056] like Figure 3 As shown, the pre-configured backup cluster includes operations S310 to S320.

[0057] When operating S310, a preset ratio is obtained based on the historical peak load data of operational transaction requests, the expected business scale, and the capacity of the cloud cluster resource pool.

[0058] First, extract historical peak load data of operational transaction requests over a period of time, excluding faulty or extreme anomaly data. Next, calculate the expected load requirement based on the anticipated business scale. For example, if the anticipated business scale is "user growth of 25% and activity intensity increase of 20%", set "expected growth coefficient = 1 + user growth percentage + activity intensity percentage" (calculating an expected growth coefficient of 1.45), and calculate the expected load requirement: Expected peak query rate per second (QPS) = historical peak QPS × expected growth coefficient, expected total resource requirement = expected peak QPS × unit load resource consumption ratio. Then, calculate the minimum resource requirements for commonly used clusters, including resources for stable operation of regular transactions and safety redundancy resources reserved to cope with fluctuations in regular transactions; calculate the total cloud cluster resources and the resource ratio of commonly used clusters. =Minimum resource requirements of commonly used clusters / Total resources of cloud clusters, with reserve cluster resource ratio =1- .

[0059] When operating S320, the cloud cluster resource pool is divided into a primary cluster and a backup cluster based on a preset ratio. At this time, the server resources of the backup cluster are at the initial size.

[0060] According to embodiments of this application, based on a preset ratio : The core resources of the cloud cluster resource pool, such as CPU and memory, are allocated to frequently used clusters and backup clusters. A proportion of the total cloud cluster resources are allocated to commonly used clusters, and their nodes are tagged with "biz_type=regular" and bound with regular transaction application deployment permissions; A proportion of the total cloud cluster resources is allocated to the standby cluster, which is the initial size of the standby cluster. Its nodes are tagged with "biz_type=operation" and only the deployment permissions for operational transaction applications are opened.

[0061] By leveraging multi-dimensional data to determine preset ratios, subjective ratio settings are avoided, ensuring that the ratios match actual traffic demand and resource supply. This prevents the initial size of the backup cluster from being too large, resulting in idle resources, or too small, making it unable to handle basic operational traffic. In addition, dividing the cloud cluster resource pool according to the ratio can reserve sufficient resources for the commonly used clusters to ensure the stable operation of regular transactions, while configuring initial resources for the backup clusters to enable them to handle basic operational transaction requests. This lays the resource foundation for the subsequent elastic expansion of the backup clusters, shortens emergency response time, and ensures the timeliness and stability of handling operational transaction traffic.

[0062] Figure 4 The flowchart illustrating the expansion of a standby cluster according to an embodiment of this application is shown schematically.

[0063] like Figure 4 As shown, expanding the standby cluster includes operations S410 to S440.

[0064] In S410, a compute instance and storage volume are created for an operational transaction request, and the storage volume is mounted on the compute instance.

[0065] According to an embodiment of this application, based on the resource consumption characteristics of operational transactions, matching computing and storage resources are called from the cloud cluster resource pool, including: determining the instance specifications based on the unit QPS resource consumption ratio of operational transactions; creating computing instances in batches through the cloud platform application programming interface; and assigning unique tags (such as "biz_type=operation, cluster=backup") to the instances for subsequent cluster identification and resource scheduling; matching one elastic block storage volume to each computing instance, selecting solid-state drive type to meet the high-frequency read and write requirements of operational transaction logs, and also tagging the storage volume with an "associated instance identifier" and setting the permission of "only allowing associated instances to mount" to prevent information leakage caused by cross-instance data access.

[0066] According to the embodiments of this application, the created storage volume is bound to the computing instance through the block storage mount interface of the cloud platform, ensuring that operational transaction data can be securely stored and retrieved. Specifically, the mount command is executed in the cloud platform console or through a script to mount the storage volume to a fixed directory of the computing instance, and the corresponding system configuration file is configured to automatically remount after the instance restarts, avoiding data loss due to the storage volume going offline; permissions are set for the mount directory, allowing only the user running the operational transaction application to read and write to the directory, and prohibiting other users from accessing it, ensuring the security of operational activity data.

[0067] When operating the S420, configure the corresponding application node for the compute instance and add the application node to the standby cluster.

[0068] According to embodiments of this application, an application adapted for operational transactions is deployed on a computing instance to ensure that the instance has the business capability to handle operational requests. Specifically, through containerized deployment or automated operation and maintenance tools, an application image dedicated to operational transactions (such as modules for coupon redemption and event registration) is installed on the computing instance. The image version is consistent with the operational applications in commonly used clusters to avoid interface compatibility issues caused by version differences. At the same time, parameters of the current operational activity (such as the upper limit of coupon inventory and the scope of users participating in the activity) are pulled through the configuration center to ensure that the application node can run according to the activity rules after startup. An adapted runtime environment and database connection pool are configured for the application node, and the database connection address is pointed to a temporary database dedicated to operational transactions to achieve data-level isolation.

[0069] According to embodiments of this application, a service registration and discovery mechanism is used to connect configured application nodes to the service scheduling network of the backup cluster, ensuring that the load balancer can identify and allocate traffic. Specifically, when an application node starts up, it automatically registers its node information with the service discovery component of the backup cluster, including the node's Internet Protocol address, application port, service name, and health check path. During registration, the node must be marked with "belonging to the backup cluster" to avoid confusion with commonly used cluster nodes. The node status is checked in the scheduling platform of the backup cluster to confirm that the node has been included in the "backup cluster node pool" and that the cluster's load scheduling policy has been updated, allowing operational transaction requests to be routed to the newly added node.

[0070] When operating the S430, network configuration and security verification are performed on the application nodes.

[0071] According to embodiments of this application, network isolation and security detection ensure that application nodes only receive legitimate operational traffic and do not affect the security of other clusters. Specifically, a private Internet Protocol (IP) address of a backup cluster subnet is allocated to the application node, and "ports required only for operational transactions" are opened through cloud platform security group rules. At the same time, nodes are prohibited from actively accessing the subnet of commonly used clusters and the address of regular transaction databases to prevent fault propagation or unauthorized data access. In addition, the DNS server of the node is configured to point to the dedicated DNS system of the operational business to ensure that the application node can normally resolve the domain names of dependent services such as temporary databases and configuration centers. The system of the application node is detected by scanning tools, the user permissions of the node are checked by permission auditing tools, and test operation requests are sent by traffic simulation tools to verify whether the node can normally return a 200 status code, no, or interface error, and finally confirm that the application node meets the security and availability conditions.

[0072] By adding compute instances and storage volumes adapted to operational transactions, configuring application nodes, and connecting them to the cluster, the total hardware resources and business processing capacity of the standby cluster can be directly increased. The expanded standby cluster can handle a higher proportion of operational transaction requests, significantly increasing the peak QPS capacity of operational transactions and avoiding request timeouts or failures due to operational traffic exceeding capacity. In addition, the expanded standby cluster can more efficiently share the operational transaction pressure of the frequently used cluster, reduce the crowding of resources of the frequently used cluster by operational traffic, ensure that the frequently used cluster always has sufficient resources to support the stable operation of regular transactions, and reduce the risk of the frequently used cluster triggering the first preset condition due to resource shortage.

[0073] Figure 5 The flowchart illustrating the expansion of the standby cluster according to an embodiment of this application is shown schematically.

[0074] like Figure 5 As shown, after expanding the backup cluster, it also includes operations S510 to S520.

[0075] When operating S510, in response to the server load meeting the third preset condition, the standby cluster is scaled down to the initial size. The third preset condition is the normal load trigger condition of the commonly used cluster's servers.

[0076] According to the embodiments of this application, the third preset condition is the normal load triggering condition of the commonly used cluster servers. When the operational transaction requests fall back from a high load state (such as peak scenarios like flash sales or major promotions) to a stable range of low concurrency and low resource consumption, and the commonly used cluster fully recovers to a safe load state after absorbing the fallen traffic, the third preset condition is triggered. When the server load meets the third preset condition, the standby cluster is scaled down to its initial size to release redundant cloud resources expanded during the high load period, reduce unnecessary resource cost consumption, and maintain the standby cluster's capacity to handle basic operational traffic and subsequent elastic response space while ensuring the continuous and stable operation of operational transactions.

[0077] When operating the S520, transaction requests are distributed to the primary cluster and the backup cluster based on a preset ratio.

[0078] According to embodiments of this application, by adjusting the routing rules of the load balancer based on a preset ratio... : Distribute transaction requests to the primary cluster and the backup cluster, so that A proportion of transaction requests flow to the commonly used cluster. A proportion of transaction requests are redirected to the backup cluster. , All are positive numbers and > During this process, the load balancer randomly distributes regular transaction requests and operational transaction requests to either the primary cluster or the backup cluster. The primary cluster handles more traffic, while the backup cluster handles less traffic.

[0079] When the third preset condition is met, the standby cluster is scaled down to its initial size. This releases redundant resources in the standby cluster when the resources of the primary cluster are sufficient, avoiding resource idleness and unnecessary cost consumption. At the same time, the initial number of nodes is retained to ensure that the standby cluster still has the basic operational transaction handling capacity, laying the foundation for rapid response to subsequent traffic fluctuations. In addition, the request allocation according to the preset ratio can precisely control the load boundary between the primary and standby clusters. This allows the primary cluster to take the lead in handling regular transactions and some operational transactions, avoiding excessive resource consumption by the standby cluster. It also allows the standby cluster to take on operational transactions proportionally to share the pressure on the primary cluster. This ensures stable operation of regular transactions and continuous handling of operational transactions, optimizes resource utilization and costs, and maintains system elasticity to ensure efficient adjustment in response to load changes.

[0080] Figure 6 The flowchart illustrating the scaling down of a standby cluster according to an embodiment of this application is shown schematically.

[0081] like Figure 6 As shown, scaling down the standby cluster includes operations S610 to S640.

[0082] In operation S610, modify the load balancing strategy for operational transaction requests so that the target compute instance of the operational transaction request stops receiving operational transaction requests.

[0083] According to an embodiment of this application, by adjusting the configuration of the load balancer associated with the standby cluster, the target computing instance is gradually made to stop receiving new requests. The target computing instance is the computing instance with the latest creation time corresponding to the operational transaction request, while ensuring that requests being processed are completed normally. Specifically, the target computing instance is selected from the backend server list of the load balancer based on the "creation time" tag of the computing instance; the load balancing strategy is modified so that the load balancer no longer allocates new requests to the target computing instance.

[0084] When operating S620, remove the application node from the target compute instance from the standby cluster.

[0085] According to embodiments of this application, after the target computing instance has no active requests, the application node is deregistered through the service discovery and cluster management components to prevent the cluster scheduler from mistakenly routing requests to that node. Specifically, the registration information of the application node on the target computing instance is located, and the instance deregistration operation is performed, or an application node offline script is executed on the target computing instance to make the application actively send a deregistration request to the service discovery component, ensuring that the cluster no longer recognizes the node as an available node; in the management platform of the standby cluster, the target computing instance is removed from the standby cluster node pool, and its unique tag is deleted to prevent the cluster operation and maintenance tools from performing subsequent management operations on it.

[0086] When operating the S630, configure the network to disconnect the target compute instance from the business network and perform data backup.

[0087] According to the embodiments of this application, network isolation is used to prevent accidental access by external traffic, while simultaneously backing up the operational transaction data on the target computing instance to avoid data loss. Specifically, in the cloud platform security group configuration, the inbound rules for the allowed business ports of the security group to which the target computing instance belongs are deleted. At the same time, in the routing table of the standby cluster, the routing entry corresponding to the target computing instance identifier is deleted to ensure that the business subnet cannot access the target instance, completely blocking business traffic. Log in to the target computing instance and synchronize the operational transaction data under the storage volume mount directory to the initial scale node storage volume or cloud object storage bucket of the standby cluster. After the backup is completed, the checksum of the source file and the backup file is compared using a file verification tool to ensure that the data is complete and error-free.

[0088] In operation S640, the storage volume is unloaded for the target compute instance, and the corresponding server resources are reclaimed.

[0089] According to the embodiments of this application, after data backup is completed and network isolation is achieved, the storage volume is securely unmounted and computing resources are released to avoid resource residue. Specifically, first, the command to unmount the storage volume is executed on the target computing instance, then the mount configuration of the storage volume is deleted, and finally, the storage volume unmounting operation is executed on the cloud platform console to disconnect the storage volume from the target instance; the target computing instance is deleted, and the storage volume is processed according to the data retention policy. After the operation is completed, the CPU and memory usage of the target instance are verified on the cloud resource monitoring platform to have dropped to 0, and the storage volume has changed from "mounted" to "idle / deleted", ensuring that the resources are completely recovered.

[0090] By scaling down the backup server cluster, idle CPU, memory, and other resources can be rolled back to the cloud cluster resource pool, avoiding waste caused by long-term resource idling and reducing cloud service costs incurred by excess resources. After scaling down, the backup cluster retains the initial number of nodes, maintaining the capacity to handle basic operational transactions while ensuring that the network configuration and security status of the nodes remain ready. If operational traffic increases again in the future, expansion can be quickly initiated without building the cluster from scratch, further consolidating the overall architecture's synergy in stably supporting regular transactions with the commonly used cluster and dynamically adapting to operational traffic with the backup cluster.

[0091] Based on the above-described server resource configuration method, this application also provides a server resource configuration apparatus. The following will be combined with... Figure 7 The device is described in detail.

[0092] Figure 7 A schematic block diagram of a server resource configuration apparatus according to an embodiment of this application is shown.

[0093] like Figure 7 As shown, the server resource configuration device 700 of this embodiment includes an acquisition module 710, a first response module 720, and a second response module 730.

[0094] The acquisition module 710 is used to acquire the server load caused by transaction requests, including regular transaction requests and operational transaction requests. In one embodiment, the acquisition module 710 can be used to perform the operation S210 described above, which will not be repeated here.

[0095] The first response module 720 is used to respond to a first preset condition by expanding the backup cluster to a first scale, allocating regular transaction requests to the primary cluster, and allocating operational transaction requests to the backup cluster. The primary cluster has the first scale of server resources, and the backup cluster is pre-configured independently of the primary cluster. In one embodiment, the first response module 720 can be used to execute the operation S220 described above, which will not be repeated here.

[0096] The second response module 730 is used to respond to the server load meeting the second preset condition by expanding the standby cluster to the second scale, and based on a preset ratio. : Transaction requests are distributed to the primary cluster and the backup cluster, where the second cluster is smaller than or equal to the first cluster. , All are positive numbers and > The first preset condition is a load triggering condition for abnormal server load in the commonly used cluster, and the second preset condition is a load triggering condition for resource scarcity on the servers of the commonly used cluster. In one embodiment, the second response module 730 can be used to execute the operation S230 described above, which will not be repeated here.

[0097] According to embodiments of this application, any plurality of modules among the acquisition module 710, the first response module 720, and the second response module 730 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least a portion of the functionality of one or more of these modules can be combined with at least a portion of the functionality of other modules and implemented in one module. According to embodiments of this application, at least one of the acquisition module 710, the first response module 720, and the second response module 730 can be at least partially implemented as a hardware circuit, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented by any other reasonable means of integrating or packaging the circuit, or implemented in any one of the three methods of software, hardware, and firmware, or in a suitable combination of any of these. Alternatively, at least one of the acquisition module 710, the first response module 720, and the second response module 730 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0098] Figure 8 A block diagram schematically illustrates an electronic device suitable for implementing a server resource configuration method according to an embodiment of this application.

[0099] like Figure 8As shown, an electronic device 800 according to an embodiment of this application includes a processor 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from a storage portion 808 into a random access memory (RAM) 803. The processor 801 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 801 may also include onboard memory for caching purposes. The processor 801 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0100] RAM 803 stores various programs and data required for the operation of electronic device 800. Processor 801, ROM 802, and RAM 803 are interconnected via bus 804. Processor 801 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 802 and / or RAM 803. It should be noted that the programs may also be stored in one or more memories other than ROM 802 and RAM 803. Processor 801 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0101] According to embodiments of this application, the electronic device 800 may further include an input / output (I / O) interface 805, which is also connected to a bus 804. The electronic device 800 may also include one or more of the following components connected to the input / output (I / O) interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN card, modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the input / output (I / O) interface 805 as needed. A removable medium 811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 810 as needed so that computer programs read from it can be installed into the storage section 808 as needed.

[0102] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0103] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 802 and / or RAM 803 and / or one or more memories other than ROM 802 and RAM 803 described above.

[0104] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to enable the computer system to implement the server resource configuration method provided in the embodiments of this application.

[0105] When the computer program is executed by the processor 801, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0106] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 809, and / or installed from a removable medium 811. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0107] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 809, and / or installed from the removable medium 811. When the computer program is executed by the processor 801, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0108] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0109] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0110] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A method for configuring server resources, characterized in that, include: Get the server load caused by transaction requests, including regular transaction requests and operational transaction requests; In response to the server load meeting a first preset condition, the backup cluster is expanded to a first size, and the regular transaction requests are allocated to the primary cluster, while the operational transaction requests are allocated to the backup cluster. The primary cluster has the server resources of the first size, and the backup cluster is pre-configured independently of the primary cluster; or, In response to the server load meeting a second preset condition, the backup cluster is expanded to a second size, and based on a preset ratio. : The transaction requests are allocated to the primary cluster and the backup cluster, wherein the second size is less than or equal to the first size. , All are positive numbers and > ; The first preset condition is a load triggering condition for abnormal server load in the commonly used cluster, and the second preset condition is a load triggering condition for resource shortage on the server of the commonly used cluster.

2. The server resource configuration method according to claim 1, characterized in that, Pre-configuring the backup cluster includes: Based on the historical peak load data of the operational transaction requests, the expected business scale, and the cloud cluster resource pool capacity, the preset ratio is obtained; Based on the preset ratio, the cloud cluster resource pool is divided into the commonly used cluster and the backup cluster, at which time the server resources of the backup cluster are at the initial scale.

3. The server resource configuration method according to claim 2, characterized in that, After expanding the backup cluster, the following is also included: In response to the server load meeting a third preset condition, the backup cluster is scaled down to the initial size, where the third preset condition is the normal load triggering condition of the commonly used cluster's servers. The transaction requests are allocated to the primary cluster and the backup cluster based on the preset ratio.

4. The server resource configuration method according to claim 3, characterized in that, Expanding the capacity of the backup cluster includes: Create a compute instance and a storage volume for the aforementioned operational transaction request, and mount the storage volume onto the compute instance; Configure the corresponding application node for the computing instance, and add the application node to the standby cluster; Perform network configuration and security verification on the application nodes.

5. The server resource configuration method according to claim 4, characterized in that, Downsizing the backup cluster includes: Modify the load balancing strategy of the operation transaction request so that the target computing instance of the operation transaction request stops receiving the operation transaction request, wherein the target computing instance is the computing instance with the latest creation time corresponding to the operation transaction request; Remove the application node from the target compute instance from the backup cluster; Configure the network to disconnect the target computing instance from the business network and perform data backup; Unload the storage volume for the target computing instance and reclaim the corresponding server resources.

6. The server resource configuration method according to claim 1, characterized in that, Setting the first preset condition includes: Within a first preset time window, the CPU load exceeds a first threshold; and / or, Within the first preset time window, the memory load exceeds the second threshold; and / or, Within the first preset time window, the transaction processing load exceeds the third threshold.

7. The server resource configuration method according to claim 6, characterized in that, Setting the second preset condition includes: Within the second preset time window, the CPU load exceeds the fourth threshold; and / or, Within the second preset time window, the memory load exceeds the fifth threshold; and / or, Within the second preset time window, the transaction processing load exceeds the sixth threshold. Wherein, the second preset time window is greater than the first preset time window, the fourth threshold is less than the first threshold, the fifth threshold is less than the second threshold, and the sixth threshold is less than the third threshold.

8. A server resource configuration device, characterized in that, include: The acquisition module is used to acquire the server load caused by transaction requests, including regular transaction requests and operational transaction requests; A first response module is configured to, in response to the server load meeting a first preset condition, expand the backup cluster to a first size, allocate the regular transaction requests to the primary cluster, and allocate the operational transaction requests to the backup cluster, wherein the server resources of the primary cluster are at the first size, and the backup cluster is pre-configured independently of the primary cluster; or, The second response module is used to, in response to the server load meeting a second preset condition, expand the backup cluster to a second size, and based on a preset ratio : The transaction requests are allocated to the primary cluster and the backup cluster, wherein the second size is less than or equal to the first size. , All are positive numbers and > ; The first preset condition is a load triggering condition for abnormal server load in the commonly used cluster, and the second preset condition is a load triggering condition for resource shortage on the server of the commonly used cluster.

9. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

Images