Anomaly capture methods, devices, equipment and storage media

Abstract

This invention relates to the field of microservices and discloses an exception handling method, apparatus, device, and storage medium applied to a microservice system, including a gateway layer and at least one microservice module. The method includes: obtaining a business request from a requester through the gateway layer, and determining at least one microservice module and its corresponding interface to be invoked based on the business request; sequentially invoking the corresponding microservice modules through the interfaces, and determining whether the business requirements corresponding to the business request are met during each invocation; if not, re-propagating the exception thrown by the current microservice module through its upper-level caller, processing the exception, and obtaining an exception handling result set; and returning a success message to the requester through the gateway layer when the requirements are met. This method ensures that the location of the exception is clearly identified at each stage by processing the re-propagated exception data by each microservice module, thus improving the efficiency of developers.

Description

Technical Field

[0001] This invention relates to the field of microservices, and more particularly to an anomaly capture method, apparatus, device, and storage medium. Background Technology

[0002] Many cloud platforms are divided into a gateway layer and various business modules serving the entire cloud platform. These business modules have microservice interfaces that call each other. Currently, most microservice interfaces only provide simple database interaction, while the business logic is mostly written in the management layer, leading to a large amount of business logic duplication. Some business logic is also written in their own microservices or in CRM modules developed later. These microservices perform parameter validation and throw specific exceptions to improve the user experience. However, when an exception is thrown by the callee, the caller cannot catch the microservice exception; it can only catch the specific exception. This makes it impossible for the existing system to accurately locate microservice exceptions, resulting in a poor user experience. Summary of the Invention

[0003] The main objective of this invention is to solve the technical problem that existing systems cannot accurately locate microservice anomalies.

[0004] The first aspect of this invention provides an exception handling method applied to a microservice system, the microservice system including a gateway layer and at least one microservice module, comprising: obtaining a business request issued by a requester through the gateway layer, and determining at least one microservice module and its corresponding interface to be invoked based on the business request; sequentially invoking the corresponding microservice module through the interface, and determining whether the business requirements corresponding to the business request are met each time a microservice module is invoked; when there is a microservice module that does not meet the business requirements, the exception thrown by the current microservice module is sequentially propagated upwards through the upper-level caller of the current microservice module, and the exception is processed to obtain an exception handling result set; the exception handling result set and a call exception message are returned to the requester through the gateway layer; when there is no microservice module that does not meet the business requirements, a call success message is returned to the requester through the gateway layer.

[0005] Optionally, in a first implementation of the first aspect of the present invention, before obtaining the business request sent by the requester through the gateway layer, the method further includes: encapsulating an exception base class entity in the gateway layer, constructing a global capture mechanism based on the exception base class entity; performing custom exception encapsulation in each of the microservice modules to obtain a corresponding custom encapsulation class, wherein the custom encapsulation class inherits from the exception base class entity.

[0006] Optionally, in a second implementation of the first aspect of the present invention, the step of sequentially re-propagating exceptions thrown by the current microservice module through the upper-layer caller of the current microservice module and processing the exceptions to obtain an exception processing result set includes: throwing an exception through a custom exception encapsulation class inherited from the gateway layer by the current microservice module; capturing the exception thrown by the current microservice module through the global capture mechanism of the gateway layer, modifying the response information of the exception, sequentially re-propagating the modified exception through the upper-layer caller of the current microservice module until it is re-propagated to the gateway layer; and processing the exception through the exception processing mechanism of the gateway layer to obtain an exception processing result set.

[0007] Optionally, in a third implementation of the first aspect of the present invention, the step of capturing the exception thrown by the current microservice module through the global capture mechanism of the gateway layer includes: obtaining the information thrown by the current microservice module through the global capture mechanism of the gateway layer; determining whether the information thrown by the current microservice module is an exception base class entity or a custom exception encapsulation class; if so, then identifying the information thrown by the current microservice module as an exception and capturing it.

[0008] Optionally, in the fourth implementation of the first aspect of the present invention, the step of modifying the response information of the exception and sequentially re-throwing the modified exception to the gateway layer by the upper-layer caller of the current microservice module includes: modifying the response information of the exception, encapsulating the exception with a response framework, and modifying the response status of the exception to errorMsgCode; intercepting the exception after the response information modification by calling the exception interception mechanism of the microservice module above the current microservice module; and throwing the exception by the custom exception encapsulation class of the upper microservice module, which is then intercepted by the exception interception mechanism of the next upper microservice module, until it is re-thrown to the gateway layer.

[0009] Optionally, in the fifth implementation of the first aspect of the present invention, after the current microservice module throws an exception by the custom exception encapsulation class inherited from the gateway layer, the method further includes: obtaining the internationalization identification code of the current microservice module; parsing the exception to obtain the exception key, and obtaining the corresponding internationalization exception information from a preset database based on the exception key; and responding to the internationalization exception information using the internationalization identification code of the current microservice module.

