Cloud side gateway capacity expansion and contraction processing method and device

Abstract

The invention relates to the technical field of power grid cloud computing, provides a cloud side gateway capacity expansion and contraction processing method and device, and can perform automatic capacity expansion and contraction processing on a gateway cluster. The method comprises the steps of monitoring a load request number of a gateway cluster of a power grid cloud server; determining the relative size between the number of load requests in a plurality of continuous detection periods and the boundary value to obtain a relative size result; when it is determined that capacity expansion and shrinkage need to be carried out according to the relative size result, the target number of various gateways is determined according to the number of load requests in a plurality of continuous detection periods and the real-time performance of the load requests; and according to the target number of various gateways, carrying out capacity expansion and shrinkage on the gateway cluster.

Description

Technical Field

[0001] The present application relates to the field of power grid cloud computing technology, and in particular to a cloud-edge gateway scaling processing method, apparatus, computer equipment, storage medium, and computer program product. Background Art

[0002] In cloud-edge collaboration scenarios for power grids, the gateway services between the grid edge cloud servers and the grid center cloud servers serve as the entry and exit points for microservice interface interactions. Faced with increasing service demand, the pressure on the gateway services has reached bottlenecks, which can cause service call delays or failures in severe cases. In cloud-edge collaboration scenarios, ensuring stable operation of the gateways between the grid edge cloud servers and the grid center cloud servers while supporting the growing demand for power business services has become a challenge in managing cloud-edge collaboration gateways.

[0003] The power grid's cloud-edge collaborative service gateway is primarily deployed in advance, either in a single-node or clustered mode, based on anticipated business needs to support cloud-edge service interactions. As business grows, gateway instances are manually scaled up. This scaling process requires manual intervention and is not automated. Summary of the Invention

[0004] Based on this, it is necessary to provide a cloud-edge gateway scaling processing method, device, computer equipment, storage medium and computer program product to address the above technical problems.

[0005] This application provides a method for scaling a cloud edge gateway, the method comprising:

[0006] Monitor the number of load requests from the gateway cluster of the power grid cloud server;

[0007] Determine the relative size between the number of load requests and the boundary value in a plurality of consecutive detection cycles to obtain a relative size result;

[0008] When it is determined that expansion or contraction is required based on the relative size results, the target number of each type of gateway is determined based on the number of load requests in multiple consecutive detection cycles and the real-time nature of the load requests;

[0009] The gateway cluster is expanded or reduced in size according to the target number of each type of gateway.

[0010] In one embodiment, determining the relative size between the number of load requests and the boundary value in a plurality of consecutive detection cycles to obtain a relative size result includes:

[0011] The number of load requests in a plurality of consecutive detection cycles is compared with the upper boundary value, and the number of load requests in a plurality of consecutive detection cycles is compared with the lower boundary value to obtain a relative size result.

[0012] In one embodiment, the method further comprises:

[0013] Obtaining an average number of load requests at the multiple real-time levels according to the number of load requests at the multiple real-time levels in each detection cycle of the multiple consecutive detection cycles;

[0014] Compare the number of load requests in multiple consecutive detection cycles with the upper limit value, including:

[0015] Compare the average number of load requests of multiple real-time levels with the corresponding upper limit values;

[0016] Compare the number of load requests in multiple consecutive detection cycles with the lower limit value, including:

[0017] The average number of load requests for multiple real-time classes is compared with the corresponding lower bound values.

[0018] In one embodiment, the target number of each type of gateway is determined based on the number of load requests and the real-time nature of the load requests within a plurality of consecutive detection cycles, including:

[0019] Obtaining an average number of load requests at the multiple real-time levels according to the number of load requests at the multiple real-time levels in each detection cycle of the multiple consecutive detection cycles;

[0020] According to the average number of load requests for each real-time level and the maximum number of load requests corresponding to a single gateway of the corresponding category of each real-time level, the number of gateways of the corresponding category of each real-time level is obtained to determine the target number of each type of gateway.

