CN119988080A - A service degradation method and related equipment - Google Patents
A service degradation method and related equipment Download PDFInfo
- Publication number
- CN119988080A CN119988080A CN202510123802.XA CN202510123802A CN119988080A CN 119988080 A CN119988080 A CN 119988080A CN 202510123802 A CN202510123802 A CN 202510123802A CN 119988080 A CN119988080 A CN 119988080A
- Authority
- CN
- China
- Prior art keywords
- service
- thread
- thread pool
- interface
- threads
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Debugging And Monitoring (AREA)
Abstract
本申请公开了一种服务降级方法及相关设备，涉及数据处理技术领域，进程外的监控组件检测数据获取请求中各个业务线程池中所有线程的状态，计算每个业务线程池处于等待状态的线程占比，当业务线程池中处于等待状态的线程占比达到预设占比阈值，判定该服务出现故障，对出现故障的业务线程池对应的第三方调用接口做降级处理。本申请基于进程外的监控组件监控微服务，在降低监控复杂度的基础上提高了微服务监控的性能，具体采用与第三方调用接口一一对应的业务线程池中处于等待状态的线程占比是否超出预设占比阈值判断服务是否出现故障，判断出现故障后立即对出现故障的第三方调用接口做降级处理，问题处理及时，相较于现有技术中手动降级时效性高。
The present application discloses a service downgrade method and related equipment, which relates to the field of data processing technology. An out-of-process monitoring component detects the status of all threads in each business thread pool in a data acquisition request, calculates the proportion of threads in a waiting state in each business thread pool, and when the proportion of threads in a waiting state in a business thread pool reaches a preset proportion threshold, it is determined that the service has failed, and the third-party call interface corresponding to the failed business thread pool is downgraded. The present application monitors microservices based on an out-of-process monitoring component, improves the performance of microservice monitoring on the basis of reducing the complexity of monitoring, and specifically determines whether a service has failed by determining whether the proportion of threads in a waiting state in a business thread pool corresponding to a third-party call interface exceeds a preset proportion threshold. After determining that a failure has occurred, the failed third-party call interface is immediately downgraded, and the problem is handled in a timely manner, which is more timely than manual downgrade in the prior art.
Description
Technical Field
The present application relates to the field of data processing technologies, and in particular, to a service degradation method and related devices.
Background
Micro-service is a style of software architecture, which splits a large application into multiple independent, independently operable and deployable small services, each of which typically implements a single function and operates in its own process, which cooperate with each other through a lightweight mechanism to together form a complete application system.
Invoking a third party interface has become a common and necessary operation with applications of micro-service architecture. The micro service realizes function expansion, improves performance and ensures availability by calling a third party interface, and meanwhile, can avoid repeated development and improve the efficiency and stability of the whole system.
When the third party interfaces shake, particularly because of network fluctuation, server problems or other reasons, interface response of the third party services becomes unstable or slow, and thus the micro service performance and stability of calling the interfaces are affected, or when a large-scale service fault is caused by network abnormality, operation and maintenance personnel or developers are required to manually open a degradation switch, call on certain third party interfaces is temporarily closed, and the whole system where the micro service is located is prevented from being affected because the third party interfaces are faulty or unavailable. However, when the degradation switch is manually turned on, the system where the micro service is located delays and the response to the service request of the user is not timely, so that the processing time is low when the micro service needing to call the third party interface has a problem.
Disclosure of Invention
In view of the above problems, the present application provides a service degradation method and related devices, so as to achieve the purpose of improving the timeliness of micro-service problem processing. The specific scheme is as follows:
the first aspect of the present application provides a service degradation method, applied to a monitoring component outside a process in a server, comprising:
The method comprises the steps of responding to a client to send a data acquisition request, determining at least one service thread pool corresponding to the data acquisition request, respectively executing operation of acquiring service data corresponding to the data acquisition request by the at least one service thread pool, wherein the types of the service data acquired by the at least one service thread pool are different, and each service thread pool corresponds to a third party call interface;
detecting the states of all threads in at least one service thread pool respectively, and calculating the thread duty ratio in a waiting state in each service thread pool;
when the thread duty ratio in the waiting state in the service thread pool reaches a preset duty ratio threshold, determining that an interface corresponding to the service thread pool is an interface to be demoted;
and degrading the interface to be degraded.
In one possible implementation, the method further includes:
monitoring the thread duty ratio in a waiting state;
When the thread duty ratio is lower than a preset duty ratio threshold value, a degradation stopping instruction is sent to an interface to be degraded;
monitoring the thread duty ratio in a waiting state;
And stopping sending the degradation stopping instruction to the interface to be degraded when the thread duty ratio reaches a preset duty ratio threshold value.
In one possible implementation, determining at least one business thread pool corresponding to a data acquisition request includes:
determining a main thread corresponding to the data acquisition request according to the data acquisition request;
And determining at least one business thread pool generated by the main thread drive according to a preset characteristic value, wherein the characteristic value is used for identifying the type of business data required to be acquired by the business thread pool.
In one possible implementation, detecting the states of all threads in at least one service thread pool, respectively, includes:
Acquiring thread stack information of all threads in at least one service thread pool;
Analyzing whether each thread is in a waiting state or not according to the state identification information in the thread stack information.
In one possible implementation, the monitoring component includes jstack processes, obtains thread stack information for all threads in the at least one service thread pool, including:
jstack the process obtains thread stack information for all threads in at least one business thread pool.
In one possible implementation, the method further includes:
Judging whether the service provided by the interface to be degraded is distributed service or not;
when the service provided by the interface to be demoted is distributed service, calculating the proportion of service objects with service errors in all the service objects corresponding to the interface to be demoted;
and when the service object proportion reaches a preset proportion threshold value, directly fusing the interface to be degraded.
A second aspect of the present application provides a service degradation apparatus, including:
the device comprises a first determining unit, a detection calculating unit, a second determining unit and a degradation processing unit, wherein:
The system comprises a first determining unit, a second determining unit and a third party calling interface, wherein the first determining unit is used for responding to a data acquisition request sent by a client and determining at least one service thread pool corresponding to the data acquisition request;
the detection calculation unit is used for respectively detecting the states of all threads in at least one service thread pool and calculating the thread duty ratio in the waiting state in each service thread pool;
The second determining unit is used for determining that the interface corresponding to the service thread pool is the interface to be demoted when the thread duty ratio in the waiting state in the service thread pool reaches a preset duty ratio threshold;
And the degradation processing unit is used for carrying out degradation processing on the interface to be degraded.
A third aspect of the present application provides a service degradation device comprising at least one processor and a memory coupled to the processor, wherein:
the memory is used for storing a computer program;
the processor is configured to execute a computer program to enable a service degradation device to implement a service degradation method as claimed in any one of the preceding claims.
A fourth aspect of the present application provides a computer storage medium carrying one or more computer programs which, when executed by the computer storage medium, enable a service degradation device to implement a service degradation method as claimed in any one of the preceding claims.
A fifth aspect of the application provides a computer program product comprising computer readable instructions which, when run on the computer program product, cause the computer program product to implement a service degradation method as claimed in any one of the preceding claims.
By means of the technical scheme, the service degradation method and the related equipment are applied to the monitoring component outside the process in the server, after the monitoring component sends the data acquisition request, the monitoring component starts to determine the service thread pools corresponding to the service acquisition request, the states of all threads in each service thread pool are detected, the thread proportion of each service thread pool in a waiting state is calculated, when the thread proportion of each service thread pool in the waiting state reaches a preset proportion threshold value, the service provided by the server is judged to be faulty, and degradation processing is carried out on a third party calling interface corresponding to the service thread pool with the fault. In the prior art, a degradation switch is manually opened to carry out degradation treatment on a failed interface, the micro-service is monitored based on an out-of-process monitoring component, the performance of micro-service monitoring is improved on the basis of reducing the complexity of micro-service monitoring, whether the service fails or not is judged by adopting whether the thread duty ratio in a waiting state in a service thread pool corresponding to the third party calling interfaces exceeds a preset duty ratio threshold value, and degradation treatment is carried out on the failed third party calling interfaces immediately after the failure is judged, so that the problem treatment is timely and compared with manual degradation timeliness.
Drawings
The above and other features, advantages, and aspects of embodiments of the present disclosure will become more apparent by reference to the following detailed description when taken in conjunction with the accompanying drawings. The same or similar reference numbers will be used throughout the drawings to refer to the same or like elements. It should be understood that the figures are schematic and that elements and components are not necessarily drawn to scale.
FIG. 1 is a schematic flow chart of a service degradation method according to the present application;
FIG. 2 is a flowchart illustrating a service degradation method according to the present application;
FIG. 3 is a schematic flow chart of another service degradation method according to the present application;
FIG. 4 is a schematic flow chart of another service degradation method according to the present application;
fig. 5 is a schematic structural diagram of a service degradation device according to an embodiment of the present application;
Fig. 6 is a schematic structural diagram of a service degradation device according to an embodiment of the present application.
Detailed Description
Embodiments of the present application will be described below with reference to the accompanying drawings in the embodiments of the present application. The terminology used in the description of the embodiments of the application herein is for the purpose of describing particular embodiments of the application only and is not intended to be limiting of the application.
Embodiments of the present application are described below with reference to the accompanying drawings. As one of ordinary skill in the art can know, with the development of technology and the appearance of new scenes, the technical scheme provided by the embodiment of the application is also applicable to similar technical problems.
The terms first, second and the like in the description and in the claims and in the above-described figures, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the terms so used are interchangeable under appropriate circumstances and are merely illustrative of the manner in which embodiments of the application have been described in connection with the description of the objects having the same attributes. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.
The micro service can expand the function, improve the performance and ensure the usability by calling the third party interface, and can avoid repeated development and improve the efficiency and the stability of the whole system.
For the extended functions, the micro-service can acquire rich functions provided by the third party service, such as payment processing, map service, social media login and the like, can acquire standard interfaces of a plurality of industries to ensure that the micro-service accords with industry standards, such as payment interfaces of financial industries, and can ensure that the micro-service accords with the industry standards through the standardized interfaces, and can also quickly integrate new functions by calling the third party calling interface, so that development period is shortened, and test requirements are reduced.
For improving the performance, the micro-service can obtain high-efficiency data processing capability by calling a third-party interface, for example, high-efficiency large data analysis can be performed by calling a third-party data analysis service, and the micro-service can also obtain a cache function by calling the third-party interface.
For ensuring availability, the micro service can call a plurality of third party services through a third party interface to serve as backup, and can automatically switch to another service when one service is not available, so that the overall availability of the system is improved, and the load balancing function and the overload protection mechanism of the third party service can be obtained through the third party interface.
For avoiding repeated development, the micro-service can directly call the existing third party service, thereby avoiding redevelopment and saving labor and time cost. And the service provider can provide technical support, update and maintenance service, so that the problem in development and use of the micro service is solved, and the maintenance burden of the micro service is reduced.
When the third party interface shakes or a large-scale service fault is caused by network abnormality, service degradation can be performed by manually opening a degradation switch, and the manual opening of the degradation switch can cause delay of a system where the micro service is located and untimely response to a service request of a user, and untimely problem treatment of the micro service needing to call the third party interface is performed, so that the overall operation of the system where the micro service is located is affected.
In order to solve the problems, the application provides a service degradation method and related equipment.
Referring to fig. 1, a flow chart of a service degradation method provided by the present application, as shown in fig. 1, includes the following steps:
It should be noted that, in the prior art, the monitoring manner of the micro service generally occurs in a process, and the monitoring manner of the micro service in the process specifically refers to monitoring in the micro service instance to obtain information such as an operation state and a performance index of the instance.
However, the monitoring process of the micro-service monitoring mode in the process is complex, resources in the process are occupied, and the performance cost is high. Therefore, the application provides a monitoring mode independent of micro services, namely an out-of-process monitoring mode. It is understood that the off-process monitoring means that the monitoring is not directly performed in the micro-service process, but the running state and performance index of the micro-service are collected, analyzed and displayed through an external system or tool.
Specifically, the application adopts an off-process monitoring component to monitor the micro-service.
The embodiment of the application is illustrated by standing on the monitoring component side of the server side.
And step 101, responding to a data acquisition request sent by a client, determining at least one service thread pool corresponding to the data acquisition request, respectively executing operation of acquiring service data corresponding to the data acquisition request by the at least one service thread pool, wherein the types of the service data acquired by the at least one service thread pool are different, and each service thread pool corresponds to a third party call interface.
It should be noted that, the data acquisition request is sent by the client, specifically, the client requests to acquire the service data. The micro-service providing end can be called as a service end, the third party calling interface belongs to the service end, and the third party calling interface of the micro-service calls the third party interface of the third party service end to acquire corresponding request data. The micro-service may correspond to a plurality of applications, each of which may include a plurality of third party call interfaces.
After receiving a data acquisition request sent by a client, a server generates a main thread corresponding to the data acquisition request, wherein the main thread drives to generate a thread pool, and at least one of the thread pools is used for generating the data acquisition request. The monitoring component starts each operation of the monitoring server after the server receives the data acquisition request. First, a main thread corresponding to a data acquisition request is determined, and then a business thread pool generated by the main thread driver is determined.
The service thread pool is used for executing service 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 a plurality of service thread pools, each service thread pool is different in type of service data corresponding to the request to be acquired, and each service thread pool only performs to acquire specific service data. The service thread pools may also be called sub thread pools, each service 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 service thread pool obtains service data which is required to be obtained and corresponds to the service thread pool from a third party interface corresponding to the third party calling interface through a third party calling interface corresponding to the service thread pool.
The monitoring component is an independent component for monitoring the whole process of acquiring the service data by the micro-service. It should be noted that, the thread monitored by the monitoring component is mainly a thread generated by a client request, and the function of the monitored thread is generally to obtain data from a third party server.
Optionally, after the monitoring component monitors that the micro-service receives the data acquisition request, a series of subsequent operations within the micro-service for the data acquisition request are started to be monitored. First, the monitoring component determines a main thread corresponding to the data acquisition request according to the data acquisition request.
Specifically, there are many ways in which the monitoring component determines its main thread according to the data acquisition request, and by way of example, the main thread corresponding to the data acquisition request may be determined based on log association. In the micro-service process, a unified log format is provided, a unique identifier is generated for each service, and the corresponding relation between the identifier and the thread ID (Identification) is recorded in the log. When the monitoring component is collecting logs, the request can be associated with a particular thread based on the identifier. The monitoring component parses the collected log, extracts key information, such as request ID, thread ID, timestamp, etc., and builds an index. Thus, when inquiring the related information of the specific service request, the main thread can be determined by rapidly locating the request ID to the corresponding thread ID and the log content.
And then, determining the business thread pool generated by the main thread drive according to the preset characteristic value in the business thread pool.
Each business thread pool comprises preset characteristic values, the characteristic values in each business thread pool are different, and the characteristic values are used for identifying the business data types required to be acquired by the business thread pool. The feature value may be understood as a name of each service thread pool, specifically, when the main thread driver generates the service thread pool, a name is set for the service thread pool, and the name identifies a service data type required to be acquired by the service thread pool.
It will be appreciated that the micro-service request third party interface is typically a concurrent request, i.e. a data acquisition request needs to call many third party interfaces, and if the data acquisition is performed serially, the response speed will be slow, so the micro-service request third party interface is typically concurrent, and in this case, in order to distinguish between executing each service thread pool that acquires service data from the third party interface, the main thread will name the service thread pool in the process of generating the service thread pool.
For example, for a high-traffic service front page feed stream, the request third party interface is a concurrent request, and each service thread pool is distinguished by setting an independent name for the service thread pool.
And 102, respectively detecting the states of all threads in at least one service thread pool, and calculating the thread duty ratio in the waiting state in each service thread pool.
The thread state of the monitored thread mainly comprises running state (running), blocking state (blocked), waiting state (waiting), timeout waiting state (timed_waiting) and ending state (terminated).
Specifically, when the thread obtains the time slice of the central processing unit, the thread is in a running state, and at the moment, the thread is executing codes, occupies the resources of the central processing unit and consumes a certain time and space. Illustratively, when a thread is dispatched by the central processor, the thread enters a run state, at which point the thread will execute its own code logic;
A blocked state is entered when a thread temporarily fails to continue execution for some reason. Illustratively, when a thread is executing while an I/O operation (e.g., waiting for data to be read and written, waiting for a network connection, etc.) is occurring, or a thread (), wait (), join (), etc. method is invoked. At this time, the thread temporarily stops executing its own code logic and enters a blocking state;
When the resources required by the thread are not ready or the operation is not completed, the thread enters a waiting state, and the thread in the waiting state needs to wait for some operations of other threads to complete so as to continue executing. Illustratively, when a thread invokes a wait (), join (), park (), etc., method, the thread will enter a wait state. Unlike the blocking state, where the thread actively relinquishes CPU usage while waiting, the blocking state is somehow forced to relinquish CPU usage. In the waiting state, the thread needs to wait for the notification or interrupt of other threads to continue execution;
And when the time of waiting for a certain event by the thread reaches the preset timeout time, entering a timeout waiting state. When a running thread invokes sleep (time), wait, join, parkNanos, parkUntil, a timeout wait state is entered, which like the wait state is not because no resources are requested, but rather the state is actively entered. Also, a thread in the timeout wait state needs to wait for the wakeup of other threads to continue execution. The thread entering the timeout wait state releases the execution right and occupied resources for the cpu, and the state is different from the wait state in that the thread automatically enters the blocking queue after the timeout time is up, and starts to compete for the lock.
When the thread is finished or ends due to an exception, it is in a terminated state. For example, when a thread runs out or abnormally ends, the thread enters a termination state, at which point the thread has completed its lifecycle and is no longer scheduled for execution.
It should be noted that, in a general case, the number of threads in each state in the service thread pool is basically at a constant level, and when the thread in the waiting state and the overtime waiting state occupy a relatively high amount, it is obvious that a problem occurs in the bottom service of the micro service, and the third party call interface is in a fault state.
Optionally, the monitoring component acquires thread stack information of all threads in the service thread pool, analyzes whether each thread is in a waiting state according to state identification information in the thread stack information, and calculates the thread duty ratio in the waiting state in each thread pool.
In one possible implementation, the monitoring component includes jstack processes, jstack processes as monitoring processes, and can execute a shell or python script to initiate monitoring of the java process every time a period of time elapses, thereby monitoring the running state of threads in the java process.
Specifically, jstack is a command line tool of Java, which is called Java STACK TRACE in english, and is used to generate thread stack information of a process in a Java virtual machine, where the thread stack information can be used to analyze the behavior and performance problems of the thread. When a process is run jstack and designated, the process is printed out to aggregate the state information of all threads. The thread stack information includes thread ID, thread state, call stack. Then, by examining the thread state and related method calls in the thread stack information, it can be determined whether the thread is in a wait state. For example, if the thread stack information indicates that the thread is calling a wait (), join (), or locksupport.
After the number of threads in a waiting state in each service thread pool is determined, the thread duty ratio in the waiting state in the service thread pool is calculated.
The thread in the waiting state may include only the thread in the waiting state, or may include both the thread in the waiting state and the thread in the timeout waiting state.
And 103, determining an interface corresponding to the service thread pool as an interface to be demoted when the thread duty ratio in the waiting state in the service thread pool reaches a preset duty ratio threshold.
The preset duty ratio threshold value is a duty ratio threshold value preset by a developer or an operation and maintenance person according to experience or calculation, and the duty ratio threshold value is used for representing whether the business thread pool is in a fault state or not.
Threads in the wait state include the thread in the wait state (wait) mentioned above and the thread in the timeout wait state (timed_wait).
Optionally, when the duty ratio of the thread in the waiting state in the service thread pool reaches or exceeds the duty ratio threshold, the monitoring component determines that the service thread pool is in a fault state, the third party calling interface corresponding to the service thread pool is determined to be the interface to be demoted, and when the duty ratio of the thread in the waiting state in the service thread pool is lower than the duty ratio threshold, the monitoring component determines that the service thread is in a normal state, and no processing measures are taken for the service thread pool.
Step 104, performing degradation treatment on the interface to be degraded.
Optionally, the monitoring component invokes the downgrade program to downgrade the third party invoking interface determined to be in a fault state.
Specifically, the monitoring component opens the down switch by calling the down interface to implement the down processing for the interface to be down-graded.
Exemplary, referring to fig. 2, a flowchart of a service degradation method provided by the present application is illustrated.
Step 201, setting a separate name for each thread pool in the code.
First, an independent name is set in the code for each thread pool.
Step 202, jstack process control executes a shell or python script to initiate monitoring of the java process.
Step 203, analyzing the duty ratio of waiting for the third party interface response in the corresponding thread pool through the thread stack and the thread state to determine whether a fault occurs.
And 204, if the failure occurs, directly performing degradation processing on the third party interface corresponding to the thread pool.
If the duty ratio of the influence of the waiting third party interface in the thread pool reaches a certain degree, judging that the thread pool fails, and directly performing degradation treatment on the third party call interface corresponding to the thread pool.
After a client sends a data acquisition request, a monitoring component outside a server starts to determine service thread pools corresponding to the service acquisition request, states of all threads in each service thread pool are detected, the thread proportion of each service thread pool in a waiting state is calculated, when the thread proportion of each service thread pool in the waiting state reaches a preset proportion threshold value, the service provided by the server is judged to have faults, and a third party calling interface corresponding to the service thread pool with faults is subjected to degradation treatment. In the prior art, a degradation switch is manually opened to carry out degradation treatment on a failed interface, and the application monitors micro services based on an out-of-process monitoring component, improves the performance of micro service monitoring on the basis of reducing the complexity of micro service monitoring, and particularly judges whether the service fails or not by judging whether the thread duty ratio in a waiting state exceeds a preset duty ratio threshold value in a service thread pool corresponding to the third party calling interface one by one, and immediately carries out degradation treatment on the failed third party calling interface after judging that the failure occurs, so that the problem treatment is timely and has higher timeliness compared with manual degradation.
Optionally, referring to fig. 3, another flow chart of the service degradation method provided by the present application is shown.
The service degradation processing method described above further includes the steps of:
step 301, canceling the degradation process until the thread duty ratio is lower than a preset duty ratio threshold value.
Optionally, the monitoring component may continuously monitor the states of all threads in each service thread pool, calculate the thread duty ratio in the waiting state in each service thread pool once at intervals, and when the thread duty ratio in the waiting state in the service thread pool in the fault state is lower than a preset duty ratio threshold, the monitoring component may call the downgrade interface to close the downgrade switch, and cancel downgrade processing on the third party call interface corresponding to the service thread pool.
In summary, the application adopts the monitoring component outside the process to monitor the health of the micro-service, the monitoring mode does not occupy the resources in the process, and the thread ratio in the waiting state in the service thread pool is used as the fault index. And once the thread duty ratio in the waiting state in the service thread pool reaches the preset duty ratio threshold, performing degradation treatment on a third party calling interface corresponding to the service thread pool immediately, and realizing the monitoring of micro service to the monitoring of the service thread pool.
Optionally, referring to fig. 4, another flow chart of the service degradation method provided by the present application is shown.
Before performing step 104, the method further comprises step 401 of determining whether the service provided by the interface to be downgraded is a distributed service.
The above-mentioned determination process of the interface to be degraded mainly determines whether a certain service in a certain server has a problem or not. From another level, the service provided by the interface to be downgraded may be a distributed service. Therefore, before the interface to be degraded is degraded, the application judges whether the service provided by the interface to be degraded is distributed service or not.
The deployment mode of the distributed service is a multi-machine-room multi-server mode, specifically, a certain application is provided with services by a plurality of servers in a plurality of machine rooms, and the service providing mode of the application dimension is provided. Each application can be divided according to the domain dimension, wherein A is a long video domain, B is a short video domain, C is a comment area domain, D is a message domain, each domain corresponds to one machine room, a plurality of servers are arranged in each machine room, namely, the service of the application is provided by the machine rooms in different domains, particularly the servers in the machine rooms, and the application can also be a small-volume monomer application, such as an operation background, and the operation and maintenance can be completed only by a single server in one machine room.
When it is determined that the service provided by the interface to be downgraded is not a distributed service, step 104 is performed to downgrade the interface to be downgraded.
And step 402, calculating the proportion of the service objects with service errors in all the service objects corresponding to the interfaces to be demoted when the services provided by the interfaces to be demoted are distributed services.
It should be noted that the service object proportion is an error proportion of all services between the interface to be demoted and all service objects of the service provided by the interface to be demoted.
Further, after judging that the service provided by the interface to be degraded is the distributed service, calculating error proportions of all the services between the interface to be degraded and all the service objects of the service provided by the interface to be degraded, wherein the error proportions are mainly used for judging whether to directly fuse the service provided by the interface to be degraded.
Step 403, when the service object proportion reaches a preset proportion threshold, directly fusing the interface to be degraded.
And when the error proportion of all the services provided by the interface to be degraded reaches a preset proportion threshold, fusing the interface to be degraded in a fusing degradation mode.
It should be noted that, there is a complex call relationship between micro services, a failure of one service may cause a cascading reaction, if the error proportion of a certain service is too high, continuing to call may cause more services to be affected, forming a cascading failure, and finally may cause a breakdown of the whole system. The fusing mechanism can rapidly cut off a fault source, and effectively avoid the occurrence of the cascade reaction.
For example, after determining that the service provided by the interface to be demoted is a distributed service, the ip of the interface to be demoted and the corresponding thread name and time are reported to the central control node of service demotion, and the central control node monitors the service error proportion provided by the interface to be demoted for all the corresponding service objects within a preset time period. When the error proportion of the service provided by the interface to be degraded in the fixed time period reaches a preset proportion threshold value, the central control node directly fuses the interface to be degraded until the central control node detects that the error proportion of the service provided by the interface to be degraded in the fixed time period is lower than the preset proportion threshold value, and continuous calling of the service provided by the interface to be degraded is resumed.
The service degradation method provided by the embodiment of the application is introduced above, and the device for executing the service degradation method is introduced below.
Referring to fig. 5, fig. 5 is a schematic structural diagram of a service degradation device according to an embodiment of the present application.
As shown in fig. 5, the service degradation apparatus includes a first determination unit 10, a detection calculation unit 20, a second determination unit 30, and a degradation processing unit 40, wherein:
The first determining unit 10 is configured to determine at least one service thread pool corresponding to the data acquisition request in response to the data acquisition request sent by the client, where the at least one service thread pool performs an operation of acquiring service data corresponding to the data acquisition request, the types of service data acquired by the at least one service thread pool are different, and each service thread pool corresponds to a third party call interface;
the detecting and calculating unit 20 is configured to detect states of all threads in at least one service thread pool, and calculate a thread duty ratio in a waiting state in each service thread pool;
a second determining unit 30, configured to determine, when the duty ratio of the thread in the waiting state in the service thread pool reaches a preset duty ratio threshold, that an interface corresponding to the service thread pool is an interface to be downgraded;
and the degradation processing unit 40 is used for performing degradation processing on the interface to be degraded.
In one embodiment, the service degradation device further includes a cancel degradation unit;
the de-demotion unit is specifically used for monitoring the thread duty ratio in a waiting state;
When the thread duty ratio is lower than a preset duty ratio threshold value, a degradation stopping instruction is sent to an interface to be degraded;
monitoring the thread duty ratio in a waiting state;
And stopping sending the degradation stopping instruction to the interface to be degraded when the thread duty ratio reaches a preset duty ratio threshold value.
In one embodiment, the first determining unit 10 is specifically configured to:
determining a main thread corresponding to the data acquisition request according to the data acquisition request;
And determining at least one business thread pool generated by the main thread drive according to a preset characteristic value, wherein the characteristic value is used for identifying the type of business data required to be acquired by the business thread pool.
In one embodiment, the detection calculation unit 20 is specifically configured to:
Acquiring thread stack information of all threads in at least one service thread pool;
Analyzing whether each thread is in a waiting state or not according to the state identification information in the thread stack information.
In one embodiment, the monitoring component includes jstack processes, and the detection computing unit 20 is specifically configured to:
jstack the process obtains thread stack information for all threads in at least one business thread pool.
In one embodiment, the service degradation device further includes a determining unit, specifically configured to:
Judging whether the service provided by the interface to be degraded is distributed service or not;
when the service provided by the interface to be demoted is distributed service, calculating the proportion of service objects with service errors in all the service objects corresponding to the interface to be demoted;
and when the service object proportion reaches a preset proportion threshold value, directly fusing the interface to be degraded.
The embodiment of the application also provides service degradation equipment. Referring to fig. 6, a schematic diagram of a service degradation device suitable for implementing the embodiment of the present application is shown. Service degradation devices in embodiments of the present application may include, but are not limited to, fixed terminals such as mobile phones, notebook computers, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, and the like. The service degradation device shown in fig. 6 is only an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present application.
As shown in fig. 6, the service degradation apparatus may include a processing device (e.g., a central processor, a graphic processor, etc.) 601 that may 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 into a Random Access Memory (RAM) 603. In the state where 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 through a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.
In general, devices may be connected to I/O interface 605 including input devices 606, including for example, touch screens, touch pads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc., output devices 607, including for example, liquid Crystal Displays (LCDs), speakers, vibrators, etc., storage devices 608, including for example, memory cards, hard disks, etc., and communication devices 609. The communication means 609 may allow the service degradation device to communicate wirelessly or by wire with other devices to exchange data. While fig. 6 shows a service degradation apparatus having various means, it should be understood that not all of the illustrated means are required to be implemented or provided. More or fewer devices may be implemented or provided instead.
The embodiment of the application also provides a computer readable storage medium, which carries one or more computer programs, and when the one or more computer programs are executed by electronic equipment, the computer readable storage medium can realize any service degradation method provided by the embodiment of the application.
Embodiments of the present application also provide a system comprising a computer program product comprising computer readable instructions, which when run on the computer program product, cause the computer program product to implement any of the service degradation methods provided by the embodiments of the present application. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions in accordance with embodiments of the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may 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 may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center by a wired (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). Computer readable storage media can be any available media that can be stored by a computer or data storage devices such as training devices, data centers, and the like, that contain an integration of one or more available media. Usable media may be magnetic media (e.g., floppy disk, hard disk, magnetic tape), optical media (e.g., DVD), or semiconductor media (e.g., solid state disk (Solid STATE DISK, SSD)), etc.
It should be further noted that the above-described apparatus embodiments are merely illustrative, and that the units described as separate units may or may not be physically separate, and that units shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. In addition, in the drawings of the embodiment of the device provided by the application, the connection relation between the modules represents that the modules have communication connection, and can be specifically implemented as one or more communication buses or signal lines.
From the above description of the embodiments, it will be apparent to those skilled in the art that the present application may be implemented by means of software plus necessary general purpose hardware, or of course by means of special purpose hardware including application specific integrated circuits, special purpose CPUs, special purpose memories, special purpose components, etc. Generally, functions performed by computer programs can be easily implemented by corresponding hardware, and specific hardware structures for implementing the same functions can be varied, such as analog circuits, digital circuits, or dedicated circuits. But a software program implementation is a preferred embodiment for many more of the cases of the present application. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a readable storage medium, such as a floppy disk, a usb disk, a removable hard disk, a ROM, a RAM, a magnetic disk or an optical disk of a computer, etc., comprising several instructions for causing a computer device (which may be a personal computer, a training device, a network device, etc.) to perform the method according to the embodiments of the present application.
In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product.
Claims (10)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202510123802.XA CN119988080A (en) | 2025-01-26 | 2025-01-26 | A service degradation method and related equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202510123802.XA CN119988080A (en) | 2025-01-26 | 2025-01-26 | A service degradation method and related equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN119988080A true CN119988080A (en) | 2025-05-13 |
Family
ID=95639149
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202510123802.XA Pending CN119988080A (en) | 2025-01-26 | 2025-01-26 | A service degradation method and related equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN119988080A (en) |
-
2025
- 2025-01-26 CN CN202510123802.XA patent/CN119988080A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103201724B (en) | Providing application high availability in highly-available virtual machine environments | |
| US7958402B2 (en) | Generate diagnostic data for overdue thread in a data processing system | |
| US10802847B1 (en) | System and method for reproducing and resolving application errors | |
| WO2016000298A1 (en) | System exception capturing method, main system, shadow system and intelligent device | |
| CN102314382A (en) | Method and module for emergently probing system information | |
| CN109101371B (en) | Disaster recovery switching method and device | |
| CN108415765B (en) | Task scheduling method and device and intelligent terminal | |
| CN114189429A (en) | System, method, device and medium for monitoring server cluster faults | |
| CN109343955B (en) | Recommendation service calling method, medium, device and computing equipment | |
| JP2003173272A (en) | Information processing system, information processing device and maintenance center | |
| CN111506331A (en) | Server BMC refreshing method, system, terminal and storage medium | |
| CN118245331B (en) | Data acquisition method and electronic equipment | |
| CN119182716A (en) | Service interface flow control method, device, equipment, medium and program product | |
| CN113742113B (en) | Health management method, equipment and storage medium for embedded system | |
| CN119363568A (en) | Fault handling methods, devices, equipment, storage media and products | |
| CN117851182B (en) | A Kubernetes resource monitoring method and system based on CMDB | |
| US7356683B2 (en) | System and method for monitoring BIOS messages of remote computers by a local server | |
| CN118779232A (en) | Test case execution method, device and server | |
| CN119988080A (en) | A service degradation method and related equipment | |
| CN112463514A (en) | Monitoring method and device for distributed cache cluster | |
| CN114363221A (en) | Heartbeat detection method based on micro-service system, storage medium, electronic device and system | |
| CN114328090A (en) | A program monitoring method, device, electronic device and storage medium | |
| CN112650381A (en) | Health self-checking method and system for nodes of distributed storage cluster | |
| CN118331841B (en) | Test engine management method, device and readable storage medium | |
| CN120785794A (en) | Method and related device for detecting availability of NAS service |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |