Service exception processing method and device, electronic equipment and storage medium

Abstract

The application discloses a service exception processing method and device, electronic equipment and storage medium, the method is applied to micro-service system, including in the processing process of target business, obtaining exception information, which includes exception identification information; determining the calling topology graph of the exception service node corresponding to the exception identification information, determining the target weight information corresponding to the exception service node and each downstream service node according to the service identification information and calling interface information included in the calling topology graph, which is used for representing the importance degree of the corresponding service for the target business; determining the exception influence factor corresponding to the exception service node and each downstream service node according to the calling depth information; obtaining the exception evaluation result corresponding to the exception information according to the target weight information and the exception influence factor of the service node in the calling topology graph, which is used for representing the influence degree of the exception information on the target business. The application can improve the explainability and business relevance of the exception evaluation.

Description

Technical Field

[0001] This invention relates to the field of intelligent operation and maintenance technology, and in particular to a service anomaly handling method, apparatus, electronic device, and storage medium. Background Technology

[0002] Microservice systems consist of numerous fine-grained microservices that collaborate to achieve system functionality and are widely used in fields such as finance, telecommunications, and transportation. With the widespread adoption of microservice architecture in business systems, the number of microservices is growing rapidly, and the inter-service call relationships are becoming increasingly complex and dynamic. An anomaly in a single service node can propagate rapidly through the call chain, triggering cascading failures and ultimately rendering the entire business system unavailable.

[0003] In existing technologies, static alarm methods based on fixed thresholds are difficult to perceive the propagation path and impact range of anomalies between services, and it is difficult to distinguish the degree of impact of anomalies on different businesses. As a result, critical anomalies are difficult to detect and handle in a timely manner, and cannot meet the operation and maintenance needs of business systems. Summary of the Invention

[0004] To address the aforementioned problems in the prior art, this invention discloses a service anomaly handling method, apparatus, electronic device, and storage medium, which can improve the interpretability and business relevance of anomaly evaluation. The technical solution disclosed in this invention is as follows: According to one aspect of the disclosed embodiments of the present invention, a service exception handling method is provided, the method being applied to a microservice system, the method comprising: During the processing of the target business, abnormal information is obtained; the abnormal information includes abnormal identification information. Determine the call topology diagram of the abnormal service node corresponding to the abnormal identification information; the call topology diagram is used to represent the call relationship between the abnormal service node and multiple downstream service nodes within a preset time period, and the call topology diagram includes service identification information, call interface information and call depth information; Based on the service identifier information and the call interface information, the target weight information corresponding to the abnormal service node and each of the downstream service nodes is determined; the target weight information is used to characterize the importance of the corresponding service to the target business. Based on the call depth information, an abnormal impact factor is determined for each abnormal service node and each of the downstream service nodes; the abnormal impact factor is used to characterize the degree of influence of the abnormal service node on each service node in the call topology graph. Based on the target weight information and abnormal impact factor corresponding to each of the multiple service nodes in the call topology diagram, the abnormal evaluation result corresponding to the abnormal information is calculated; the abnormal evaluation result is used to characterize the degree of impact of the abnormal information on the target business.

[0005] Optionally, determining the target weight information corresponding to the abnormal service node and each of the downstream service nodes based on the service identifier information and the call interface information includes: For each service identifier, the weight information of the corresponding call interface information is summed to obtain the initial weight information corresponding to the abnormal service node and each of the downstream service nodes. Determine the upper limit weight information corresponding to the abnormal service node and each of the downstream service nodes; The target weight information is determined from the initial weight information and the upper limit weight information.

[0006] Optionally, determining the upper limit weight information corresponding to the abnormal service node and each of the downstream service nodes includes: Obtain the weight information of the preset call interface information corresponding to the service identifier information, and the preset adjustment coefficient corresponding to the service identifier information; The upper limit weight information is obtained by multiplying the weight information of the preset call interface information corresponding to the service identifier information and the preset adjustment coefficient.

[0007] Optionally, the step of calculating the anomaly evaluation result corresponding to the anomaly information based on the target weight information and anomaly impact factor corresponding to each of the multiple service nodes in the call topology graph includes: Based on the target weight information corresponding to each of the multiple service nodes in the call topology graph, the abnormal influence factors corresponding to each of the multiple service nodes are multiplied to obtain the target abnormal factor corresponding to each service node in the call topology graph. The anomaly evaluation result is obtained by summing the target anomaly factors corresponding to each service node.

[0008] Optionally, determining the call topology of the abnormal service node corresponding to the abnormal identification information includes: Obtain valid call chain information corresponding to multiple services in the target business within the preset time period; From the valid call chain information, determine the target call chain information between the abnormal service node and the multiple downstream service nodes corresponding to the abnormal service node; Using the abnormal service node as the root node, the call topology graph is constructed based on the target call chain information; the call depth information between each downstream service node and the abnormal service node does not exceed a preset depth threshold.

[0009] Optionally, obtaining the abnormal information includes: Obtain alarm information; The alarm information is parsed and mapped into a preset format to obtain the abnormal information.

[0010] Optionally, the method further includes: If the anomaly evaluation result meets the preset conditions, the target anomaly level corresponding to the anomaly information is determined, and the corresponding early warning content information is sent based on the corresponding early warning path information.

[0011] Optionally, determining the target anomaly level corresponding to the anomaly information when the anomaly evaluation result meets preset conditions includes: If the abnormal evaluation result is greater than or equal to the first preset evaluation threshold, the first abnormal level is determined as the target abnormal level. If the abnormal evaluation result is greater than or equal to the second preset evaluation threshold and less than the first preset evaluation threshold, the second abnormal level is determined as the target abnormal level. If the abnormal evaluation result is greater than or equal to the third preset evaluation threshold and less than the second preset evaluation threshold, the third abnormal level is determined as the target abnormal level. If the anomaly evaluation result is less than the third preset evaluation threshold, the fourth anomaly level will be determined as the target anomaly level.

[0012] According to another aspect of the disclosed embodiments of the present invention, a service exception handling apparatus is provided, comprising: The acquisition module is used to acquire abnormal information during the processing of the target business; the abnormal information includes abnormal identification information. The topology graph determination module is invoked to determine the call topology graph of the abnormal service node corresponding to the abnormal identification information; the call topology graph is used to represent the call relationship between the abnormal service node and multiple downstream service nodes within a preset time period, and the call topology graph includes service identification information, call interface information and call depth information; The target weight information determination module is used to determine the target weight information corresponding to the abnormal service node and each of the downstream service nodes based on the service identification information and the call interface information; the target weight information is used to characterize the importance of the corresponding service to the target business; An abnormal impact factor determination module is used to determine the abnormal impact factor corresponding to the abnormal service node and each of the downstream service nodes based on the call depth information; the abnormal impact factor is used to characterize the degree of influence of the abnormal service node on each service node in the call topology graph; The anomaly evaluation result determination module is used to calculate the anomaly evaluation result corresponding to the anomaly information based on the target weight information and anomaly impact factor of each of the multiple service nodes in the call topology graph; the anomaly evaluation result is used to characterize the degree of impact of the anomaly information on the target business.

[0013] According to another aspect of the disclosed embodiments of the present invention, an electronic device for service exception handling is provided, including a processor and a memory, wherein the memory stores at least one instruction, the at least one instruction being loaded and executed by the processor to implement the service exception handling method described in any of the preceding claims.

[0014] According to another aspect of the embodiments disclosed in this invention, a computer-readable storage medium is provided, wherein at least one instruction is stored in the computer storage medium, the at least one instruction being loaded and executed by a processor to implement the service exception handling method described in any of the preceding claims.

[0015] According to another aspect of the disclosed embodiments of the present invention, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to perform the service exception handling method described in any of the above embodiments of the present invention.

[0016] The service exception handling method provided by this invention has the following technical effects: This invention acquires anomaly information, including anomaly identification information, during the processing of a target business. Then, it determines the call topology graph of the abnormal service node corresponding to the anomaly identification information. The call topology graph represents the call relationships between the abnormal service node and multiple downstream service nodes within a preset time period. Specifically, the call topology graph includes service identification information, call interface information, and call depth information. Furthermore, based on the service identification information and call interface information, it determines the target weight information corresponding to the abnormal service node and each downstream service node. The target weight information represents the importance of the corresponding service to the target business. And, based on the call depth information, it determines the anomaly impact factor corresponding to the abnormal service node and each downstream service node. The anomaly impact factor represents the degree of influence of the abnormal service node on each service node in the call topology graph. Finally, based on the target weight information and anomaly impact factors corresponding to multiple service nodes in the call topology graph, it calculates the anomaly evaluation result corresponding to the anomaly information. The anomaly evaluation result represents the degree of influence of the anomaly information on the target business.

[0017] Therefore, by constructing a partial call topology diagram downstream of the abnormal service node, which includes service identifier, call interface, and call depth information, the propagation path of the anomaly in the business chain can be effectively described. Furthermore, by combining the business importance weights at both the service and interface levels, as well as the anomaly impact factor dynamically calculated based on call depth, the impact of the anomaly on the target business can be quantified. This can improve the interpretability and business relevance of anomaly evaluation, thereby efficiently supporting the operation and maintenance decisions of large-scale microservice systems and ensuring system stability and business continuity.

[0018] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating a service exception handling method according to an exemplary embodiment; Figure 2 This is a flowchart illustrating a call topology diagram for determining abnormal service nodes according to an exemplary embodiment; Figure 3 This is a schematic diagram illustrating a process for determining target weight information according to an exemplary embodiment; Figure 4 This is a schematic diagram illustrating a process for determining anomaly evaluation results according to an exemplary embodiment; Figure 5 This is a block diagram illustrating a service exception handling apparatus according to an exemplary embodiment; Figure 6 This is a block diagram illustrating a terminal electronic device for handling service exceptions according to an exemplary embodiment; Figure 7 This is a block diagram illustrating a server electronic device for service exception handling according to an exemplary embodiment. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solutions disclosed in this invention, the technical solutions in the disclosed embodiments will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0022] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention disclosed herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0023] The following describes a service exception handling method proposed in this application. This method is applied to a microservice system. Please refer to [link / reference]. Figure 1 , Figure 1 This is a flowchart illustrating a service exception handling method according to an exemplary embodiment. This specification provides the operational steps of the method as described in the embodiments or flowchart, but based on conventional or non-inventive labor, more or fewer operational steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only execution order. In actual system or server product execution, the method can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment) as shown in the embodiments or drawings. Specifically, as... Figure 1 As shown, the above method may include: S101: Obtain abnormal information during the processing of the target business.

[0024] In one specific embodiment, the exception information may include exception identifier information, exception name information, exception description information, exception instance information, service information corresponding to the exception identifier information, and exception occurrence time information. The exception identifier information can be a unique identifier for the exception; each exception corresponds to one exception identifier information, and the exception identifier information can be one-to-one with the exception occurrence time. The service information can be related information of the microservice that experienced the exception. Specifically, the service information may include service identification information, such as the service name. The service identifier information can be one-to-one with the service, and the corresponding service can be uniquely identified through the service identifier information. The exception identifier information can be used to determine the relevant information of the service that experienced the exception, such as the service identifier information.

[0025] In one specific embodiment, the target business can be any business that requires anomaly monitoring. In practical applications, the target business can include credit resource allocation business, resource installment service business, resource allocation risk assessment business, and resource transfer business, etc. Specifically, the credit resource allocation business can include credit-based refundable resource allocation business (such as lending business) and resource allocation business based on third-party platforms (such as loan assistance business), etc. The resource installment service business can include scenario-based electronic resource installment service business (such as consumer loan business), the resource allocation risk assessment business can include risk control / credit review business, and the resource transfer business can include payment business, transaction business, etc.

[0026] Optionally, obtaining the above-mentioned abnormal information may include: Obtain alarm information; The alarm information is parsed and mapped to a preset format to obtain the abnormal information.

[0027] In one specific embodiment, the alarm information can be sent by the monitoring system when an abnormal alarm is detected. By parsing the alarm information, abnormal-related information can be extracted and mapped into a preset format to obtain the aforementioned abnormal message (including abnormal information). The preset format can be a pre-defined abnormal alarm message format. Specifically, the generated abnormal message can also be cleaned and supplemented to remove invalid or duplicate information, and relevant default values ​​or fields can be added as needed, such as abnormal identification information, alarm information reception time, etc.

[0028] S103: Determine the call topology of the abnormal service node corresponding to the abnormal identification information.

[0029] In one specific embodiment, the call topology graph can be used to represent the call relationships between the abnormal service node and multiple downstream service nodes within a preset time period. Each node in the call topology graph can correspond to a service, and each edge can be used to represent the runtime dependency relationship between two services. The multiple downstream service nodes can be multiple service nodes located downstream of the abnormal service node. Specifically, they can include service nodes located one level downstream of the abnormal service node (direct call nodes), and service nodes located one level downstream of the abnormal service node (i.e., two levels downstream of the abnormal service node, indirect call nodes), and so on.

[0030] Specifically, the call topology graph can include service identification information, call interface information, and call depth information. The exception identification information, such as the service identifier, can be used to identify the relevant information of the service that experienced the exception. This allows us to determine the call topology graph of the exception service node corresponding to that service identifier; in other words, the call topology graph of the service node experiencing the exception can be retrieved using the exception identification information. The call interface information can be the call interface between two services with dependencies. A single service can have runtime dependencies on multiple other services, each corresponding to a different call interface. The call depth information can be the number of edges traversed in the shortest path from a downstream service node to the exception service node. For example, the call depth between the exception service node and its direct caller node is 1, while the call depth with its indirect caller node is 2 or higher, and so on.

[0031] Specifically, the call topology graph can also include call time information and the call relationships between service nodes within a preset time period. This can be the call relationships between service nodes within a preset time period before the anomaly occurred, i.e., the call time is within a preset time period before the anomaly occurred. In practical applications, determining the call topology graph of the abnormal service node within a preset time period ensures that the call relationships of the abnormal service node are currently active and valid, representing the current actual business path, thereby ensuring the accuracy and effectiveness of subsequent anomaly evaluation. Specifically, the preset time period and preset depth threshold can be set according to actual application needs; for example, the preset time period can be set to 10 minutes, and the preset depth threshold can be set to 3.

[0032] Optional, such as Figure 2 As shown, the call topology diagram for determining the abnormal service node corresponding to the above-mentioned abnormal identification information may include: S201: Obtain valid call chain information for multiple services in the target business within a preset time period.

[0033] In one specific embodiment, the valid call chain information can be call information within a preset time period prior to the time the exception occurred. Specifically, the call chain information may include calling service information, called service information, call path information, and call time information. The calling service information and the called service information may each include service identification information (such as service name) to uniquely identify the corresponding service.

[0034] S203: From the valid call chain information, determine the abnormal service node and the target call chain information between multiple downstream service nodes corresponding to the abnormal service node.

[0035] In one specific embodiment, the abnormal service node and multiple downstream service nodes with the required call depth can be found from the valid call chain information based on the service identifier information corresponding to the abnormal identifier information, and the call relationship information such as the call path and call time between these service nodes can be extracted to obtain the above-mentioned target call chain information.

[0036] S205: Using the abnormal service node as the root node, construct a call topology graph based on the target call chain information.

[0037] In one specific embodiment, the call topology graph described above uses the abnormal service node as the root node, and the call depth information between each downstream service node and the abnormal service node does not exceed a preset depth threshold. The call topology graph can be composed of the abnormal service node, downstream service nodes whose call hierarchy depth does not exceed the preset depth, and the dependencies between these service nodes.

[0038] In the embodiments described in this specification, a call topology graph is dynamically constructed based on the currently active abnormal links. The call topology graph is not the full call topology graph of the services in the business, but a partial subgraph. It can dynamically reflect the propagation range of the abnormality in the service call chain while avoiding the computation and storage overhead caused by relying on the full graph. As a result, it can run in a lightweight and real-time manner in a large-scale microservice environment with thousands of service nodes, greatly reducing computation and memory overhead, and completing the abnormality evaluation in seconds.

[0039] S105: Based on the service identification information and the call interface information, determine the target weight information corresponding to the abnormal service node and each downstream service node.

[0040] In one specific embodiment, target weight information can be used to characterize the importance of the corresponding service to the target business. The larger the target weight information, the higher the importance.

[0041] Optional, such as Figure 3 As shown, the target weight information for determining the abnormal service node and each downstream service node based on the service identifier information and the API call information may include: S301: For each service identifier, sum the weight information of the corresponding call interface information to obtain the initial weight information of the abnormal service node and each downstream service node.

[0042] In one specific embodiment, before summing the weight information, the corresponding weight information can be determined based on the service identifier information and the corresponding call interface information. This weight information can be used to characterize the importance of the service and its corresponding call interface to the business; the larger the weight information, the higher the importance. Specifically, according to the first preset mapping relationship, the weight information corresponding to each call interface information under the service identifier information can be determined. The weight information of each call interface information corresponding to each service identifier information is added together, and the sum is the initial weight information corresponding to each service node. Specifically, the above-mentioned first preset mapping relationship can be used to characterize the correspondence between the service identifier information, the corresponding call interface information, and the weight information.

[0043] For example, when the service identifier is h5Server (i.e., h5 service), its corresponding call interface can be DEFAULT (i.e., default interface), and the corresponding weight information can be set to 0.8; when the service identifier is user-center (i.e., user center service), its corresponding call interfaces can include DEFAULT (i.e., default interface) and login (i.e., login interface), and the corresponding weight information for the default interface can be set to 0.8, and the weight information for the login interface can be set to 0.9; when the service identifier is payment-gateway (i.e., payment gateway service), its corresponding call interfaces can include DEFAULT (i.e., default interface), charge (i.e., deduction interface), and refund (i.e. refund interface), and the corresponding weight information for the default interface can be set to 0.8, the weight information for the deduction interface can be set to 1, and the weight information for the refund interface can be set to 0.8.

[0044] In practical applications, a service can have a calling relationship with one or more services. That is, a service identification information can correspond to one or more calling interface information, and different service identification information can also correspond to the same or different calling interface information. This weight information can be jointly determined based on the service identification information and the calling interface information, and the importance of the service and interface to the business can be ranked and weighted.

[0045] S303: Determine the upper limit weight information for each abnormal service node and each downstream service node.

[0046] Optionally, the aforementioned information on determining the upper limit weight of each abnormal service node and each downstream service node may include: Obtain the weight information of the preset call interface information corresponding to the service identification information, as well as the preset adjustment coefficient corresponding to the service identification information; The weight information of the preset call interface information corresponding to the service identifier information and the preset adjustment coefficient are multiplied together to obtain the upper limit weight information.

[0047] In one specific embodiment, the weight information of the preset call interface information corresponding to the service identifier information can be determined according to the first preset mapping relationship described above, and the preset adjustment coefficient corresponding to the service identifier information can be determined according to the second preset mapping relationship. The preset adjustment coefficient can be used to adjust the weight information of the preset call interface information. Specifically, the second preset mapping relationship can be used to characterize the correspondence between the service identifier information and the adjustment coefficient. The second preset mapping relationship can be set according to actual application requirements, and the adjustment coefficients corresponding to different services can be the same or different. Specifically, the preset call interface information can be the default interface DEFAULT.

[0048] S305: Determine the target weight information from the initial weight information and the upper limit weight information.

[0049] In one specific embodiment, the smaller of the initial weight information and the upper limit weight information can be determined as the target weight information. Alternatively, the initial weight information and the upper limit weight information can be calculated (e.g., by averaging) to obtain the target weight information. This prevents the target weight value from being artificially inflated due to the large number of service interfaces, thus affecting the reliability of subsequent anomaly evaluations.