[0021] In one embodiment, the average number of load requests at multiple real-time levels is obtained based on the number of load requests at multiple real-time levels in each detection period of a plurality of consecutive detection periods, including:

[0022] For any real-time level, the number of load requests for the real-time level in multiple consecutive detection cycles is summed and divided by the number of detection cycles to obtain the average number of load requests for the real-time level, so as to determine the average number of load requests for multiple real-time levels.

[0023] In one embodiment, the grid cloud server includes a grid center cloud server or a grid edge cloud server.

[0024] The present application provides a cloud edge gateway expansion and contraction processing device, the device comprising:

[0025] A monitoring and processing module is used to monitor the number of load requests of the gateway cluster of the power grid cloud server;

[0026] A comparison module is used to determine the relative size between the number of load requests and the boundary value in a plurality of consecutive detection cycles to obtain a relative size result;

[0027] A gateway quantity determination module is configured to determine a target quantity of each type of gateway based on the number of load requests within a plurality of consecutive detection cycles and the real-time nature of the load requests when it is determined that expansion or contraction is required based on the relative size results;

[0028] The expansion and contraction processing module is used to expand and contract the gateway cluster according to the target number of each type of gateway.

[0029] The present application provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the above method.

[0030] The present application provides a computer-readable storage medium having a computer program stored thereon, and the computer program is used by a processor to execute the above method.

[0031] The present application provides a computer program product having a computer program stored thereon, wherein the computer program is used by a processor to execute the above method.

[0032] The above-mentioned cloud-edge gateway scaling processing method, device, computer equipment, storage medium and computer program product monitor the number of load requests of the gateway cluster of the power grid cloud server; determine the relative size between the number of load requests and the boundary value in multiple consecutive detection cycles to obtain a relative size result; when it is determined based on the relative size result that scaling is required, the target number of each type of gateway is determined based on the number of load requests in multiple consecutive detection cycles and the real-time nature of the load requests; and the gateway cluster is scaled up or down according to the target number of each type of gateway. The present application provides a solution for automatic expansion and contraction of gateways, which can be performed automatically without human intervention; wherein, the relative size relationship between the number of load requests and the boundary value of the gateway cluster of the power grid cloud server in multiple consecutive detection cycles is monitored to determine whether expansion or contraction is required, and to avoid incorrect expansion or contraction caused by errors in a single detection cycle; and, after determining that expansion or contraction is required, the target number of each type of gateway is determined based on the number of load requests in multiple consecutive detection cycles and the real-time nature of the load requests, so that more reasonable expansion or contraction can be performed, avoiding adding too many high-real-time gateways when the real-time nature of the load requests is mostly low, thereby wasting computing resources, and avoiding adding too many low-real-time gateways when the real-time nature of the load requests is mostly high, resulting in load requests not being responded to in a timely manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0034] Figure 1 This is a diagram of the interaction architecture between a power grid center cloud server and a power grid edge cloud server in one embodiment;

[0035] Figure 2 Schematic diagram of a process for scaling a cloud-edge gateway in one embodiment;

[0036] Figure 3 This is a diagram of the interaction architecture between the power grid center cloud server and the power grid edge cloud server in another embodiment;

[0037] Figure 4 This is a structural block diagram of a cloud edge gateway expansion and contraction processing device in one embodiment;

[0038] Figure 5 FIG. 1 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0039] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0040] Cloud-edge collaboration gateway: Cloud-edge collaboration consists of a central cloud gateway and an edge cloud gateway. It generally provides data exchange and transparent transmission capabilities, and can be understood as a web gateway service, supporting interface calls or data exchange business needs between cloud and edge microservices.

[0041] The cloud-edge gateway scaling processing method provided in this application relates to a power grid cloud server, which includes a power grid center cloud server or a power grid edge cloud server.

[0042] The interaction between the grid center cloud server and the grid edge cloud server is as follows: Figure 1 As shown in the figure, both the grid center cloud server and the grid edge cloud server are deployed with a virtualization platform, microservices, and gateway clusters. The microservices run on the virtualization platform, and the microservices of the grid edge cloud server and the microservices of the grid center cloud server can call each other through the gateway clusters of the grid edge cloud server and the gateway clusters of the grid center cloud server.

[0043] Traditionally, cloud-edge collaborative service gateways for power grids lack automatic scaling mechanisms, leading to bottlenecks only being discovered after service demand increases and failures occur. This solution, proposed in this application, enables automatic scaling, and can be appropriately scaled based on the real-time nature of load requests.

[0044] The cloud edge gateway expansion and contraction processing method provided in this application may include Figure 2 The steps shown are, Figure 2 The steps shown can be performed by a gateway management service unit. The gateway management service unit can be set on the power grid cloud server. When the power grid cloud server includes both a power grid center cloud server and a power grid edge cloud server, the gateway management service unit can be set on the power grid center cloud server.

[0045] Step S201 : monitoring the number of load requests of the gateway cluster of the power grid cloud server.

[0046] The gateway management service unit has the authority to monitor the number of load requests of the gateway cluster. Therefore, during the operation of the power grid cloud server, the gateway management service unit can monitor the number of load requests of the gateway cluster in real time.

[0047] Step S202: Determine the relative size between the number of load requests and the boundary value in a plurality of consecutive detection cycles to obtain a relative size result.

[0048] When monitoring the number of load requests in the gateway cluster in real time, the gateway management service unit can monitor the number of load requests within N consecutive detection cycles, where N can be a positive integer greater than or equal to 2 and can be adjusted based on actual conditions. The number of load requests in each detection cycle is compared with the boundary value to obtain a comparison result corresponding to each detection cycle, thereby forming a relative size result.

[0049] The gateway management service unit determines whether scaling is required based on the relative size result. If scaling is not required, the gateway management service unit may not execute steps S203 and S204 and continue to monitor the number of load requests in the next detection cycle.

[0050] If expansion or contraction is required, the gateway management service unit may execute steps S203 and S204.

[0051] Step S203 , when it is determined that expansion or contraction is required based on the relative size result, the target number of each type of gateway is determined based on the number of load requests in a plurality of consecutive detection cycles and the real-time performance of the load requests.

[0052] Gateways can be categorized by their real-time performance, creating multiple gateway types. Each type of gateway corresponds to a different level of real-time performance. High-performance real-time performance gateways and their instances can utilize high-performance processors and high-performance communication protocols, while low-performance real-time performance gateways and their instances can utilize low-performance processors and low-performance communication protocols.

[0053] After the gateway management service unit determines that scaling is necessary, it can determine whether the real-time nature of the load requests during each of N consecutive detection cycles is high or low, and thereby determine the target number of each type of gateway. If the number of high-real-time nature load requests during N consecutive detection cycles is greater than the number of low-real-time nature load requests, the target number of high-real-time nature gateways is higher than the target number of low-real-time nature gateways; if the number of high-real-time nature load requests during N consecutive detection cycles is lower than the number of low-real-time nature load requests, the target number of high-real-time nature gateways is lower than the target number of low-real-time nature gateways.

[0054] Step S204: scaling the gateway cluster according to the target number of each type of gateway.

[0055] After determining the target number of each type of gateway, the existing number of gateways of each type in the gateway cluster of the power grid cloud server can be determined. If the target number of a certain type of gateway is greater than the existing number of gateways of that type, it indicates that there are insufficient gateways of that type. The number of gateways of that type can be increased to the corresponding target number. If the target number of a certain type of gateway is less than the existing number of gateways of that type, it indicates that there are too many gateways of that type. The number of gateways of that type can be reduced to the corresponding target number. Through the above processing method, the expansion and contraction of the gateway cluster of the power grid cloud server is completed.

