Service degradation method and related equipment

Abstract

The invention discloses a service degradation method and related equipment, and relates to the technical field of data processing, a monitoring component outside a process detects the states of all threads in each service thread pool in a data acquisition request, calculates the thread proportion of each service thread pool in a waiting state, and sends the thread proportion to a server; when the proportion of the threads in the waiting state in the service thread pool reaches a preset proportion threshold value, it is judged that the service breaks down, and degradation processing is conducted on the third-party calling interface corresponding to the service thread pool with the fault. According to the method and the device, the micro-service is monitored based on the monitoring component outside the process, the monitoring performance of the micro-service is improved on the basis of reducing the monitoring complexity, and specifically, whether the service breaks down or not is judged by judging whether the proportion of the threads in the waiting state in the service thread pools corresponding to the third-party calling interfaces one to one exceeds the preset proportion threshold value or not; and after the fault is judged to occur, the third-party calling interface with the fault is immediately subjected to degradation processing, the problem is timely processed, and compared with manual degradation in the prior art, the timeliness is high.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a service degradation method and related equipment. Background Art

[0002] Microservices is a software architecture style that splits a large application into multiple independent, independently run and deployable small services. Each service usually implements a single function and runs in its own process. These small services collaborate with each other through lightweight mechanisms to form a complete application system.

[0003] For applications using microservice architecture, calling third-party interfaces has become a common and necessary operation. It should be noted that microservices can achieve functional expansion, improve performance and ensure availability by calling third-party interfaces, while avoiding duplicate development and improving the efficiency and stability of the overall system.

[0004] When jitter occurs in the third-party interface, specifically due to network fluctuations, server problems or other reasons, the interface response of the third-party service becomes unstable or slow, which in turn affects the performance and stability of the microservices that call these interfaces, or when a large-scale service failure occurs due to network anomalies, the operation and maintenance personnel or developers need to manually turn on the degradation switch and temporarily close the call to certain third-party interfaces to avoid the overall impact of the system where the microservice is located due to the failure or unavailability of the third-party interface. However, manually turning on the degradation switch will cause delays in the system where the microservice is located and untimely responses to user service requests. Therefore, the timeliness of handling problems in microservices that need to call third-party interfaces is low. Summary of the invention

[0005] In view of the above problems, this application provides a service degradation method and related equipment to achieve the purpose of improving the timeliness of microservice problem handling. The specific solution is as follows:

[0006] The first aspect of the present application provides a service degradation method, which is applied to a monitoring component outside a process in a server, including:

[0007] In response to a data acquisition request issued by a client, at least one business thread pool corresponding to the data acquisition request is determined; the at least one business thread pool respectively executes an operation of acquiring business data corresponding to the data acquisition request, the type of business data acquired by the at least one business thread pool is different, and each business thread pool corresponds to a third-party calling interface;

[0008] Detect the status of all threads in at least one business thread pool respectively, and calculate the proportion of threads in a waiting state in each business thread pool;

[0009] When the proportion of threads in the waiting state in the business thread pool reaches a preset proportion threshold, the interface corresponding to the business thread pool is determined to be an interface to be downgraded;

[0010] Degrade the interface to be degraded.

[0011] In a possible implementation, the method further includes:

[0012] Monitor the percentage of threads in the waiting state;

[0013] When the thread ratio is lower than the preset ratio threshold, a downgrade stop instruction is sent to the interface to be downgraded;

[0014] Monitor the percentage of threads in the waiting state;

[0015] When the thread ratio reaches a preset ratio threshold, stop sending downgrade stop instructions to the interface to be downgraded.

[0016] In a possible implementation, determining at least one service thread pool corresponding to the data acquisition request includes:

[0017] Determine the main thread corresponding to the data acquisition request according to the data acquisition request;

[0018] At least one service thread pool generated by the main thread driver is determined according to a preset characteristic value, where the characteristic value is used to identify the type of service data that the service thread pool needs to obtain.

[0019] In a possible implementation, the status of all threads in at least one service thread pool is detected respectively, including:

[0020] Obtain thread stack information of all threads in at least one business thread pool;

[0021] According to the state identification information in the thread stack information, it is analyzed whether each thread is in a waiting state.

[0022] In a possible implementation, the monitoring component includes a jstack process, which obtains thread stack information of all threads in at least one business thread pool, including:

[0023] The jstack process obtains thread stack information of all threads in at least one business thread pool.

