Distributed service resource configuration method, device and system

Abstract

The application discloses a distributed service resource configuration method, device and system, which can be used in the field of artificial intelligence technology, and the method comprises the following steps: determining the calling data of the target service node container of the distributed service arranged on each virtual machine; determining the calling frequency of each target service node container according to the calling data, determining the corresponding resource allocation strategy according to the calling frequency and the service property of the target service node container on each virtual machine; updating the number of service node containers of the virtual machine of the distributed service and the corresponding physical machine according to the resource allocation strategy, and configuring the distributed service to the updated physical machine. The application starts from the actual business scene, automatically configures the server resources according to the calling frequency and the service property of the distributed service to the service node container, makes the resource configuration more objective and in line with the business scene demand, reduces the workload of the operation and maintenance personnel, and improves the configuration efficiency of the distributed system service resources.

Description

Technical Field

[0001] This invention relates to the field of distributed systems technology, particularly to the field of artificial intelligence technology, and especially to a method, apparatus and system for configuring distributed service resources. Background Technology

[0002] This section is intended to provide background or context for the embodiments of this application set forth in the claims. The description herein is not an admission that it is prior art simply because it is included in this section.

[0003] With the gradual popularization of distributed service technology, large-scale distributed service system R&D enterprises face immense development pressure. To quickly meet business requirements, they typically adopt a project iteration approach, rotating through several development environments to support project development. Each development environment contains various resources, such as database server resources, PaaS service node resources, cache server resources, and file server resources. Therefore, large R&D enterprises have a significant demand for server resources. Given limited development resources, how to rationally allocate, manage, and reclaim various resources to improve resource utilization is a challenging issue.

[0004] In existing technologies, the allocation of R&D resources is generally done manually by the operation and maintenance personnel of each R&D environment. For example, the operation and maintenance personnel apply for server resources. However, if the resources are not registered or manually returned in a timely manner after use, it will lead to idle and wasted resources, which will affect the progress of subsequent R&D. Summary of the Invention

[0005] One objective of this application is to provide a distributed service resource configuration method. Starting from actual business scenarios, this method automatically configures server resources based on the frequency of calls to service node containers and the nature of the services. This makes resource configuration more objective and aligned with business needs, reduces the workload of operations and maintenance personnel, and improves the configuration efficiency of distributed system service resources. Another objective of this application is to provide a distributed service resource configuration device. A further objective is to provide a distributed system. A further objective is to provide a computer device. A final objective is to provide a readable medium.

[0006] To achieve the above objectives, this application discloses a distributed service resource configuration method, the method comprising:

[0007] Determine the call data for the target service node containers on each virtual machine for the distributed service settings;

[0008] The call frequency of each target service node container is determined based on the call data, and the corresponding resource allocation strategy is determined based on the call frequency and the service nature of the target service node container on each virtual machine.

[0009] According to the resource allocation strategy, update the number of service node containers and the corresponding physical machines of the virtual machines of the distributed service, and configure the distributed service on the updated physical machines.

[0010] Optionally, the step of determining the call data for the target service node containers set up on each virtual machine for the distributed service includes:

[0011] Determine the target monthly version based on the current time;

[0012] The distributed service whose resource configuration needs to be updated is determined based on the target monthly version and the service identifier of the distributed service, wherein the service identifier of the distributed service includes the monthly version and the service name;

[0013] Obtain the call data of the target service node container on each virtual machine for the distributed service settings of the resource configuration to be updated.

[0014] Optionally, determining the target monthly version based on the current time includes:

[0015] The target monthly version is obtained by determining the months included in the preset time period before and after the current time.

[0016] Optionally, determining the corresponding resource allocation strategy based on the call frequency and the service nature of the target service node container on each virtual machine includes:

[0017] If the sum of the call frequencies of all target service node containers on the virtual machine is a high-frequency call, the resource allocation strategy of the virtual machine is determined to be a resource expansion strategy.

[0018] If the sum of the call frequencies of all target service node containers on the virtual machine is low-frequency call and there are target service node containers that make critical service calls, then the resource allocation strategy of the virtual machine is determined to be a resource scaling-down strategy.

[0019] If the sum of the call frequencies of all target service node containers on the virtual machine is low-frequency call and there are no target service node containers that call critical services, then the resource allocation strategy of the virtual machine is determined to be a resource reclamation strategy.

[0020] Optionally, the resource allocation strategy is a resource expansion strategy, and updating the number of service node containers and corresponding physical machines of the virtual machines of the distributed service according to the resource allocation strategy includes:

[0021] The number of target containers required for the virtual machine is determined based on the sum of the call frequencies of all target service node containers on the virtual machine and the standard call frequency of the service node containers.

[0022] Update the number of service node containers supported by the virtual machine based on the target number of containers;

[0023] The updated physical machine is determined based on the updated number of service node containers.

[0024] Optionally, the resource allocation strategy is a resource scaling-down strategy, and updating the number of service node containers and corresponding physical machines of the virtual machines of the distributed service according to the resource allocation strategy includes:

[0025] Delete the target service node containers on the virtual machine that are not critical service calls to obtain the number of target containers after the virtual machine is scaled down.

[0026] Update the number of service node containers supported by the virtual machine corresponding to the distributed service based on the target number of containers.

[0027] The updated physical machine is determined based on the updated number of service node containers.

[0028] Optionally, it may further include:

[0029] Determine the total number of service node containers on all virtual machines after the distributed service update;

[0030] The decision on whether the virtual machines of the distributed service need to be merged is determined based on the total number of service node containers and the number of physical machines corresponding to the distributed service.

[0031] If so, re-determine the updated virtual machine corresponding to the distributed service, and configure the distributed service on the physical machine corresponding to the updated virtual machine.

[0032] Optionally, updating the number of service node containers supported by the virtual machine corresponding to the distributed service based on the target number of containers includes:

[0033] The number of service node containers supported by the virtual machine is determined based on the maximum value between the target number of containers and the number of service node containers supported by the physical machine.

[0034] Optionally, the resource allocation strategy is a resource reclamation strategy, and updating the number of service node containers and the physical machines corresponding to the virtual machines of the distributed service according to the resource allocation strategy includes:

[0035] Delete the virtual machine corresponding to the distributed service.

[0036] Optionally, configuring the distributed service on the updated physical machine includes:

[0037] Configure the service node containers corresponding to the updated number of service node containers on the virtual machine of the distributed service onto the physical machine.

[0038] Another aspect of this application discloses a distributed service resource configuration apparatus, comprising:

[0039] The call data determination module is used to determine the call data of the target service node containers on each virtual machine for the distributed service settings.

[0040] The strategy configuration module is used to determine the call frequency of each target service node container based on the call data, and to determine the corresponding resource allocation strategy based on the call frequency and the service nature of the target service node container on each virtual machine.

[0041] The parameter update module is used to update the number of service node containers and the corresponding physical machines of the virtual machines of the distributed service according to the resource allocation strategy, and to configure the distributed service on the updated physical machines.

[0042] This application also discloses a distributed system, including a distributed service resource configuration device and a distributed system. The distributed system includes a physical machine cluster with virtual machines, the physical machine cluster includes multiple physical machines, and the virtual machines are equipped with service node containers for distributed services.

[0043] This application also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described method.

[0044] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0045] This application's distributed service resource configuration method determines the call data of target service node containers set on each virtual machine for a distributed service; determines the call frequency of each target service node container based on the call data; determines a corresponding resource allocation strategy based on the call frequency and the service nature of the target service node containers on each virtual machine; updates the number of service node containers and the corresponding physical machines of the virtual machine for the distributed service according to the resource allocation strategy; and configures the distributed service on the updated physical machines. By configuring service resources according to the call status of the distributed service to the target service node containers on the virtual machine and the service nature of the service node containers, this application's distributed service resource configuration method can automatically configure server resources based on the actual business scenario, the call frequency of the distributed service to the service node containers, and the service nature of the service. This makes resource configuration more objective and in line with business scenario requirements, and also reduces the workload of operation and maintenance personnel, thus improving the configuration efficiency of distributed system service resources in multiple dimensions. Attached Figure Description

[0046] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:

[0047] Figure 1 This is a schematic diagram of the structure of the distributed system provided in the embodiments of this application.

[0048] Figure 2 This is a flowchart illustrating the distributed service resource configuration method provided in an embodiment of this application.

[0049] Figure 3 This is a flowchart illustrating the distributed service resource configuration method provided in an embodiment of this application.

[0050] Figure 4 This is a flowchart illustrating the distributed service resource configuration method provided in an embodiment of this application.

[0051] Figure 5 This is a schematic diagram illustrating the node container invocation situation provided in an embodiment of this application.

[0052] Figure 6 This is a flowchart illustrating the distributed service resource configuration method provided in an embodiment of this application.

[0053] Figure 7 This is a flowchart illustrating the distributed service resource configuration method provided in an embodiment of this application.

[0054] Figure 8 This is a schematic diagram illustrating the node container invocation situation provided in an embodiment of this application.

[0055] Figure 9 This is a schematic diagram illustrating the node container invocation situation provided in an embodiment of this application.

[0056] Figure 10 This is a schematic diagram of the structure of the distributed service resource configuration device provided in the embodiments of this application.

[0057] Figure 11 A schematic diagram of a computer device suitable for implementing embodiments of the present invention is shown. Detailed Implementation

[0058] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments and descriptions of this application are used to explain this application, but are not intended to limit this application.

[0059] It should be noted that the distributed service resource configuration method, apparatus and system disclosed in this application can be used in the field of artificial intelligence technology, or in any field other than artificial intelligence technology. The application field of the distributed service resource configuration method, apparatus and system disclosed in this application is not limited.