[0010] Optionally, in a sixth implementation of the first aspect of the present invention, the step of processing the exception through the exception handling mechanism of the gateway layer to obtain an exception handling result set includes: determining the exception type of the exception based on the response information through the exception handling mechanism of the gateway layer; obtaining the corresponding exception handling script based on the exception type; and processing the exception through the exception handling script to obtain an exception handling result set.

[0011] A second aspect of the present invention provides an exception capture device applied to a microservice system, the microservice system including a gateway layer and at least one microservice module, the exception capture device comprising: an interface determination module, configured to obtain a business request issued by a requester through the gateway layer, and determine at least one microservice module and its corresponding interface to be called based on the business request; a judgment module, configured to sequentially call the corresponding microservice module through the interface, and determine whether the business requirements corresponding to the business request are met each time a microservice module is called; an exception handling module, configured to, when there is a microservice module that does not meet the business requirements, sequentially propagate the exception thrown by the current microservice module through the upper-level caller of the current microservice module, process the exception, obtain an exception handling result set, and return the exception handling result set and a call exception message to the requester through the gateway layer; and a success notification module, configured to, when there is no microservice module that does not meet the business requirements, return a call success message to the requester through the gateway layer.

[0012] Optionally, in the first implementation of the second aspect of the present invention, the exception capture device further includes an encapsulation module, which is specifically used for: encapsulating an exception base class entity at the gateway layer, constructing a global capture mechanism based on the exception base class entity; performing custom exception encapsulation in each of the microservice modules to obtain a corresponding custom encapsulation class, wherein the custom encapsulation class inherits from the exception base class entity.

[0013] Optionally, in a second implementation of the second aspect of the present invention, the exception handling module specifically includes: an exception throwing unit, used to throw an exception by a custom exception encapsulation class inherited from the gateway layer by the current microservice module; a modification unit, used to capture the exception thrown by the current microservice module through the global capture mechanism of the gateway layer, modify the response information of the exception, and sequentially propagate the modified exception to the upper-level caller of the current microservice module until it is propagated to the gateway layer; and a processing unit, used to process the exception through the exception handling mechanism of the gateway layer to obtain an exception handling result set.

[0014] Optionally, in a third implementation of the second aspect of the present invention, the modification unit is specifically used to: obtain the information thrown by the current microservice module through the global capture mechanism of the gateway layer; determine whether the information thrown by the current microservice module is an exception base class entity or a custom exception encapsulation class; if so, identify the information thrown by the current microservice module as an exception and capture it.

[0015] Optionally, in the fourth implementation of the second aspect of the present invention, the modification unit is further configured to: modify the response information of the exception, encapsulate the exception with a response framework, and modify the response status of the exception to errorMsgCode; intercept the exception after the response information modification by calling the exception interception mechanism of the previous microservice module of the current microservice module; throw the exception through the custom exception encapsulation class of the previous microservice module, and have it intercepted by the exception interception mechanism of the next higher microservice module, until it is thrown up to the gateway layer.

[0016] Optionally, in a fifth implementation of the second aspect of the present invention, the exception capture device further includes an internationalization module, which is specifically used for: obtaining the internationalization identification code of the current microservice module; parsing the exception to obtain the exception key, and obtaining the corresponding internationalization exception information from a preset database based on the exception key; and responding to the internationalization exception information through the internationalization identification code of the current microservice module.

[0017] Optionally, in a sixth implementation of the second aspect of the present invention, the processing unit is specifically used to: determine the exception type of the exception based on the response information through the exception handling mechanism of the gateway layer; obtain the corresponding exception handling script based on the exception type; process the exception through the exception handling script to obtain an exception handling result set.

[0018] A third aspect of the present invention provides an anomaly capture device, comprising: a memory and at least one processor, wherein the memory stores instructions, and the memory and the at least one processor are interconnected via a circuit; the at least one processor invokes the instructions in the memory to cause the anomaly capture device to perform the steps of the anomaly capture method described above.

[0019] A fourth aspect of the present invention provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the steps of the above-described exception capture method.

[0020] The technical solution of this invention is applied to a microservice system, which includes a gateway layer and at least one microservice module. The gateway layer obtains the business request from the requester and determines the at least one microservice module and its corresponding interface to be invoked based on the business request. The corresponding microservice modules are invoked sequentially through the interfaces, and each time a microservice module is invoked, it is determined whether the business requirements corresponding to the business request are met. If not, the exception thrown by the current microservice module is sequentially propagated upwards through the upper-level caller of the current microservice module, and the exception is processed to obtain an exception handling result set. If the requirements are met, a success message is returned to the requester through the gateway layer. This method, by handling the propagated exception data by each microservice module, ensures that the location of the exception is clearly known at each stage, improving the efficiency of developers. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the first embodiment of the anomaly capture method in this invention;

[0022] Figure 2 This is a schematic diagram of a second embodiment of the anomaly capture method in this invention;

[0023] Figure 3 This is a schematic diagram of a third embodiment of the anomaly capture method in this invention;

[0024] Figure 4 This is a schematic diagram of one embodiment of the anomaly capture device in this invention;

[0025] Figure 5 This is a schematic diagram of another embodiment of the anomaly detection device in this invention;

[0026] Figure 6 This is a schematic diagram of one embodiment of the anomaly capture device in this invention. Detailed Implementation

[0027] The technical solution of this invention is applied to a microservice system, which includes a gateway layer and at least one microservice module. The gateway layer obtains the business request from the requester and determines the at least one microservice module and its corresponding interface to be invoked based on the business request. The corresponding microservice modules are invoked sequentially through the interfaces, and each time a microservice module is invoked, it is determined whether the business requirements corresponding to the business request are met. If not, the exception thrown by the current microservice module is sequentially propagated upwards through the upper-level caller of the current microservice module, and the exception is processed to obtain an exception handling result set. If the requirements are met, a success message is returned to the requester through the gateway layer. This method, by handling the propagated exception data by each microservice module, ensures that the location of the exception is clearly known at each stage, improving the efficiency of developers.

[0028] The terms "first," "second," "third," "fourth," etc. (if present) 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 described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" or "having" and any variations thereof are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0029] For ease of understanding, the specific process of the embodiments of the present invention is described below. Please refer to [link / reference]. Figure 1 The present invention provides an exception handling method applied to a microservice system, the microservice system comprising a gateway layer and at least one microservice module. A first embodiment of the exception handling method includes:

[0030] 101. Obtain the business request sent by the requester through the gateway layer, and determine at least one microservice module and corresponding interface to be called based on the business request;

[0031] It is understood that the executing entity of this invention can be an anomaly detection device, a terminal, or a server; no specific limitation is made here. This embodiment of the invention uses a server as the executing entity as an example for illustration. The server can be an independent server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0032] In practical applications, different microservices typically have different network addresses. Clients must remember dozens or even hundreds of addresses when accessing these microservices, which is too complex and difficult to maintain for the client, increasing development complexity. Therefore, a microservice gateway is needed, acting as an intermediary layer between the client and the server—the gateway layer. All external requests first pass through the microservice gateway. The client only needs to interact with the gateway and knows only one gateway address. In this embodiment, the gateway is a server and the system's sole external entry point. The gateway layer encapsulates the system's internal architecture, providing a customized API for each client. All clients and consumers access the microservices through a unified gateway, handling all non-business functions at the gateway layer.

[0033] In practical applications, microservices are a software development technique and a variant of the service-oriented architecture (SOA) style. It advocates dividing a single application into a set of small services that coordinate and cooperate with each other to provide end value to users. Each service runs in its own independent process, and services communicate with each other using lightweight communication mechanisms.

[0034] In this embodiment, the requester can be a user's personal terminal or a client running on the personal terminal. The business request calls the microservice gateway to trigger the microservice modules to provide services. The information of each microservice module may include the IP address of the corresponding microservice module and the name of the interface provided by the microservice. These two pieces of information can be stored in the microservice gateway in a corresponding storage manner.

[0035] 102. Call the corresponding microservice modules sequentially through the interface, and determine whether the business requirements corresponding to the business request are met each time the microservice module is called;

[0036] In this embodiment, the business request may include the name of the microservice providing the interface to be called. The gateway layer can check whether the name of the interface of the microservice module is pre-stored. If it is pre-stored, the gateway layer obtains the IP address of the microservice module based on the name of the interface. The microservice module corresponding to the determined IP address is the microservice module corresponding to the business request, and then the gateway layer calls the microservice module.

[0037] In this embodiment, the microservice business chain corresponding to the business request can be obtained. The microservice business chain is the order in which microservices are called. In the order in which microservices are called, the microservice that comes first can obtain the address of the microservice that comes later from the registry center so as to realize the sequential calling of the corresponding microservices.

[0038] In this embodiment, after receiving a business request, the microservice module processes the request according to its own business strategy and generates a corresponding intermediate processing result. Based on this intermediate processing result, it determines whether the business requirements corresponding to the request are met. If the microservice does not meet the business requirements, it indicates an anomaly. If the microservice meets the business requirements, it is necessary to determine whether to call the next microservice module based on the microservice business chain. For example, in an interface call scenario, there are three microservices, one of which acts as a gateway. The gateway calls microservice module one, and microservice module one may also call microservice module two. For instance, if microservice module one has an 'external' interface for device control, after the gateway calls this interface, microservice module one must first determine if the device exists. This business logic resides in microservice module three. In this case, microservice module one must call the device control interface of microservice module two to implement the entire device control logic.