[0024] In a possible implementation, the method further includes:

[0025] Determine whether the service provided by the interface to be downgraded is a distributed service;

[0026] When the service provided by the interface to be degraded is a distributed service, the proportion of service objects with service errors among all service objects corresponding to the interface to be degraded is calculated;

[0027] When the proportion of service objects reaches the preset proportion threshold, the interface to be downgraded is directly disconnected.

[0028] A second aspect of the present application provides a service degradation device, including:

[0029] A first determination unit, a detection calculation unit, a second determination unit and a degradation processing unit; wherein:

[0030] A first determination unit is used to determine at least one business thread pool corresponding to the data acquisition request in response to a data acquisition request issued by a client; the at least one business thread pool respectively executes an operation of acquiring business data corresponding to the data acquisition request, the type of business data acquired by the at least one business thread pool is different, and each business thread pool corresponds to a third-party calling interface;

[0031] A detection and calculation unit, used to detect the status of all threads in at least one business thread pool respectively, and calculate the proportion of threads in a waiting state in each business thread pool;

[0032] The second determining unit is used to determine that the interface corresponding to the business thread pool is an interface to be downgraded when the proportion of threads in the business thread pool in a waiting state reaches a preset proportion threshold;

[0033] The degradation processing unit is used to perform degradation processing on the interface to be degraded.

[0034] A third aspect of the present application provides a service degradation device, comprising at least one processor and a memory connected to the processor, wherein:

[0035] The memory is used to store computer programs;

[0036] The processor is used to execute the computer program so that the service degradation device can implement the service degradation method as described in any one of the above.

[0037] A fourth aspect of the present application provides a computer storage medium, which carries one or more computer programs. When the one or more computer programs are executed by the computer storage medium, the service degradation device can implement the service degradation method as described in any one of the above.

[0038] A fifth aspect of the present application provides a computer program product, comprising computer-readable instructions. When the computer-readable instructions are executed on the computer program product, the computer program product implements the service degradation method as described in any one of the above.

[0039] By means of the above technical scheme, the service downgrade method and related equipment provided by the present application are applied to the monitoring component outside the process in the server. After the client sends a data acquisition request, the monitoring component starts to determine the business thread pool corresponding to the service acquisition request, detects the status of all threads in each business thread pool, and calculates the proportion of threads in the waiting state in each business thread pool. When the proportion of threads in the waiting state in the business thread pool reaches the preset proportion threshold, it is determined that the service provided by the server has failed, and the third-party call interface corresponding to the failed business thread pool is downgraded. In the prior art, the downgrade switch is manually turned on to downgrade the failed interface, while the present application monitors microservices based on the monitoring component outside the process, improves the performance of microservice monitoring on the basis of reducing the complexity of microservice monitoring, and specifically uses whether the proportion of threads in the waiting state in the business thread pool corresponding to the third-party call interface exceeds the preset proportion threshold to determine whether the service has failed. After determining that a failure has occurred, the third-party call interface with the failure is immediately downgraded, and the problem is handled in a timely manner, which is more timely than manual downgrade. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the accompanying drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the originals and elements are not necessarily drawn to scale.

[0041] Figure 1 A flow chart of a service downgrade method provided for this application;

[0042] Figure 2 A flowchart of a service downgrade method provided by the present application;

[0043] Figure 3 Another flowchart of the service downgrade method provided for this application;

[0044] Figure 4 Another flowchart of the service downgrade method provided for this application;

[0045] Figure 5 A schematic diagram of the structure of a service degradation device provided in an embodiment of the present application;

[0046] Figure 6 A schematic diagram of the structure of the service degradation device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0047] The following describes the embodiments of the present application in conjunction with the drawings in the embodiments of the present application. The terms used in the implementation method section of the present application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application.

[0048] The embodiments of the present application are described below in conjunction with the accompanying drawings. Those skilled in the art will appreciate that, with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0049] The terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and need not be used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances, which is only to describe the distinction mode adopted by the objects of the same attributes when describing in the embodiments of the present application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0050] Microservices can expand functionality, improve performance, and ensure availability by calling third-party interfaces. They can also avoid duplicate development and improve the efficiency and stability of the overall system.

[0051] For extended functions, microservices can obtain rich functions provided by third-party services by calling third-party interfaces, such as payment processing, map services, social media login, etc.; they can also ensure that microservices comply with industry standards by obtaining standard interfaces in many industries, such as payment interfaces in the financial industry. Through these standardized interfaces, microservices can ensure that they comply with industry standards; microservices can also quickly integrate new functions by calling third-party call interfaces, shortening the development cycle and reducing testing requirements.

[0052] To improve performance, microservices can obtain efficient data processing capabilities by calling third-party interfaces. For example, by calling third-party data analysis services, big data analysis can be performed efficiently. Microservices can also obtain caching functions by calling third-party interfaces.

[0053] To ensure availability, microservices can call multiple third-party services as backup through third-party interfaces, and automatically switch to another service when one of the services is unavailable, thereby improving the overall availability of the system; they can also obtain the load balancing function and overload protection mechanism of third-party services through third-party interfaces.

[0054] To avoid duplicate development, microservices can directly call existing third-party services to avoid redevelopment, saving manpower and time costs. In addition, the service provider will provide technical support, update and maintenance services to help the microservice side solve problems that arise during development and use, and also reduce the maintenance burden on the microservice side.

[0055] When jitter occurs in the third-party interface, or a large-scale service failure occurs due to network anomalies, the service can be downgraded by manually turning on the downgrade switch. Manually turning on the downgrade switch will cause delays in the system where the microservice is located and untimely responses to user service requests. Problems with microservices that need to call third-party interfaces are not handled in a timely manner, thus affecting the overall operation of the system where the microservice is located.

[0056] In order to solve the above problems, the present application provides a service degradation method and related equipment.

[0057] See also Figure 1 , a flow chart of a service degradation method provided by this application, such as Figure 1 As shown, the service degradation method includes the following steps:

[0058] It should be noted that the monitoring method of microservices in the prior art generally occurs within the process. The microservice monitoring method within the process specifically refers to monitoring within the microservice instance to obtain information such as the running status and performance indicators of the instance.

[0059] However, the monitoring process of this in-process microservice monitoring method is complicated, occupies in-process resources and has a large performance overhead. Therefore, this application provides a monitoring method independent of microservices: an out-of-process monitoring method. It is understandable that the out-of-process monitoring method refers to not directly monitoring within the microservice process, but collecting, analyzing and displaying the operating status and performance indicators of the microservice through an external system or tool.

[0060] Specifically, this application uses an out-of-process monitoring component to monitor microservices.

[0061] The embodiment of the present application is described from the perspective of the monitoring component of the server.

[0062] Step 101: In response to a data acquisition request issued by a client, determine at least one business thread pool corresponding to the data acquisition request; at least one business thread pool respectively executes operations to acquire business data corresponding to the data acquisition request, and the type of business data acquired by at least one business thread pool is different, and each business thread pool corresponds to a third-party calling interface.

[0063] It should be noted that the data acquisition request is issued by the client, specifically the customer's request to obtain business data. The microservice provider can be called the server, and the third-party call interface belongs to the server. The third-party call interface of the microservice calls the third-party interface of the third-party server to obtain the corresponding request data. A microservice can correspond to multiple applications, and each application can include multiple third-party call interfaces.

[0064] After receiving the data acquisition request sent by the client, the server generates a main thread corresponding to the data acquisition request. The main thread drives the generation of a thread pool, and there is at least one thread pool. After receiving the data acquisition request, the monitoring component starts to monitor every step of the server operation. First, determine the main thread corresponding to the data acquisition request, and then determine the business thread pool generated by the main thread drive.

[0065] The business thread pool is used to execute the business data acquisition operation corresponding to the data acquisition request. It should be noted that if the main thread driver corresponding to the data acquisition request generates multiple business thread pools, each business thread pool corresponds to a different type of business data required to be acquired, and each business thread pool only executes to acquire specific business data. The business thread pool can also be called a sub-thread pool, and each business thread pool corresponds to a third-party call interface, and each third-party call interface corresponds to a third-party interface of a third-party server. Specifically, each business thread pool obtains the business data that it needs to obtain from the third-party interface corresponding to the third-party call interface through the third-party call interface corresponding to the business thread pool.

[0066] The monitoring component is an independent component that monitors the entire process of microservices obtaining business data. It should be noted that the threads monitored by the monitoring component are mainly threads generated by customer requests, and the function of the monitored threads is generally to obtain data from third-party servers.

[0067] Optionally, after the monitoring component detects that the microservice receives the data acquisition request, it starts to monitor a series of subsequent operations of the microservice for the data acquisition request. First, the monitoring component determines the main thread corresponding to the data acquisition request based on the data acquisition request.