[0060] With the gradual promotion and popularization of distributed service technology, large-scale distributed service system R&D enterprises face enormous development pressure. In order to quickly realize business requirements, large-scale distributed service system R&D enterprises generally adopt project iteration and rotate several R&D environments to support project development. Each R&D environment contains various resources, including database server resources, PaaS service node resources, cache server resources, file server resources, etc. Therefore, large R&D enterprises have a large demand for resources.

[0061] PaaS is an abbreviation for Platform as a Service. It refers to a business model that provides a server platform as a service, delivering applications over the network. SaaS (Software as a Service) is one of the three service models of cloud computing. In the cloud computing era, the provision of server platforms or development environments as services constitutes PaaS (Platform as a Service).

[0062] A file server, also known as an archive server, is a file storage device accessible to all users in a computer network environment. It's a specialized computer designed for other computers to retrieve and store files. File servers typically have larger storage capacities than regular personal computers and offer additional features such as disk mirroring, multiple network interface cards, and hot-standby power supplies. File servers have evolved into high-performance systems with RAID storage subsystems and other high-availability features. File servers enhance storage capabilities and simplify network data management. This improves system performance and data availability while reducing management complexity and lowering operating costs.

[0063] Caching server: Caching refers to a technology that stores frequently accessed network content in a system closer to the user and with faster access speed, thereby improving content access speed. A caching server is a server that stores frequently accessed content.

[0064] When configuring service resources for large-scale distributed service systems, existing technologies primarily verify resource usage based on the registered usage period during resource requests. If the operations and maintenance personnel do not request an extension, resources are automatically reclaimed. Alternatively, technical detection is used to monitor the CPU, memory, and disk usage of these resources. If particularly inefficient resources are found, a warning is issued to the relevant operations and maintenance personnel. If the personnel do not object, the resources are reclaimed within a certain timeframe. However, when configuring service resources using these methods, the lack of identification of specific business scenarios leads to coarse-grained resource configuration, resulting in either complete resource reclamation or complete non-reclamation. Resource configuration tailored to specific business scenarios often relies more on the experience of operations and maintenance personnel for fine-grained operations. For example, in a test scenario where a critical service node container is running on a resource but the resource utilization is low, simply reclaiming the resource would cause the test scenario link to break, preventing full-link testing. Conversely, not reclamating the resource would result in significant resource idleness. Therefore, this application provides a distributed service resource configuration method. By matching the corresponding resource allocation strategy to configure service resources based on the call status of the distributed service to the target service node container on the virtual machine and the service nature of the service node container, the method is based on the actual business scenario. The method automatically configures server resources according to the call frequency and service nature of the distributed service to the service node container. On the one hand, it makes the resource configuration more objective and in line with the needs of the business scenario. On the other hand, it reduces the workload of operation and maintenance personnel and improves the configuration efficiency of distributed system service resources in multiple dimensions.

[0065] Figure 1 This is a schematic diagram of the structure of the distributed system provided in the embodiments of this application, such as... Figure 1As shown, the distributed system provided in this application embodiment includes a distributed service resource configuration device 100 and a distributed system. The distributed system includes a physical machine cluster with virtual machines 300. The physical machine cluster includes multiple physical machines 200. Service node containers for distributed services are configured on the virtual machines 300.

[0066] The following uses the distributed service resource configuration device 100 as an example to illustrate the implementation process of the distributed service resource configuration method provided in this application embodiment. It is understood that the execution subject of the distributed service resource configuration method provided in this application embodiment includes, but is not limited to, the distributed service resource configuration device.

[0067] According to one aspect of this application, this embodiment discloses a method for configuring distributed service resources. For example... Figure 2 As shown, in this embodiment, the method includes:

[0068] S100: Determine the call data for the target service node containers on each virtual machine for the distributed service settings;

[0069] S200: Determine the call frequency of each target service node container based on the call data, and determine the corresponding resource allocation strategy based on the call frequency and the service nature of the target service node container on each virtual machine;

[0070] S300: Update the number of service node containers and corresponding physical machines of the virtual machines of the distributed service according to the resource allocation strategy, and configure the distributed service on the updated physical machines.

[0071] This application configures service resources by matching the corresponding resource allocation strategy based on the call frequency and service nature of the target service node container on the virtual machine by the distributed service. The distributed service resource configuration method of this application can automatically configure server resources based on the actual business scenario and the call frequency and service nature of the distributed service to the service node container. On the one hand, it makes the resource configuration more objective and in line with the needs of the business scenario, and on the other hand, it reduces the workload of operation and maintenance personnel, thus improving the configuration efficiency of distributed system service resources in multiple dimensions.

[0072] In alternative implementations, such as Figure 3 As shown, step S100 determines the call data of the target service node container set on each virtual machine for the distributed service, including:

[0073] S110: Determine the target monthly version based on the current time;

[0074] S120: Determine the distributed service whose resource configuration needs to be updated based on the target monthly version and the service identifier of the distributed service, wherein the service identifier of the distributed service includes the monthly version and the service name;