[0050] In practical applications, if the abnormal service node is an H5 service node, the calling interface is the default interface, and the call depth is 3, then the first-level downstream service node of this abnormal service node is the user center service node, and the calling interface is the login interface. The first-level downstream service node of the user center service node is the payment gateway service, and the calling interfaces include the deduction interface and the refund interface. Taking the aforementioned service interface weight settings as an example, the weight corresponding to the default interface of each service node is 0.8, the weight corresponding to the login interface of the user center service is 0.9, and the weights corresponding to the deduction interface and the refund interface of the payment gateway service are 1 and 0.8 respectively. For each service node, by adding up the weights corresponding to its interfaces, the initial weights corresponding to the H5 service node, user center service, and payment gateway service can be calculated to be 0.8, 0.9, and 1.8 respectively. With a preset adjustment coefficient of 1.5, the upper limit weight corresponding to each service is 1.2. Furthermore, the smaller of the initial weight and the upper limit weight corresponding to each service, 0.8, 0.9, and 1.2 respectively, is the target weight information for each service.

[0051] S107: Based on the call depth information, determine the abnormal service node and the corresponding abnormal impact factor for each downstream service node.

[0052] In one specific embodiment, the anomaly impact factor can be used to characterize the degree of influence of an abnormal service node on each service node in the call topology graph. The larger the anomaly impact factor, the higher the degree of influence. The anomaly impact factor can decrease as the call depth information increases, meaning that the service impact is greater closer to the root node (i.e., the abnormal service node). Optionally, the anomaly impact factor corresponding to the call depth information can be determined based on third preset mapping information, and then the anomaly impact factor corresponding to each service node can be determined based on the call hierarchy depth of each service node in the call topology graph.

[0053] Specifically, the third preset mapping information can be used to characterize the correspondence between call depth information and abnormal impact factor. The third preset mapping information can be set according to actual application needs. For example, if the call depth information is 0, the corresponding abnormal impact factor can be set to 1; if the call depth information is 1, the corresponding abnormal impact factor can be set to 0.5; if the call depth information is 2, the corresponding abnormal impact factor can be set to 0.25; if the call depth information is 2, the corresponding abnormal impact factor can be set to 0.125.

[0054] S109: Based on the target weight information and abnormal influence factors corresponding to multiple service nodes in the call topology diagram, calculate the abnormal evaluation result corresponding to the abnormal information.

[0055] In one specific embodiment, the anomaly evaluation result can be used to characterize the degree of impact of abnormal information on the target business. The anomaly evaluation result can be represented by a score or a grade, etc. The higher the value or grade of the anomaly evaluation result, the greater the degree of impact.

[0056] Optional, such as Figure 4 As shown, the anomaly evaluation results calculated based on the target weight information and anomaly impact factors corresponding to multiple service nodes in the call topology graph can include:

[0057] S401: Based on the target weight information of each service node in the call topology graph, multiply the abnormal influence factors of each service node to obtain the target abnormal factor of each service node in the call topology graph.

[0058] Specifically, the target anomaly factor can be used to characterize the degree of impact of anomaly information on the corresponding service. It can be combined with the degree of impact of the anomaly service node on each service node in the call topology graph, as well as the importance of the corresponding service to the target business, to determine the degree of impact of the anomaly information on each service.

[0059] S403: Sum the target anomaly factors corresponding to each service node to obtain the anomaly evaluation result.

[0060] In practical applications, taking the aforementioned service nodes and corresponding target weights as examples, the target weights for the H5 service, user center service, and payment gateway service are 0.8, 0.9, and 1.2, respectively, and their corresponding anomaly impact factors are 1, 0.5, and 0.25, respectively. Correspondingly, their target anomaly factors are 0.8, 0.45, and 0.3, respectively. Adding these target anomaly factors yields an anomaly evaluation result of 1.55. Optionally, to prevent extreme values, the obtained anomaly evaluation result can be optimized by pre-setting an upper limit evaluation result (e.g., 3), and taking the smaller of the above anomaly evaluation result and the upper limit evaluation result as the final anomaly evaluation result (i.e., 1.55).

[0061] In the above embodiments, based on the calculation method of the anomaly evaluation results, without relying on complex models and large amounts of historical data, the actual impact of a single anomaly on the overall business is accurately quantified. An interpretable and comparable comprehensive impact result (i.e., anomaly evaluation result) is calculated for each anomaly. Services closer to the root node (the anomaly service node) receive higher anomaly evaluation results, and services with a greater impact on the business (such as payment services) also receive higher anomaly evaluation results. The calculated anomaly evaluation results are both consistent with technical logic and meet the needs of operational decisions. The contribution of each service node to the comprehensive impact result is clearly visible, and the evaluation results have clear business meaning, allowing operations personnel to intuitively understand the degree and scope of the anomaly's impact. Simultaneously, the unified evaluation standard enables horizontal comparisons between anomalies of different types and sources, providing an objective and quantifiable basis for priority ranking.

[0062] Optionally, the above method may also include: If the anomaly evaluation results meet the preset conditions, the target anomaly level corresponding to the anomaly information is determined, and the corresponding early warning content information is sent based on the corresponding early warning channel information.