[0068] Specifically, there are many ways for the monitoring component to determine its main thread based on the data acquisition request. For example, the main thread corresponding to the data acquisition request can be determined based on log association. During the microservice process, a unified log format will be provided, a unique identifier will be generated for each service, and the correspondence between the identifier and the thread ID (Identification) will be recorded in the log. When the monitoring component collects logs, it can associate the request with a specific thread based on the identifier. The monitoring component parses the collected logs, extracts key information, such as request ID, thread ID, timestamp, etc., and creates an index. In this way, when querying the relevant information of a specific service request, the corresponding thread ID and log content can be quickly located by the request ID to determine the main thread.

[0069] Then, the business thread pool generated by the main thread driver is determined according to the pre-set characteristic value in the business thread pool.

[0070] Each business thread pool includes a pre-set feature value, which is different in each business thread pool. The feature value is used to identify the type of business data that the business thread pool needs to obtain. The feature value can be understood as the name of each business thread pool. Specifically, when the main thread driver generates a business thread pool, a name is set for the business thread pool. This name identifies the type of business data that the business thread pool needs to obtain.

[0071] It is understandable that microservice requests to third-party interfaces are generally concurrent requests, that is, a data acquisition request requires calling many third-party interfaces. If the data is acquired serially, the response speed will be slowed down. Therefore, microservices generally request third-party interfaces concurrently. At this time, in order to distinguish the various business thread pools that execute to obtain business data from third-party interfaces, the main thread will name the business thread pool during the generation process of the business thread pool.

[0072] For example, for a high-traffic service homepage feed stream, requests to third-party interfaces are all concurrent requests, and each business thread pool is distinguished by setting an independent name for the business thread pool.

[0073] Step 102: Detect the status of all threads in at least one business thread pool respectively, and calculate the proportion of threads in a waiting state in each business thread pool.

[0074] The thread states of the monitored threads mainly include running state (running), blocked state (blocked), waiting state (waiting), timed waiting state (timed_waiting), and terminated state (terminated).

[0075] Specifically, when a thread obtains a time slice of the CPU, it is in the running state. At this time, the thread is executing code, occupying the resources of the CPU and consuming a certain amount of time and space. For example, when the CPU schedules a thread, the thread enters the running state, and the thread executes its own code logic;

[0076] When a thread cannot continue to execute for some reason, it enters a blocked state. For example, when a thread performs an I / O operation (such as waiting to read or write data, waiting for a network connection, etc.) or calls methods such as Thread.sleep(), wait(), and join(), the thread will temporarily stop executing its own code logic and enter a blocked state.

[0077] When the resources required by the thread are not ready or the operation is not completed, the thread will enter the waiting state. The thread in the waiting state needs to wait for certain operations of other threads to complete before it can continue to execute. For example, when the thread calls wait(), join(), park() and other methods, the thread will enter the waiting state. Unlike the blocking state, the thread actively gives up the right to use the CPU in the waiting state, while the blocking state is forced to give up the right to use the CPU for some reason. In the waiting state, the thread needs to wait for notification or interruption from other threads to continue execution;

[0078] When the time a thread waits for an event reaches the preset timeout time, it will enter the timeout waiting state. When the running thread calls sleep (time), wait, join, parkNanos, parkUntil, it will enter the timeout waiting state. It is the same as the waiting state. It is not because the resource cannot be requested, but it actively enters this state. In addition, the thread in the timeout waiting state needs to wait for other threads to wake up before continuing to execute. The thread entering the timeout waiting state will release the execution right and occupied resources for the CPU. The difference between this state and the waiting state is that after the timeout time, it will automatically enter the blocking queue and start competing for the lock.

[0079] When the thread is finished or ends due to an exception, it will be in the terminated state. For example, when the thread runs to the end or ends abnormally, the thread will enter the terminated state, at which time the thread has completed its life cycle and will no longer be scheduled for execution.

[0080] It should be noted that, under normal circumstances, the number of threads in various states in the business thread pool is basically at a constant level. When the proportion of threads in the waiting state and the timed waiting state is high, it is obvious that there is a problem with the underlying service of the microservice and the third-party call interface is in a faulty state.

[0081] Optionally, the monitoring component obtains thread stack information of all threads in the business thread pool, analyzes whether each thread is in a waiting state through state identification information in the thread stack information, and calculates the proportion of threads in a waiting state in each thread pool.

