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

Abstract

The invention 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 steps that after a service instance is started, a service directory registration request of the service instance is intercepted through a section, whether the service directory registration request is a first request or not is judged, under the condition that the service directory registration request is the first request, the flow weight of the service instance is configured to be a first weight, and a timed preheating task is started, and under the condition that the running duration of the timed preheating task reaches a preset preheating duration threshold value, resetting the registration state of the service instance to be an unregistered state, so that the service instance initiates service directory registration again, intercepting a service directory registration request of the service instance again through the aspect, configuring the traffic weight of the service instance to be a second weight, and executing the second weight. The second weight is higher than the first weight. By adopting the method, the service reliability can be improved.

Description

Technical Field

[0001] The present application relates to the field of big data technology, and in particular to a service preheating method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Art

[0002] With the development of Internet technology and e-commerce, the scale and complexity of distributed data processing systems continue to increase. In order to ensure that these systems can operate efficiently and reliably, the industry has adopted 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 of a transaction service, the service directory registration information configured by the application is usually loaded, and relevant data such as registered components and their traffic control strategies are registered to the service directory.

[0003] However, with existing service catalog solutions, once a service is deployed and registered, its request processing capacity (i.e., the maximum traffic it can withstand) is fixed. Newly launched or restarted services may have to directly face a full volume of user requests due to insufficient time for resource preparation, which may lead to increased response delays or even service interruptions, reducing service reliability. Summary of the invention

[0004] Based on this, it is necessary to provide a service preheating method, device, computer equipment, computer-readable storage medium and computer program product with higher reliability in response to 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 the aspect to determine whether the service directory registration request is the first request;

[0007] In the case where the service catalog registration request is a first request, configuring the traffic weight of the service instance to be a first weight, and starting a scheduled warm-up task;

[0008] When the running time of the scheduled warm-up task reaches a preset warm-up time threshold, resetting the registration state of the service instance to an unregistered state so that the service instance initiates service catalog registration again;

[0009] The service catalog registration request of the service instance is intercepted again through the slice, and the traffic weight of the service instance is configured to be a second weight, which is higher than the first weight.

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

[0011] Monitor the performance indicators of the service instance after it is started;

[0012] The traffic configuration of the service instance is adjusted according to the performance indicator and the preset traffic adjustment rule.

[0013] In one embodiment, the performance indicators include response time, error rate and throughput; and adjusting the traffic configuration of the service instance according to the performance indicators and preset traffic adjustment rules includes:

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

[0015] When the error rate is higher than a preset error rate threshold, reducing the traffic weight of the service instance;

[0016] When the throughput is lower than a preset throughput threshold, the traffic weight of the service instance is increased.

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

[0018] Obtaining the service status and performance indicators of the service instance after it is started;

[0019] Taking the service state and the performance indicator as input, calling a trained warm-up time prediction model to determine a target warm-up time required for the service instance to achieve optimal performance, the warm-up time prediction model being trained based on the historical service state, historical performance indicator, and warm-up time of the service instance;

[0020] Based on the target warm-up time, a preset warm-up time threshold of the service instance is adjusted.

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

[0022] Obtain historical performance data of the service instance after multiple deployments;

[0023] Based on the historical performance data, predict the warm-up time required for the service instance to run stably;

[0024] A preheating time threshold of the service instance is determined according to the predicted preheating time.

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

[0026] During the warm-up 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 previous version of the service instance.

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

[0028] A request interception module is used to intercept the service catalog registration request of the service instance through a slice after the service instance is started, and determine whether the service catalog registration request is a first request;

[0029] A first traffic configuration module, configured to configure the traffic weight of the service instance to a first weight and start a timed warm-up task when the service catalog registration request is a first request;

[0030] A registration status reset module, used to reset the registration status of the service instance to an unregistered state when the running time of the scheduled preheating task reaches a preset preheating time threshold, so that the service instance initiates service directory registration again;

[0031] The second traffic configuration module is used to intercept the service directory registration request of the service instance again through the section, and configure the traffic weight of the service instance to a second weight, which is higher than the first weight.

[0032] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps in any one of the above-mentioned service preheating method embodiments when executing the computer program.

[0033] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps in any one of the service preheating method embodiments are implemented.

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

[0035] The above-mentioned service preheating method, apparatus, computer equipment, computer-readable storage medium and computer program product, after the service instance is started, intercepts the registration request through the aspect to determine whether the request is the first registration request. When the service directory registration request is the first request, the traffic weight of the service instance is first set to a lower first weight, which can reduce the possibility of performance bottlenecks or failures caused by a large number of requests when the service is not fully ready. At the same time, the scheduled preheating task is started to make the service instance start preheating. After the preheating time reaches the preheating time threshold, the registration state of the service instance is automatically reset to an unregistered state, so that the service instance initiates the service directory registration request again, and the traffic weight of the service instance is configured to a higher second weight, that is, open large traffic requests, so that the preheated service instance can efficiently process requests. During the whole process, the server is controlled to transition from low traffic to higher traffic by timing warm-up tasks and resetting service registration status. This not only allows the service to have a smooth transition period, but also receives only a small amount of traffic requests during the warm-up phase, reducing system instability or high latency caused by sudden large traffic, improving service reliability and response speed, and being able to adapt to different types of services and their specific startup characteristics, thereby improving system flexibility and resource utilization. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0037] Figure 1 A schematic flow chart of a service preheating method in one embodiment;

[0038] Figure 2 A schematic flow chart of a service preheating method in another embodiment;

[0039] Figure 3 It is a flowchart of a service preheating method in another embodiment;

[0040] Figure 4 A schematic flow chart of a service preheating method in yet another embodiment;

[0041] Figure 5 A schematic diagram of a flow chart of a step of determining a preheating time threshold in an embodiment;

[0042] Figure 6 A detailed flow chart of a service preheating method in one embodiment;

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

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

[0045] Fig. 9 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0046] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application. It should be noted that in the embodiments of the present application, certain software, components, models and other existing solutions in the industry may be mentioned, which should be considered as exemplary, and their purpose is only to illustrate the feasibility of the implementation of the technical solution of the present application, but it 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 used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations. The acquisition, storage, use, and processing of data in the technical solution of this application are in compliance with relevant provisions of national laws and regulations.

[0048] In one embodiment, Figure 1 As shown, a service preheating method is provided. This embodiment uses the method applied to a server as an example for illustration. It can 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 implemented through the interaction between the terminal and the server. In this embodiment, the method includes the following steps:

[0049] S202: After the service instance is started, a service directory registration request of the service instance is intercepted through a slice to determine whether the service directory registration request is a first request.

[0050] Aspect refers to AOP (Aspect-Oriented Programming) aspect. Aspect-oriented programming 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 the service catalog registration request and determine whether the service catalog is the first request. A service instance is a running copy of a service program that can process client requests. The service catalog is a centralized registry that stores information about all available service instances to help other services or clients discover and connect to these services.

[0051] For example, in actual applications, when a new order processing service instance is started, the OpenConsole driver service instance attempts to initiate a registration request to the service directory. During this process, the AOP aspect will be triggered and intercept the registration request. The aspect can check whether this is the first registration attempt of the service instance. Specifically, it can be checked whether there is a record of the service instance in the database or cache. If so, it indicates that this service instance is not the first time to register with the service directory. Otherwise, it proves that this service instance is the first time to register with the service directory.

[0052] S204: When the service catalog registration request is a first request, the traffic weight of the service instance is configured as a first weight, and a scheduled warm-up task is started.

[0053] Traffic weight refers to the proportion of requests assigned to a specific service instance. For example, if a service instance has a traffic weight of 5%, it will only handle 5% of all requests. A scheduled warm-up task is a pre-set task that is used to perform certain actions, such as resetting the service status, after a preset period of time.

[0054] In the case where it is determined that this service instance is registering with the service directory 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 in the initial stage. At the same time, a timed warm-up task is started to perform specific operations at the end of the timed task. It is understandable that in other embodiments, the first weight can also be 3%, 6%, and other values, which can be determined according to actual conditions and are not uniquely limited here. If the service instance is not registering with the service directory for the first time, the service directory registration is performed directly without modifying the traffic configuration of the service instance.

