Service deployment method and device, storage medium and electronic device

Abstract

The present invention discloses a service deployment method and device, a storage medium and an electronic device. The method comprises: obtaining historical load data of multiple services, wherein the multiple services are used to provide real-time interaction, and the historical load data comprises: load data collected at multiple historical moments; based on the historical load data of each service, predicting the load time series change trend of each service; based on the load time series change trend of the multiple services, deploying some or all of the multiple services on the same server. The present invention solves the technical problem of low resource utilization of online service deployment solutions in related technologies.

Description

Technical Field

[0001] The present invention relates to the field of computers, and in particular to a service deployment method and device, a storage medium and an electronic device. Background Art

[0002] In the financial industry, due to the particularity of financial business in terms of legal compliance, for different business directions such as payment, insurance, credit, funds, wealth management, and financial technology, it is necessary to physically isolate the service programs and data of different businesses. That is, the servers between different businesses need to be placed in different computer rooms, and the programs between different businesses cannot be mixed. The direct communication of different data leads to a small number of offline loads for some businesses, and it is impossible to effectively improve resource utilization through offline mixing.

[0003] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0004] The embodiments of the present invention provide a service deployment method and device, a storage medium and an electronic device, so as to at least solve the technical problem of low resource utilization of online service deployment solutions in related technologies.

[0005] According to one aspect of an embodiment of the present invention, a service deployment method is provided, comprising: obtaining historical load data of multiple services, wherein the multiple services are used to provide real-time interaction, and the historical load data comprises: load data collected at multiple historical moments; based on the historical load data of each service, predicting a time series change trend of the load of each service; based on the time series change trend of the load of the multiple services, deploying some or all of the multiple services on the same server.

[0006] Optionally, based on the historical load data of each service, predicting the load time series change trend of each service includes: determining the weight value of each load data in the historical load data; based on the weight value of each load data, obtaining the weighted average value of the load data collected at the same historical moment, and obtaining the load mean values ​​at multiple historical moments; fitting the load mean values ​​at multiple historical moments to obtain the load time series change trend.

[0007] Optionally, the weight value of each load data is determined based on the distance between the historical collection time of each load data and the current time.

[0008] Optionally, based on the load time series variation trends of multiple services, deploying some or all of the multiple services on the same server includes: determining the type of each service based on the load time series variation trends of each service, wherein the type is used to characterize the differences in the load data of the current service in different time periods; based on the types of multiple services, deploying some or all of the multiple services on the same server.

[0009] Optionally, based on the load timing change trend of each service, determining the type of each service includes: determining the load average within a first time period and the load average within a second time period based on the load timing change trend of the current service, wherein the first time period is later than the second time period; obtaining the ratio of the load average within the first time period to the load average within the second time period; and obtaining the type of the current service based on a comparison result of the ratio with a preset interval.

[0010] Optionally, based on the comparison result between the ratio and the preset interval, the type of the current service is obtained, including: when the ratio is within the preset interval, determining the type as the first type; when the ratio is less than the minimum value of the preset interval, determining the type as the second type; when the ratio is greater than the maximum value of the preset interval, determining the type as the third type.

[0011] Optionally, based on the types of multiple services, deploying some or all of the multiple services on the same server includes: evenly deploying the first type of services on multiple servers; determining the target services to be deployed on the same server based on the load timing change trends of the second type of services and the third type of services, wherein the target services include: at least one second type of service, at least one third type of service, and the volatility of the load data of the target services is minimal; and deploying the target services on the same server.

[0012] Optionally, when multiple services of the second type are deployed on the same server, the method also includes: if it is detected that the traffic of the same server is greater than a first preset value, determining the first service according to the priority of the multiple services of the second type; determining the target server among other servers based on the load time series change trend of the first service, wherein the variance between the traffic of the first service and the traffic of the target server is minimized; migrating the first service to the target server, and scheduling the traffic of the first service to the target server.

[0013] Optionally, when multiple services of the second type are deployed on the same server, the method further includes: if it is detected that the load of a second service among the multiple services of the second type is greater than a second preset value, starting an instance corresponding to the second service on other servers.

[0014] Optionally, obtaining historical load data of multiple services includes: obtaining resource quantity data corresponding to multiple instances corresponding to each service; and superimposing the resource quantity data corresponding to the multiple instances to obtain historical load data of each service.

[0015] According to another aspect of an embodiment of the present invention, a service deployment device is also provided, including: an acquisition module, used to obtain historical load data of multiple services, wherein the multiple services are used to provide real-time interaction, and the historical load data includes: load data collected at multiple historical moments; a prediction module, used to predict the load time series change trend of each service based on the historical load data of each service; and a deployment module, used to deploy part or all of the multiple services on the same server based on the load time series change trend of the multiple services.

