Service preheating method and device, computer device and readable storage medium

Abstract

The application relates to the technical field of big data, and particularly discloses a service preheating method and device, computer equipment and a readable storage medium. The method comprises the following steps: after a service instance is started, a service directory registration request of the service instance is intercepted through an aspect, it is judged whether the service directory registration request is a first request, in the case that the service directory registration request is the first request, the traffic weight of the service instance is configured as a first weight, and a timing preheating task is started, in the case that the running time length of the timing preheating task reaches a preset preheating time length threshold, the registration state of the service instance is reset to an unregistered state, so that the service directory registration of the service instance is initiated again, the service directory registration request of the service instance is intercepted again through the aspect, the traffic weight of the service instance is configured as a second weight, and the second weight is higher than the first weight. The method can improve the reliability of the service.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of big data, and in particular, relates to a service preheating method and device, a computer device, a computer readable storage medium and a computer program product. BACKGROUND

[0002] With the development of Internet technology and e-commerce, the scale and complexity of distributed data processing systems are increasing. In order to ensure that these systems can operate efficiently and reliably, the industry uses a technology called service directory to manage distributed components and services. As a centralized management mechanism, the service directory is responsible for collecting and maintaining information about each service instance, including but not limited to the location, status and configuration of the service. Currently, during the startup process of a transaction service, the service directory registration information of the application configuration is usually loaded, and related data such as registered components and their traffic control strategies are registered on the service directory.

[0003] However, once the service is deployed and registered, the existing service directory solution fixes the ability to handle requests (i.e., the maximum traffic it can withstand). New online or restarted services may directly face full volume of user requests without sufficient time to prepare resources, which may lead to increased response delay or even service interruption, reducing the reliability of the service. SUMMARY

[0004] Therefore, it is necessary to provide a service preheating method, device, computer device, computer readable storage medium and computer program product with higher reliability to solve the above technical problems.

[0005] In a first aspect, the present application provides a service preheating method, comprising:

[0006] After the service instance is started, the service directory registration request of the service instance is intercepted through an aspect, and it is determined whether the service directory registration request is a first request;

[0007] In the case where the service directory registration request is a first request, the traffic weight of the service instance is configured as a first weight, and a timing preheating task is started;

[0008] In the case where the running duration of the timing preheating task reaches a preset preheating duration threshold, the registration state of the service instance is reset to an unregistered state, so that the service directory registration of the service instance is initiated again;

[0009] The service directory registration request of the service instance is intercepted again through the aspect, the traffic weight of the service instance is configured as a second weight, and the second weight is higher than the first weight.

[0010] In one of the embodiments, the method further comprises:

[0011] monitoring a performance indicator of the service instance after the service instance is started;

[0012] adjusting a traffic configuration of the service instance according to the performance indicator and a preset traffic adjustment rule.

[0013] In one of the embodiments, the performance indicator comprises a response time, an error rate and a throughput; and the adjusting the traffic configuration of the service instance according to the performance indicator and the preset traffic adjustment rule comprises:

[0014] increasing the traffic weight of the service instance if the response time is lower than a preset response time threshold;

[0015] decreasing the traffic weight of the service instance if the error rate is higher than a preset error rate threshold;

[0016] increasing the traffic weight of the service instance if the throughput is lower than a preset throughput threshold.

[0017] In one of the embodiments, the method further comprises:

[0018] obtaining a service state and a performance indicator of the service instance after the service instance is started;

[0019] calling a trained warm-up duration prediction model with the service state and the performance indicator as inputs to determine a target warm-up duration required for the service instance to reach an optimal performance, the warm-up duration prediction model being trained based on historical service states, historical performance indicators and warm-up durations of service instances;

[0020] adjusting a preset warm-up duration threshold of the service instance based on the target warm-up duration.

[0021] In one of the embodiments, the method further comprises:

[0022] obtaining historical performance data of the service instance after the service instance is deployed multiple times;

[0023] predicting a warm-up duration required for the service instance to run stably based on the historical performance data;

[0024] determining a warm-up duration threshold of the service instance according to the predicted warm-up duration.

[0025] In one of the embodiments, the method further comprises:

[0026] if an abnormal event is detected during a warm-up process of the service instance, triggering a rollback operation to redirect traffic of the service instance to a service instance of a previous version.

[0027] In a second aspect, the present application also provides a service preheating device, comprising:

[0028] A request interception module is configured to, after a service instance is started, intercept a service directory registration request of the service instance through an aspect, and determine whether the service directory registration request is a first request;

[0029] A first traffic configuration module is configured to, in a case where the service directory registration request is the first request, configure a traffic weight of the service instance as a first weight, and start a timing preheating task;