[0039] 103. When there is a microservice module that does not meet the business requirements, the exception thrown by the current microservice module is sequentially propagated upwards by the upper-level caller of the current microservice module, the exception is processed, the exception processing result set is obtained, and the exception processing result set and the call exception message are returned to the requester through the gateway layer.

[0040] In practical applications, when a microservice interface has an exception in the business logic, it is usually caught by the internal exception mechanism, and the original exception will be overridden and redefined as a feignException, preventing the exception from being continued.

[0041] In this embodiment, the exception base class entity ServiceException is encapsulated in the gateway layer, and a custom global capture mechanism GlabalExceptionHandler and a custom microservice exception interception mechanism FeignClientErrorDecoder implement the interface ErrorDecoder are used. ServiceException serves as the exception base class, and each other microservice has its own custom exception encapsulation that inherits from this base class and implements its own microservice exception encapsulation class. For example, the exception encapsulation for the microservice module operation is OperationCloudServiceException, the exception encapsulation for the microservice module device is DeviceCloudServiceException, and so on.

[0042] In this embodiment, the called microservice module is the callee, and the microservice module that calls the callee is the caller. The callee's GlabalExceptionHandler globally catches exceptions. For exception catching, the response information for specific microservice exceptions is modified, the response status is changed to the value of errorMsgCode, and then the caught exception is returned directly. The caller implements the FeignClientErrorDecoder of the ErrorDecoder interface to intercept microservice exceptions, extract exception information, re-throw it through the base class ServiceException, and then GlabalExceptionHandler globally catches it. After being processed by the exception handling mechanism, the exception handling result set is returned to the front end.

[0043] 104. When there is no microservice module that does not meet the business requirements, a message indicating a successful call is returned to the requester through the gateway layer.

[0044] In this embodiment, a message indicating a successful call is returned directly to the requester through the gateway layer, and the message carries the results of the business requirements corresponding to the execution of the business requests by each microservice module, so that the user can understand the execution status of the microservice module.

[0045] This embodiment is applied to a microservice system, which includes a gateway layer and at least one microservice module. The gateway layer receives the business request from the requester and determines the at least one microservice module and its corresponding interface to be invoked based on the request. The corresponding microservice modules are then invoked sequentially through the interfaces, and each time a microservice module is invoked, it is determined whether the business requirements corresponding to the request are met. If not, the exception thrown by the current microservice module is propagated upwards through its parent caller, and the exception is processed to obtain an exception handling result set. If the requirements are met, a success message is returned to the requester through the gateway layer. This method, by handling the propagated exception data by each microservice module, ensures that the location of the exception is clearly identified at each stage, improving the efficiency of developers.

[0046] Please see Figure 2 The second embodiment of the anomaly capture method in this invention includes:

[0047] 201. Encapsulate the exception base class entity at the gateway layer and build a global capture mechanism based on the exception base class entity;

[0048] In this embodiment, the exception base class entity ServiceException is encapsulated in the gateway layer, and a custom global capture mechanism GlabalExceptionHandler is used.

[0049] 202. Each microservice module performs custom exception encapsulation to obtain a corresponding custom encapsulation class, wherein the custom encapsulation class inherits from the exception base class entity;

[0050] In this embodiment, the exception base class entity ServiceException encapsulated by the gateway layer serves as the exception base class. Each other microservice defines its own exception encapsulation, inherits from this base class, and implements its own microservice exception encapsulation class. For example, the exception encapsulation for operation is OperationCloudServiceException, the exception encapsulation for device is DeviceCloudServiceException, and so on.

[0051] 203. Obtain the business request sent by the requester through the gateway layer, and determine at least one microservice module and corresponding interface to be called based on the business request;

[0052] 204. Call the corresponding microservice modules sequentially through the interface, and determine whether the business requirements corresponding to the business request are met each time the microservice module is called;

[0053] 205. When there is a microservice module that does not meet the business requirements, an exception is thrown through the custom exception wrapper class inherited from the gateway layer by the current microservice module.

[0054] In this embodiment, the called microservice module is the callee, and the microservice module that calls the callee is the caller. The callee is a microservice module that does not meet the business requirements and throws the corresponding custom exception through a custom exception encapsulation that inherits from the exception base class entity ServiceException.

[0055] 206. Obtain information thrown by the current microservice module through the global capture mechanism of the gateway layer;