[0075] S130: Obtain the call data of the target service node container on each virtual machine for the distributed service settings of the resource configuration to be updated.

[0076] Specifically, to statistically analyze the calls made by each distributed service to specific service node containers and thus objectively reflect resource utilization, this embodiment selects the target monthly version of the distributed service to be analyzed based on the current time. The target monthly version is pre-set and can be divided by month. For example, by setting the target monthly version to include January, February, March…December, the variable application parameters used in different months can be distinguished by the target monthly version. In other examples, those skilled in the art can also set the target monthly version of the variable application parameters according to actual circumstances. For example, the effective time of the target monthly version can be limited by the effective start date and end date. This application does not limit the setting of the target monthly version.

[0077] In a preferred embodiment, determining the target monthly version based on the current time includes: determining the months included in a preset time period before and after the current time to obtain the target monthly version.

[0078] To more accurately define the monthly versions of various distributed services included in the target monthly version, and to reduce the impact of monthly versions that are about to be taken offline and / or those that are about to be launched on the statistical results of the call status of the target service node container, for example, the February monthly version is the version that mainly provides services. Therefore, when calculating the call status, the time period of the target monthly version is first selected as the entire month of February. Based on this, considering that the January monthly version is about to be taken offline and the March monthly version has varying degrees of call status to the target service node container during online testing, the time range of the target monthly version is set to January-March.

[0079] In this embodiment, the target monthly version extends the current time range forward and backward by a preset time, and statistically analyzes the calls of distributed services of multiple monthly versions to the target service node container within the entire time period, thereby improving the accuracy of step S100 in determining the call data of the target service node container set on each virtual machine for distributed services.

[0080] In an optional implementation, the step of determining the corresponding resource allocation strategy based on the call frequency and the service nature of the target service node container on each virtual machine in S200 includes:

[0081] If the sum of the call frequencies of all target service node containers on the virtual machine is a high-frequency call, the resource allocation strategy of the virtual machine is determined to be a resource expansion strategy.

[0082] If the sum of the call frequencies of all target service node containers on the virtual machine is low-frequency call and there are target service node containers that make critical service calls, then the resource allocation strategy of the virtual machine is determined to be a resource scaling-down strategy.

[0083] If the sum of the call frequencies of all target service node containers on the virtual machine is low-frequency call and there are no target service node containers that call critical services, then the resource allocation strategy of the virtual machine is determined to be a resource reclamation strategy.

[0084] In order to overcome the problem that the existing technology has a coarse resource allocation and low accuracy due to the lack of identification of special scenarios, this embodiment takes the situation of various business scenarios as a factor to consider when formulating resource allocation strategies.

[0085] Specifically, when the total call frequency of all target service node containers on the virtual machine is high-frequency, it indicates that the user has a great demand for a specific distributed service and needs server resources to provide services to the outside world in a large and continuous manner. In order to ensure that the distributed service can call server resources smoothly, the virtual machine needs to be scaled up to increase the number of service node containers of the corresponding virtual machine.

[0086] When the total call frequency of all target service node containers on a virtual machine is low-frequency, but there are target service node containers calling critical services, the existing resource allocation method ignores the factor of the target node server being called, only considering the low total call frequency, and adopts a resource allocation strategy of reclaiming all service node containers on the virtual machine. However, if a test scenario is encountered where a critical service node container is running on the resource, but the resource utilization is low, simply reclaiming the resource will cause the test scenario link to break, making it impossible to conduct full-link testing. If the resource is not reclaimed, a large amount of resource will be idle. To address this situation, in order to refine the resource allocation strategy, this embodiment first ensures that the service resources called by the critical service can continuously provide services. On this basis, according to the call frequency, the virtual machine is scaled down to reduce the number of service node containers on the corresponding virtual machine, but not all resources of the virtual machine are reclaimed. While ensuring the stability of the distributed system, service resources are rationally allocated, improving resource allocation efficiency.

[0087] In the business scenario of personal settlement applications within the banking system, different services have varying degrees of importance. Therefore, it is necessary to categorize services according to their business functions. The key service calls mentioned during resource configuration are divided into five categories, and the list of key services is as follows:

[0088] 1- Door opening and closing transactions in this application.

[0089] 2- Core functions that will cause bottlenecks in the testing of this application.

[0090] 3. Services / interfaces that upstream and downstream applications need to call for door opening and closing transactions.

[0091] 4- Services / interfaces that may cause bottlenecks in testing of upstream and downstream applications.

[0092] 5- Checkpoints that can cause pain points in testing.

[0093] These five types of key services are indispensable in business scenario verification, and it is necessary to focus on ensuring the server resources for these five types of key services to provide services to the outside world.

[0094] In other business scenarios, the key service calls can be set by those skilled in the art as needed, and this application does not limit this.

[0095] If the sum of the call frequencies of all target service node containers on a virtual machine is low-frequency and there are no target service node containers that call critical services, it indicates that the current virtual machine is called by services at a low frequency and there is no service that must be continuously provided to the outside world. At this time, the virtual machine can be recycled and the released service resources can be allocated to other virtual machines with high service call frequencies.

[0096] In alternative implementations, such as Figure 4 As shown, the resource allocation strategy is a resource expansion strategy. In step S300, updating the number of service node containers and corresponding physical machines of the virtual machines of the distributed service according to the resource allocation strategy includes:

[0097] S310a: Determine the number of target containers required for the virtual machine based on the sum of the call frequencies of all target service node containers on the virtual machine and the standard call frequency of the service node containers;

[0098] S320a: Update the number of service node containers supported by the virtual machine according to the target number of containers;

[0099] S330a: Determine the updated physical machine based on the updated number of service node containers.

[0100] Specifically, the total call frequency of all target service node containers on the virtual machine in S310a is the total call volume of all distributed services configured on the virtual machine to the service node containers. The total call frequency is compared with a preset standard. If it exceeds a certain standard, it can be considered that the current service has a large demand for resources and a resource allocation strategy for expansion needs to be adopted.

[0101] The standard call frequency of the service node container refers to the appropriate call frequency that the service node can bear in order to prevent the service node container from experiencing abnormal load. Those skilled in the art can also set this according to the actual situation. This application does not limit the setting of the target monthly version.

[0102] Based on the total call frequency required by the distributed services deployed on the virtual machine and the standard call frequency of the service node containers, the number of service node containers required to ensure that the distributed services can smoothly and continuously call service resources in large quantities can be determined, and the number of service node containers supported by the virtual machine can be updated.

[0103] Correspondingly, since the number of service node containers supported by the physical machine deploying the virtual machine virtual environment is limited by its hardware conditions, after updating the number of service node containers supported by the virtual machine, the configuration of the physical machine it depends on also needs to be updated and adjusted. If the number of service node containers supported by the physical machine before the update is less than the number of service node containers supported by the virtual machine after the update, then a new physical machine needs to be configured.

[0104] Figure 5 This is a schematic diagram illustrating the node container invocation situation provided in one embodiment, such as... Figure 5 As shown, taking a monthly version of the personal settlement application in the banking system as an example, the overall call volume of the node containers increased significantly over a period of time. For instance, the total call volume of service node container ats-1-1 and service node container ats-30-1 both exceeded 4000 transactions per day. Furthermore, the service AtsCardCheck is a critical service of type 4 (which can cause bottlenecks in upstream and downstream application testing), and the service AtsCardOpen is a critical service of type 1 (the opening and closing transaction of this application). Therefore, the service resources of service node container ats-1-1 need to ensure that server resources can continuously provide services. In other words, the overall service call volume of the entire virtual machine 1 is very high, requiring scaling up. The specific operation is as follows:

[0105] 1. Adjust the service deployment on virtual machine 1, reducing the number of service deployments per service node container and increasing the number of service node containers based on the total call frequency required by the distributed services. For example, if virtual machine 1 currently has 30 service node containers, after the service deployment adjustment, increase it to 40 service node containers.

[0106] 2. Adjust the resource quota of virtual machine 1 to support a maximum of 50 service node containers.

[0107] 3. Based on the resource allocation rule that each 16C32G host machine can support 25 service node containers, virtual machine 1 originally required two physical machines, 122.132.23.AA and 122.132.23.BB. If these two physical machines are not used by other users, the resource requirements of virtual machine 1 can continue to be met. If these two physical machines are still used by other users, it is necessary to consider configuring an additional physical machine for virtual machine 1.

[0108] In alternative implementations, such as Figure 6 As shown, the resource allocation strategy is a resource scaling-down strategy. In step S300, updating the number of service node containers and corresponding physical machines of the virtual machines of the distributed service according to the resource allocation strategy includes:

[0109] S310b: Delete the target service node containers on the virtual machine that are not critical service calls to obtain the number of target containers after the virtual machine is scaled down.

[0110] S320b: Update the number of service node containers supported by the virtual machine corresponding to the distributed service based on the target number of containers;

[0111] S330b: Determine the updated physical machine based on the updated number of service node containers.

[0112] When the total call frequency of all target service node containers on a virtual machine is low-frequency, but there are target service node containers calling critical services, the existing resource allocation method ignores the factor of the target node server being called, only considering the low total call frequency, and adopts a resource allocation strategy of reclaiming all service node containers on the virtual machine. However, if a test scenario is encountered where a critical service node container is running on the resource, but the resource utilization is low, simply reclaiming the resource will cause the test scenario link to break, making it impossible to conduct full-link testing. If the resource is not reclaimed, a large amount of resource will be idle. To address this situation, in order to refine the resource allocation strategy, this embodiment first ensures that the service resources called by the critical service can continuously provide services. On this basis, according to the call frequency, the virtual machine is scaled down to reduce the number of service node containers on the corresponding virtual machine, but not all resources of the virtual machine are reclaimed. While ensuring the stability of the distributed system, service resources are rationally allocated, improving resource allocation efficiency.