[0055] S206, when the running time of the scheduled 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.

[0056] In this embodiment, the running time of the scheduled preheating task can be set to 2 minutes, that is, after the scheduled preheating task runs for 2 minutes, the service instance has been preheated for 2 minutes, and the registration status of the service instance can be reset to the unregistered state, and the service instance can be deregistered from the service directory, so that the service instance can be re-registered and registered with normal traffic weight. It is understandable that in other embodiments, the preheating time can also be 3 minutes, 1 minute, or other time lengths, which can be determined according to actual conditions and are not limited here.

[0057] S208, intercepting the service catalog registration request of the service instance again through the slice, and configuring the traffic weight of the service instance to a second weight, where the second weight is higher than the first weight.

[0058] In this embodiment, the second weight is a higher weight than 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 applications, if the service status of a service instance is reset to an unregistered state, OpenConsole will detect that the service instance is unregistered again, and drive the service instance to initiate a service catalog registration request again. At this time, the AOP aspect intercepts the registration request again. Since this request is not the first registration, a higher second weight (such as 100%) can be used directly for registration, so that the service is ready to handle the full amount of traffic. With the above approach, the newly started service instance can only process a small number of requests in the first two minutes, thereby ensuring that it has sufficient resource preparation time. After two minutes, the service instance is fully ready and can handle a full amount of requests. This mechanism helps to improve the stability of the system and the user experience. It is understandable that in other embodiments, the second weight can also be other weights such as 90%, 95%, and 98%, which can be determined according to actual conditions and are not limited here.

[0060] The above service preheating method, after the service instance is started, intercepts the registration request through the aspect to determine whether the request is the first registration request. In the case that the service directory registration request is the first request, the traffic weight of the service instance is first set to a lower first weight, which can reduce the possibility of performance bottlenecks or failures caused by a large number of requests when the service is not fully ready. At the same time, the scheduled preheating task is started to make the service instance start preheating. After the preheating time reaches the preheating time threshold, the registration state of the service instance is automatically reset to an unregistered state, so that the service instance initiates the service directory registration request again, and the traffic weight of the service instance is configured to a higher second weight, that is, open large traffic requests, so that the preheated service instance can efficiently process requests. In the whole process, by means of scheduled preheating tasks and resetting the service registration state, the server is controlled to change from low traffic to high traffic, which not only allows the service to have a smooth transition period, but also receives only a small number of traffic requests during the preheating stage, reducing the system instability or high latency caused by sudden large traffic, improving the reliability and response speed of the service, but also can adapt to different types of services and their specific startup characteristics, and improve overall flexibility and resource utilization.

[0061] After the service instance is started, the traffic weight can also be adjusted dynamically. In an exemplary embodiment, Figure 2 As shown, after S208, it also includes:

[0062] S210, monitoring the performance indicators of the service instance after it is started.

[0063] S212: Adjust the traffic configuration of the service instance according to the performance indicator and the preset traffic adjustment rule.

[0064] Performance indicators are various metrics used to measure the operating status of service instances, such as response time, throughput, error rate, CPU usage, and memory usage. Among them, response time refers to the time from when the client sends a request to when the response is received. Throughput refers to the number of requests processed per unit time. Error rate refers to the proportion of failed requests. Traffic adjustment rules are a series of rules defined based on changes in performance indicators, which are used to dynamically adjust the traffic weight of service instances. Exemplarily, these rules can be set based on thresholds, trend analysis, or other algorithms.

[0065] In actual applications, when a service instance is started, the server can continuously monitor its performance indicators, including but not limited to response time, throughput, error rate, CPU usage, and memory usage, and then determine whether the performance indicators meet the preset performance requirements according to the preset traffic adjustment rules. If not, the traffic weight of the service instance is adjusted. For example, if the CPU usage is higher than the expected CPU usage threshold, such as 80%, the traffic weight is gradually reduced, such as reducing the traffic weight by 10% steps to reduce the CPU load.

[0066] In this embodiment, the traffic weight of the service instance is dynamically adjusted according to the real-time performance indicators to achieve fine traffic control, which can more effectively utilize computing resources, reduce resource waste, and enable the service to maintain optimal performance under different load conditions.

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

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

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

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