[0063] In one specific embodiment, the target anomaly level can be used to characterize the urgency of an anomaly requiring handling, more intuitively displaying the impact of anomaly information on business operations. A higher target anomaly level indicates a higher urgency, ensuring timely handling of anomalies with significant business impact. Specifically, the warning channel information can be the notification channel for the warning, and the warning content information can be the aforementioned anomaly message with a unified format. Different target anomaly levels can correspond to different warning channel information and warning content information. As the target anomaly level gradually decreases, indicating a decreasing urgency of handling the anomaly, the warning channel information can be, in order, telephone notification, strong notification via WeChat Work (such as pop-ups), email notification, regular notification via WeChat Work, and channels that only display on the alarm platform without pushing related notifications. Specifically, the above preset conditions can be set according to actual application needs.

[0064] Optionally, when the anomaly evaluation results meet preset conditions, determining the target anomaly level corresponding to the anomaly information may include: If the abnormal evaluation result is greater than or equal to the first preset evaluation threshold, the first abnormal level will be determined as the target abnormal level. If the abnormal evaluation result is greater than or equal to the second preset evaluation threshold and less than the first preset evaluation threshold, the second abnormal level will be determined as the target abnormal level. If the abnormal evaluation result is greater than or equal to the third preset evaluation threshold and less than the second preset evaluation threshold, the third abnormal level will be determined as the target abnormal level. If the anomaly evaluation result is less than the third preset evaluation threshold, the fourth anomaly level will be determined as the target anomaly level.

[0065] In one specific embodiment, the larger the value of the anomaly evaluation result, the higher the anomaly level. The first, second, third, and fourth anomaly levels decrease sequentially, corresponding to a decrease in the urgency of handling the anomaly and a decrease in its impact on business operations. Consequently, the warning intensity and warning methods gradually decrease. The first, second, and third preset evaluation thresholds can all be set according to actual application needs, for example, they can be set to 2, 1, and 0.5, respectively.

[0066] In the above embodiments, a large number of anomalies can be intelligently filtered and prioritized according to the anomaly level corresponding to the anomaly information, accurately and efficiently identifying key anomalies affecting core business and edge service jitter, and quickly locating the fault source that truly affects business among a large number of anomalies.

[0067] As can be seen from the technical solutions provided in the embodiments of this specification above, during the processing of the target business, abnormal information is obtained, including abnormal identification information. Then, the call topology graph of the abnormal service node corresponding to the abnormal identification information is determined. The call topology graph represents the call relationships between the abnormal service node and multiple downstream service nodes within a preset time period. Specifically, the call topology graph includes service identification information, call interface information, and call depth information. Furthermore, based on the service identification information and call interface information, the target weight information corresponding to the abnormal service node and each downstream service node is determined. The target weight information represents the importance of the corresponding service to the target business. And, based on the call depth information, the abnormal impact factor corresponding to the abnormal service node and each downstream service node is determined. The abnormal impact factor represents the degree of influence of the abnormal service node on each service node in the call topology graph. Finally, based on the target weight information and abnormal impact factor corresponding to multiple service nodes in the call topology graph, the abnormal evaluation result corresponding to the abnormal information is calculated. The abnormal evaluation result represents the degree of influence of the abnormal information on the target business.

[0068] Therefore, by constructing a partial call topology diagram downstream of the abnormal service node, which includes service identifier, call interface, and call depth information, the propagation path of the anomaly in the business chain can be effectively described. Furthermore, by combining the business importance weights at both the service and interface levels, as well as the anomaly impact factor dynamically calculated based on call depth, the impact of the anomaly on the target business can be quantified. This can improve the interpretability and business relevance of anomaly evaluation, thereby efficiently supporting the operation and maintenance decisions of large-scale microservice systems and ensuring system stability and business continuity.

[0069] This invention also provides a service exception handling device, such as... Figure 5 As shown, the device includes: The acquisition module 510 is used to acquire abnormal information during the processing of the target business; the abnormal information includes abnormal identification information. The topology graph determination module 520 is used to determine the call topology graph of the abnormal service node corresponding to the abnormal identification information; the call topology graph is used to represent the call relationship between the abnormal service node and multiple downstream service nodes within a preset time period, and the call topology graph includes service identification information, call interface information and call depth information; The target weight information determination module 530 is used to determine the target weight information corresponding to the abnormal service node and each of the downstream service nodes based on the service identification information and the call interface information; the target weight information is used to characterize the importance of the corresponding service to the target business; An anomaly impact factor determination module 540 is used to determine the anomaly impact factor corresponding to the anomaly service node and each of the downstream service nodes based on the call depth information; the anomaly impact factor is used to characterize the degree of influence of the anomaly service node on each service node in the call topology graph; The anomaly evaluation result determination module 550 is used to calculate the anomaly evaluation result corresponding to the anomaly information based on the target weight information and anomaly impact factor corresponding to each of the multiple service nodes in the call topology graph; the anomaly evaluation result is used to characterize the degree of impact of the anomaly information on the target business.