[0082] In a possible implementation, the monitoring component includes a jstack process. As a monitoring process, the jstack process can execute a shell or python script to start monitoring of a java process at regular intervals, thereby monitoring the running status of threads in the java process.

[0083] Specifically, jstack is a command line tool for Java, and its full English name is Java Stack Trace. It is used to generate thread stack information for a process in the Java virtual machine. The thread stack information can be used to analyze thread behavior and performance issues. When you run jstack and specify a process, the status information of all threads of the process will be printed out. The thread stack information includes thread ID, thread status, and call stack. Then, by checking the thread status and related method calls in the thread stack information, you can determine whether the thread is in a waiting state. For example, if the thread stack information shows that the thread is calling methods such as wait(), join(), or LockSupport.park(), then the thread is likely to be in a waiting state.

[0084] After determining the number of threads in the waiting state in each business thread pool, calculate the proportion of threads in the waiting state in the business thread pool.

[0085] It should be noted that the threads in the waiting state may include only threads in the waiting state, or may include two types of threads: threads in the waiting state and threads in the timeout waiting state.

[0086] Step 103: When the proportion of threads in the waiting state in the business thread pool reaches a preset proportion threshold, it is determined that the interface corresponding to the business thread pool is an interface to be downgraded.

[0087] It should be noted that the preset ratio threshold is a ratio threshold pre-set by developers or operation and maintenance personnel based on experience or calculation, and the ratio threshold is used to indicate whether the business thread pool is in a fault state.

[0088] Threads in the waiting state include the threads in the waiting state (waiting) and the threads in the timed waiting state (timed_waiting) mentioned above.

[0089] Optionally, when the proportion of threads in the waiting state in the business thread pool reaches or exceeds the proportion threshold, the monitoring component will determine that the business thread pool is in a fault state, and the third-party call interface corresponding to the business thread pool will be determined as an interface to be degraded; when the proportion of threads in the waiting state in the business thread pool is lower than the proportion threshold, the monitoring component determines that the business thread is in a "normal state" and will not take any processing measures for the business thread pool.

[0090] Step 104: Downgrade the interface to be downgraded.

[0091] Optionally, the monitoring component calls a downgrade program to downgrade the third-party call interface that is determined to be in a fault state.

[0092] Specifically, the monitoring component turns on the degradation switch by calling the degradation interface to implement degradation processing for the interface to be degraded.

[0093] For example, see Figure 2 , a flow chart showing an example of a service downgrade method provided in this application.

[0094] Step 201: Set an independent name for each thread pool in the code.

[0095] First, set a separate name for each thread pool in the code.

[0096] Step 202: The jstack process controls the execution of a shell or python script to start monitoring of the java process.

[0097] Step 203: Analyze the proportion of threads in the corresponding thread pool waiting for a response from a third-party interface through the thread stack and thread status to determine whether a fault occurs.

[0098] Step 204: If a failure occurs, directly downgrade the third-party interface corresponding to the thread pool.

[0099] If the proportion of waiting for the third-party interface in the thread pool reaches a certain level, the thread pool is judged to have a fault, and the third-party call interface corresponding to the thread pool is directly downgraded.

[0100] The service downgrade method provided by the present application is that after the client issues a data acquisition request, the monitoring component outside the server process starts to determine the business thread pool corresponding to the service acquisition request, detects the status of all threads in each business thread pool, calculates the proportion of threads in the waiting state in each business thread pool, and when the proportion of threads in the waiting state in the business thread pool reaches a preset proportion threshold, it is determined that the service provided by the server has failed, and the third-party call interface corresponding to the failed business thread pool is downgraded. In the prior art, the downgrade switch is manually turned on to downgrade the failed interface, while the present application monitors microservices based on the monitoring component outside the process, improves the performance of microservice monitoring on the basis of reducing the complexity of microservice monitoring, and specifically uses the business thread pool corresponding to the third-party call interface one by one to determine whether the proportion of threads in the waiting state exceeds the preset proportion threshold to determine whether the service has failed. After determining that a failure has occurred, the third-party call interface with the failure is immediately downgraded, and the problem is handled in a timely manner, which is more timely than manual downgrade.

[0101] Optional, see Figure 3 , another flow chart of the service degradation method provided in this application.

[0102] The service degradation processing method described above further includes the following steps:

[0103] Step 301: cancel the downgrade process until the thread proportion is lower than a preset proportion threshold.

[0104] Optionally, the monitoring component will continue to monitor the status of all threads in each business thread pool, and calculate the proportion of threads in the waiting state in each business thread pool at regular intervals. When the proportion of threads in the waiting state in the business thread pool in a faulty state is lower than the preset proportion threshold, the monitoring component will call the downgrade interface to turn off the downgrade switch and cancel the downgrade processing of the third-party call interface corresponding to the business thread pool.

[0105] In summary, this application uses an out-of-process monitoring component to monitor the health of microservices. This monitoring method does not occupy resources within the process, and uses the proportion of threads in the business thread pool in a waiting state as a fault indicator. Once it is found that the proportion of threads in the business thread pool in a waiting state reaches the preset proportion threshold, the third-party call interface corresponding to the business thread pool is immediately downgraded, and the monitoring of microservices is implemented on the monitoring of the business thread pool. When the state of the business thread pool has a potential risk of causing problems on the server side where the microservice is located, downgrade processing is promptly adopted to promptly eliminate major problems that may arise later, thereby reducing the maintenance cost of microservices.

[0106] Optional, see Figure 4 , another flow chart of the service degradation method provided in this application.

[0107] Before executing step 104: performing downgrading processing on the interface to be degraded, the method further includes step 401: determining whether the service provided by the interface to be degraded is a distributed service.

[0108] The process of determining the interface to be downgraded mentioned above mainly determines whether there is a problem with a service in a certain server. From another perspective, the service provided by the interface to be downgraded may be a distributed service. Therefore, in this application, before downgrading the interface to be downgraded, it will first be determined whether the service provided by the interface to be downgraded is a distributed service.

[0109] The deployment method of distributed services is multiple computer rooms and multiple servers. Specifically, a certain application is provided by multiple computer rooms and multiple servers, which is the service provision method of application dimension. For example, each application can be divided according to the field dimension, A is the long video field, B is the short video field, C is the comment area field, and D is the message field. Each field corresponds to a computer room, and each computer room has multiple servers, that is, the service of the application is provided by computer rooms in different fields, specifically by servers in the computer room; in particular, the application can also be a small-scale single application, such as the operation background, which only requires a single server in a computer room to complete operation and maintenance.

[0110] It should be noted that, when it is determined that the service provided by the interface to be degraded is not a distributed service, the above step 104 is executed to degrade the interface to be degraded.

[0111] Step 402: When the service provided by the interface to be degraded is a distributed service, the proportion of service objects having service errors among all service objects corresponding to the interface to be degraded is calculated.

[0112] It should be noted that the service object ratio is the error ratio of all services between the interface to be degraded and all service objects provided by the interface to be degraded.

[0113] Furthermore, after determining that the service provided by the interface to be downgraded is a distributed service, the error ratio of all services between the interface to be downgraded and all service objects provided by the interface to be downgraded is calculated. The error ratio is mainly used to determine whether to directly fuse the service provided by the interface to be downgraded.

[0114] Step 403: When the service object ratio reaches a preset ratio threshold, the interface to be degraded is directly disconnected.

[0115] When the error ratio of all services provided by the interface to be degraded reaches a preset ratio threshold, the interface to be degraded is fused through fuse fusion degradation.

[0116] It should be noted that there are complex calling relationships between microservices. The failure of a service may trigger a chain reaction. If the error rate of a service is too high, continued calls may cause more services to be affected, forming a cascading failure, and eventually may cause the collapse of the entire system. The fuse mechanism can quickly cut off the source of the fault and effectively avoid the occurrence of such a chain reaction.

[0117] Exemplarily, when it is determined that the service provided by the interface to be degraded is a distributed service, the IP address of the interface to be degraded and the corresponding thread name and time will be reported to the central control node of service degrade, and the central control node will monitor the service error ratio provided by the interface to be degraded for all its corresponding service objects within a preset time period. When the error ratio of the service provided by the interface to be degraded within a fixed time period reaches a preset ratio threshold, the central control node will directly fuse the interface to be degraded until the central control node detects that the error ratio of the service provided by the interface to be degraded within a fixed time period is lower than the preset ratio threshold, and then resumes the continued call of the service provided by the interface to be degraded.

[0118] A service degradation method provided in an embodiment of the present application is introduced above, and a device for executing the above service degradation method will be introduced below.

[0119] See also Figure 5 , Figure 5 A schematic diagram of the structure of a service degradation device provided in an embodiment of the present application.