[0071] In actual applications, the preset response time threshold can be set to 100 milliseconds, the preset error rate threshold can be set to 1%, and the preset throughput threshold can be set to 100 times / second. The server can call the monitoring tool to regularly collect the response time, error rate, and throughput of each service instance. According to the preset traffic adjustment rules, it is determined whether the performance indicators of the service instance meet the traffic adjustment conditions. If so, the traffic weight is adjusted.

[0072] Exemplarily, when the response time of the monitored service instance is lower than a preset threshold (e.g., 100 milliseconds), this indicates that the service instance can process requests quickly and has sufficient resources to process more requests. Therefore, the traffic weight of the service instance can be increased, and the traffic weight in the service directory can be updated so that it can receive more requests. If the error rate of the monitored service instance is higher than the preset threshold (e.g., 1%), this indicates that the service instance has encountered problems when processing requests, which may be due to insufficient resources, misconfiguration, or other reasons. In order to prevent further problems from occurring, the traffic weight of the service instance can be reduced to reduce its load. If the throughput of the monitored service instance is lower than a preset threshold (e.g., 100 times / second), this 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 is understandable that the amplitude of each adjustment of the above-mentioned traffic weight can be other values ​​such as 5%, 10%, or 20%, which are not limited here.

[0073] For example, suppose the response time of a service instance A is 80 milliseconds, which is lower than the threshold of 100 milliseconds. At this time, the traffic weight of the instance can be increased from 10% to 12%. If the error rate of 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 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, dynamic adjustment of the traffic of service instances based on performance indicators not only improves the performance and stability of the system, allowing the service instances to run in the best state, but also significantly reduces user waiting time and error rate caused by service performance issues, improves user experience and simplifies operation and maintenance management.

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

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

[0077] S216, using the service status 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 achieve optimal performance.

[0078] S218: Adjust a preset warm-up time threshold of the service instance based on the target warm-up time.

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

[0080] In actual applications, operation and maintenance personnel can select appropriate machine learning models for warm-up time prediction. The models may include but are not limited to linear regression modules, decision tree models, support vector machines, and neural networks. Next, collect performance indicators and service status data after the historical service instance is started, as well as corresponding warm-up time and other data from the service log files. 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 the warm-up time), etc. Subsequently, the format of the preprocessed data is converted into a format that the machine learning model can recognize and process, and then the converted data is input into the selected machine learning model such as the support vector machine model, and the model is trained to improve the model performance by adjusting the model parameters to obtain the trained warm-up time prediction model. Subsequently, the performance of the model on the new data is verified and deployed to the production environment.

[0081] In specific implementation, when a new service instance is started, the system can continuously monitor its service status and service performance indicators through various monitoring tools and log records. Subsequently, the data format of the collected service status and service performance indicators is converted into the model input format, and the converted data is passed as input to a trained warm-up time prediction model, which will predict the target warm-up time required for the service instance to achieve optimal performance based on these input data. After obtaining the target warm-up time, the server dynamically adjusts the preset warm-up time threshold of the service instance according to the target warm-up time. After the next service instance of the same type is started, it will be preheated according to the adjusted warm-up time threshold.

[0082] In this embodiment, by real-time monitoring of service status and service performance indicators, and combining with the preheating time prediction model, the system can dynamically adjust the preheating time so that the service instance can achieve optimal performance in the shortest time, reducing resource waste or performance problems caused by too long or too short preheating time, and can better adapt to the specific circumstances of different service instances.

[0083] In addition to dynamically adjusting the warm-up time threshold based on the actual performance of the service instance after startup, the warm-up time of the service instance can also be determined in advance based on the historical data of the service instance for different types of service instances. Figure 5 As shown, in some exemplary embodiments, the method further includes:

[0084] S201, obtaining historical performance data of a service instance after multiple deployments.

[0085] S221, based on historical performance data, predict the warm-up time required for the service instance to run stably.

[0086] S241: Determine a preheating time threshold of the service instance according to the predicted preheating time.