[0030] A registration state resetting module is configured to, in a case where a running time length of the timing preheating task reaches a preset preheating time length threshold, reset a registration state of the service instance to an unregistered state, so that the service instance initiates service directory registration again;

[0031] A second traffic configuration module is configured to, through the aspect, intercept the service directory registration request of the service instance again, and configure the traffic weight of the service instance as a second weight, the second weight being higher than the first weight.

[0032] In a third aspect, the present application also provides a computer device, comprising a memory and a processor, the memory storing a computer program, and the processor realizing steps in any one of the service preheating method embodiments when executing the computer program.

[0033] In a fourth aspect, the present application also provides a computer readable storage medium, storing a computer program, the computer program realizing steps in any one of the service preheating method embodiments when executed by a processor.

[0034] In a fifth aspect, the present application also provides a computer program product, comprising a computer program, the computer program realizing steps in any one of the service preheating method embodiments when executed by a processor.

[0035] The service preheating method, device, computer equipment, computer readable storage medium and computer program product can reduce the possibility that the service faces a large number of requests and causes performance bottleneck or failure when the service instance is not completely ready, and can start the timing preheating task, so that the service instance starts preheating, and automatically resets the registration state of the service instance to the unregistered state after the preheating duration reaches the preheating duration threshold, so that the service instance initiates the service directory registration request again, and the traffic weight of the service instance is configured to the second higher weight, that is, the large flow request is opened, so that the service instance that has completed preheating can efficiently process the request. In the whole process, the server is controlled to change from low traffic to higher traffic through the timing preheating task and the resetting of the service registration state, so that the service has a smooth transition period, only a small amount of traffic request is received in the preheating phase, the phenomenon of system instability or high delay caused by sudden large flow is reduced, the reliability and response speed of the service are improved, and the flexibility and resource utilization of the system are improved. BRIEF DESCRIPTION OF DRAWINGS

[0036] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related art, the drawings needed to be used in the description of the embodiments of the present application or the related art will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other related drawings can also be obtained without creative labor on the basis of these drawings.

[0037] Figure 1 The flowchart of the service preheating method in one embodiment is shown.

[0038] Figure 2 The flowchart of the service preheating method in another embodiment is shown.

[0039] Figure 3 The flowchart of the service preheating method in another embodiment is shown.

[0040] Figure 4 The flowchart of the service preheating method in another embodiment is shown.

[0041] Figure 5 The flowchart of the service preheating method in one embodiment is shown.

[0042] Figure 6 The detailed flowchart of the service preheating method in one embodiment is shown.

[0043] Figure 7 Structure block diagram of a service preheating device in one embodiment;

[0044] Figure 8 Structure block diagram of a service preheating device in another embodiment;

[0045] Figure 9 Internal structure diagram of a computer device in one embodiment. DETAILED DESCRIPTION

[0046] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application is further described in detail below in combination with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and do not limit the present application. It should be noted that in the embodiments of the present application, some software, components, models and other industry existing solutions may be mentioned, which should be considered as exemplary, and the purpose is only to illustrate the feasibility of the technical solution implementation of the present application, but does not mean that the applicant has or will necessarily use the solution.

[0047] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant regulations. The acquisition, storage, use, processing and other data in the technical solution of the present application comply with the relevant regulations of national laws and regulations.

[0048] In one embodiment, as shown in Figure 1 A service preheating method is provided, and the present embodiment is exemplified by the method applied to a server. It should be understood that the method can also be applied to a terminal, and can also be applied to a system including a terminal and a server, and is realized through the interaction of the terminal and the server. In the present embodiment, the method includes the following steps:

[0049] S202, after the service instance is started, the service directory registration request of the service instance is intercepted through the aspect, and it is judged whether the service directory registration request is a first request.

[0050] Aspect refers to an AOP (Aspect-Oriented Programming) aspect, which is a programming paradigm that allows cross-cutting concerns (such as logging, performance monitoring, etc.) to be separated from business logic. In this embodiment, the aspect is used to intercept service directory registration requests and determine whether the service directory is a first request. A service instance is a running copy of a service program that can handle client requests. A service directory is a centralized registry that stores information about all available service instances, helping other services or clients discover and connect to these services.

[0051] For example, in actual application, when a new order processing service instance starts, the OpenConsole driver service instance attempts to initiate a registration request to the service directory. In this process, the AOP aspect is triggered and intercepts the registration request. The aspect can check whether this is the first attempt by the service instance to register. Specifically, it can check whether there is a record of the service instance in the database or cache. If there is, it means that the service instance is not registering for the first time. Otherwise, it means that the service instance is registering for the first time.