[0056] 207. Determine whether the information thrown by the current microservice module is an exception base class entity or a custom exception wrapper class;

[0057] 208. If so, the information thrown by the current microservice module will be identified as an exception and captured.

[0058] 209. Modify the response information for exceptions, and then propagate the modified exceptions sequentially to the upper-level caller of the current microservice module until they are propagated to the gateway layer.

[0059] In this embodiment, GlabalExceptionHandler globally captures exceptions. For exception capture, it modifies the response information for specific microservice exceptions, changes the response status to the value of errorMsgCode, and then directly returns the captured exception.

[0060] In this embodiment, the caller implements the FeignClientErrorDecoder interface of the ErrorDecoder interface to intercept microservice exceptions, extract the exception information, re-throw it through the base class ServiceException, and then globally capture it by GlabalExceptionHandler. The exceptions are then thrown up the chain according to the microservice call chain until they are returned to the gateway layer for exception handling.

[0061] 210. The exception is handled through the exception handling mechanism of the gateway layer, the exception handling result set is obtained, and the exception handling result set and the message of calling the exception are returned to the requester through the gateway layer.

[0062] 211. When there is no microservice module that does not meet the business requirements, a message indicating a successful call is returned to the requester through the gateway layer.

[0063] This embodiment, building upon the previous embodiment, details the process of sequentially propagating exceptions thrown by the current microservice module through its upper-layer caller, processing these exceptions, and obtaining an exception handling result set. This is achieved by: the current microservice module throwing an exception using a custom exception encapsulation class inherited from the gateway layer; the gateway layer's global capture mechanism capturing the exception and modifying its response information; the upper-layer caller then sequentially propagating the modified exception until it reaches the gateway layer; and finally, the gateway layer's exception handling mechanism processing the exception to obtain the exception handling result set. This method, by handling the propagated exception data in each microservice module, ensures that the location of the exception is clearly identified at every stage, improving the efficiency of developers.

[0064] Please see Figure 3 The third embodiment of the anomaly capture method in this invention includes:

[0065] 301. Encapsulate the exception base class entity at the gateway layer and build a global capture mechanism based on the exception base class entity;

[0066] 302. Each microservice module performs custom exception encapsulation to obtain a corresponding custom encapsulation class, wherein the custom encapsulation class inherits from the exception base class entity;

[0067] 303. Obtain the business request sent by the requester through the gateway layer, and determine at least one microservice module and corresponding interface to be called based on the business request;

[0068] 304. Call the corresponding microservice modules sequentially through the interface, and determine whether the business requirements corresponding to the business request are met each time the microservice module is called;

[0069] 305. When there is a microservice module that does not meet the business requirements, an exception is thrown through the custom exception wrapper class inherited from the gateway layer by the current microservice module.

[0070] 306. Obtain the internationalization identifier of the current microservice module;

[0071] 307. Parse the exception to obtain the exception key, and retrieve the corresponding internationalized exception information from a preset database based on the exception key;

[0072] In this embodiment, the exception is parsed according to a predetermined communication protocol to obtain the field content in the exception.

[0073] 308. Respond to the internationalization exception information using the internationalization identifier of the current microservice module;

[0074] In this embodiment, after the current microservice module throws a custom exception, the internationalization identification code zh, en, etc., transmitted from the cloud will be used. Since the exception is thrown custom, the code will retrieve the internationalized exception information corresponding to the key from the Redis cache or database based on the maintained exception key, and then respond with the corresponding internationalized exception information based on the internationalization identification code.

[0075] 309. The exceptions thrown by the current microservice module are captured through the global capture mechanism of the gateway layer, and the response information of the exceptions is modified. The modified exceptions are then thrown up to the gateway layer by the upper-level callers of the current microservice module.

[0076] In this embodiment, the step of modifying the response information of the exception, and having the upper-layer caller of the current microservice module sequentially propagate the modified exception until it reaches the gateway layer, includes: modifying the response information of the exception, encapsulating the exception in a response framework, and changing the response status of the exception to errorMsgCode; intercepting the exception with modified response information by calling the exception interception mechanism of the microservice module above the current microservice module; and throwing the exception through a custom exception encapsulation class of the upper-layer microservice module, which is then intercepted by the exception interception mechanism of the next upper-layer microservice module, until it reaches the gateway layer.

[0077] 310. The exception is handled through the exception handling mechanism of the gateway layer, and the exception handling result set is obtained. The exception handling result set and the message of calling the exception are returned to the requester through the gateway layer.

[0078] In this embodiment, processing the exception through the exception handling mechanism of the gateway layer to obtain an exception handling result set includes: determining the exception type of the exception based on the response information through the exception handling mechanism of the gateway layer; obtaining the corresponding exception handling script based on the exception type; and processing the exception through the exception handling script to obtain an exception handling result set.