[0056] In the above-mentioned cloud-edge gateway scaling processing method, the number of load requests of the gateway cluster of the power grid cloud server is monitored; the relative size between the number of load requests and the boundary value in multiple consecutive detection cycles is determined to obtain a relative size result; when it is determined based on the relative size result that scaling is required, the target number of each type of gateway is determined based on the number of load requests in multiple consecutive detection cycles and the real-time nature of the load requests; the gateway cluster is scaled up or down according to the target number of each type of gateway. The present application provides a solution for automatic expansion and contraction of gateways, which can be performed automatically without human intervention; wherein, the relative size relationship between the number of load requests and the boundary value of the gateway cluster of the power grid cloud server in multiple consecutive detection cycles is monitored to determine whether expansion or contraction is required, and to avoid incorrect expansion or contraction caused by errors in a single detection cycle; and, after determining that expansion or contraction is required, the target number of each type of gateway is determined based on the number of load requests in multiple consecutive detection cycles and the real-time nature of the load requests, so that more reasonable expansion or contraction can be performed, avoiding adding too many high-real-time gateways when the real-time nature of the load requests is mostly low, thereby wasting computing resources, and avoiding adding too many low-real-time gateways when the real-time nature of the load requests is mostly high, resulting in load requests not being responded to in a timely manner.

[0057] In one embodiment, determining the relative size between the number of load requests and the boundary value in a plurality of consecutive detection cycles to obtain a relative size result includes:

[0058] The number of load requests in a plurality of consecutive detection cycles is compared with the upper boundary value, and the number of load requests in a plurality of consecutive detection cycles is compared with the lower boundary value to obtain a relative size result.

[0059] In this embodiment, for each of N consecutive detection cycles, the gateway management service unit can compare the number of load requests in the detection cycle with the upper boundary value and the lower boundary value. After comparing the number of load requests in each detection cycle, a relative size result is formed. The gateway management service unit can determine whether it is necessary to expand or shrink the gateway cluster of the power grid cloud server based on the relative size result. It is understood that in the solution provided by this application, expansion and shrinkage can be performed simultaneously, such as expanding a certain type of gateway and shrinking another type of gateway.

[0060] In one embodiment, the method provided by the present application further includes: obtaining an average number of load requests of multiple real-time levels based on the number of load requests of multiple real-time levels in each detection cycle of multiple consecutive detection cycles. Comparing the number of load requests in the multiple consecutive detection cycles with the upper boundary value respectively includes: comparing the average number of load requests of multiple real-time levels with the corresponding upper boundary value. Comparing the number of load requests in the multiple consecutive detection cycles with the lower boundary value respectively includes: comparing the average number of load requests of multiple real-time levels with the corresponding lower boundary value.

[0061] You can pre-set upper and lower bounds for different real-time levels. The higher the real-time level of a load request, the more timely it is processed, the less likely it is to accumulate too many load requests, and the smaller the upper bound. For example, if one real-time level is higher than another, the upper bound corresponding to the former is smaller than the upper bound corresponding to the latter. Therefore, when the load requests for the former exceed the smaller upper bound, capacity can be expanded, ensuring that load requests with a higher real-time level are processed promptly and prevented from accumulating too many.

[0062] The higher the real-time level of the load request, the more timely the processing, the less allowed the accumulation of too many load requests, and the smaller the lower boundary value; for example, if one real-time level is higher than another, the lower boundary value corresponding to the former is smaller than the lower boundary value corresponding to the latter. Therefore, the load request of the former will only be scaled down when it is lower than the smaller lower boundary value, thereby ensuring that the load requests with a high real-time level are processed in a timely manner and will not accumulate too much.

[0063] For N consecutive detection cycles, the number of load requests for multiple real-time levels in each detection cycle can be determined. The number of load requests for the same real-time level in each detection cycle is summed and divided by N to obtain the average number of load requests for the same real-time level, thereby obtaining the average number of load requests for each real-time level.

[0064] Taking the average number of load requests with high real-time level as an example, the average number of load requests with high real-time level can be compared with the upper boundary value corresponding to the high real-time level. If the average number of load requests with high real-time level is greater than the upper boundary value corresponding to the high real-time level, it can be determined that gateways with high real-time level need to be increased; the average number of load requests with high real-time level can also be compared with the lower boundary value corresponding to the high real-time level. If the average number of load requests with high real-time level is less than the lower boundary value corresponding to the high real-time level, it can be determined that gateways with high real-time level need to be reduced.