[0052] S204, if the service directory registration request is a first request, configure the traffic weight of the service instance as a first weight, and start a timing warm-up task.

[0053] Traffic weight refers to the proportion of requests allocated to a specific service instance for processing. For example, if a service instance has a traffic weight of 5%, it will only handle 5% of all requests. The timing warm-up task is a pre-set task that performs certain operations after a pre-set period of time, such as resetting the service state.

[0054] In the case where the service instance is registering for the first time, the traffic weight of the service instance can be set to a lower first weight, such as 5%, to limit the number of requests received by the service instance initially. At the same time, a timing warm-up task is started to perform specific operations when the timing task ends. It can be understood that in other embodiments, the first weight can also be 3%, 6%, and other numerical values, etc., which can be determined according to actual conditions and are not limited to this. If the service instance is not registering for the first time, the service directory registration is performed directly without modifying the traffic configuration of the service instance.

[0055] S206, if the running time of the timing warm-up task reaches the pre-set warm-up time threshold, reset the registration state of the service instance to an unregistered state, so that the service instance initiates service directory registration again.

[0056] In this embodiment, the running time of the timing preheating task can be set to 2 minutes, that is, after the timing preheating task runs for 2 minutes, at this time, the service instance has been preheated for 2 minutes, the registration state of the service instance can be reset to the unregistered state, and then the service instance is unregistered from the service directory. In this way, the service instance can be re-registered and registered with a normal traffic weight. It can be understood that in other embodiments, the preheating time can also be 3 minutes, 1 minute, and other times, etc., which can be determined according to actual conditions and is not uniquely limited here.

[0057] In S208, the service directory registration request of the service instance is intercepted again through the aspect, and the traffic weight of the service instance is configured as a second weight, which is higher than the first weight.

[0058] In this embodiment, the second weight is a higher weight compared to the first weight, that is, the first weight can be understood as a low weight, and the second weight can be understood as a high weight.

[0059] In actual application, if the service state of the service instance is reset to the unregistered state, OpenConsole will detect again that the service instance is unregistered, and drive the service instance to initiate a service directory registration request again. At this time, the AOP aspect intercepts the registration request again, because this request is not the first registration, so a higher second weight (such as 100%) can be directly used for registration, so that the service is ready to handle full traffic. The above method can ensure that the newly started service instance only handles a small amount of requests within the first two minutes, so as to ensure that it has enough resource preparation time. After two minutes, the service instance is fully prepared and can handle full requests. This mechanism helps to improve the stability of the system and user experience. It can be understood that in other embodiments, the second weight can also be 90%, 95%, and 98% and other weights, which can be determined according to actual conditions and is not uniquely limited here.

[0060] The service preheating method, after the service instance is started, intercepts a registration request through an aspect, judges whether the request is a first registration request, sets a traffic weight of the service instance to a first lower weight in a case where the service directory registration request is a first request, can reduce the possibility that the service faces a large number of requests to cause performance bottleneck or failure when the service is not completely ready, starts a timing preheating task, and makes the service instance start preheating. After a preheating duration reaches a preheating duration threshold, the registration state of the service instance is automatically reset to an unregistered state, so that the service instance initiates a service directory registration request again, and the traffic weight of the service instance is configured to a second higher weight, that is, a large traffic request is opened, so that the service instance that has completed preheating can efficiently process requests. Through the timing preheating task and the resetting of the service registration state, the server is controlled to change from low traffic to higher traffic, so that the service has a smooth transition period, only a small amount of traffic requests are received in the preheating phase, the phenomenon of system instability or high delay caused by sudden large traffic is reduced, the reliability and response speed of the service are improved, and the overall flexibility and resource utilization are improved.

[0061] After the service instance is started, the traffic weight can also be dynamically adjusted. In an exemplary embodiment, as shown in FIG. 2B, after S208, the method further includes: Figure 2

[0062] S210, monitoring a performance index of the service instance after the service instance is started.

[0063] S212, adjusting a traffic configuration of the service instance according to the performance index and a preset traffic adjustment rule.

[0064] The performance index is various measurement indexes for measuring the running state of the service instance, such as response time, throughput, error rate, CPU usage, and memory occupation. The response time is the time from sending a request by a client to receiving a response. The throughput is the number of requests processed per unit time. The error rate is the proportion of failed requests. The traffic adjustment rule is a series of rules defined according to the change of the performance index, used to dynamically adjust the traffic weight of the service instance. Exemplarily, these rules can be set based on threshold, trend analysis, or other algorithms.