[0087] Historical performance data includes performance metrics of service instances after multiple deployments, including response time, throughput, error rate, and resource usage. Warm-up time refers to the time required for a service instance to reach a stable operating state from startup.

[0088] In actual applications, performance indicators can be continuously collected during multiple deployments and runs of service instances, and the behavior patterns of service instances can be analyzed through these data to predict future performance. A machine learning model such as a random forest regression model can be trained with historical performance data to obtain a warm-up time evaluation model, which enables the model to predict the warm-up time required for a service instance to reach a stable operating state based on historical performance data.

[0089] In specific implementation, the historical performance data of the service instance after multiple deployments is collected, and then the format of the historical performance data is converted into the model input format, and the historical performance data is input into the trained warm-up duration evaluation model. The model predicts the warm-up duration, and then the warm-up duration predicted by the model is determined as the warm-up duration threshold of the service instance. In the subsequent service warm-up process, the service instance is warmed up by the predicted warm-up duration.

[0090] In this embodiment, by collecting historical performance data of service instances, the warm-up time required for the service instance to achieve stable operation is predicted, and the warm-up time threshold of the service instance is set accordingly. This enables each service instance to be ready to handle a large number of requests within the optimal warm-up time, thereby reducing user waiting time and error rate and improving user experience.

[0091] In some exemplary embodiments, the method further includes: during the warm-up 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 previous version of the service instance.

[0092] During the warm-up process of the service instance, you may encounter a variety of abnormal events, which may cause the newly deployed service instance to fail to operate normally or perform poorly. Common abnormal events include but are not limited to: Abnormal response time: The response time is significantly higher than the expected threshold (for example, more than 500 milliseconds). Excessive error rate: A high error rate occurs when the service instance processes requests (for example, the error rate exceeds 1%). Insufficient throughput: The throughput of the service instance is lower than the expected threshold (for example, the number of requests processed per second is less than 100). Abnormal resource usage: CPU usage or memory usage exceeds the expected range (for example, CPU usage continues to exceed 90%). System crash or hang: The service instance crashes or is unresponsive for a long time. Configuration error: The service cannot start or run normally due to a configuration error. Dependent 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 the service instance, the server will continuously monitor 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 and redirect the traffic to the previous version of the service instance to ensure the stability and availability of the system. Specifically, the rollback operation includes deregistering the new service instance from the service directory or reallocating the traffic to the previous version of the service instance, and recording the abnormal information for subsequent analysis and repair.

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

[0095] like Figure 6 As shown, in an exemplary embodiment, in order to make a clearer description of the service preheating method provided by the present application, a specific embodiment is described below, and the specific embodiment includes the following steps:

[0096] S1, after the service instance is started, the service directory registration request of the service instance is intercepted through the aspect to determine whether the service directory registration request is the first request.

[0097] S2: When the service catalog registration request is the first request, the traffic weight of the service instance is configured as the first weight, and a scheduled warm-up task is started.

[0098] S3: When the running time of the scheduled warm-up task reaches the 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, intercepting the service catalog registration request of the service instance again through the slice, and configuring the traffic weight of the service instance to a second weight, which is higher than the first weight.

[0100] S5, monitoring the performance indicators of the service instance after it is started, and adjusting the traffic configuration of the service instance according to the performance indicators and preset traffic adjustment rules.

[0101] Exemplarily, when the response time of a service instance is monitored to be lower than a preset threshold (e.g., 100 milliseconds), this indicates that the service instance is able to process requests quickly and has sufficient resources to process more requests. Therefore, the traffic weight of the service instance can be increased, and the traffic weight in the service directory can be 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%), this indicates that the service instance has encountered problems when processing requests, which may be due to insufficient resources, misconfiguration, or other reasons. In order to prevent further problems from occurring, 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), this 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, obtain the service status and performance indicators after the service instance is started, use the service status and performance indicators as input, call the trained warm-up time prediction model, and determine the target warm-up time required for the service instance to achieve optimal performance.

[0103] S7: Based on the target warm-up time, adjust a preset warm-up time threshold of the service instance.

[0104] S8: During the warm-up 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 previous version of the service instance.