[0065] Taking the average number of load requests with low real-time level as an example, the average number of load requests with low real-time level is compared with the upper boundary value corresponding to the low real-time level. If the average number of load requests with low real-time level is greater than the upper boundary value corresponding to the low real-time level, it can be determined that the number of gateways with low real-time level needs to be increased; the average number of load requests with low real-time level can also be compared with the lower boundary value corresponding to the low real-time level. If the average number of load requests with low real-time level is less than the lower boundary value corresponding to the low real-time level, it can be determined that the number of gateways with low real-time level needs to be reduced.

[0066] In this embodiment, by comparing the average number of load requests of multiple real-time levels with the corresponding upper and lower boundary values, a more reasonable comparison result can be obtained, thereby performing capacity expansion and contraction more reasonably.

[0067] In one embodiment, the target number of each type of gateway is determined based on the number of load requests and the real-time nature of the load requests within a plurality of consecutive detection cycles, including:

[0068] Based on the number of load requests for multiple real-time levels in each detection cycle of multiple consecutive detection cycles, the average number of load requests for multiple real-time levels is obtained; based on the average number of load requests for each real-time level and the maximum number of load requests corresponding to a single gateway of the corresponding category of each real-time level, the number of gateways of the corresponding category of each real-time level is obtained to determine the target number of gateways of each category.

[0069] For example, gateways of the corresponding category with a high real-time performance level can be called high real-time performance gateways, and the maximum number of load requests that a single high real-time performance gateway can handle can be pre-set; similarly, gateways of the corresponding category with a low real-time performance level can be called low real-time performance gateways, and the maximum number of load requests that a single low real-time performance gateway can handle can be pre-set.

[0070] For N consecutive detection cycles, the number of load requests for multiple real-time levels in each detection cycle can be determined. The number of load requests for the same real-time level in each detection cycle is summed and divided by N to obtain the average number of load requests for the same real-time level, thereby obtaining the average number of load requests for each real-time level.

[0071] Taking the high real-time level as an example, the average number of high real-time level load requests can be divided by the maximum number of load requests that a single high real-time level gateway can handle, so as to determine the number of gateways required to handle these high real-time level load requests, and use this number of gateways as the target number of high real-time level gateways.

[0072] Taking the low real-time level as an example, the average number of low real-time level load requests can be divided by the maximum number of load requests that a single low real-time level gateway can handle, so as to determine the number of gateways required to handle these low real-time level load requests, and use this number of gateways as the target number of low real-time level gateways.

[0073] In this embodiment, the number of gateways of each category of real-time performance is obtained based on the average number of load requests of each real-time performance level and the maximum number of load requests corresponding to a single gateway of each category of real-time performance level, so that the target number of each category of gateways can be determined more reasonably.

[0074] In one embodiment, the average number of load requests at multiple real-time levels is obtained based on the number of load requests at multiple real-time levels in each detection period of a plurality of consecutive detection periods, including:

[0075] For any real-time level, the number of load requests for the real-time level in multiple consecutive detection cycles is summed and divided by the number of detection cycles to obtain the average number of load requests for the real-time level, so as to determine the average number of load requests for multiple real-time levels.

[0076] For N consecutive detection cycles, the number of load requests for multiple real-time levels in each detection cycle can be determined. The number of load requests for the same real-time level in each detection cycle is summed and divided by N to obtain the average number of load requests for the same real-time level, thereby obtaining the average number of load requests for each real-time level.

[0077] When the grid cloud server includes a grid center cloud server and a grid edge cloud server, the gateway management service unit provided in this application can detect the number of load requests of the gateway cluster of the grid center cloud server and the number of load requests of the gateway cluster of the grid edge cloud server in real time.

[0078] The gateway management service unit can periodically obtain the number of load requests from the gateway cluster. If the number of load requests exceeds the upper limit, the expansion mechanism is triggered. If the number of load requests is less than the lower limit for a long time, the reduction mechanism is triggered.

[0079] In addition, when the gateway management service unit detects that the number of load requests obtained in multiple consecutive (adjustable) detection cycles is greater than the upper limit, the gateway cluster instance expansion mechanism is triggered.