[0065] ​In practical applications, once a service instance starts, the server continuously monitors its performance metrics, including but not limited to response time, throughput, error rate, CPU utilization, and memory usage. Then, based on preset traffic adjustment rules, it determines whether the performance metrics meet preset performance requirements. If not, the traffic weight of the service instance is adjusted. For example, if the CPU utilization exceeds the expected CPU utilization threshold, such as 80%, the traffic weight is gradually reduced, for example, in 10% increments, to alleviate CPU load.

[0066] In this embodiment, the traffic weight of service instances is dynamically adjusted based on real-time performance indicators to achieve fine-grained traffic control. This allows for more effective use of computing resources, reduces resource waste, and enables services to maintain optimal performance under different load conditions.

[0067] like Figure 3 As shown, in an exemplary embodiment, performance metrics include response time, error rate, and throughput. S212 includes:

[0068] S2122, If the response time is lower than the preset response time threshold, increase the traffic weight of the service instance.

[0069] S2124, If the error rate is higher than the preset error rate threshold, reduce the traffic weight of the service instance.

[0070] S2126, If the throughput is lower than the preset throughput threshold, increase the traffic weight of the service instance.

[0071] In practical applications, preset response time thresholds can be set to 100 milliseconds, preset error rate thresholds to 1%, and preset throughput thresholds to 100 times / second. The server can use monitoring tools to periodically collect the response time, error rate, and throughput of each service instance. Based on preset traffic adjustment rules, it can be determined whether the service instance's performance metrics meet the traffic adjustment conditions; if so, the traffic weights are adjusted.

[0072] For example, when the response time of a service instance is monitored to be below a preset threshold (e.g., 100 ms), it indicates that the service instance can process requests quickly and has enough resources to handle more requests. Therefore, the traffic weight of the service instance can be increased, and the traffic weight in the service directory is updated so that it can receive more requests. If the error rate of a service instance is monitored to be higher than a preset threshold (e.g., 1%), it indicates that the service instance encounters problems in processing requests, which may be due to insufficient resources, configuration errors, or other reasons. In order to prevent further problems, the traffic weight of the service instance can be reduced to reduce its load. If the throughput of a service instance is monitored to be lower than a preset threshold (e.g., 100 times / second), it indicates that the service instance may not fully utilize its processing capacity. In this case, the traffic weight of the service instance can be increased to improve its utilization and overall system performance. It can be understood that the magnitude of each adjustment of the traffic weight described above can be 5%, 10%, or 20% or other values, which are not limited herein.

[0073] For example, assume that the response time of a service instance A is 80 ms, which is lower than the threshold of 100 ms. At this time, the traffic weight of the instance can be increased from 10% to 12%. If the error rate of a service instance B is 1.5%, which is higher than the threshold of 1%, the traffic weight of the instance can be reduced from 10% to 5%. If the throughput of a service instance C is 80 times / second, which is lower than the threshold of 100 times / second, the traffic weight of the instance can be increased from 10% to 12%.

[0074] In this embodiment, the dynamic adjustment of the traffic of the service instance based on the performance indicators not only improves the performance and stability of the system, so that the service instance can run in the best state, but also significantly reduces the user waiting time and error rate caused by service performance problems, improves the user experience, and simplifies the operation and maintenance.

[0075] As shown in FIG. 8, in some exemplary embodiments, after S208, the method further includes: Figure 4

[0076] S214, obtaining the service state and performance indicators after the service instance is started.

[0077] S216, taking the service state and performance indicators as input, calling the trained warm-up time prediction model to determine the target warm-up time required for the service instance to reach the best performance.

[0078] S218, adjusting the preset warm-up time threshold of the service instance based on the target warm-up time.

[0079] ​The service state refers to the current running state of the service instance, including whether it has been registered, whether it is processing a request, whether there is an error, etc. The performance indicators include, but are not limited to, response time, throughput, error rate, resource usage (CPU, memory occupation), etc. The warm-up duration prediction model is a model trained based on machine learning or statistical methods, which is used to predict the time required for the service instance to reach optimal performance from startup. The target warm-up duration is the warm-up time required for the service instance to reach optimal performance calculated according to the warm-up duration prediction model. The warm-up duration threshold is the initially set warm-up duration, which is used for traffic control and warm-up after the service starts.

[0080] In actual application, the operation and maintenance personnel can select a suitable machine learning model for warm-up duration prediction, which can include but is not limited to linear regression module, decision tree model, support vector machine, and neural network, etc. Then, the historical performance indicators and service state data of the service instance after startup are collected from the log files of the service, as well as the corresponding warm-up duration data. Subsequently, the collected data is preprocessed, including missing value processing, outlier processing, standardization, normalization, and feature selection (selecting features that have a significant impact on warm-up duration), etc. Then, the format of the preprocessed data is converted to a format that can be recognized and processed by the machine learning model, and the converted data is input into the selected machine learning model such as the support vector machine model. The model is trained by adjusting the model parameters to improve the model performance, and the trained warm-up duration prediction model is obtained. Subsequently, the performance of the model on new data is verified, and it is deployed to the production environment.