[0079] Specifically, the exception types include system exceptions and business exceptions. It is necessary to pre-configure the exception policy configuration file. In the pre-configured policy configuration file, there are corresponding handlers for various exception codes. These handlers are the program code for exception handling. Specifically, the pre-configured policy configuration file is a pre-configured policy configuration list. For different exception codes and exception description information, different handlers are recorded in the pre-configured policy configuration list so that users can call the corresponding policies to implement exception handling.

[0080] 311. When there is no microservice module that does not meet the business requirements, a message indicating a successful call is returned to the requester through the gateway layer.

[0081] This embodiment, based on the previous embodiment, describes in detail the process of handling the exception through the exception handling mechanism of the gateway layer to obtain an exception handling result set. The exception handling mechanism of the gateway layer determines the exception type based on the response information; obtains the corresponding exception handling script based on the exception type; and processes the exception through the exception handling script to obtain the exception handling result set. This method ensures that the location of the exception is clearly identified at each stage by processing the exception data thrown upwards by each microservice module, thus improving the efficiency of R&D personnel.

[0082] The above describes the anomaly capture method in the embodiments of the present invention. The following describes the anomaly capture device in the embodiments of the present invention. Please refer to [link / reference]. Figure 4 In one embodiment of the exception handling device of the present invention, the exception handling device is applied to a microservice system, the microservice system including a gateway layer and at least one microservice module, and the exception handling device includes:

[0083] The interface determination module 401 is used to obtain the business request sent by the requester through the gateway layer, and determine at least one microservice module and corresponding interface to be called based on the business request.

[0084] The judgment module 402 is used to sequentially call the corresponding microservice modules through the interface, and to determine whether the business requirements corresponding to the business request are met each time the microservice module is called.

[0085] The exception handling module 403 is used to, when there is a microservice module that does not meet the business requirements, sequentially propagate the exception thrown by the current microservice module to the upper-level caller of the current microservice module, process the exception, obtain an exception handling result set, and return the exception handling result set and the call exception message to the requester through the gateway layer.

[0086] The success notification module 404 is used to return a message of successful call to the requester through the gateway layer when there is no microservice module that does not meet the business requirements.

[0087] In this embodiment of the invention, the exception capture device runs the above-described exception capture method. The exception capture device is applied to a microservice system, which includes a gateway layer and at least one microservice module. The gateway layer obtains the business request from the requester and determines the at least one microservice module and its corresponding interface to be called based on the business request. The corresponding microservice modules are called sequentially through the interfaces, and each time a microservice module is called, it is determined whether the business requirements corresponding to the business request are met. If not, the exception thrown by the current microservice module is sequentially propagated upwards through the upper-level caller of the current microservice module, and the exception is processed to obtain an exception processing result set. If the requirements are met, a successful call message is returned to the requester through the gateway layer. This method ensures that the location of the exception is clearly known at each stage by processing the propagated exception data by each microservice module, thus improving the efficiency of developers.

[0088] Please see Figure 5 A second embodiment of the anomaly detection device in this invention includes:

[0089] The interface determination module 401 is used to obtain the business request sent by the requester through the gateway layer, and determine at least one microservice module and corresponding interface to be called based on the business request.

[0090] The judgment module 402 is used to sequentially call the corresponding microservice modules through the interface, and to determine whether the business requirements corresponding to the business request are met each time the microservice module is called.

[0091] The exception handling module 403 is used to, when there is a microservice module that does not meet the business requirements, sequentially propagate the exception thrown by the current microservice module to the upper-level caller of the current microservice module, process the exception, obtain an exception handling result set, and return the exception handling result set and the call exception message to the requester through the gateway layer.

[0092] The success notification module 404 is used to return a message of successful call to the requester through the gateway layer when there is no microservice module that does not meet the business requirements.

[0093] In this embodiment, the exception capture device further includes an encapsulation module 405, which is specifically used for: encapsulating an exception base class entity at the gateway layer, constructing a global capture mechanism based on the exception base class entity; and performing custom exception encapsulation in each of the microservice modules to obtain corresponding custom encapsulation classes, wherein the custom encapsulation classes inherit from the exception base class entity.

[0094] In this embodiment, the exception handling module 403 specifically includes: an exception throwing unit 4031, used to throw an exception by a custom exception encapsulation class inherited from the gateway layer by the current microservice module; a modification unit 4032, used to capture the exception thrown by the current microservice module through the global capture mechanism of the gateway layer, modify the response information of the exception, and then propagate the modified exception to the upper-level caller of the current microservice module in sequence until it is propagated to the gateway layer; and a processing unit 4033, used to process the exception through the exception handling mechanism of the gateway layer to obtain an exception handling result set.

[0095] In this embodiment, the modification unit 4032 is specifically used to: obtain the information thrown by the current microservice module through the global capture mechanism of the gateway layer; determine whether the information thrown by the current microservice module is an exception base class entity or a custom exception encapsulation class; if so, identify the information thrown by the current microservice module as an exception and capture it.

[0096] In this embodiment, the modification unit 4032 is further configured to: modify the response information of the exception, encapsulate the exception with a response framework, and modify the response status of the exception to errorMsgCode; intercept the exception after the response information modification by calling the exception interception mechanism of the previous microservice module of the current microservice module; throw the exception through the custom exception encapsulation class of the previous microservice module, and have it intercepted by the exception interception mechanism of the next higher microservice module, until it is thrown up to the gateway layer.

[0097] In this embodiment, the exception capture device further includes an internationalization module 406, which is specifically used for: obtaining the internationalization identification code of the current microservice module; parsing the exception to obtain the exception key, and obtaining the corresponding internationalization exception information from a preset database based on the exception key; and responding to the internationalization exception information through the internationalization identification code of the current microservice module.

[0098] In this embodiment, the processing unit 4033 is specifically used to: determine the exception type of the exception based on the response information through the exception handling mechanism of the gateway layer; obtain the corresponding exception handling script based on the exception type; process the exception through the exception handling script to obtain an exception handling result set.

[0099] This embodiment, building upon the previous embodiment, details the specific functions of each module and applies them to a microservice system. The microservice system includes a gateway layer and at least one microservice module. The gateway layer obtains the business request from the requester and determines the at least one microservice module and its corresponding interface to be invoked based on the business request. The corresponding microservice modules are invoked sequentially through the interfaces, and each time a microservice module is invoked, it is determined whether the business requirements corresponding to the business request are met. If not, the exception thrown by the current microservice module is propagated upwards through its upper-level caller, and the exception is processed to obtain an exception handling result set. If the requirements are met, a success message is returned to the requester through the gateway layer. This device ensures that the location of the exception is clearly identified at each stage by processing the propagated exception data by each microservice module, thus improving the efficiency of developers.

[0100] above Figure 4 and Figure 5 The anomaly capture device in the embodiments of the present invention will be described in detail from the perspective of modular functional entities. The anomaly capture device in the embodiments of the present invention will be described in detail from the perspective of hardware processing.

[0101] Figure 6 This is a schematic diagram of an anomaly capture device 600 provided in an embodiment of the present invention. The anomaly capture device 600 can vary significantly due to different configurations or performance characteristics. It may include one or more central processing units (CPUs) 610 (e.g., one or more processors) and a memory 620, and one or more storage media 630 (e.g., one or more mass storage devices) storing application programs 633 or data 632. The memory 620 and storage media 630 can be temporary or persistent storage. The program stored in the storage media 630 may include one or more modules (not shown in the diagram), each module may include a series of instruction operations on the anomaly capture device 600. Furthermore, the processor 610 may be configured to communicate with the storage media 630 and execute the series of instruction operations in the storage media 630 on the anomaly capture device 600 to implement the steps of the above-described anomaly capture method.

[0102] The anomaly detection device 600 may also include one or more power supplies 640, one or more wired or wireless network interfaces 650, one or more input / output interfaces 660, and / or one or more operating systems 631, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, etc. Those skilled in the art will understand that... Figure 6 The anomaly capture device structure shown does not constitute a limitation on the anomaly capture device provided in this application. It may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0103] The present invention also provides a computer-readable storage medium, which may be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when the instructions are executed on a computer, cause the computer to perform the steps of the exception capture method.

[0104] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the system, device, or unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0105] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0106] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. An anomaly capturing method characterized by, The exception handling method is applied to a microservice system, which includes a gateway layer and at least one microservice module. The exception handling method includes: The gateway layer obtains the business request sent by the requester and determines at least one microservice module and corresponding interface to be called based on the business request. The corresponding microservice modules are called sequentially through the interface, and the business requirements corresponding to the business request are determined each time a microservice module is called. When there is a microservice module that does not meet the business requirements, the exception thrown by the current microservice module is sequentially propagated upwards by the upper-level caller of the current microservice module, and the exception is processed to obtain an exception processing result set. The exception processing result set and the call exception message are returned to the requester through the gateway layer. When there is no microservice module that does not meet the business requirements, a message indicating a successful call is returned to the requester through the gateway layer. The exceptions thrown by the current microservice module are sequentially propagated upwards by the upper-level caller of the current microservice module, and the exceptions are processed to obtain an exception processing result set, including: The current microservice module throws an exception using a custom exception wrapper class inherited from the gateway layer. The gateway layer uses a global capture mechanism to capture exceptions thrown by the current microservice module, modifies the response information of the exceptions, and then uses the upper-level caller of the current microservice module to propagate the modified exceptions sequentially until they reach the gateway layer. The exception is handled through the exception handling mechanism of the gateway layer to obtain an exception handling result set; After the current microservice module throws an exception using a custom exception wrapper class inherited from the gateway layer, the following is also included: Obtain the internationalization identifier of the current microservice module; The exception is parsed to obtain the exception key, and the corresponding internationalized exception information is retrieved from a preset database based on the exception key; wherein, the internationalized exception information is the internationalized exception information corresponding to the key retrieved from the Redis cache or database according to the maintained exception key. The internationalization exception information is responded to using the internationalization identifier of the current microservice module.