[0016] Optionally, the prediction module includes: a weight determination unit, used to determine the weight value of each load data in the historical load data; a mean acquisition unit, used to obtain the weighted average value of the load data collected at the same historical moment based on the weight value of each load data, and obtain the load mean value of multiple historical moments; a fitting unit, used to fit the load mean values ​​of multiple historical moments to obtain the load time series change trend.

[0017] Optionally, the weight determination unit is further configured to determine the weight value of each load data based on the distance between the historical collection time of each load data and the current moment.

[0018] Optionally, the deployment module includes: a type determination unit, used to determine the type of each service based on the time series change trend of the load of each service, wherein the type is used to characterize the difference in the load data of the current service in different time periods; and a deployment unit, used to deploy part or all of the multiple services on the same server based on the types of the multiple services.

[0019] Optionally, the type determination unit is also used to: determine the load average within a first time period and the load average within a second time period based on the load timing change trend of the current service, wherein the first time period is later than the second time period; obtain the ratio of the load average within the first time period to the load average within the second time period; and obtain the type of the current service based on the comparison result of the ratio with a preset interval.

[0020] Optionally, the type determination unit is also used to: when the ratio is within a preset interval, determine the type as the first type; when the ratio is less than the minimum value of the preset interval, determine the type as the second type; when the ratio is greater than the maximum value of the preset interval, determine the type as the third type.

[0021] Optionally, the deployment unit is also used to: evenly deploy services of the first type on multiple servers; determine target services deployed on the same server based on the load time series change trends of the second type of services and the third type of services, wherein the target services include: at least one service of the second type, at least one service of the third type, and the volatility of the load data of the target services is minimal; and deploy the target services on the same server.

[0022] Optionally, in the case where multiple services of the second type are deployed on the same server, the device also includes: a priority determination module, used to determine the first service according to the priorities of multiple second-type services if it is detected that the traffic of the same server is greater than a first preset value; a server determination module, used to determine the target server among other servers based on the load time series change trend of the first service, wherein the variance between the traffic of the first service and the traffic of the target server is minimized; and a migration module, used to migrate the first service to the target server and schedule the traffic of the first service to the target server.

[0023] Optionally, when multiple second-type services are deployed on the same server, the device further includes: a starting module, configured to start an instance corresponding to the second service on other servers if it is detected that the load of a second service among the multiple second-type services is greater than a second preset value.

[0024] Optionally, the acquisition module includes: a data acquisition unit, used to acquire resource quantity data corresponding to multiple instances corresponding to each service; and a superposition unit, used to superimpose the resource quantity data corresponding to the multiple instances to obtain historical load data of each service.

[0025] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided. The computer-readable storage medium includes a stored program, wherein when the program is running, the device where the computer-readable storage medium is located is controlled to execute the service deployment method in the above embodiment.

[0026] According to another aspect of an embodiment of the present invention, an electronic device is provided, including: a processor and a memory, wherein the processor is used to run a program stored in the memory, wherein the service deployment method in the above embodiment is executed when the program is run.

[0027] In an embodiment of the present invention, by obtaining the historical load data of multiple services, and then predicting the load time series change trend of each service based on the historical load data of each service, and then based on the load time series change trend of multiple services, some or all of the multiple services are deployed on the same server to achieve the purpose of service colocation. It is easy to notice that by predicting the load time series change trend of online services, based on the differences in predicted load characteristics, finer-grained segmentation and scheduling are performed for different online service loads, real-time intelligent traffic scheduling is performed, and complementary colocation of online services is achieved, so that the use of fewer machines can be achieved, greater peak traffic carrying capacity can be obtained, and better resource utilization can be improved, thereby solving the technical problem of low resource utilization of online service deployment solutions in related technologies. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0029] Figure 1 is a flow chart of a service deployment method according to an embodiment of the present invention;

[0030] Figure 2 is a schematic diagram of an optional service scheduling scenario according to an embodiment of the present invention;

[0031] Figure 3 is a schematic diagram of an optional load data collection scenario according to an embodiment of the present invention;

[0032] Figure 4 is a schematic diagram of a service deployment device according to an embodiment of the present invention; DETAILED DESCRIPTION

[0033] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0034] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0035] First, the technical terms appearing in the embodiments of the present invention are explained as follows:

[0036] Program: can be run on computer terminals, mobile terminals and other devices, and has specific functions. For example, an APP on a mobile phone is a program.

[0037] Service: includes one or more programs that can be accessed by users inside or outside the company and provide users with one or several functions.