[0081] In specific implementation, when a new service instance starts, the system can continuously monitor its service state and service performance indicators through various monitoring tools and log records. Subsequently, the data format of the collected service state and service performance indicators is converted to the model input format, and the converted data is input into a trained warm-up duration prediction model. The model will predict the target warm-up duration required for the service instance to reach optimal performance according to the input data. After obtaining the target warm-up duration, the server dynamically adjusts the preset warm-up duration threshold of the service instance according to the target warm-up duration, and adjusts the warm-up duration threshold of the service instance according to the target warm-up duration. After the next service instance of the same type starts, the warm-up is performed according to the adjusted warm-up duration threshold.

[0082] In this embodiment, by monitoring the service state and service performance indicators in real time and combining the warm-up duration prediction model, the system can dynamically adjust the warm-up duration, so that the service instance reaches optimal performance in the shortest time, reduces the waste of resources or performance problems caused by excessive or insufficient warm-up time, and can better adapt to the specific circumstances of different service instances.

[0083] In addition to the actual performance of the service instance after starting, the preheating time threshold is dynamically adjusted. In addition, for different types of service instances, the preheating time of the service instance can be determined in advance according to historical data of the service instance. For example Figure 5 As shown in some example embodiments, the method further includes:

[0084] S201, historical performance data of the service instance after multiple deployments is obtained.

[0085] S221, based on the historical performance data, the preheating time required for the service instance to run stably is predicted.

[0086] S241, the preheating time threshold of the service instance is determined according to the predicted preheating time.

[0087] The historical performance data includes performance indicator records of the service instance after multiple deployments, including response time, throughput, error rate, and resource usage, etc. The preheating time refers to the time required for the service instance to reach a stable running state from starting.

[0088] In actual application, the performance indicators of the service instance can be continuously collected during multiple deployments and running of the service instance, the behavior pattern of the service instance is analyzed through these data, and the future performance is predicted. A machine learning model such as a random forest regression model is trained through historical performance data to obtain a preheating time evaluation model, so that the model can predict the preheating time required for the service instance to reach a stable running state according to historical performance data.

[0089] In specific implementation, the historical performance data of the service instance after multiple deployments is collected, the format of the historical performance data is converted into a model input format, the historical performance data is input into the trained preheating time evaluation model, the preheating time is predicted by the model, and then the preheating time predicted by the model is determined as the preheating time threshold of the service instance. In the subsequent service preheating process, the preheating of the service instance is realized through the predicted preheating time.

[0090] In this embodiment, the historical performance data of the service instance is collected, the preheating time required for the service instance to reach a stable running state is predicted, and the preheating time threshold of the service instance is set accordingly, so that each service instance can be ready to handle a large number of requests within the optimal preheating time, reducing user waiting time and error rate, and improving user experience.

[0091] In some example embodiments, the method further includes: during the preheating process of the service instance, if an abnormal event is detected, a rollback operation is triggered to redirect the traffic of the service instance to the service instance of the previous version.

[0092] During the warm-up process of a service instance, various abnormal events may occur, which can cause the newly deployed service instance to malfunction or perform poorly. Common abnormal events include, but are not limited to: response time anomaly: the response time is significantly higher than the expected threshold (e.g., more than 500 milliseconds). High error rate: high error rate when the service instance processes requests (e.g., error rate exceeds 1%). Low throughput: the throughput of the service instance is lower than the expected threshold (e.g., the number of processed requests per second is less than 100). Resource usage anomaly: CPU usage or memory usage exceeds the expected range (e.g., CPU usage continuously exceeds 90%). System crash or hang: the service instance crashes or is unresponsive for a long time. Configuration error: the service fails to start or run due to configuration errors. Dependency service failure: other services or components that the service depends on fail, affecting the normal operation of the service instance.

[0093] During the warm-up process of a service instance, the server continuously monitors the performance indicators and service status of the service instance. If any of the above abnormal events are detected, the system will trigger a rollback operation to redirect traffic to the previous version of the service instance to ensure system stability and availability. Specifically, the rollback operation includes deregistering the new service instance from the service directory, or redistributing traffic to the previous version of the service instance, and recording abnormal information for subsequent analysis and repair.