[0113] Specifically, in this embodiment, based on a preset list of critical services, node containers on the virtual machine that are called by other distributed services outside the list of critical services are deleted, thereby releasing service resources. The number of remaining service node containers deployed on the virtual machine after deleting the above-mentioned service node containers is the target number of containers after the virtual machine is scaled down. The number of service node containers supported by the virtual machine is updated based on the target number of containers after scaling down.

[0114] Correspondingly, since the number of service node containers supported by the physical machine deploying the virtual machine virtual environment is limited by its hardware conditions, after updating the number of service node containers supported by the virtual machine, it is also necessary to update and adjust the configuration of the physical machine it depends on. If the virtual machine before the update depends on multiple physical machines, while the updated virtual machine only needs a portion of the service resources of one physical machine to run stably, then the service resources of other physical machines are released.

[0115] In alternative implementations, such as Figure 7 As shown, in step S300, updating the number of service node containers and corresponding physical machines of the virtual machines of the distributed service according to the resource allocation strategy further includes:

[0116] S340b: Determine the total number of service node containers on all virtual machines after the distributed service update;

[0117] S350b: Determine whether the virtual machines of the distributed service need to be merged based on the total number of service node containers and the number of physical machines corresponding to the distributed service;

[0118] S360b: If so, re-determine the updated virtual machine corresponding to the distributed service, and configure the distributed service on the physical machine corresponding to the updated virtual machine.

[0119] Specifically, after implementing a resource scaling-down configuration strategy for the service node containers on the virtual machines, the number of service node containers on all virtual machines deployed for the distributed service is reduced. Consequently, there are idle service node containers on the physical machines to which the virtual machines depend.

[0120] To further release service resources and optimize resource allocation efficiency, in this embodiment, there are idle service node containers on the physical machines corresponding to the scaled-down virtual machines. To improve utilization, after determining the total number of service node containers for all virtual machines deployed in the distributed service, if the number of service node containers called by a certain virtual machine is less than the number of idle service node containers on the physical machines of the scaled-down virtual machines, then the two virtual machines are merged, thereby making full use of the idle service node containers on the physical machines corresponding to the scaled-down virtual machines, and correspondingly releasing the service resources of the other physical machine.

[0121] Figure 8 This is a schematic diagram illustrating the node container invocation situation provided in one embodiment, such as... Figure 8 As shown, taking a monthly version of a personal settlement application in a banking system as an example, the service node container has critical services with low call volume. Service AtsCardCheck is a type 4 service / interface that could cause bottlenecks in upstream and downstream application testing; service AtsCardOpen is a type 1 service—a critical service for opening and closing transactions in this application. Therefore, the service resources of service node container ats-1-1 need to ensure that server resources can continuously provide services. However, the overall service call volume of virtual machine 1 is low; for example, the average daily call volume of service AtsCardPay is 1 transaction / day. The resource elastic allocation system will scale down virtual machine 1. The specific operation is as follows:

[0122] 1. Adjust the service deployment on virtual machine 1, increasing the number of service deployments per service node container and decreasing the number of service node containers. For example, if virtual machine 1 currently has 30 service node containers, after the service deployment adjustment, reduce it to 20 service node containers.

[0123] 2. Adjust the resource quota of virtual machine 1 to support a maximum of 25 service node containers.

[0124] 3. Based on the resource allocation rule that each 16C32G physical machine can support 25 service node containers, virtual machine 1 originally required two physical machines, 122.132.23.AA and 122.132.23.BB. Now, only one physical machine needs to be used. For example, if the physical machine with IP 122.132.23.AA is still used, the physical machine with IP 122.132.23.BB is returned, thereby realizing the scaling down of virtual machine 1.

[0125] 4. If at this time, another virtual machine 2 only needs to call 5 service node containers, since the scaled-down virtual machine 1 only needs 20 service node containers, and each 16C32G physical machine can support 25 service node containers, then virtual machine 1 and virtual machine 2 can be merged to make full use of the physical machine service resources of virtual machine 1 and release the service resources occupied by virtual machine 2.

[0126] In an optional implementation, updating the number of service node containers supported by the virtual machine corresponding to the distributed service based on the target number of containers includes:

[0127] The number of service node containers supported by the virtual machine is determined based on the maximum value between the target number of containers and the number of service node containers supported by the physical machine.

[0128] Specifically, due to hardware limitations, physical machines can only support a specific number of service node containers, such as 25 or 50.

[0129] The minimum number of target containers required for the distributed service deployed on the virtual machine is taken as the minimum number of service node containers supported by the virtual machine. The maximum number of service node containers supported by the virtual machine is determined based on the maximum number of service node containers supported by the physical machine. For example, the maximum number of service node containers supported by the virtual machine can be an integer multiple of the maximum number of service node containers supported by the physical machine. Those skilled in the art can set it as needed, and this application does not make specific limitations here.