[0038] Server: The computer device on which the program runs, which can provide hardware resources such as CPU, memory, disk, network, GPU, etc. for the program to use.

[0039] Online service: A service used to provide real-time interaction to users. It needs to quickly respond to user operation requests and return results. For example, when a user scans a code to pay, it needs to immediately return whether the user has paid successfully and the amount deducted.

[0040] Offline service: It is used to provide non-real-time interactive services. It only needs to return the results within a longer period of time. For example, the daily income of current financial management and the deduction service of automatic renewal only need to be completed on the same day.

[0041] Load: The hardware resources such as CPU, memory, and disk used when the service is running will change with the traffic.

[0042] Currently, the existing technology provides the following service colocation methods:

[0043] Solution 1: Online service co-location + offline service co-location method, directly increases the number of programs running on a single server to improve the average utilization of machine resources. Since online services require higher real-time response speed, and direct co-location of online services with offline services will affect online services, online and offline services are isolated: that is, only online services or only offline services exist on a server at the same time. However, this solution simply co-locates online services with online services and offline services with offline services, without more sophisticated scheduling and management through load prediction, making it difficult to effectively achieve time-sharing complementarity of service loads, and there is little room for improving co-location resource utilization.

[0044] Solution 2: Online service co-location + offline service co-location + whole machine peak avoidance method. Since the busyness of online services depends on the user's living habits, for example, during the daytime on weekdays, users will scan code to pay more frequently, but rarely at night and in the early morning. When the service is busy or idle, the corresponding resources used will also be busy or idle. The busyness and busy hours of offline services can be controlled by programmers to a certain extent. Therefore, when the online service is idle, the online service programs on some servers can be taken offline and the offline service programs can be started instead to make use of the idle resources; and when the online service is approaching the busy period, the reverse operation is performed, the offline service programs are taken offline and the online service programs are started instead. In this way, the whole machine peak avoidance is realized to improve the overall resource utilization rate. However, the financial industry has the most stringent compliance requirements, and servers of different business lines must be physically isolated and deployed; due to different businesses, the scale ratio of online and offline is also different. For real-time interactive businesses, because there are fewer offline services, there is little room for improving resource utilization by simply avoiding peak hours on the whole machine.

[0045] Solution 3: Offline colocation based on load prediction, which uses resource isolation to colocate online and offline services on the same server. The load of online services is predicted through machine learning, reinforcement learning and other technologies. The available resources of the machine are calculated based on the prediction results. The upper limit of resources that can be used by offline services is customized by time according to the predicted available resources. When the load exceeds the prediction, the offline colocation service is temporarily shut down to avoid resources. However, due to the physical isolation of the servers of the business lines, offline tasks can no longer be conveniently scheduled globally. Some business lines will inevitably lack sufficient offline services, and the room for improving resource utilization is limited.

[0046] As can be seen from the above, existing colocation methods, such as direct online colocation, have limited improvement in resource utilization. Online and offline avoidance and offline colocation require sufficiently large-scale offline services that can be scheduled for colocation. These methods have certain limitations in financial scenarios and cannot meet the needs of colocation.

[0047] In order to solve the above problems, according to an embodiment of the present invention, a service deployment method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0048] Figure 1 is a flow chart of a service deployment method according to an embodiment of the present invention. Figure 1 As shown, the method comprises the following steps:

[0049] Step S102, obtaining historical load data of multiple services, wherein the multiple services are used to provide real-time interaction, and the historical load data includes: load data collected at multiple historical moments.

[0050] When meeting financial compliance requirements, due to strict business isolation, the number of offline loads of some businesses is small, and it is impossible to effectively improve resource utilization through offline colocation. It is necessary to further improve the resource utilization of pure online colocation by optimizing the online service colocation mode and traffic scheduling scheme. Therefore, the service in the embodiment of the present invention refers to online services in the financial field.

[0051] The multiple services in the above steps may be multiple online services that need to be deployed in a hybrid manner. The specific service types may be set according to actual deployment requirements, and the present invention does not specifically limit this.

[0052] The load change of the service is related to the user's usage behavior, and is often regular in units of weeks. The historical moments in the above steps may refer to multiple moments in a day, such as 00:00, 04:00, 8:00, 12:00, 16:00, 20:00, etc., but are not limited thereto and can be set according to the specific situation of the service.

[0053] In an optional embodiment, each service can start an instance on a different server to provide services externally. Therefore, the resource usage data actually used by each service over a period of time (such as 8 weeks) can be collected from a server that has multiple services running, to obtain the historical load data of each service, wherein the resource usage data of multiple services are collected at the same time on the same day.