[0120] like Figure 5 As shown, the service degradation device includes a first determination unit 10, a detection calculation unit 20, a second determination unit 30 and a degradation processing unit 40; wherein:

[0121] The first determination unit 10 is used to determine at least one business thread pool corresponding to the data acquisition request in response to the data acquisition request issued by the client; the at least one business thread pool respectively performs an operation of acquiring business data corresponding to the data acquisition request, the type of business data acquired by the at least one business thread pool is different, and each business thread pool corresponds to a third-party call interface;

[0122] A detection and calculation unit 20 is used to detect the status of all threads in at least one business thread pool respectively, and calculate the proportion of threads in a waiting state in each business thread pool;

[0123] The second determining unit 30 is used to determine that the interface corresponding to the business thread pool is an interface to be downgraded when the proportion of threads in the business thread pool in a waiting state reaches a preset proportion threshold;

[0124] The degradation processing unit 40 is used to perform degradation processing on the interface to be degraded.

[0125] In one embodiment, the service degradation device further includes a degradation cancellation unit;

[0126] Cancel the degradation unit, which is specifically used to monitor the proportion of threads in the waiting state;

[0127] When the thread ratio is lower than the preset ratio threshold, a downgrade stop instruction is sent to the interface to be downgraded;

[0128] Monitor the percentage of threads in the waiting state;

[0129] When the thread ratio reaches a preset ratio threshold, stop sending downgrade stop instructions to the interface to be downgraded.

[0130] In one implementation, the first determining unit 10 is specifically configured to:

[0131] Determine a main thread corresponding to the data acquisition request according to the data acquisition request;

[0132] At least one service thread pool generated by the main thread driver is determined according to a preset characteristic value, where the characteristic value is used to identify the type of service data that the service thread pool needs to obtain.

[0133] In one embodiment, the detection calculation unit 20 is specifically configured to:

[0134] Obtain thread stack information of all threads in at least one business thread pool;

[0135] According to the state identification information in the thread stack information, it is analyzed whether each thread is in a waiting state.

[0136] In one embodiment, the monitoring component includes a jstack process, a detection computing unit 20, and is specifically used to:

[0137] The jstack process obtains thread stack information of all threads in at least one business thread pool.

[0138] In one implementation, the service degradation device further includes a determination unit, specifically configured to:

[0139] Determine whether the service provided by the interface to be downgraded is a distributed service;

[0140] When the service provided by the interface to be degraded is a distributed service, the proportion of service objects with service errors among all service objects corresponding to the interface to be degraded is calculated;

[0141] When the proportion of service objects reaches the preset proportion threshold, the interface to be downgraded is directly disconnected.

[0142] The present application also provides a service degradation device in an embodiment. Figure 6As shown, it shows a schematic diagram of the structure of a service degradation device suitable for implementing the service degradation provided in the embodiment of the present application. The service degradation device in the embodiment of the present application may include but is not limited to fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 6 The service degradation device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0143] like Figure 6 As shown, the service degradation device may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage device 608 to a random access memory (RAM) 603. When the service degradation device is powered on, various programs and data required for the operation of the service degradation device are also stored in the RAM 603. The processing device 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0144] Typically, the following devices may be connected to the I / O interface 605: input devices 606 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; output devices 607 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 608 including, for example, a memory card, a hard disk, etc.; and communication devices 609. The communication devices 609 may allow the service degradation device to communicate with other devices wirelessly or by wire to exchange data. Although Figure 6 The service degradation device with various devices is shown, but it should be understood that it is not required to implement or have all the devices shown. More or fewer devices may be implemented or have instead.

[0145] A computer-readable storage medium is also provided in an embodiment of the present application. The storage medium carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the computer-readable storage medium can implement any service degradation method provided in the embodiment of the present application.

[0146] In the embodiment of the present application, there is also provided a computer program product, including computer-readable instructions, when the computer-readable instructions are run on the computer program product, so that the computer program product implements any service degradation method provided in the embodiment of the present application. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on the computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, a computer, a training device or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, training device or data center. The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a training device, a data center, etc. that contains one or more available media integrated. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a DVD), or a semiconductor medium (eg, a solid state disk (SSD)).

[0147] It should also be noted that the device embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed over multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. In addition, in the drawings of the device embodiments provided by the present application, the connection relationship between the modules indicates that there is a communication connection between them, which may be specifically implemented as one or more communication buses or signal lines.

