Global exception processing method and platform in large-scale micro-service cluster scenario

Abstract

This invention relates to the field of computer microservice applications and discloses a global exception handling method and platform for large-scale microservice cluster scenarios. The method includes the following steps: obtaining all original exception information from the microservice cluster; processing the microservice exception information to obtain first concatenated exception information, and processing the common component exception information to obtain second concatenated exception information; sending the obtained first and second concatenated exception information to a Spring framework aspect for exception encapsulation processing to obtain corresponding first and second encapsulated exception information; and returning the first and second encapsulated exception information to the sender of the corresponding original exception information. This invention can solve the problem of difficult unified management of exception handling in existing systems, and achieves functions such as centralized storage, fast query, and unified processing of global exceptions with less resource consumption.

Description

Technical Field

[0001] This invention relates to the field of computer microservice applications, and in particular to a global exception handling method and platform for large-scale microservice cluster scenarios. Background Technology

[0002] Microservices are an architectural design approach where each microservice is deployed independently, focusing on completing only one task. Clustering, on the other hand, achieves load balancing by deploying the same set of services on different servers for external access. Many large and complex application systems currently break down business logic into multiple sub-businesses and then deploy each sub-business in a cluster. If a sub-business experiences a problem, the entire system can still function normally. Each sub-business can consist of one or more microservices. Each microservice typically includes an external service interface for providing services such as user login and registration to external clients; and an internal service interface for inter-microservice calls to implement a complete business process.

[0003] In practical applications, whether providing microservices to external clients as a server or inter-microservice calls, exceptions are inevitable and require timely capture and handling. Exceptions are categorized as checked and unchecked. When any exception occurs, the system's business logic must handle it to prevent it from being directly thrown to the user. Checked exceptions require handling at the method that generated the exception, and this handling may be distributed throughout the system. Unchecked exceptions can be handled at the top level of the method / service call. Since a system has numerous method / service calls, unchecked exception handling may also occur at various call points. Therefore, managing exception handling across different parts of the system is difficult.

[0004] The industry commonly uses Spring's aspect-based approach for global exception handling in business systems. Spring is a microservice framework where aspects consist of pointcuts and enhancements, encompassing both cross-cutting logic and join point definitions. Spring's exception handling methods target classes annotated with specific methods, enabling business logic processing for specific exceptions. While this approach can handle global exceptions within a single service, it struggles to achieve high cohesion between exception handling and business logic, making it less suitable for multi-service scenarios like microservice clusters. Furthermore, exception messages may require replacement of certain fields, and the content thrown may differ across scenarios. Large-scale microservice clusters require a balance between unified exception handling and minimizing system focus on specific exception handling aspects. Finally, each microservice may use common components like databases; placing exception handling for these common components within individual microservices would result in redundant code. Summary of the Invention

[0005] Technical objective: To address the aforementioned technical problems, this invention discloses a global exception handling method and platform for large-scale microservice cluster scenarios, which enables centralized storage, rapid querying, and unified processing of global exceptions in large-scale microservice cluster scenarios.

[0006] Technical solution: To achieve the above technical objectives, the present invention adopts the following technical solution:

[0007] A global exception handling method for large-scale microservice cluster scenarios, characterized by the following steps:

[0008] Retrieve all raw exception information from the microservice cluster;

[0009] Based on the difference in information format, the obtained raw exception information is classified into microservice exception information and public component exception information. The microservice exception information is processed to obtain the first concatenated exception information, and the public component exception information is concatenated to obtain the second concatenated exception information.

[0010] The first and second concatenated exception information are sent to the Spring framework aspect for exception encapsulation processing to obtain the corresponding first and second encapsulated exception information.

[0011] Return the first and second encapsulated exception information to the sender of the corresponding original exception information.

[0012] Preferably, the acquired raw exception information is classified into microservice exception information and public component exception information, including the following steps:

[0013] Determine whether the original exception information is represented in a format including the microservice name, exception code, exception message with a first variable, and a second variable. If so, classify the original exception information as microservice exception information; otherwise, classify the original exception information as public component exception information.

[0014] Preferably, the process of processing microservice exception information to obtain first concatenated exception information, and concatenating common component exception information to obtain second concatenated exception information, includes the following steps:

[0015] For microservice exception information, determine the source of the exception from the microservice name, replace the first variable in the microservice exception information with the second variable, and obtain the first concatenated exception information.

[0016] For common component exception information, the common component exception information is concatenated according to a predefined format to obtain the second concatenated exception information.

[0017] Preferably, the original exception information is generated by any microservice in the microservice cluster when a service call error occurs, and is issued by the called microservice; or it is generated by the microservice that accesses and discovers the exception of the public component when a public component malfunctions.

[0018] Preferably, the original exception information, the first concatenated exception information, and the second concatenated exception information are stored in the form of a Map, where the key is the exception code and the value is the content of the exception information, and the exception code is defined as a global static constant.

[0019] A global exception handling platform, characterized in that it includes:

[0020] The detector module is used to acquire all raw exception information from the microservice cluster and classify the acquired raw exception information into microservice exception information and common component exception information according to the difference in information format. Then, the microservice exception information is processed to obtain the first concatenated exception information, and the common component exception information is processed to obtain the second concatenated exception information.

[0021] The encapsulation module is used to send the first concatenated exception information and the second concatenated exception information to the Spring framework aspect for exception encapsulation processing, and obtain the corresponding first encapsulated exception information and the second encapsulated exception information.

[0022] The feedback module is used to return the first and second encapsulated exception information to the sender of the corresponding original exception information.

[0023] Preferably, it also includes a service module, used to receive exception information query requests and perform exception information queries.

[0024] Preferably, it also includes a storage module for storing all original abnormal information, first splicing abnormal information and second splicing abnormal information.

[0025] A medium storing computer-executable instructions, characterized in that: the instructions are used to implement the method when executed by a processing unit.

[0026] An electronic device is characterized in that it includes a processing unit and a storage unit, storing computer-executable instructions, which, when executed by the processing unit, are used to implement the method.

[0027] Beneficial effects: Compared with the prior art, the present invention has the following technical effects:

[0028] The solution adopted in this invention can solve the problem of difficult unified management of global exception handling in large-scale microservice cluster scenarios. It uses an exception handling platform to uniformly process exception information and combines the aspect capabilities of the Spring framework to achieve functions such as centralized storage, fast query and unified processing of global exceptions with less resource consumption, thereby minimizing the amount of exception information to be processed in the system. Attached Figure Description

[0029] Figure 1 This is a flowchart of a global exception handling method in an embodiment of the present invention;

[0030] Figure 2 This is a schematic diagram of the structure of the entire microservice group in the Internet in an embodiment of the present invention;

[0031] Figure 3 This is a schematic diagram of the structure of the global exception handling platform in an embodiment of the present invention. Detailed Implementation

[0032] Example 1

[0033] This embodiment provides a global exception handling method for a large-scale microservice cluster scenario, including the following steps:

[0034] Retrieve all raw exception information from the microservice cluster;

[0035] Based on the difference in information format, the obtained raw exception information is classified into microservice exception information and public component exception information. The microservice exception information is processed to obtain the first concatenated exception information, and the public component exception information is processed to obtain the second concatenated exception information.

[0036] The obtained first and second concatenated exception information are sent to the Spring framework aspect for exception encapsulation processing to obtain the corresponding first and second encapsulated exception information.

[0037] Return the first and second encapsulated exception information to the sender of the corresponding original exception information;

[0038] The original exception information is generated when any microservice in the microservice cluster encounters an error during a service call, and is issued by the called microservice; or it is generated when a common component encounters an exception, and is issued by the microservice that accesses and discovers the exception in the common component.

[0039] Specifically, when classifying the acquired raw anomaly information based on differences in information format, the steps include:

[0040] Analyze the format of the received original exception information. If the original exception information is represented in the format of including microservice ID, exception code ID, exception message with first variable, and second variable, determine that the original exception information is classified as microservice exception information; otherwise, classify the original exception information as public component exception information.

[0041] Specifically, the processing of the classified raw anomaly information includes the following steps:

[0042] When processing microservice exception information, the source of the exception is determined based on the microservice ID, and the first variable in the original exception information is replaced with the second variable to obtain the first concatenated exception information; for example, if the original information includes "device %s exception, PE1", "%s" is the first variable and "PE1" is the second variable.

[0043] When processing exception information of common components, the exception information of common components is concatenated according to a predefined format to obtain the second concatenated exception information.

[0044] The original exception information, the first concatenated exception information, and the second concatenated exception information are stored in the form of a Map, where the key is the exception code and the value is the content of the exception information. The exception code is defined as a global static constant.

[0045] Specifically, microservice exception information includes: exceptionEnum (the exception code), serviceId (the microservice name), exceptionMessage (with a first variable, errorVariable), and a second variable. Different microservices can define different microservice names, serviceId.

[0046] Example 2

[0047] like Figure 3As shown, this embodiment provides a global exception handling platform. First, a unified exception handling platform decoupled from business code needs to be built. The platform consists of two modules: a detector module for storing and processing exceptions, and a service module for querying exceptions. The detector module's processing includes two aspects: concatenating variables from exception information and handling exceptions in common components.

[0048] Specifically, it includes:

[0049] The detector module is used to acquire all raw exception information from the microservice cluster and classify the acquired raw exception information into microservice exception information and common component exception information according to the difference in information format. Then, the microservice exception information is processed to obtain the first concatenated exception information, and the common component exception information is processed to obtain the second concatenated exception information.

[0050] The encapsulation module is used to send the obtained first and second concatenated exception information to the Spring framework aspect for exception encapsulation processing, and obtain the corresponding first and second encapsulated exception information.

[0051] The feedback module is used to return the first and second encapsulated exception information to the sender that issued the corresponding original exception information.

[0052] The service module is used to receive exception information query requests and perform exception information queries.

[0053] The storage module stores all original exception information, first exception information, and second exception information.

[0054] Furthermore, each microservice includes a service publishing module, a business process module, a remote invocation module, and an information processing module.

[0055] The service publishing module is used to send business requirements to the business process module, and to receive business requests from other microservices and send the business requests to the business process module.

[0056] The business process module is used to process business information sent by the service publishing module, and to call the detector module or service module of the global exception handling platform when a service call or a common component exception occurs.

[0057] The remote call module is used to send business requests to other microservices or receive encapsulated exception information sent by other microservices.

[0058] The information processing module is used to receive encapsulated exception information forwarded by the remote call module, and to process or forward the encapsulated exception information.

[0059] The service module depends on the detector module. It provides a service query interface to the outside world and can query the abnormal information in the detector module. For example, it exposes a URL query interface with the GET protocol. If an abnormal information has added abnormal handling steps and the amount of information is large, the user can query the abnormal information and return the abnormal information and handling steps by using the abnormal code displayed on the interface.

[0060] Example 3:

[0061] Figure 1 The following is an application example of the global exception handling platform in Example 2.

[0062] A cluster service contains microservices A, B, C, and D. Microservice A calls microservice B, and microservice B calls microservices C and D. In order to perform global exception handling, exception information for microservices B, C, and D needs to be defined in the detector module.

[0063] Taking the process of microservice A calling microservice B as an example, it includes the following steps:

[0064] (1) Microservice A initiates a remote microservice call to microservice B;

[0065] (2) Microservice B performs business processing based on the instructions sent by microservice A; if microservice B's business processing is correct, it returns response information to microservice A; if there is an error, microservice B calls the detector module of the global exception handling platform to handle the exception.

[0066] (3) The detector module generates the concatenated exception information and throws it out;

[0067] (4) The assembled exception information is captured by the Spring framework aspect, and after unified exception encapsulation processing at the Spring framework aspect, it is returned to microservice B.

[0068] (5) Microservice B returns the encapsulated exception information to microservice A;

[0069] (6) Microservice A handles exceptions.

[0070] The detector module adds a definition format for system exception information. All exception information is stored in the form of a Map, where the key is the exception code and the value is the content of the exception information.

[0071] 1) Microservice exception handling:

[0072] In the detector module, define a class BMircoServiceConstants for microservice B to represent the exception information of microservice B; define a global static constant PE_NOT_EXIST to represent the exception code when the PE device does not exist; define a global Map structure to store exception information; and store the exception code and exception information in the Map.

[0073] The method for handling exception information of microservice B is as follows: the input parameter exceptionEnum is the exception code, and errorVariable is the variable that needs to be replaced in the exception information; the detector method in the detector module is called to process it, and the wrapped exception class of microservice B is returned. Finally, the concatenated exception information is thrown.

[0074] If the first variable in the microservice exception message before concatenation can be temporarily filled with %s or other content, then during concatenation, the second variable, errorVariable, should be replaced with the second variable. For example, if errorVariable is "PE1" and exceptionMessage is "Device %s exception", the first exception message after concatenation will be "Device PE1 exception".

[0075] 2) Handling of common component exception information:

[0076] The detector module concatenates common component exception information according to a predefined format to obtain a second concatenated exception message. Specifically, this involves the following steps: determining whether the common component exception information belongs to a predefined, identifiable common component exception; if so, packaging it into a second concatenated exception message with an exception code and exception information (i.e., packaging it as a BaseException) and then throwing it to the Spring framework aspect; otherwise, it is thrown directly and handled by the corresponding microservice.

[0077] Taking a database syntax error as an example, the handling steps include the following:

[0078] Add a Map to the CommonConstants class in the detector module that stores common exceptions. The key of the Map is the exception code. Here, you can add a global static constant, SQL_SYNTAX_ERROR, to represent the exception code and put it into the Map. The value is "database syntax exception".

[0079] Then, during the common exception handling, the `handlerException` method of the common exception handling class `CommonExceptionHandler` is executed directly. In this method, the handling logic for "database syntax exception" can be added. The logic is to first determine whether the exception is of type `MySQLSyntaxErrorException`. If it is, then define a `BaseException` and throw it. The content of `BaseException` is the exception code and exception information mentioned above.

[0080] The exception information definition, handling methods, and execution flow for microservice B calling microservices C and D are similar and will not be repeated here.

[0081] Example 4

[0082] Figure 2 The diagram shown is a schematic of the microservice group where the global exception handling platform in Example 2 is located on the public network.

[0083] Microservices have internal service call interfaces for use within the cluster and external service interfaces for use outside the cluster. The external service interfaces provide services to the public network through the API routing gateway Spring Cloud Gateway, such as providing user login and registration service interfaces to external clients.

[0084] External clients, such as mobile devices and computers, access the public network. After security authentication via nginx reverse proxy and API routing gateway, and load balancing (Ribbon) or service rate limiting and circuit breaking (Sentiel), they connect to the microservice cluster. In a Spring Cloud-based microservice architecture, external service interfaces are exposed to the public network through the Spring Cloud Gateway API routing gateway, while internal service interfaces are shielded by the API routing gateway. Internal microservices operate within the microservice cluster and are not exposed to the public network. All microservices register their information with Nacos. The Nacos component stores storage information and provides a service list query interface. Spring Cloud Gateway can then query all currently active microservices through Nacos.

[0085] In the global exception handling platform, system development engineers write exception information code and add the definition format of system exception information to the detector module. When the detector module handles exceptions for common components, it defines the handling of Exception exceptions in Spring's exception handling aspect. The handling content initially uses the public ErrorResulthandlerException(Exception ex)throws Exception method.

[0086] If a defined BaseException is thrown, it means that it is a known exception and has been handled. Otherwise, it means that there are still unhandled exceptions in the system, and additional code is needed to handle them. Specifically, if it is a database exception, which is the so-called common three-component exception, the common component exception is wrapped into a recognized custom BaseException and thrown. If it is not a known common component exception, it is thrown directly and left to be handled by the respective microservice.

[0087] In summary, this invention establishes a unified exception handling platform in a microservice cluster scenario. It combines the aspect-oriented capabilities of the Spring framework, which includes an AOP (Aspect-Oriented Programming) module. This module encapsulates logic or responsibilities that are unrelated to business logic but are commonly invoked by business modules at the aspect level. This helps reduce code duplication, decreases coupling between modules, and improves future operability and maintainability.

[0088] The present invention also provides a medium storing computer-executable instructions, which, when executed by a processing unit, are used to implement any of the above-described global exception handling methods.

[0089] The present invention also provides an electronic device, including a processing unit and a storage unit, storing computer-executable instructions, which, when executed by the processing unit, are used to implement any of the above-described global exception handling methods.

[0090] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A global exception handling method for large-scale microservice cluster scenarios, characterized in that, Including the following steps: Retrieve all raw exception information from the microservice cluster; Based on the difference in information format, the obtained raw exception information is classified into microservice exception information and public component exception information. The microservice exception information is processed to obtain the first concatenated exception information, and the public component exception information is concatenated to obtain the second concatenated exception information. The first and second concatenated exception information are sent to the Spring framework aspect for exception encapsulation processing to obtain the corresponding first and second encapsulated exception information. Return the first and second encapsulated exception information to the sender of the corresponding original exception information; The acquired raw exception information is categorized into microservice exception information and public component exception information, including the following steps: Determine whether the original exception information is represented in the format of including the microservice name, exception code, exception message with a first variable, and a second variable. If so, classify the original exception information as microservice exception information; otherwise, classify the original exception information as public component exception information. The process involves processing microservice exception information to obtain the first concatenated exception information, and concatenating common component exception information to obtain the second concatenated exception information. This includes the following steps: For microservice exception information, determine the source of the exception from the microservice name, replace the first variable in the microservice exception information with the second variable, and obtain the first concatenated exception information. For common component exception information, the common component exception information is concatenated according to a predefined format to obtain the second concatenated exception information.

2. The global exception handling method in a large-scale microservice cluster scenario according to claim 1, characterized in that: The original exception information is generated by any microservice in the microservice cluster when a service call error occurs, issued by the called microservice; or it is generated by the microservice that accesses and discovers the exception of the public component when an exception occurs.

3. The global exception handling method in a large-scale microservice cluster scenario according to claim 1, characterized in that: The original exception information, the first concatenated exception information, and the second concatenated exception information are stored in the form of a Map, where the key is the exception code and the value is the content of the exception information. The exception code is defined as a global static constant.

4. A global exception handling platform, characterized in that, include: The detector module is used to acquire all raw exception information from the microservice cluster and classify the acquired raw exception information into microservice exception information and common component exception information according to the difference in information format. Then, the microservice exception information is processed to obtain the first concatenated exception information, and the common component exception information is processed to obtain the second concatenated exception information. The classification of the acquired raw exception information into microservice exception information and common component exception information includes the following steps: Determine whether the original exception information is represented in the format of including the microservice name, exception code, exception message with a first variable, and a second variable. If so, classify the original exception information as microservice exception information; otherwise, classify the original exception information as public component exception information. The process involves processing microservice exception information to obtain the first concatenated exception information, and concatenating common component exception information to obtain the second concatenated exception information. This includes the following steps: For microservice exception information, determine the source of the exception from the microservice name, replace the first variable in the microservice exception information with the second variable, and obtain the first concatenated exception information. For common component exception information, the common component exception information is concatenated according to a predefined format to obtain the second concatenated exception information; The encapsulation module is used to send the first concatenated exception information and the second concatenated exception information to the Spring framework aspect for exception encapsulation processing, and obtain the corresponding first encapsulated exception information and the second encapsulated exception information. The feedback module is used to return the first and second encapsulated exception information to the sender of the corresponding original exception information.

5. A global exception handling platform according to claim 4, characterized in that: It also includes a service module, which is used to receive exception information query requests and perform exception information queries.

6. A global exception handling platform according to claim 4, characterized in that: It also includes a storage module for storing all original exception information, first concatenated exception information, and second concatenated exception information.

7. A medium storing computer-executable instructions, characterized in that: When executed by the processing unit, the instructions are used to implement the method of any one of claims 1 to 3.

8. An electronic device, characterized in that: It includes a processing unit and a storage unit, and stores computer-executable instructions, which, when executed by the processing unit, are used to implement the method of any one of claims 1 to 3.

Images