[0094] In this embodiment, by automatically detecting abnormal events and triggering rollback operations, the service instance can quickly recover to the stable state of the previous version, reducing service interruption time. Moreover, automated rollback operations simplify operations and maintenance, reducing the complexity and error probability of manual rollback.

[0095] As shown in Figure 6 To make the service warm-up method provided by the present application more clearly, the following will be described in combination with a specific embodiment, which includes the following steps:

[0096] S1, after the service instance is started, the service directory registration request of the service instance is intercepted by the aspect, and it is judged whether the service directory registration request is a first request.

[0097] S2, in the case where the service directory registration request is a first request, the traffic weight of the service instance is configured as a first weight, and a timing warm-up task is started.

[0098] S3, in the case where the running time of the timing warm-up task reaches a preset warm-up time threshold, the registration state of the service instance is reset to an unregistered state, so that the service instance initiates service directory registration again.

[0099] S4, re-intercepting the service directory registration request of the service instance through the cut surface, configuring the traffic weight of the service instance as a second weight, the second weight being higher than the first weight.

[0100] S5, monitoring the performance indicators of the service instance after startup, and adjusting the traffic configuration of the service instance according to the performance indicators and a preset traffic adjustment rule.

[0101] For example, when the response time of the service instance is monitored to be lower than a preset threshold (e.g., 100 milliseconds), it indicates that the service instance can quickly process requests and has enough resources to handle more requests. Therefore, the traffic weight of the service instance can be increased, and the traffic weight in the service directory is updated to enable it to receive more requests. If the error rate of the service instance is monitored to be higher than a preset threshold (e.g., 1%), it indicates that the service instance encounters problems in processing requests, which may be due to insufficient resources, configuration errors or other reasons. In order to prevent further problems, the traffic weight of the service instance can be reduced to reduce its load. If the throughput of the service instance is monitored to be lower than a preset threshold (e.g., 100 times / second), it indicates that the service instance may not fully utilize its processing capacity. In this case, the traffic weight of the service instance can be increased to improve its utilization and overall system performance.

[0102] S6, obtaining the service state and performance indicators of the service instance after startup, and calling the trained preheating time prediction model to determine the target preheating time required for the service instance to reach the best performance, using the service state and performance indicators as input.

[0103] S7, adjusting the preset preheating time threshold of the service instance based on the target preheating time.

[0104] S8, during the preheating process of the service instance, if an abnormal event is detected, triggering a rollback operation to redirect the traffic of the service instance to the service instance of the previous version.

[0105] It should be understood that although each step in the flowchart involved in each embodiment as described above is displayed in sequence according to the direction of the arrow, these steps are not necessarily executed in the order indicated by the arrow. Unless otherwise specified herein, the execution of these steps is not strictly limited in sequence, and these steps can be executed in other orders. Moreover, at least part of the steps in the flowchart involved in each embodiment as described above can include multiple steps or stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily sequential, but can be executed in rotation or alternation with at least part of other steps or steps or stages in other steps.

[0106] Based on the same inventive concept, the embodiments of the present application also provide a service preheating device for implementing the service preheating method described above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme described in the above method, so the specific limitations in one or more service preheating device embodiments provided below can refer to the limitations of the service preheating method described above, and will not be repeated here.

[0107] In one exemplary embodiment, as shown in Figure 7 A service preheating device 700 is provided, comprising: a request interception module 710, a first traffic configuration module 720, a registration state resetting module 730, and a second traffic configuration module 740, wherein:

[0108] The request interception module 710 is configured to intercept a service directory registration request of the service instance through an aspect after the service instance is started, and determine whether the service directory registration request is a first request.

[0109] The first traffic configuration module 720 is configured to configure a traffic weight of the service instance as a first weight and start a timing preheating task in a case where the service directory registration request is the first request.

[0110] The registration state resetting module 730 is configured to reset a registration state of the service instance to an unregistered state to make the service instance initiate the service directory registration again in a case where a running time length of the timing preheating task reaches a preset preheating time length threshold.

[0111] The second traffic configuration module 740 is configured to intercept the service directory registration request of the service instance through the aspect again, and configure the traffic weight of the service instance as a second weight, the second weight being higher than the first weight.

[0112] The service preheating apparatus can, after the service instance is started, intercept a registration request through an aspect, judge whether the request is a first registration request, set a traffic weight of the service instance to a first weight which is relatively low in a case that the service directory registration request is a first request, reduce the possibility that the service faces a large number of requests and causes a performance bottleneck or a failure when the service is not completely ready, start a timing preheating task, and make the service instance start preheating. After a preheating duration reaches a preheating duration threshold, the registration state of the service instance is automatically reset to an unregistered state, so that the service instance initiates a service directory registration request again, and the traffic weight of the service instance is configured to a second weight which is relatively high, that is, a large traffic request is opened, so that the service instance that has completed preheating can efficiently process requests. Through the timing preheating task and the resetting of the service registration state, the server is controlled to change from low traffic to relatively high traffic, so that the service has a smooth transition period, only a small amount of traffic requests are received in the preheating phase, the phenomenon of system instability or high delay caused by a sudden large amount of traffic is reduced, the reliability and response speed of the service are improved, and the flexibility and resource utilization of the system are improved.