[0054] Step S104: Based on the historical load data of each service, the time series change trend of the load of each service is predicted.

[0055] The load time series variation trend in the above steps can be the variation of the load over time within a day obtained by fitting, that is, the load time series variation trend can reflect the difference in load time periods, and the load peak time can be accurately determined through the load time series variation trend.

[0056] In the embodiment of the present invention, historical load data of different services can be modeled and predicted to obtain the time series change trend of load of different services. Specifically, polynomial fitting, linear regression and other models can be used for modeling. In terms of effectiveness, polynomial fitting has better effect. Therefore, the polynomial fitting model is used in the embodiment of the present invention.

[0057] Step S106: deploy part or all of the multiple services on the same server based on the load time series variation trend of the multiple services.

[0058] In an embodiment of the present invention, after predicting the load timing variation trends of different services, one or more services with different and complementary peak time characteristics can be screened out from all services based on the peak time characteristics of all services, and the screened services can be deployed in a mixed manner on the same server, so that in the same server, different services will have load peaks at different times, thereby improving the resource utilization of the server.

[0059] It should be noted that the deployment in the above steps may refer to deploying an instance of the service on the server and starting it, or starting an instance that has been deployed, but is not limited thereto.

[0060] Through the above steps, we can take advantage of the fact that the traffic of regular business in the financial industry will not peak at the same time, predict the time series change trend of the load of online services, and realize complementary co-location of online services based on the differences in the predicted load characteristics, so as to achieve the use of fewer machines, obtain greater peak traffic carrying capacity, and better resource utilization, thereby solving the technical problem of low resource utilization of online service deployment solutions in related technologies.

[0061] Optionally, based on the historical load data of each service, predicting the load time series change trend of each service includes: determining the weight value of each load data in the historical load data; based on the weight value of each load data, obtaining the weighted average value of the load data collected at the same historical moment, and obtaining the load mean values ​​at multiple historical moments; fitting the load mean values ​​at multiple historical moments to obtain the load time series change trend.

[0062] Since the load change of services in the financial field is easily affected by time, for historical load data, the closer the data is to the current moment, the higher the influence is, that is, the newer the data, the higher the influence is, and the older the data, the lower the influence is. In an embodiment of the present invention, the weight value of each load data can be determined based on the distance between the historical collection time of each load data and the current moment, wherein the closer the historical collection time is to the current moment, the higher the influence of the load data is, and thus the greater the weight value of the load data is.

[0063] In an optional embodiment, for each service, the load mean value P(t) at each time in a week can be calculated based on historical load data by the following formula:

[0064] ;

[0065] Among them, L(t) represents the load data at each time t, Q(t) represents the weight value of the load data L(t), that is, the attenuation coefficient, and T represents one week.

[0066] At this point, the load mean is still a series of discrete data, which needs to be smoothed using a polynomial fitting algorithm. With the load as the vertical axis and the relative time within a week as the horizontal axis, the load mean within a week is fitted into a polynomial according to the following formula to obtain the load time series change trend:

[0067] ;

[0068] in, Indicates the load timing change trend, N represents the highest power of the polynomial, Indicates the fitting coefficient corresponding to the current power n.

[0069] It should be noted that the load of some or all of the multiple services after co-location can be obtained by directly superimposing the time series change trends of the load of some or all of the services.

[0070] By introducing the attenuation coefficient of different load data, the influence of historical data on the prediction results is reasonably retained, and the load prediction model is calculated using a polynomial fitting algorithm to achieve good superposition calculation performance.

[0071] Optionally, based on the load time series variation trends of multiple services, deploying some or all of the multiple services on the same server includes: determining the type of each service based on the load time series variation trends of each service, wherein the type is used to characterize the differences in the load data of the current service in different time periods; based on the types of multiple services, deploying some or all of the multiple services on the same server.

[0072] In an embodiment of the present invention, the core goal of service colocation and refined traffic scheduling is to make the resource utilization rate of the machine fluctuate as little as possible and as high as possible. Therefore, services can be divided into multiple types according to the time series change trend of the load of different services, and can be specifically divided according to the specific circumstances of the financial services. In an embodiment of the present invention, services can be divided into three types, among which the first type indicates that the difference in the load data of the service in different time periods is small, that is, the load averages of different time periods are equivalent; the second type indicates that the load data of the service is higher during the day than at night, that is, users usually use the service during the day, such as the scan code payment service; the third type indicates that the load data of the service is higher at night than during the day, that is, users usually use the service at night.

[0073] After service classification, you can use the following colocation strategies to deploy multiple services to achieve the core goals:

[0074] Strategy 1: For the first type of services, no additional scheduling is required and they can be deployed roughly evenly on all servers.

[0075] Strategy 2: For type 2 and type 3 services, complementary co-location is performed. Type 2 and type 3 services are deployed on the same server at the same time. The specific services deployed on the server can be determined based on the superposition results of the load time series change trend to ensure that the load volatility variance is minimized.

[0076] Strategy 3: Since most online services belong to the second type, strategy 2 alone cannot meet the needs of the entire online service colocation, and colocation between second type services is also required. Before colocation, services can be divided according to their performance priority; during colocation, the following principles need to be followed: second type services with higher service performance priority should be deployed as stably as possible to reduce the frequency of scheduling; second type services with lower service performance priority are used to schedule traffic to achieve peak load shifting.

[0077] For example, taking five services (service a, service b, service c, service d, and service e) deployed on two servers (server A and server B) as an example, based on the load time series change trend of the five services, it can be determined that service a belongs to the first type, service b and service e belong to the second type, and service c and service d belong to the third type. Then service a can be deployed on both server A and server B. According to the load time series change trend of service b, service c, service d, and service e, service b and service c can be deployed on server A, and service d and service e can be deployed on server B.

[0078] By co-locating different types of services according to pre-set policies, we can tap the potential of online service co-location and improve overall resource utilization while ensuring service performance requirements.

[0079] Optionally, based on the load timing change trend of each service, determining the type of each service includes: determining the load average within a first time period and the load average within a second time period based on the load timing change trend of the current service, wherein the first time period is later than the second time period; obtaining the ratio of the load average within the first time period to the load average within the second time period; and obtaining the type of the current service based on a comparison result of the ratio with a preset interval.

[0080] The first time period in the above steps may be a night time period, such as 20:00-08:00, and the second time period may be a day time period, such as 08:00-20:00. The specific time period division may be determined according to actual service conditions.

[0081] In an optional embodiment, after obtaining the load time series change trend of the current service, the load average of the first time period can be counted, and the load average of the second time period can be counted, and then the ratio of the load averages of the two time periods can be calculated. The load period difference of the current service can be determined, and the type of the current service can be obtained.

[0082] By pre-dividing online services into multiple types according to load period characteristics and using static deployment of different types of services, the effect of service colocation can be more effectively improved and resource utilization can be increased.

[0083] Optionally, based on the comparison result between the ratio and the preset interval, the type of the current service is obtained, including: when the ratio is within the preset interval, determining the type as the first type; when the ratio is less than the minimum value of the preset interval, determining the type as the second type; when the ratio is greater than the maximum value of the preset interval, determining the type as the third type.

[0084] The preset interval in the above steps can be set according to the actual service type classification requirements. The ratio within this interval represents that the load time periods are not very different. For example, the preset interval can be 0.5-1.5, but is not limited thereto.

[0085] In an optional embodiment, if the ratio of the load average of the first time period to the load average of the second time period is within a preset interval (such as the night load average is between 0.5-1.5 of the daytime load average), it indicates that the load average of the first time period is not much different from the load average of the second time period, and the type of the service can be determined to be the first type; if the ratio of the load average of the first time period to the load average of the second time period is less than the minimum value of the preset interval (such as the night load average is between 0-0.5 of the daytime load average), it indicates that the load average of the first time period is lower than the load average of the second time period, and the type of the service can be determined to be the second type; if the ratio of the load average of the first time period to the load average of the second time period is greater than the maximum value of the preset interval (such as the night load average is more than 1.5 of the daytime load average), it indicates that the load average of the first time period is higher than the load average of the second time period, and the type of the service can be determined to be the third type.

[0086] Optionally, based on the types of multiple services, deploying some or all of the multiple services on the same server includes: evenly deploying the first type of services on multiple servers; determining the target services to be deployed on the same server based on the load timing change trends of the second type of services and the third type of services, wherein the target services include: at least one second type of service, at least one third type of service, and the volatility of the load data of the target services is minimal; and deploying the target services on the same server.

[0087] In an embodiment of the present invention, based on a pre-set co-location strategy, services of the first type can be evenly deployed on all servers; for services of the second and third types, complementary co-location can be performed based on the load timing change trends of the second and third types of services, and the second and third types of services can be deployed on the same server at the same time. The specific services deployed on the server can be determined based on the superposition results of the load timing change trends, ensuring that the load volatility variance is minimized.

[0088] Optionally, when multiple services of the second type are deployed on the same server, the method also includes: if it is detected that the traffic of the same server is greater than a first preset value, determining the first service according to the priority of the multiple services of the second type; determining the target server among other servers based on the load time series change trend of the first service, wherein the variance between the traffic of the first service and the traffic of the target server is minimized; migrating the first service to the target server, and scheduling the traffic of the first service to the target server.