[0130] For example, if the target number of containers is 20 and the maximum number of service node containers supported by a physical machine is 25, then the maximum number of service node containers supported by a virtual machine can also be 25. In this case, configuring a physical machine for the virtual machine is sufficient. This ensures that the number of service node containers supported by the virtual machine can meet the target number of containers required by the distributed service, and also improves the utilization efficiency of physical machine resources.

[0131] In an optional implementation, the resource allocation strategy is a resource reclamation strategy, and step S300, which updates the number of service node containers of the virtual machine of the distributed service and the physical machine corresponding to the virtual machine according to the resource allocation strategy, includes:

[0132] Delete the virtual machine corresponding to the distributed service.

[0133] Specifically, in this embodiment, based on a preset list of key services, the distributed services that call virtual machines are service node containers are checked. If it is confirmed that there are no key services in the list of key services and the total call frequency of all target service node containers on the virtual machine is low frequency, the virtual machines corresponding to these distributed services are deleted and the released service resources are reclaimed.

[0134] Figure 9 This is a schematic diagram illustrating the node container invocation situation provided in one embodiment, such as... Figure 9 As shown, taking a monthly version of the personal settlement application in the banking system as an example, the service node container does not have critical services and has a low call volume. For example, the daily average call volume of the service AcsCardBind is 0 times / day, and the daily average call volume of the service AcsCardClose is 1 time / day. Therefore, virtual machine 2 is recycled. The specific operation is as follows:

[0135] 1. Adjust the service deployment on virtual machine 2, remove services with zero calls and no long-term use, and redeploy them when there are special project requirements, thereby reducing the number of service node containers on virtual machine 2.

[0136] 2. Adjust the service deployment on virtual machine 1, and deploy the adjusted service node containers of virtual machine 2 to virtual machine 1. For example, if virtual machine 1 currently has 30 service node containers, after the service deployment adjustment, it will increase to 45 service node containers, of which the 15 added service node containers are the original service node containers deployed on virtual machine 2 after the service adjustment.

[0137] 3. Based on the resource allocation rule that each 16C32G physical machine can support 25 service node containers, the two physical machines originally used by virtual machine 1 can continue to support 45 service node container resources for virtual machine 1.

[0138] 4. Perform resource reclamation on virtual machine 2, and also perform resource reclamation on the two physical machines originally used by virtual machine 2.

[0139] In one implementation, configuring the distributed service on the updated physical machine in step S300 includes:

[0140] Configure the service node containers corresponding to the updated number of service node containers on the virtual machine of the distributed service onto the physical machine.

[0141] Specifically, the updated number of service node containers refers to the number of service node containers on a virtual machine after implementing resource configuration policies for scaling up, scaling down, or recycling virtual machines. Based on this number, physical machines are configured for the virtual machines to provide the corresponding service resources.

[0142] Based on the same principle, this application also discloses a distributed service resource configuration device. For example... Figure 10 As shown, the device includes a call data determination module 11, a strategy configuration module 12, and a parameter update module 13.

[0143] Among them, the call data determination module 11 is used to determine the call data of the target service node container set on each virtual machine for the distributed service;

[0144] The strategy configuration module 12 is used to determine the call frequency of each target service node container based on the call data, and to determine the corresponding resource allocation strategy based on the call frequency and the service nature of the target service node container on each virtual machine.

[0145] The parameter update module 13 is used to update the number of service node containers and the corresponding physical machines of the virtual machines of the distributed service according to the resource allocation strategy, and to configure the distributed service on the updated physical machines.

[0146] Since the principle by which this device solves the problem is similar to the methods described above, the implementation of this device can be found in the implementation of the methods, and will not be repeated here.

[0147] This application also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described method.

[0148] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0149] Those skilled in the art will understand that the embodiments of this application can be provided as methods, systems, or computer programs, producing the systems, apparatuses, modules, or units described in the above embodiments. Specifically, they can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer device; specifically, a computer device can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0150] In a typical example, the computer device specifically includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the method executed by the client as described above, or the method executed by the server as described above.

[0151] The following is for reference. Figure 11 It shows a schematic diagram of the structure of a computer device 600 suitable for implementing the embodiments of this application.

[0152] like Figure 11 As shown, the computer device 600 includes a central processing unit (CPU) 601, which can perform various appropriate tasks and processes based on programs stored in read-only memory (ROM) 602 or programs loaded from storage section 608 into random access memory (RAM) 603. The RAM 603 also stores various programs and data required for system operation. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0153] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal feedback (LCD), etc., and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed in storage section 608 as needed.

[0154] In particular, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program tangibly embodied on a machine-readable medium, the computer program including program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611.