[0113] As shown in FIG. 7, in an example embodiment, the service preheating apparatus further includes a traffic adjustment module 750 configured to monitor a performance index of the service instance after the service instance is started, and adjust a traffic configuration of the service instance according to the performance index and a preset traffic adjustment rule. Figure 8

[0114] In an example embodiment, the performance index includes a response time, an error rate, and a throughput. The traffic adjustment module 750 is further configured to increase the traffic weight of the service instance in a case that the response time is lower than a preset response time threshold, decrease the traffic weight of the service instance in a case that the error rate is higher than a preset error rate threshold, and increase the traffic weight of the service instance in a case that the throughput is lower than a preset throughput threshold.

[0115] As shown in FIG. 7, in an example embodiment, the service preheating apparatus further includes a preheating duration dynamic adjustment module 760 configured to obtain a service state and a performance index of the service instance after the service instance is started, input the service state and the performance index, call a trained preheating duration prediction model, determine a target preheating duration required for the service instance to reach an optimal performance, and adjust a preset preheating duration threshold of the service instance based on the target preheating duration, wherein the preheating duration prediction model is trained based on historical service states, historical performance indexes, and preheating durations of the service instance. Figure 8

[0116] ​​In an example embodiment, the service preheating apparatus further comprises a preheating duration threshold determination module 702 configured to obtain historical performance data of the service instance after multiple deployments, predict a preheating duration required for stable operation of the service instance based on the historical performance data, and determine a preheating duration threshold of the service instance according to the predicted preheating duration.

[0117] In an example embodiment, the service preheating apparatus further comprises an exception handling module 770 configured to, in the preheating process of the service instance, trigger a rollback operation to redirect traffic of the service instance to a previous version of the service instance if an exception event is detected.

[0118] The modules in the service preheating apparatus described above can be implemented in whole or in part by software, hardware, and combinations thereof. The modules described above can be embedded in or independent of a processor in a computer device in hardware form, or stored in a memory in a computer device in software form, so as to be called and executed by a processor to perform operations corresponding to the modules.

[0119] In an example embodiment, a computer device is provided, which can be a server, and an internal structure diagram of the computer device can be as shown in Figure 9 The computer device includes a processor, a memory, an input / output interface (I / O), and a communication interface. The processor, the memory, and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for running of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is configured to store data such as service instances and performance indicators. The input / output interface of the computer device is configured to exchange information between the processor and external devices. The communication interface of the computer device is configured to communicate with external terminals through a network connection. The computer program is executed by the processor to implement a service preheating method.

[0120] Those skilled in the art can understand that Figure 9 the structure shown in the above

[0121] In an example embodiment, a computer device is provided, comprising a memory and a processor, the memory storing a computer program, the processor implementing the steps in any one of the service warm-up method embodiments when executing the computer program.

[0122] In an example embodiment, a computer readable storage medium is provided, storing a computer program, the computer program implementing the steps in any one of the service warm-up method embodiments when executed by a processor.

[0123] In an example embodiment, a computer program product is provided, comprising a computer program, the computer program implementing the steps in any one of the service warm-up method embodiments when executed by a processor.

[0124] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium, and when executed, can include the processes of the above-mentioned embodiment methods. Any reference to memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. The non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical storage, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. The volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration but not limitation, the RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The database involved in the embodiments provided in the present application can include at least one of a relational database and a non-relational database. The non-relational database can include a distributed database based on a block chain, etc., without being limited thereto. The processor involved in the embodiments provided in the present application can be a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., without being limited thereto.

[0125] The technical features of the above embodiments can be combined in any manner. To make the description concise, all possible combinations of the technical features in the above embodiments are not described, but as long as the combinations of the technical features do not exist, they should be considered as the scope of the present application.

[0126] The above-described embodiments are merely illustrative of several embodiments of the present application, and the description is relatively specific and detailed, but should not be understood as a limitation on the scope of the patent. It should be noted that for those skilled in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are all within the scope of the present application. Therefore, the scope of protection of the present application should be subject to the appended claims.

Claims