[0089] The first preset value in the above step may be a preset upper limit of the peak value of resource usage, which may be specifically set according to the actual situation of the server.

[0090] In an optional embodiment, for a server deployed with multiple second-type services, after the services are deployed, a prediction and calculation can be performed on the hourly service scheduling plan according to the hourly dimension. The calculation principle is as follows: the deployment of services with higher priority remains unchanged, and the traffic is normally evenly scheduled; the target server that needs to be migrated is determined by superimposing the prediction model for services with lower priority. When it is detected that the traffic of the server is greater than the first preset value, it can be determined that an unexpected traffic surge has occurred on the server. In order to improve the peak traffic carrying capacity of the server, all second-type services can be screened in order from low to high priority, and the first service that needs to be migrated is determined, and then the first service is migrated to other servers. The specific migration plan is as follows: The prediction model can be superimposed to calculate each server one by one to determine the target server with the smallest traffic variance, and the first service can be deployed to the target server, and the traffic of the first service can be simultaneously scheduled to the target server.

[0091] For example, Figure 2Taking the scenario shown as an example, service a, service b, and service c are deployed on server A and server B. The load of all services on server A and server B can be monitored through service load modeling. For each service, modeling is performed based on the resource volume data collected in real time and historical data to predict the load time series change trend, and the scheduling strategy is fed back to the traffic proportion balancing scheduler. The traffic proportion balancing scheduler migrates low-priority services to other servers according to the performance priorities of the three services. For example, service c on server A is migrated to server C, and the load of service c is scheduled to server C, so that the load of a part of online services at different times will be controlled and scheduled to different servers, so as to achieve the goal of improving overall resource utilization.

[0092] By pre-dividing online services into multiple layers of priority according to performance priority requirements, using dynamic scheduling of services with different priorities, and using lower-level services as mobile loads, the optimal scheduling destination can be quickly calculated through the load prediction model to achieve real-time automatic scheduling of loads and peak shaving and valley filling between online services. In scenarios with fewer offline services, resource utilization can be further improved, the peak elasticity of the system can be improved, and server costs can be saved.

[0093] Optionally, when multiple services of the second type are deployed on the same server, the method further includes: if it is detected that the load of a second service among the multiple services of the second type is greater than a second preset value, starting an instance corresponding to the second service on other servers.

[0094] The second preset value in the above steps can be set according to actual needs. When the load of the service is greater than the second preset value, it indicates that the load of the service is too large.

[0095] In an optional embodiment, for a service whose single instance is overloaded, a proportional expansion method is used to start instances of the service on other servers and proportionally dispatch part of the load to other servers, thereby maintaining load predictability after expansion, breaking up the large load, and improving the overall traffic peak carrying capacity.

[0096] For example, Figure 2Taking the scenario shown as an example, service a, service b, and service c are deployed on both server A and server B. Service load modeling can be used to monitor the load of all services on server A and server B. For each service, modeling is performed based on the resource volume data collected in real time and historical data to predict the load time series change trend, and the scheduling strategy is fed back to the traffic proportion balancing scheduler. The capacity is expanded proportionally through the traffic proportion balancing scheduler. For example, an instance of service b is started on server C, and part of the load of service b is scheduled to server C, so that the load of a part of the online service at different times will be controlled and scheduled to different servers, so as to achieve the goal of improving the overall resource utilization.

[0097] Through elastic expansion of peak traffic, online service deployment has good practical application capabilities, realizes real-time automatic scheduling of loads, and achieves peak shaving and valley filling between online services.

[0098] Through the above two scheduling schemes, different online service loads can be segmented and scheduled in a more fine-grained manner, and real-time intelligent traffic scheduling can be performed to obtain greater peak traffic carrying capacity and better resource utilization.

[0099] Optionally, obtaining historical load data of multiple services includes: obtaining resource quantity data corresponding to multiple instances corresponding to each service; and superimposing the resource quantity data corresponding to the multiple instances to obtain historical load data of each service.

[0100] Each service can start multiple instances at the same time, and the multiple instances run on multiple servers. Through traffic scheduling, the load can be forwarded to all instances to ensure that the service can be provided normally. In an optional embodiment, a service load data collection tool can be used to collect the actual resource usage data of each instance in real time, and by superimposing the resource usage data of all instances, the historical load data of the entire service can be obtained.

[0101] For example, Figure 3As shown, instances of service a, service b and service c are running on server A and server B, wherein the instances running on server A are: instance 1, instance 2 and instance 3, and the instances running on server B are instance 4, instance 5 and instance 6. Therefore, the resource quantity data of instance 1 and instance 4 can be collected in real time, and then the resource quantity data of instance 1 and instance 4 are superimposed to obtain the historical load data of service a, thereby achieving the purpose of service a load collection; the resource quantity data of instance 2 and instance 5 are collected in real time, and then the resource quantity data of instance 2 and instance 5 are superimposed to obtain the historical load data of service b, thereby achieving the purpose of service b load collection; the resource quantity data of instance 3 and instance 6 are collected in real time, and then the resource quantity data of instance 3 and instance 6 are superimposed to obtain the historical load data of service c, thereby achieving the purpose of service c load collection.

[0102] According to an embodiment of the present invention, a service deployment device is also provided, which can execute the service deployment method in the above embodiment. The specific implementation scheme and application scenario are the same as those in the above embodiment and will not be repeated here.

[0103] Figure 4 is a schematic diagram of a service deployment device according to an embodiment of the present invention. Figure 4 As shown, the device comprises:

[0104] The acquisition module 42 is used to acquire historical load data of multiple services, wherein the multiple services are used to provide real-time interaction, and the historical load data includes: load data collected at multiple historical moments.

[0105] The prediction module 44 is used to predict the time series change trend of the load of each service based on the historical load data of each service.

[0106] The deployment module 46 is used to deploy part or all of the multiple services on the same server based on the time series change trend of the load of the multiple services.

[0107] Optionally, the prediction module includes: a weight determination unit, used to determine the weight value of each load data in the historical load data; a mean acquisition unit, used to obtain the weighted average value of the load data collected at the same historical moment based on the weight value of each load data, and obtain the load mean value of multiple historical moments; a fitting unit, used to fit the load mean values ​​of multiple historical moments to obtain the load time series change trend.

[0108] Optionally, the weight determination unit is further configured to determine the weight value of each load data based on the distance between the historical collection time of each load data and the current moment.

[0109] Optionally, the deployment module includes: a type determination unit, used to determine the type of each service based on the time series change trend of the load of each service, wherein the type is used to characterize the difference in the load data of the current service in different time periods; and a deployment unit, used to deploy part or all of the multiple services on the same server based on the types of the multiple services.

[0110] Optionally, the type determination unit is also used to: determine the load average within a first time period and the load average within a second time period based on the load timing change trend of the current service, wherein the first time period is later than the second time period; obtain the ratio of the load average within the first time period to the load average within the second time period; and obtain the type of the current service based on the comparison result of the ratio with a preset interval.

[0111] Optionally, the type determination unit is also used to: when the ratio is within a preset interval, determine the type as the first type; when the ratio is less than the minimum value of the preset interval, determine the type as the second type; when the ratio is greater than the maximum value of the preset interval, determine the type as the third type.

[0112] Optionally, the deployment unit is also used to: evenly deploy services of the first type on multiple servers; determine target services deployed on the same server based on the load time series change trends of the second type of services and the third type of services, wherein the target services include: at least one service of the second type, at least one service of the third type, and the volatility of the load data of the target services is minimal; and deploy the target services on the same server.

[0113] Optionally, in the case where multiple services of the second type are deployed on the same server, the device also includes: a priority determination module, used to determine the first service according to the priorities of multiple second-type services if it is detected that the traffic of the same server is greater than a first preset value; a server determination module, used to determine the target server among other servers based on the load time series change trend of the first service, wherein the variance between the traffic of the first service and the traffic of the target server is minimized; and a migration module, used to migrate the first service to the target server and schedule the traffic of the first service to the target server.

[0114] Optionally, when multiple second-type services are deployed on the same server, the device further includes: a starting module, configured to start an instance corresponding to the second service on other servers if it is detected that the load of a second service among the multiple second-type services is greater than a second preset value.

[0115] Optionally, the acquisition module includes: a data acquisition unit, used to acquire resource quantity data corresponding to multiple instances corresponding to each service; and a superposition unit, used to superimpose the resource quantity data corresponding to the multiple instances to obtain historical load data of each service.

[0116] According to an embodiment of the present invention, a computer-readable storage medium is further provided. The computer-readable storage medium includes a stored program, wherein when the program is running, the device where the computer-readable storage medium is located is controlled to execute the service deployment method in the above embodiment.

[0117] According to an embodiment of the present invention, there is also provided an electronic device, including: a processor and a memory, wherein the processor is used to run a program stored in the memory, wherein the service deployment method in the above embodiment is executed when the program is run.