[0080] When the gateway management service unit detects that the number of load requests obtained in multiple consecutive (adjustable) detection cycles is less than the lower limit and some gateway instances are not in use, the gateway cluster instance scaling mechanism is triggered.

[0081] Reference Figure 3 , Figure 3 The cloud-edge collaborative architecture diagram provided for this application, in which the gateway management service unit is set in the power grid center cloud server, and both the power grid center cloud server and the power grid edge cloud server are deployed with VIP (virtual IP address), so that their respective gateway clusters interact through VIP.

[0082] In the solution provided in this application, the cloud-edge collaborative gateway service has automatic dynamic expansion and contraction, avoiding manual intervention, improving production efficiency for enterprises and saving operating costs; moreover, the cloud-edge collaborative gateway service runs stably, supports the interaction needs of cloud-edge business microservices, responds to growing business needs, and improves the stability and availability of gateway services.

[0083] It should be understood that, although the various steps in the flowcharts involved in the various embodiments described above are displayed in sequence according to the instructions of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the various embodiments described above can include multiple steps or multiple stages, and these steps or stages are not necessarily executed and completed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0084] Based on the same inventive concept, an embodiment of the present application also provides a cloud edge gateway scaling processing device for implementing the cloud edge gateway scaling processing method involved above. The implementation solution provided by the device is similar to the implementation solution described in the above method, so the specific limitations in one or more cloud edge gateway scaling processing device embodiments provided below can be found in the limitations of the cloud edge gateway scaling processing method above, and will not be repeated here.

[0085] In one embodiment, Figure 4 As shown, a cloud edge gateway expansion and contraction processing device is provided, including:

[0086] The monitoring and processing module 401 is used to monitor the number of load requests of the gateway cluster of the power grid cloud server;

[0087] A comparison module 402 is configured to determine a relative size between the number of load requests and a boundary value within a plurality of consecutive detection cycles, and obtain a relative size result;

[0088] The gateway quantity determination module 403 is configured to determine the target quantity of each type of gateway based on the number of load requests within a plurality of consecutive detection cycles and the real-time nature of the load requests when it is determined that expansion or contraction is required based on the relative size result;

[0089] The expansion and contraction processing module 404 is configured to expand and contract the gateway cluster according to the target number of each type of gateway.

[0090] In one embodiment, the comparison module 402 is further configured to:

[0091] The number of load requests in a plurality of consecutive detection cycles is compared with the upper boundary value, and the number of load requests in a plurality of consecutive detection cycles is compared with the lower boundary value to obtain a relative size result.

[0092] In one embodiment, the apparatus further includes an average processing module configured to: obtain an average number of load requests at multiple real-time levels based on the number of load requests at multiple real-time levels in each of a plurality of consecutive detection cycles;

[0093] The comparison module 402 is further configured to: compare the average number of load requests of multiple real-time levels with the corresponding upper boundary value; and compare the average number of load requests of multiple real-time levels with the corresponding lower boundary value.

[0094] In one embodiment, the apparatus further includes an average processing module configured to: obtain an average number of load requests at multiple real-time levels based on the number of load requests at multiple real-time levels in each of a plurality of consecutive detection cycles;

[0095] The gateway quantity determination module 403 is used to obtain the number of gateways of the corresponding category of each real-time level according to the average number of load requests of each real-time level and the maximum number of load requests corresponding to a single gateway of the corresponding category of each real-time level, so as to determine the target number of each type of gateway.

[0096] In one embodiment, the averaging processing module is configured to:

[0097] For any real-time level, the number of load requests for the real-time level in multiple consecutive detection cycles is summed and divided by the number of detection cycles to obtain the average number of load requests for the real-time level, so as to determine the average number of load requests for multiple real-time levels.

[0098] In one embodiment, the grid cloud server includes a grid center cloud server or a grid edge cloud server.

[0099] Each module in the above-mentioned cloud edge gateway scaling processing device can be implemented in whole or in part through software, hardware, or a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of the above modules.