[0070] Optionally, the target weight information determination module 530 includes: The initial weight information determination unit is used to sum the weight information of the corresponding call interface information for each service identifier information to obtain the initial weight information corresponding to the abnormal service node and each of the downstream service nodes. The upper limit weight information determination unit is used to determine the upper limit weight information corresponding to the abnormal service node and each of the downstream service nodes. The target weight information determination unit is used to determine the target weight information from the initial weight information and the upper limit weight information.

[0071] Optionally, the upper limit weight information determination unit includes: The first acquisition unit is used to acquire the weight information of the preset call interface information corresponding to the service identification information, and the preset adjustment coefficient corresponding to the service identification information. The multiplication processing unit is used to multiply the weight information of the preset call interface information corresponding to the service identifier information and the preset adjustment coefficient to obtain the upper limit weight information.

[0072] Optionally, the anomaly evaluation result determination module 550 includes: The target anomaly factor determination unit is used to multiply the anomaly influence factors corresponding to the multiple service nodes according to the target weight information of the multiple service nodes in the call topology graph, so as to obtain the target anomaly factor corresponding to each service node in the call topology graph. The anomaly evaluation result determination unit is used to sum the target anomaly factors corresponding to each of the service nodes to obtain the anomaly evaluation result.

[0073] Optionally, the topology map determination module 520 includes: The second acquisition unit is used to acquire valid call chain information corresponding to multiple services in the target business within the preset time period; The target call chain information determination unit is used to determine the target call chain information between the abnormal service node and the multiple downstream service nodes corresponding to the abnormal service node from the valid call chain information. The topology graph construction unit is invoked to construct the call topology graph based on the target call chain information, with the abnormal service node as the root node; the call depth information between each downstream service node and the abnormal service node does not exceed a preset depth threshold.

[0074] Optionally, the acquisition module 510 includes: The third acquisition unit is used to acquire alarm information; An anomaly information determination unit is used to parse the alarm information and map it into a preset format to obtain the anomaly information.

[0075] Optionally, the device further includes: The target anomaly level determination module is used to determine the target anomaly level corresponding to the anomaly information when the anomaly evaluation result meets the preset conditions, so as to send the corresponding early warning content information based on the corresponding early warning path information.

[0076] Optionally, the target anomaly level determination module includes: The first target anomaly level determination unit is used to determine the first anomaly level as the target anomaly level when the anomaly evaluation result is greater than or equal to the first preset evaluation threshold. The second target anomaly level determination unit is used to determine the second anomaly level as the target anomaly level when the anomaly evaluation result is greater than or equal to the second preset evaluation threshold and less than the first preset evaluation threshold. The third target anomaly level determination unit is used to determine the third anomaly level as the target anomaly level when the anomaly evaluation result is greater than or equal to the third preset evaluation threshold and less than the second preset evaluation threshold. The fourth target anomaly level determination unit is used to determine the fourth anomaly level as the target anomaly level when the anomaly evaluation result is less than the third preset evaluation threshold.

[0077] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0078] Figure 6 This is a block diagram illustrating a terminal electronic device for service exception handling according to an exemplary embodiment. The electronic device may be a terminal, and its internal structure diagram may be as follows: Figure 6As shown, the electronic device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a service exception handling method. The display screen can be a liquid crystal display (LCD) or an e-ink display. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the device's casing, or an external keyboard, touchpad, or mouse.

[0079] Figure 7 This is a block diagram illustrating a server electronic device for service exception handling according to an exemplary embodiment. The electronic device may be a server, and its internal structure diagram may be as follows: Figure 7 As shown, this electronic device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a service exception handling method.

[0080] Those skilled in the art will understand that Figure 6 or Figure 7 The structures shown are merely block diagrams of some structures related to the disclosed solutions of this invention, and do not constitute a limitation on the electronic devices to which the disclosed solutions of this invention are applied. Specific electronic devices may include more or fewer components than those shown in the figures, or combine certain components, or have different component arrangements.

[0081] In an exemplary embodiment, an electronic device for service exception handling is also provided, including a processor and a memory, the memory storing at least one instruction, which is loaded and executed by the processor to implement the service exception handling method as disclosed in the embodiments of the present invention.

[0082] In an exemplary embodiment, a computer-readable storage medium is also provided, which stores at least one instruction, which is loaded and executed by a processor to implement the service exception handling method in the embodiments disclosed herein.

[0083] In an exemplary embodiment, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute the service exception handling method disclosed in this invention.

[0084] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0085] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles disclosed herein and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of the invention are indicated by the following claims.

[0086] It should be understood that the present invention is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the present invention is limited only by the appended claims.

Claims