[0148] Through the description of the above implementation mode, the technicians in the field can clearly understand that the present application can be implemented by means of software plus necessary general hardware, and of course, it can also be implemented by special hardware including special integrated circuits, special CPUs, special memories, special components, etc. In general, all functions completed by computer programs can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be various, such as analog circuits, digital circuits or special circuits. However, for the present application, software program implementation is a better implementation mode in more cases. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a readable storage medium, such as a computer floppy disk, a U disk, a mobile hard disk, a ROM, a RAM, a magnetic disk or an optical disk, etc., including a number of instructions to enable a computer device (which can be a personal computer, a training device, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0149] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product.

Claims

1. A service degradation method, characterized in that: Monitoring components applied to the server outside the process, including: In response to a data acquisition request issued by a client, at least one business thread pool corresponding to the data acquisition request is determined; the at least one business thread pool respectively performs an operation of acquiring business data corresponding to the data acquisition request, the business data acquired by the at least one business thread pool is of different types, and each business thread pool corresponds to a third-party calling interface; Detecting the status of all threads in the at least one business thread pool respectively, and calculating the proportion of threads in a waiting state in each business thread pool; When the proportion of threads in the waiting state in the business thread pool reaches a preset proportion threshold, the interface corresponding to the business thread pool is determined to be an interface to be downgraded; Perform downgrading processing on the interface to be downgraded.

2. The service degradation method according to claim 1, characterized in that: Also includes: Monitor the proportion of threads in the waiting state; When the thread proportion is lower than the preset proportion threshold, sending a downgrade stop instruction to the interface to be downgraded; Monitor the proportion of threads in the waiting state; When the thread proportion reaches the preset proportion threshold, stop sending the downgrade stop instruction to the interface to be downgraded.

3. The service degradation method according to claim 1, characterized in that: The determining of at least one service thread pool corresponding to the data acquisition request includes: Determining a main thread corresponding to the data acquisition request according to the data acquisition request; The at least one service thread pool generated by the main thread driver is determined according to a preset characteristic value, wherein the characteristic value is used to identify the type of service data required to be acquired by the service thread pool.

4. The service degradation method according to claim 1, characterized in that: The respectively detecting the status of all threads in the at least one service thread pool includes: Obtain thread stack information of all threads in the at least one service thread pool; Whether each thread is in a waiting state is determined based on the state identification information in the thread stack information.

5. The service degradation method according to claim 4, characterized in that: The monitoring component includes a jstack process, and the obtaining of thread stack information of all threads in the at least one service thread pool includes: The jstack process obtains thread stack information of all threads in the at least one service thread pool.

6. The service degradation method according to claim 1, characterized in that: When the proportion of threads in the waiting state in the business thread pool reaches a preset proportion threshold, after determining that the interface corresponding to the business thread pool is an interface to be degraded, the method further includes: Determine whether the service provided by the interface to be downgraded is a distributed service; When the service provided by the interface to be degraded is a distributed service, calculating the proportion of service objects having service errors among all service objects corresponding to the interface to be degraded; When the service object ratio reaches a preset ratio threshold, the interface to be degraded is directly disconnected.

7. A service degradation device, characterized in that: include: A first determination unit, a detection calculation unit, a second determination unit and a degradation processing unit; wherein: The first determination unit is used to determine at least one business thread pool corresponding to the data acquisition request in response to the client sending the data acquisition request; the at least one business thread pool respectively performs the operation of acquiring the business data corresponding to the data acquisition request, the business data acquired by the at least one business thread pool is of different types, and each of the business thread pools corresponds to a third-party calling interface; The detection and calculation unit is used to respectively detect the status of all threads in the at least one business thread pool and calculate the proportion of threads in a waiting state in each business thread pool; The second determining unit is used to determine that the interface corresponding to the business thread pool is an interface to be downgraded when the proportion of threads in the business thread pool in a waiting state reaches a preset proportion threshold; The downgrade processing unit is used to perform downgrade processing on the interface to be downgraded.

8. A service degradation device, characterized in that: The method comprises at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is configured to execute the computer program so that the service degradation device can implement the service degradation method according to any one of claims 1 to 6.

9. A computer storage medium, characterized in that The computer storage medium carries one or more computer programs, and when the one or more computer programs are executed by the computer storage medium, the computer storage medium can implement the service degradation method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that The method comprises computer-readable instructions, and when the computer-readable instructions are executed on a computer program product, the computer program product implements the service degradation method according to any one of claims 1 to 6.

Images