2. The anomaly capturing method according to claim 1, characterized by, Before obtaining the service request sent by the requester through the gateway layer, the method further includes: An exception base class entity is encapsulated in the gateway layer, and a global capture mechanism is built based on the exception base class entity; Custom exception encapsulation is performed in each of the aforementioned microservice modules to obtain corresponding custom encapsulation classes, wherein the custom encapsulation classes inherit from the exception base class entity.

3. The anomaly capturing method of claim 1, wherein, The step of capturing exceptions thrown by the current microservice module through the global capture mechanism of the gateway layer includes: The information thrown by the current microservice module is obtained through the global capture mechanism of the gateway layer; Determine whether the information thrown by the current microservice module is an exception base class entity or a custom exception wrapper class; If so, the information thrown by the current microservice module will be identified as an exception and captured.

4. The anomaly capturing method according to claim 1, characterized by, The step of modifying the response information for the exception, and then having the upper-layer caller of the current microservice module sequentially propagate the modified exception upwards until it reaches the gateway layer, includes: The response information for the exception is modified, the exception is encapsulated in a response framework, and the response status of the exception is changed to errorMsgCode. The exception after the response information has been modified is intercepted by calling the exception interception mechanism of the previous microservice module of the current microservice module; The exception is thrown by the custom exception encapsulation class of the previous microservice module, and then intercepted by the exception interception mechanism of the next higher microservice module, until it is thrown up to the gateway layer.

5. The anomaly capturing method according to any one of claims 1 to 4, characterized in that, The exception handling mechanism of the gateway layer is used to process the exception, and the resulting exception handling result set includes: The exception type is determined based on the response information through the exception handling mechanism of the gateway layer; Obtain the corresponding exception handling script based on the exception type; The exception is processed by the exception handling script to obtain an exception handling result set.

6. An anomaly capturing apparatus characterized by comprising: The exception handling device is applied to a microservice system, which includes a gateway layer and at least one microservice module. The exception handling device includes: The interface determination module is used to obtain the business request sent by the requester through the gateway layer, and determine at least one microservice module and corresponding interface to be called based on the business request. The judgment module is used to sequentially call the corresponding microservice modules through the interface, and to determine whether the business requirements corresponding to the business request are met each time the microservice module is called. The exception handling module is used to, when there is a microservice module that does not meet the business requirements, sequentially propagate the exception thrown by the current microservice module to the upper-level caller of the current microservice module, process the exception, obtain an exception handling result set, and return the exception handling result set and the call exception message to the requester through the gateway layer. The success notification module is used to return a message of successful call to the requester through the gateway layer when there is no microservice module that does not meet the business requirements. The exception handling module includes: an exception throwing unit, used to throw exceptions through a custom exception encapsulation class inherited from the gateway layer by the current microservice module; a modification unit, used to capture the exceptions thrown by the current microservice module through the global capture mechanism of the gateway layer, modify the response information of the exceptions, and then propagate the modified exceptions sequentially through the upper-level callers of the current microservice module until they are propagated to the gateway layer; and a processing unit, used to process the exceptions through the exception handling mechanism of the gateway layer to obtain an exception handling result set. The exception capture device further includes an internationalization module, which is specifically used for: obtaining the internationalization identification code of the current microservice module; parsing the exception to obtain the exception key, and retrieving the corresponding internationalization exception information from a preset database based on the exception key; wherein the internationalization exception information is the internationalization exception information corresponding to the key retrieved from the Redis cache or database according to the maintained exception key; and responding to the internationalization exception information through the internationalization identification code of the current microservice module.

7. An anomaly detection device, characterized in that, The anomaly detection device includes: a memory and at least one processor, wherein the memory stores instructions, and the memory and the at least one processor are interconnected via a line; The at least one processor invokes the instructions in the memory to cause the exception capture device to perform the steps of the exception capture method as described in any one of claims 1-5.

8. A computer-readable storage medium storing a computer program thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the exception capture method as described in any one of claims 1-5.

Images