[0105] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages 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 to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0106] Based on the same inventive concept, the embodiment of the present application also provides a service preheating device for implementing the service preheating method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded 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 above, and will not be repeated here.

[0107] In an exemplary embodiment, Figure 7 As shown, a service preheating device 700 is provided, including: a request interception module 710, a first flow configuration module 720, a registration state reset module 730 and a second flow configuration module 740, wherein:

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

[0109] The first traffic configuration module 720 is used to configure the traffic weight of the service instance to the first weight and start the scheduled warm-up task when the service catalog registration request is the first request.

[0110] The registration status reset module 730 is used to reset the registration status of the service instance to an unregistered state when the running time of the scheduled preheating task reaches a preset preheating time threshold, so that the service instance initiates service directory registration again.

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

[0112] The above-mentioned service preheating device, after the service instance is started, intercepts the registration request through the aspect to determine whether the request is the first registration request. In the case that the service directory registration request is the first request, the service instance's traffic weight is first set to a lower first weight, which can reduce the possibility of performance bottlenecks or failures caused by a large number of requests when the service is not fully ready. At the same time, the scheduled preheating task is started to make the service instance start preheating. After the preheating time reaches the preheating time threshold, the registration state of the service instance is automatically reset to an unregistered state, so that the service instance initiates the service directory registration request again, and the service instance's traffic weight is configured to a higher second weight, that is, open large traffic requests, so that the preheated service instance can efficiently process requests. In the whole process, by means of scheduled preheating tasks and resetting the service registration state, the server is controlled to change from low traffic to high traffic, which not only allows the service to have a smooth transition period, but also receives only a small number of traffic requests during the preheating stage, reducing the system instability or high latency caused by sudden large traffic, improving the reliability and response speed of the service, but also can adapt to different types of services and their specific startup characteristics, and improve the flexibility and resource utilization of the system.

[0113] like Figure 8 As shown, in an exemplary embodiment, the service preheating device also includes a traffic adjustment module 750 for 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 preset traffic adjustment rules.

[0114] In an exemplary embodiment, the performance indicators include response time, error rate and throughput. The traffic adjustment module 750 is also used to increase the traffic weight of the service instance when the response time is lower than a preset response time threshold, reduce the traffic weight of the service instance when the error rate is higher than a preset error rate threshold, and increase the traffic weight of the service instance when the throughput is lower than a preset throughput threshold.

[0115] like Figure 8 As shown, in an exemplary embodiment, the service preheating device also includes a preheating time dynamic adjustment module 760, which is used to obtain the service status and performance indicators after the service instance is started, and use the service status and performance indicators as input to call the trained preheating time prediction model to determine the target preheating time required for the service instance to achieve optimal performance, and based on the target preheating time, adjust the preset preheating time threshold of the service instance, wherein the preheating time prediction model is trained based on the historical service status, historical performance indicators and preheating time of the service instance.

[0116] In an exemplary embodiment, the service preheating device also includes a preheating time threshold determination module 702, which is used to obtain historical performance data of the service instance after multiple deployments, and based on the historical performance data, predict the preheating time required for the service instance to run stably, and determine the preheating time threshold of the service instance according to the predicted preheating time.

[0117] In an exemplary embodiment, the service preheating device also includes an exception handling module 770, which is used to trigger a rollback operation and redirect the traffic of the service instance to the previous version of the service instance if an abnormal event is detected during the preheating process of the service instance.

[0118] Each module in the above service preheating device can be implemented in whole or in part by software, hardware or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module.

[0119] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Fig. 9 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as 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 used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data such as service instances and performance indicators. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a service preheating method is implemented.

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

[0121] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the steps in any one of the service preheating method embodiments are implemented.

[0122] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in any one of the service preheating method embodiments are implemented.

[0123] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in any one of the service preheating method embodiments when executed by a processor.

[0124] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the 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. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

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