1. A service warm-up method characterized by, The method comprises: After the service instance is started, the service directory registration request of the service instance is intercepted through an aspect, and it is judged whether the service directory registration request is a first request; In the case that the service directory registration request is a first request, the traffic weight of the service instance is configured as a first weight, and a timing preheating task is started; In the case that the running time length of the timing preheating task reaches a preset preheating time length threshold, the registration state of the service instance is reset to an unregistered state, so that the service instance initiates the service directory registration again; The service directory registration request of the service instance is intercepted again through an aspect, the traffic weight of the service instance is configured as a second weight, and the second weight is higher than the first weight; The performance indicators after the service instance is started are monitored, and the traffic configuration of the service instance is adjusted according to the performance indicators and a preset traffic adjustment rule; The service state and the performance indicators after the service instance is started are obtained; The service state and the performance indicators are input, a trained preheating time length prediction model is called to determine a target preheating time length required for the service instance to reach the best performance, and the preheating time length prediction model is trained based on the historical service state, the historical performance indicators and the preheating time length of the service instance; Based on the target preheating time length, the preset preheating time length threshold of the service instance is adjusted.

2. The method of claim 1, wherein, The performance indicators include response time, error rate and throughput; and the adjustment of the traffic configuration of the service instance according to the performance indicators and the preset traffic adjustment rule comprises: In the case that the response time is lower than a preset response time threshold, the traffic weight of the service instance is increased; In the case that the error rate is higher than a preset error rate threshold, the traffic weight of the service instance is reduced; In the case that the throughput is lower than a preset throughput threshold, the traffic weight of the service instance is increased.

3. The method of claim 1, wherein, The method further comprises: The historical performance data after the service instance is deployed multiple times is obtained; Based on the historical performance data, the preheating time length required for the stable operation of the service instance is predicted; According to the predicted preheating time length, the preheating time length threshold of the service instance is determined.

4. The method according to any one of claims 1 to 3, characterized in that, The method further comprises: In the preheating process of the service instance, if an abnormal event is detected, a rollback operation is triggered, and the traffic of the service instance is redirected to the service instance of the last version.

5. A service preheating device, characterized in that The device comprises: A request interception module is configured to intercept the service directory registration request of the service instance through an aspect after the service instance is started, and judge whether the service directory registration request is a first request; A first traffic configuration module is configured to configure the traffic weight of the service instance as a first weight in the case that the service directory registration request is a first request, and start a timing preheating task; A registration state resetting module is configured to reset the registration state of the service instance to an unregistered state in the case that the running time length of the timing preheating task reaches a preset preheating time length threshold, so that the service instance initiates the service directory registration again; The second traffic configuration module is configured to re-intercept a service directory registration request of the service instance through a cut surface, and configure a traffic weight of the service instance as a second weight, which is higher than the first weight. The traffic adjustment module is configured to monitor a performance index of the service instance after startup, and adjust the traffic configuration of the service instance according to the performance index and a preset traffic adjustment rule. The preheating time dynamic adjustment module is configured to obtain a service state and a performance index of the service instance after startup, take the service state and the performance index as inputs, call a trained preheating time prediction model, determine a target preheating time required for the service instance to reach an optimal performance, and adjust a preset preheating time threshold of the service instance based on the target preheating time, wherein the preheating time prediction model is trained based on historical service states, historical performance indexes, and preheating times of service instances.

6. The apparatus of claim 5, wherein, The performance index includes a response time, an error rate, and a throughput; and the traffic configuration module is further configured to increase the traffic weight of the service instance if the response time is lower than a preset response time threshold, decrease the traffic weight of the service instance if the error rate is higher than a preset error rate threshold, and increase the traffic weight of the service instance if the throughput is lower than a preset throughput threshold.

7. The apparatus of claim 5, wherein, The device further includes a preheating time threshold determination module configured to obtain historical performance data of the service instance after multiple deployments, predict a preheating time required for stable operation of the service instance based on the historical performance data, and determine a preheating time threshold of the service instance according to the predicted preheating time.

8. The apparatus of any one of claims 5 to 7, wherein, The device further includes an exception processing module configured to, during a preheating process of the service instance, trigger a rollback operation to redirect traffic of the service instance to a service instance of a previous version if an abnormal event is detected. 9.A computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the computer device is configured to perform the method according to any one of claims 1-8 when the computer program is executed by the processor. The processor implements the steps of the method of any one of claims 1 to 4 when executing the computer program.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program, when executed by the processor, implements the steps of the method of any one of claims 1 to 4.

11. A computer program product comprising a computer program, characterized in that, The computer program, when executed by the processor, implements the steps of the method of any one of claims 1 to 4. The computer program, when executed by the processor, implements the steps of the method of any one of claims 1 to 4.

Images