[0155] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0156] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0157] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0158] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0159] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0160] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0161] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0162] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0163] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0164] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for configuring distributed service resources, characterized in that, include: Determine the call data for the target service node containers on each virtual machine for the distributed service settings; The call frequency of each target service node container is determined based on the call data; If the sum of the call frequencies of all target service node containers on the virtual machine is a high-frequency call, the resource allocation strategy of the virtual machine is determined to be a resource expansion strategy. If the sum of the call frequencies of all target service node containers on the virtual machine is low-frequency call and there are target service node containers that make critical service calls, then the resource allocation strategy of the virtual machine is determined to be a resource scaling-down strategy. If the total call frequency of all target service node containers on the virtual machine is low-frequency call and there are no target service node containers that call critical services, then the resource allocation strategy of the virtual machine is determined to be a resource reclamation strategy. According to the resource allocation strategy, update the number of service node containers and the corresponding physical machines of the virtual machines of the distributed service, and configure the distributed service on the updated physical machines.

2. The distributed service resource allocation method according to claim 1, characterized in that, The call data used to determine the target service node container on each virtual machine for the distributed service configuration includes: Determine the target monthly version based on the current time; The distributed service whose resource configuration needs to be updated is determined based on the target monthly version and the service identifier of the distributed service, wherein the service identifier of the distributed service includes the monthly version and the service name; Obtain the call data of the target service node container on each virtual machine for the distributed service settings of the resource configuration to be updated.

3. The distributed service resource configuration method according to claim 2, characterized in that, The determination of the target monthly version based on the current time includes: The target monthly version is obtained by determining the months included in the preset time period before and after the current time.

4. The distributed service resource configuration method according to claim 1, characterized in that, If the resource allocation strategy is a resource expansion strategy, updating the number of service node containers and corresponding physical machines of the virtual machines of the distributed service according to the resource allocation strategy includes: The number of target containers required for the virtual machine is determined based on the sum of the call frequencies of all target service node containers on the virtual machine and the standard call frequency of the service node containers. Update the number of service node containers supported by the virtual machine corresponding to the distributed service based on the target number of containers. The updated physical machine is determined based on the updated number of service node containers.

5. The distributed service resource configuration method according to claim 1, characterized in that, If the resource allocation strategy is a resource scaling-down strategy, updating the number of service node containers and corresponding physical machines of the virtual machines of the distributed service according to the resource allocation strategy includes: Delete the target service node containers on the virtual machine that are not critical service calls to obtain the number of target containers after the virtual machine is scaled down. Update the number of service node containers supported by the virtual machine corresponding to the distributed service based on the target number of containers. The updated physical machine is determined based on the updated number of service node containers.

6. The distributed service resource configuration method according to claim 5, characterized in that, Further includes: Determine the total number of service node containers on all virtual machines after the distributed service update; The decision on whether the virtual machines of the distributed service need to be merged is determined based on the total number of service node containers and the number of physical machines corresponding to the distributed service. If so, re-determine the updated virtual machine corresponding to the distributed service, and configure the distributed service on the physical machine corresponding to the updated virtual machine.

7. The distributed service resource configuration method according to any one of claims 4-6, characterized in that, The step of updating the number of service node containers supported by the virtual machine corresponding to the distributed service based on the target number of containers includes: The number of service node containers supported by the virtual machine is determined based on the maximum value between the target number of containers and the number of service node containers supported by the physical machine.

8. The distributed service resource configuration method according to claim 1, characterized in that, If the resource allocation strategy is a resource reclamation strategy, updating the number of service node containers and the physical machine corresponding to the virtual machine of the distributed service according to the resource allocation strategy includes: Delete the virtual machine corresponding to the distributed service.

9. The distributed service resource configuration method according to claim 1, characterized in that, The step of configuring the distributed service onto the updated physical machine includes: Configure the service node containers corresponding to the updated number of service node containers on the virtual machine of the distributed service onto the physical machine.

10. A distributed service resource configuration device, characterized in that, include: The call data determination module is used to determine the call data of the target service node containers on each virtual machine for the distributed service settings. The strategy configuration module is used to determine the call frequency of each target service node container based on the call data; if the sum of the call frequencies of all target service node containers on the virtual machine is a high-frequency call, the resource allocation strategy of the virtual machine is determined to be a resource expansion strategy; if the sum of the call frequencies of all target service node containers on the virtual machine is a low-frequency call and there are target service node containers making critical service calls, the resource allocation strategy of the virtual machine is determined to be a resource reduction strategy; if the sum of the call frequencies of all target service node containers on the virtual machine is a low-frequency call and there are no target service node containers making critical service calls, the resource allocation strategy of the virtual machine is determined to be a resource reclamation strategy. The parameter update module is used to update the number of service node containers and the corresponding physical machines of the virtual machines of the distributed service according to the resource allocation strategy, and to configure the distributed service on the updated physical machines.

11. A distributed service resource allocation system, characterized in that, The system includes the distributed service resource configuration device and distributed system as described in claim 10, wherein the distributed system includes a physical machine cluster equipped with virtual machines, the physical machine cluster includes multiple physical machines, and the virtual machines are equipped with service node containers for distributed services.

12. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 9.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 9.

Images