[0126] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A service preheating method, characterized in that: The method comprises: After the service instance is started, the service directory registration request of the service instance is intercepted through the aspect to determine whether the service directory registration request is the first request; In the case where the service catalog registration request is a first request, configuring the traffic weight of the service instance to be a first weight, and starting a scheduled warm-up task; When the running time of the scheduled warm-up task reaches a preset warm-up time threshold, resetting the registration state of the service instance to an unregistered state so that the service instance initiates service catalog registration again; The service catalog registration request of the service instance is intercepted again through the slice, and the traffic weight of the service instance is configured to be a second weight, which is higher than the first weight.

2. The method according to claim 1, characterized in that The method further comprises: Monitor the performance indicators of the service instance after it is started; The traffic configuration of the service instance is adjusted according to the performance indicator and the preset traffic adjustment rule.

3. The method according to claim 2, characterized in that The performance indicators include response time, error rate and throughput; and adjusting the traffic configuration of the service instance according to the performance indicators and preset traffic adjustment rules includes: When the response time is lower than a preset response time threshold, increasing the traffic weight of the service instance; When the error rate is higher than a preset error rate threshold, reducing the traffic weight of the service instance; When the throughput is lower than a preset throughput threshold, the traffic weight of the service instance is increased.

4. The method according to claim 1, characterized in that: The method further comprises: Obtaining the service status and performance indicators of the service instance after it is started; Taking the service state and the performance indicator as input, calling a trained warm-up time prediction model to determine a target warm-up time required for the service instance to achieve optimal performance, the warm-up time prediction model being trained based on historical service states, historical performance indicators, and warm-up times of the service instance; Based on the target warm-up time, a preset warm-up time threshold of the service instance is adjusted.

5. The method according to any one of claims 1 to 4, characterized in that: The method further comprises: Obtain historical performance data of the service instance after multiple deployments; Based on the historical performance data, predict the warm-up time required for the service instance to run stably; A preheating time threshold of the service instance is determined according to the predicted preheating time.

6. The method according to any one of claims 1 to 4, characterized in that: The method further comprises: During the warm-up 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 previous version of the service instance.

7. A service preheating device, characterized in that: The device comprises: A request interception module is used to intercept the service catalog registration request of the service instance through a slice after the service instance is started, and determine whether the service catalog registration request is a first request; A first traffic configuration module, configured to configure the traffic weight of the service instance to a first weight and start a timed warm-up task when the service catalog registration request is a first request; A registration status reset module, used to reset the registration status of the service instance to an unregistered state when the running time of the scheduled preheating task reaches a preset preheating time threshold, so that the service instance initiates service directory registration again; The second traffic configuration module is used to intercept the service directory registration request of the service instance again through the section, and configure the traffic weight of the service instance to a second weight, which is higher than the first weight.

8. The device according to claim 7, characterized in that The device also includes a traffic adjustment module, which is used to monitor the performance index of the service instance after it is started, and adjust the traffic configuration of the service instance according to the performance index and a preset traffic adjustment rule.

9. The device according to claim 8, characterized in that The performance indicators include response time, error rate and throughput; the traffic configuration module is also used to increase the traffic weight of the service instance when the response time is lower than a preset response time threshold, reduce the traffic weight of the service instance when the error rate is higher than a preset error rate threshold, and increase the traffic weight of the service instance when the throughput is lower than a preset throughput threshold.

10. The device according to claim 7, characterized in that The device also includes a preheating time dynamic adjustment module, which is used to obtain the service status and performance indicators after the service instance is started, and use the service status and the performance indicators as input to call a trained preheating time prediction model to determine the target preheating time required for the service instance to achieve optimal performance, and adjust the preset preheating time threshold of the service instance based on the target preheating time, wherein the preheating time prediction model is trained based on the historical service status, historical performance indicators and preheating time of the service instance.

11. The device according to any one of claims 7 to 10, characterized in that The device also includes a preheating time threshold determination module, which is used to obtain historical performance data of the service instance after multiple deployments, predict the preheating time required for the service instance to run stably based on the historical performance data, and determine the preheating time threshold of the service instance according to the predicted preheating time.

12. The device according to any one of claims 7 to 10, characterized in that The device also includes an exception handling module, which is used to trigger a rollback operation if an abnormal event is detected during the preheating process of the service instance, and redirect the traffic of the service instance to the previous version of the service instance.

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

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

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

Images