[0100] In an exemplary embodiment, a computer device is provided, the internal structure of which can be as follows: Figure 5 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, abbreviated as I / O) and a communication interface. The processor, memory and input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store data involved in the above method. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a cloud edge gateway scaling processing method is implemented.

[0101] Those skilled in the art will understand that Figure 5 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0102] In one embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor implements the steps in the above-mentioned method embodiments when executing the computer program.

[0103] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0104] In one embodiment, a computer program product is provided, on which a computer program is stored. The computer program is used by a processor to execute the steps in the above-mentioned various method embodiments.

[0105] 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, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0106] Those skilled in the art will understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. In particular, any reference to memory, database, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The databases involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the various embodiments provided herein may be, but are not limited to, general-purpose processors, central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), programmable logic devices (PLDs), quantum computing-based data processing logic devices, artificial intelligence (AI) processors, and the like.

[0107] The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0108] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A cloud edge gateway expansion and contraction processing method, characterized in that: The method comprises: Monitor the number of load requests from the gateway cluster of the power grid cloud server; Determine the relative size between the number of load requests and the boundary value in a plurality of consecutive detection cycles to obtain a relative size result; When it is determined that expansion or contraction is required based on the relative size results, the target number of each type of gateway is determined based on the number of load requests in multiple consecutive detection cycles and the real-time nature of the load requests; The gateway cluster is expanded or reduced in size according to the target number of each type of gateway.

2. The method according to claim 1, characterized in that Determine the relative size between the number of load requests and the boundary value in multiple consecutive detection cycles, and obtain a relative size result, including: The number of load requests in a plurality of consecutive detection cycles is compared with the upper boundary value, and the number of load requests in a plurality of consecutive detection cycles is compared with the lower boundary value to obtain a relative size result.

3. The method according to claim 2, characterized in that The method further comprises: Obtaining an average number of load requests at the multiple real-time levels according to the number of load requests at the multiple real-time levels in each detection cycle of the multiple consecutive detection cycles; Compare the number of load requests in multiple consecutive detection cycles with the upper limit value, including: Compare the average number of load requests of multiple real-time levels with the corresponding upper limit values; Compare the number of load requests in multiple consecutive detection cycles with the lower limit value, including: The average number of load requests for multiple real-time classes is compared with the corresponding lower bound values.

4. The method according to claim 1, wherein Based on the number of load requests over multiple consecutive detection cycles and the real-time nature of the load requests, determine the target number of each type of gateway, including: Obtaining an average number of load requests at the multiple real-time levels according to the number of load requests at the multiple real-time levels in each detection cycle of the multiple consecutive detection cycles; According to the average number of load requests for each real-time level and the maximum number of load requests corresponding to a single gateway of the corresponding category of each real-time level, the number of gateways of the corresponding category of each real-time level is obtained to determine the target number of each type of gateway.

5. The method according to claim 4, characterized in that According to the number of load requests of the multiple real-time levels in each detection cycle of the multiple consecutive detection cycles, the average number of load requests of the multiple real-time levels is obtained, including: For any real-time level, the number of load requests for the real-time level in multiple consecutive detection cycles is summed and divided by the number of detection cycles to obtain the average number of load requests for the real-time level, so as to determine the average number of load requests for multiple real-time levels.

6. The method according to any one of claims 1 to 5, characterized in that The power grid cloud server includes the power grid center cloud server or the power grid edge cloud server.

7. A cloud edge gateway expansion and contraction processing device, characterized in that: The device comprises: A monitoring and processing module is used to monitor the number of load requests of the gateway cluster of the power grid cloud server; A comparison module is used to determine the relative size between the number of load requests and the boundary value in a plurality of consecutive detection cycles to obtain a relative size result; A gateway quantity determination module is configured to determine a target quantity of each type of gateway based on the number of load requests within a plurality of consecutive detection cycles and the real-time nature of the load requests when it is determined that expansion or contraction is required based on the relative size results; The expansion and contraction processing module is used to expand and contract the gateway cluster according to the target number of each type of gateway.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images