[0118] In the above embodiments of the present invention, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0119] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0120] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0121] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0122] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or optical disk, etc. Various media that can store program codes.

[0123] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A service deployment method, characterized in that: include: Acquire historical load data of multiple services, wherein the multiple services are used to provide real-time interaction, and the historical load data includes: load data collected at multiple historical moments; Based on the historical load data of each service, predict the time series change trend of the load of each service; Based on the load time series variation trend of the multiple services, deploy some or all of the multiple services on the same server; In the case where a plurality of services of the second type are deployed on the same server, wherein the services of the second type are services whose load average in a first time period is lower than the load average in a second time period, and the first time period is later than the second time period, the method further includes: If it is detected that the traffic of the same server is greater than a first preset value, determining the first service according to the priorities of the multiple services of the second type; Determine a target server among other servers based on a time series change trend of the load of the first service, wherein a variance between the flow of the first service and the flow of the target server is minimal; The first service is migrated to the target server, and the traffic of the first service is scheduled to the target server.

2. The method according to claim 1, characterized in that The predicting of the load time series variation trend of each service based on the historical load data of each service includes: Determine a weight value of each load data in the historical load data; Based on the weight value of each load data, a weighted average value of the load data collected at the same historical moment is obtained to obtain the load mean values ​​of the multiple historical moments; The load mean values ​​at the multiple historical moments are fitted to obtain the load time series variation trend.

3. The method according to claim 2, characterized in that The weight value of each load data is determined based on the distance between the historical collection time of each load data and the current time.

4. The method according to claim 1, characterized in that: The deploying part or all of the multiple services on the same server based on the load time series variation trends of the multiple services includes: Determine the type of each service based on the load time series variation trend of each service, wherein the type is used to characterize the difference of the load data of the current service in different time periods; Based on the types of the multiple services, some or all of the multiple services are deployed on the same server.

5. The method according to claim 4, characterized in that The determining the type of each service based on the load time series variation trend of each service includes: Determine the load average value in the first time period and the load average value in the second time period based on the load time series variation trend of the current service; Obtaining a ratio of the load average value in the first time period to the load average value in the second time period; Based on the comparison result of the ratio and the preset interval, the type of the current service is obtained.

6. The method according to claim 5, characterized in that The obtaining of the type of the current service based on the comparison result of the ratio and the preset interval includes: When the ratio is within the preset interval, determining the type to be the first type; When the ratio is less than the minimum value of the preset interval, determining the type to be the second type; When the ratio is greater than the maximum value of the preset interval, the type is determined to be the third type.

7. The method according to claim 6, characterized in that The deploying part or all of the multiple services on the same server based on the types of the multiple services includes: Deploy the first type of services evenly on multiple servers; Determine a target service deployed on the same server based on the load time series variation trends of the second type of service and the third type of service, wherein the target service includes: at least one service of the second type and at least one service of the third type, and the volatility of the load data of the target service is minimal; Deploy the target service on the same server.

8. The method according to claim 6, characterized in that In the case where a plurality of services of the second type are deployed on the same server, the method further comprises: If it is detected that the load of a second service among the multiple services of the second type is greater than a second preset value, an instance corresponding to the second service is started on other servers.

9. The method according to any one of claims 1 to 8, characterized in that Get historical load data for multiple services including: Get resource quantity data corresponding to multiple instances of each service; The resource quantity data corresponding to the multiple instances are superimposed to obtain the historical load data of each service.

10. A service deployment device, characterized in that: include: An acquisition module, used to acquire historical load data of multiple services, wherein the multiple services are used to provide real-time interaction, and the historical load data includes: load data collected at multiple historical moments; A prediction module, used to predict the load time series change trend of each service based on the historical load data of each service; A deployment module, configured to deploy some or all of the multiple services on the same server based on a time series change trend of the loads of the multiple services; In the case where multiple services of the second type are deployed on the same server, wherein the load average of the second type of service in a first time period is lower than the load average of a second time period, and the first time period is later than the second time period, the deployment module is further used to determine the first service according to the priority of the multiple services of the second type if it is detected that the traffic of the same server is greater than a first preset value; determine a target server among other servers based on the load time series change trend of the first service, wherein the variance between the traffic of the first service and the traffic of the target server is minimized; migrate the first service to the target server, and schedule the traffic of the first service to the target server.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein when the program is executed, the device where the computer-readable storage medium is located is controlled to execute the service deployment method according to any one of claims 1 to 9.

12. An electronic device, characterized in that: include: A processor and a memory, wherein the processor is used to run a program stored in the memory, wherein the program executes the service deployment method described in any one of claims 1 to 9 when running.

Images