1. A service exception handling method, characterized in that, The method is applied to a microservice system, and the method includes: During the processing of the target business, abnormal information is obtained; the abnormal information includes abnormal identification information. Determine the call topology diagram of the abnormal service node corresponding to the abnormal identification information; the call topology diagram is used to represent the call relationship between the abnormal service node and multiple downstream service nodes within a preset time period, and the call topology diagram includes service identification information, call interface information and call depth information; Based on the service identifier information and the call interface information, the target weight information corresponding to the abnormal service node and each of the downstream service nodes is determined; the target weight information is used to characterize the importance of the corresponding service to the target business. Based on the call depth information, an abnormal impact factor is determined for each abnormal service node and each of the downstream service nodes; the abnormal impact factor is used to characterize the degree of influence of the abnormal service node on each service node in the call topology graph. Based on the target weight information and abnormal impact factor corresponding to each of the multiple service nodes in the call topology diagram, the abnormal evaluation result corresponding to the abnormal information is calculated; the abnormal evaluation result is used to characterize the degree of impact of the abnormal information on the target business.

2. The method according to claim 1, characterized in that, The step of determining the target weight information corresponding to the abnormal service node and each of the downstream service nodes based on the service identifier information and the call interface information includes: For each service identifier, the weight information of the corresponding call interface information is summed to obtain the initial weight information corresponding to the abnormal service node and each of the downstream service nodes. Determine the upper limit weight information corresponding to the abnormal service node and each of the downstream service nodes; The target weight information is determined from the initial weight information and the upper limit weight information.

3. The method according to claim 2, characterized in that, The determination of the upper limit weight information corresponding to the abnormal service node and each of the downstream service nodes includes: Obtain the weight information of the preset call interface information corresponding to the service identifier information, and the preset adjustment coefficient corresponding to the service identifier information; The upper limit weight information is obtained by multiplying the weight information of the preset call interface information corresponding to the service identifier information and the preset adjustment coefficient.

4. The method according to claim 1, characterized in that, The step of calculating the anomaly evaluation result corresponding to the anomaly information based on the target weight information and anomaly impact factor of each of the multiple service nodes in the call topology graph includes: Based on the target weight information corresponding to each of the multiple service nodes in the call topology graph, the abnormal influence factors corresponding to each of the multiple service nodes are multiplied to obtain the target abnormal factor corresponding to each service node in the call topology graph. The anomaly evaluation result is obtained by summing the target anomaly factors corresponding to each service node.

5. The method according to claim 1, characterized in that, The process of determining the call topology of the abnormal service node corresponding to the abnormal identifier information includes: Obtain valid call chain information corresponding to multiple services in the target business within the preset time period; From the valid call chain information, determine the target call chain information between the abnormal service node and the multiple downstream service nodes corresponding to the abnormal service node; Using the abnormal service node as the root node, the call topology graph is constructed based on the target call chain information; the call depth information between each downstream service node and the abnormal service node does not exceed a preset depth threshold.

6. The method according to claim 1, characterized in that, The acquisition of abnormal information includes: Obtain alarm information; The alarm information is parsed and mapped into a preset format to obtain the abnormal information.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: If the anomaly evaluation result meets the preset conditions, the target anomaly level corresponding to the anomaly information is determined, and the corresponding early warning content information is sent based on the corresponding early warning path information.

8. The method according to claim 7, characterized in that, Determining the target anomaly level corresponding to the anomaly information when the anomaly evaluation result meets preset conditions includes: If the abnormal evaluation result is greater than or equal to the first preset evaluation threshold, the first abnormal level is determined as the target abnormal level. If the abnormal evaluation result is greater than or equal to the second preset evaluation threshold and less than the first preset evaluation threshold, the second abnormal level is determined as the target abnormal level. If the abnormal evaluation result is greater than or equal to the third preset evaluation threshold and less than the second preset evaluation threshold, the third abnormal level is determined as the target abnormal level. If the anomaly evaluation result is less than the third preset evaluation threshold, the fourth anomaly level will be determined as the target anomaly level.

9. A service exception handling device, characterized in that, The device includes: The acquisition module is used to acquire abnormal information during the processing of the target business; the abnormal information includes abnormal identification information. The topology graph determination module is invoked to determine the call topology graph of the abnormal service node corresponding to the abnormal identification information; the call topology graph is used to represent the call relationship between the abnormal service node and multiple downstream service nodes within a preset time period, and the call topology graph includes service identification information, call interface information and call depth information; The target weight information determination module is used to determine the target weight information corresponding to the abnormal service node and each of the downstream service nodes based on the service identification information and the call interface information; the target weight information is used to characterize the importance of the corresponding service to the target business; An abnormal impact factor determination module is used to determine the abnormal impact factor corresponding to the abnormal service node and each of the downstream service nodes based on the call depth information; the abnormal impact factor is used to characterize the degree of influence of the abnormal service node on each service node in the call topology graph; The anomaly evaluation result determination module is used to calculate the anomaly evaluation result corresponding to the anomaly information based on the target weight information and anomaly impact factor of each of the multiple service nodes in the call topology graph; the anomaly evaluation result is used to characterize the degree of impact of the anomaly information on the target business.

10. An electronic device for handling service anomalies, characterized in that, The electronic device includes a processor and a memory, the memory storing at least one instruction, which is loaded and executed by the processor to implement the service exception handling method as described in any one of claims 1 to 8.

11. A computer storage medium, characterized in that, The computer storage medium stores at least one instruction, which is loaded and executed by a processor to implement the service exception handling method as described in any one of claims 1 to 8.

Images