AI service intelligent fault tolerance and degradation method and device based on Java bytecode enhancement technology, equipment, medium and product

Abstract

The invention discloses an AI service intelligent fault tolerance and degradation method, device and equipment based on a Java bytecode enhancement technology, a medium and a product, and relates to the technical field of AI service integration. According to the method, in a class loading period of Java application starting, a loaded class is scanned to identify target methods marked with declarative fault-tolerant annotations, a bytecode operation framework is utilized to enhance the target methods so as to implant a unified fault-tolerant logic interception entry, and then in a running period, when the target methods are called, the target methods are subjected to fault-tolerant annotation processing. And triggering a fault-tolerant interceptor through the interception entrance to analyze the annotation to obtain a fault-tolerant strategy, allocating an independent fault-tolerant component instance to the fault-tolerant interceptor based on the unique identifier of the method, constructing and executing an enhanced call chain containing a fusing check and retry mechanism, and finally, if the execution of the call chain fails, executing the fault-tolerant interceptor. And if yes, a preset degradation method in the fault-tolerant strategy is automatically executed, so that complete non-intrusive decoupling of AI service fault-tolerant management and service logic can be realized, and the reliability of the system is remarkably improved.

Description

Technical Field

[0001] This invention belongs to the field of AI service integration technology, specifically relating to a method, apparatus, device, medium, and product for intelligent fault tolerance and degradation of AI services based on Java bytecode enhancement technology. Background Technology

[0002] In recent years, with the rapid development of AI (Artificial Intelligence) technology, integrating various AI services such as Optical Character Recognition (OCR), Natural Language Processing (NLP), and speech recognition into Java enterprise applications has become commonplace. These AI services are typically provided in the form of remote APIs (Application Programming Interfaces), which are characterized by high latency, high volatility, and diverse anomalies (such as network timeouts, service rate limiting, and model calculation errors). Therefore, implementing robust fault-tolerant logic in the business code, including failure retries, circuit breaker isolation, and service degradation, is crucial to ensuring the overall availability and stability of the application.

[0003] However, in existing technological practices, integrating fault-tolerant governance logic with core business logic faces the following significant technical bottlenecks: (1) The code is highly intrusive and undermines the clarity of the software architecture. The most direct way to implement this is to manually write try-catch statements, loop retry logic and fallback callbacks around the code block that calls the AI ​​service. This approach is prone to result in the fault tolerance code (i.e., "governance logic") being highly coupled with the core business logic, resulting in bloated code and poor readability, which violates the single responsibility principle. Although professional circuit breaker libraries such as Hystrix and Resilience4j have emerged, their usage mode is still programmatic integration, which requires explicitly calling their API or wrapping the call chain in the business method. This fails to fundamentally achieve decoupling, and the intrusiveness to the business code still exists. (2) Fragmented fault tolerance strategies make system behavior difficult to control. Due to the lack of a unified framework, different developers or teams may implement fault tolerance according to their personal habits, resulting in inconsistent strategies such as the number of retries, timeout thresholds, and circuit breaker conditions within the application. This fragmentation makes the fault tolerance behavior of the system difficult to predict and audit, significantly increasing the cost of later maintenance and troubleshooting. (3) The governance process is not transparent and lacks observability. That is, the existing fault tolerance implementation often only focuses on the "execution result" and ignores the "execution process". For example, key information such as how many times the internal retry was performed before a call finally failed, when the circuit breaker was triggered and entered the open state, and whether the degradation strategy was activated lacks standardized and automated collection and exposure methods. This makes it difficult for operation and maintenance personnel to quickly locate the root cause of the problem when a failure occurs, and makes it impossible to effectively measure and optimize the system resilience. (4) The strategy adjustment is rigid and lacks dynamic flexibility. Once the fault tolerance strategy (such as adjusting the number of retries from 3 to 2) is written into the application in the form of hard coding or static configuration, any modification requires a complete process of code change, recompilation, packaging and deployment. This mode cannot adapt to the dynamic fluctuation of AI service performance or the need for rapid trial and error. The strategy takes a long time to take effect and has poor operation and maintenance flexibility.

[0004] To address these issues, the industry has developed several technical solutions, but all of them have inherent limitations: (A) Aspect-Oriented Programming (AOP): By defining aspects to uniformly handle exceptions and retries, it achieves a certain degree of logic centralization; however, its dynamic proxy-based operation mechanism introduces additional performance overhead; and its interception granularity is usually coarse, making it difficult to configure dedicated and complex circuit breaker instances for each method; at the same time, AOP aspects are difficult to easily link with external configuration centers to achieve dynamic policy updates. (B) SDK (Software Development Kit) wrapping pattern: Fault tolerance logic is encapsulated in utility classes for business users to call. Although it has a certain degree of reusability, it is still essentially code intrusion. Moreover, SDK upgrades require all callers to update synchronously, resulting in high coupling. In summary, existing technologies either sacrifice code purity and maintainability to achieve fault tolerance, or suffer from shortcomings in performance, flexibility, and governance granularity. They have yet to provide an intelligent fault tolerance solution that is completely decoupled from business logic while supporting fine-grained, dynamic, and observable fault tolerance. Especially in the specific high-value scenario of AI service calls, how to achieve non-intrusive, declarative, and method-level fine-grained fault tolerance governance has become a pressing technical problem in this field. Summary of the Invention

[0005] The purpose of this invention is to provide an AI service intelligent fault tolerance and degradation method, device, computer equipment, computer-readable storage medium, and computer program product based on Java bytecode enhancement technology, in order to solve the problems of strong code invasiveness, inconsistent fault tolerance strategies, poor flexibility, and / or opaque governance process caused by the tight coupling between business code and fault tolerance governance logic when integrating AI services into Java applications in the prior art.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: Firstly, a method for intelligent fault tolerance and degradation of AI services based on Java bytecode enhancement technology is provided, including: During the class loading phase of a Java application startup, bytecode enhancement processing is performed on methods of loaded classes marked with preset declarative fault tolerance annotations using Java Agent technology. Specifically, this includes: first, a bytecode converter initialized based on Java Agent technology scans each loaded class of the Java application to identify whether there are methods marked with preset declarative fault tolerance annotations in each class; then, the bytecode manipulation framework performs bytecode enhancement processing on the identified target methods marked with the preset declarative fault tolerance annotations to implant a unified fault tolerance logic interception entry point, resulting in the enhanced loaded class, which is then loaded. During the runtime of the Java application, when the target method is called by business code, the implanted fault tolerance logic is executed. Specifically, this includes: firstly, calling the fault tolerance interceptor through the fault tolerance logic interception entry to intercept and parse the preset declarative fault tolerance annotation to obtain the fault tolerance strategy of the target method; then, obtaining an independent fault tolerance component instance based on the method identifier of the target method; next, using the fault tolerance component instance to construct and execute an enhanced call chain containing circuit breaking checks and retry mechanisms to execute the original business logic; and finally, if the enhanced call chain fails, executing the degradation method configured in the fault tolerance strategy and returning the execution result.

[0007] Based on the above-mentioned invention, a novel solution for non-intrusive, declarative, and method-level fine-grained fault tolerance governance of AI services is provided. Specifically, during the class loading phase of a Java application startup, loaded classes are scanned to identify target methods annotated with declarative fault tolerance annotations. A bytecode manipulation framework is used to enhance these target methods, embedding a unified fault tolerance logic interception entry point. Then, during runtime, when a target method is invoked, a fault tolerance interceptor is triggered through this interception entry point to parse the annotations and obtain the fault tolerance strategy. Simultaneously, an independent fault tolerance component instance is assigned based on the method's unique identifier, and an enhanced call chain including circuit breaking checks and retry mechanisms is constructed and executed. Finally, if the call chain fails, the pre-defined degradation method in the fault tolerance strategy is automatically executed. This achieves complete non-intrusive decoupling of AI service fault tolerance governance from business logic, supports method-level fine-grained strategy configuration, dynamic hot updates, and end-to-end observability, significantly improving system reliability, maintainability, and operational flexibility, facilitating practical application and promotion.

[0008] In one possible design, the method identifier based on the target method is used to obtain an independent fault-tolerant component instance, including: Generate a unique method identifier key based on the fully qualified name of the class containing the target method and the name of the target method; Using the method identifier key as an index, retrieve the circuit breaker instance specific to the target method from the circuit breaker registry, and retrieve the retryer instance specific to the target method from the retryer registry; By combining the fuse instances and the retester instances, a unique fault-tolerant component instance is obtained for the target method.

[0009] In one possible design, the method further includes the following dynamic policy update step: The fault-tolerant interceptor listens for configuration change messages issued by an external dynamic configuration center. When it detects a configuration change message indicating that the fault-tolerant policy configuration associated with a certain method identifier key has been updated, it refreshes the policy information of the method corresponding to the method identifier key in the metadata cache according to the new configuration, and triggers the reconstruction of the fault-tolerant component instance of the method, thereby realizing dynamic hot update of the fault-tolerant policy.

[0010] In one possible design, during the execution of the enhanced call chain, the fault-tolerant interceptor automatically collects and reports fault-tolerant process indicators, wherein the fault-tolerant process indicators include any one or any combination of call success / failure indicator bits, retry count, circuit breaker status, degradation trigger count, and call success rate.

[0011] In one possible design, the preset declarative fault tolerance annotation refers to a predefined declarative fault tolerance annotation, which includes a core method annotation for marking AI service call methods that require fault tolerance. The attributes of the core method annotation at least support configuring the name of the degradation method, and support referencing the circuit breaker configuration and retry configuration defined in the application context by configuring the Bean name.

[0012] In one possible design, the declarative fault-tolerant annotation also includes separate retry strategy annotations and circuit breaker strategy annotations for fine-grained configuration of the fault-tolerant behavior of individual methods. The retry strategy annotation includes a list of specific exception types for triggering retries, and the circuit breaker strategy annotation includes a list of exception types that are ignored and not included in the failure statistics.

[0013] Secondly, an AI service intelligent fault tolerance and degradation device based on Java bytecode enhancement technology is provided, including a method enhancement processing unit and a fault tolerance logic execution unit that are connected in communication. The method enhancement processing unit is used to perform bytecode enhancement processing on the loaded class and the method marked with a preset declarative fault tolerance annotation during the class loading period when the Java application starts, through Java Agent technology, and specifically includes a scanning and identification subunit and an enhancement processing subunit that are connected in communication. The scanning and identification subunit is used to scan each loaded class of the Java application by a bytecode converter initialized based on Java Agent technology, and to identify whether there are methods marked with preset declarative fault-tolerant annotations in each class. The enhancement processing subunit is used to perform bytecode enhancement processing on the identified target methods marked with the preset declarative fault tolerance annotation through the bytecode operation framework to implant a unified fault tolerance logic interception entry point, so as to obtain the enhanced loaded class and load it. The fault-tolerant logic execution unit is used to execute the implanted fault-tolerant logic during the runtime of the Java application when the target method is called by business code, and specifically includes a strategy parsing subunit, an instance acquisition subunit, a call execution subunit, and a degradation execution subunit. The strategy parsing subunit is used to call the fault tolerance interceptor through the fault tolerance logic interception entry to intercept and parse the preset declarative fault tolerance annotation to obtain the fault tolerance strategy of the target method; The instance acquisition subunit is connected to the policy parsing subunit and is used to obtain an independent fault-tolerant component instance based on the method identifier of the target method. The call execution subunit is connected to the instance acquisition subunit and is used to construct and execute an enhanced call chain containing circuit breaker checks and retry mechanisms to execute the original business logic using the fault-tolerant component instance. The degradation execution subunit is communicatively connected to the strategy parsing subunit and the call execution subunit, and is used to execute the degradation method configured in the fault tolerance strategy and return the execution result when the enhanced call chain fails.

[0014] Thirdly, the present invention provides a computer device comprising a storage module, a processing module, and a transceiver module connected in sequence for communication, wherein the storage module is used to store a computer program, the transceiver module is used to send and receive messages, and the processing module is used to read the computer program and execute the AI ​​service intelligent fault tolerance and degradation method as described in the first aspect or any possible design in the first aspect.

[0015] Fourthly, the present invention provides a computer-readable storage medium storing instructions that, when executed on a computer, perform the AI ​​service intelligent fault tolerance and degradation method as described in the first aspect or any possible design in the first aspect.

[0016] Fifthly, the present invention provides a computer program product, including a computer program or instructions, wherein the computer program or instructions, when executed by a computer, implement the AI ​​service intelligent fault tolerance and degradation method as described in the first aspect or any possible design in the first aspect.

[0017] The beneficial effects of the above scheme are: (1) This invention creatively provides a new solution for non-intrusive, declarative and method-level fine-grained fault tolerance governance of AI services. That is, during the class loading period when the Java application starts, the loaded classes are scanned to identify target methods marked with declarative fault tolerance annotations. The bytecode manipulation framework is used to enhance these target methods to implant a unified fault tolerance logic interception entry. Then, during runtime, when the target method is called, the fault tolerance interceptor is triggered through the interception entry to parse the annotations to obtain the fault tolerance strategy. At the same time, an independent fault tolerance component instance is allocated for it based on the unique identifier of the method, and an enhanced call chain containing circuit breaking checks and retry mechanisms is constructed and executed. Finally, if the call chain fails, the degradation method preset in the fault tolerance strategy is automatically executed. Thus, the fault tolerance governance of AI services can be completely decoupled from business logic in a non-intrusive manner, and it supports method-level fine-grained strategy configuration, dynamic hot updates and full-link observability, which significantly improves the reliability, maintainability and operation and maintenance flexibility of the system. (2) It can achieve complete decoupling of business logic and governance logic, ensuring the purity and maintainability of the code. That is, through the core means of bytecode enhancement during class loading, the business code only needs to use declarative annotations to express the fault tolerance intention, without writing any fault tolerance framework API calls. This makes the core business code highly concise and focused, fundamentally solving the problems of strong code intrusion, logical coupling and poor readability caused by manual coding or explicit framework integration in traditional solutions. (3) It can provide method-level fine-grained fault tolerance strategy management to ensure the precise controllability and high reliability of system behavior. That is, by enabling each labeled method to obtain a completely independent fault tolerance component instance (i.e., circuit breaker instance and retryer instance) based on its unique identifier, physical isolation can be achieved. By combining the precise matching configuration of exception types, the fault tolerance strategy (such as retry and circuit breaking) can be customized in a personalized and fine-grained manner for a single AI service method. This effectively solves the problem of "false positives" and resource competition caused by the coarse granularity of the strategy in traditional AOP or shared instance solutions, making the fault tolerance behavior more predictable and the overall system reliability higher. (4) It can give the fault tolerance strategy the ability to be dynamically adjusted and hot-updated, which greatly improves the system's operational flexibility and response speed. That is, by listening to the external configuration center and updating the method metadata and rebuilding the instance, the system can modify strategy parameters such as the number of retry and the circuit breaker threshold in real time without interrupting the application service. This enables the system to quickly adapt to the production environment where AI services fluctuate frequently, and solves the problem of rigid operation and maintenance and business risks caused by the traditional solution due to the fixed strategy and the need to restart after modification. (5) It can build a fully observable governance process, which greatly reduces the difficulty of system fault diagnosis and performance optimization. That is, the fault-tolerant interceptor automatically collects and reports key indicators (such as call status, number of retries, circuit breaker status and degradation trigger, etc.), making the originally "black box" fault tolerance process completely transparent and visible. This directly solves the problem of difficulty in locating the root cause of faults and difficulty in analyzing performance bottlenecks caused by the lack of unified monitoring in existing technologies, and provides data support for the continuous stability assurance and optimization of the system. (6) This solution systematically solves the four core pain points of fault tolerance governance in AI service integration by organically combining innovative designs such as non-intrusive bytecode enhancement, method-level instance isolation, declarative configuration, dynamic hot update and built-in observability. It realizes a fundamental transformation from "intrusive coding" to "declarative governance", from "extensive sharing" to "precise isolation", from "static rigidity" to "dynamic flexibility" and from "black box operation" to "white box observability". This significantly improves the code quality, system reliability, operation and maintenance efficiency and problem traceability of Java applications when integrating unstable external AI services, making it easy to apply and promote in practice. Attached Figure Description

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

[0019] Figure 1 This is a flowchart illustrating the AI ​​service intelligent fault tolerance and degradation method based on Java bytecode enhancement technology provided in this application embodiment.

[0020] Figure 2 This is a schematic diagram of the structure of an AI service intelligent fault tolerance and degradation device based on Java bytecode enhancement technology provided in an embodiment of this application.

[0021] Figure 3 A schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the present invention will be briefly introduced below in conjunction with the accompanying drawings and descriptions of the embodiments or the prior art. Obviously, the following description of the structure of the accompanying drawings is only some embodiments of the present invention. For those skilled in the art, other embodiments can be obtained based on these embodiments without creative effort. It should be noted that the description of these embodiments is for the purpose of helping to understand the present invention, but does not constitute a limitation of the present invention.

[0023] It should be understood that although the terms "first" and "second", etc., may be used herein to describe various objects, these objects should not be limited by these terms. These terms are only used to distinguish one object from another. For example, the first object may be referred to as the second object, and similarly, the second object may be referred to as the first object, without departing from the scope of the exemplary embodiments of the invention.

[0024] It should be understood that the term "and / or" that may appear in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, B exists alone, or A and B exist simultaneously. Another example is A, B and / or C, which can mean that any one of A, B, and C or any combination thereof exists. The term " / and" that may appear in this document describes another relationship between related objects, indicating that two relationships can exist. For example, A / and B can mean: A exists alone or A and B exist simultaneously. In addition, the character " / " that may appear in this document generally indicates that the related objects before and after it are in an "or" relationship.

[0025] Example like Figure 1 As shown, the AI ​​service intelligent fault tolerance and degradation method based on Java bytecode enhancement technology provided in the first aspect of this embodiment can be executed, but is not limited to, by computer devices with certain computing resources, such as servers, personal computers (PCs, referring to a type of multi-purpose computer suitable for personal use in terms of size, price, and performance; desktops, laptops, mini-laptops, tablets, and ultrabooks are all considered personal computers), smartphones, personal digital assistants (PDAs), or wearable devices. Figure 1 As shown, the AI ​​service intelligent fault tolerance and degradation method includes, but is not limited to, the following steps S1 to S2.

[0026] S1. During the class loading phase of a Java application startup, bytecode enhancement is performed on methods of loaded classes that are annotated with predefined declarative fault-tolerant annotations using Java Agent technology.

[0027] In step S1, the class loading period is a crucial preparatory phase in the Java technology system, occurring between the startup of a Java application and the execution of its main method. It involves the JVM (Java Virtual Machine, a specification for computing devices) loading, linking, and initializing the required class files. The Java Agent technology is a standard, low-level JVM-level extension mechanism provided by the Java platform. It allows developers to create an independent agent program separate from the main application. This agent program can be loaded when the target Java application starts or runs, gaining the ability to deeply intervene in the internal operations of the JVM (especially the class loading process). The loaded class refers to the class being loaded. A class is the basic building block of a Java program. A class contains fields (i.e., attributes) and methods (i.e., behaviors). Therefore, predefined declarative fault-tolerant annotations (i.e., the predefined declarative fault-tolerant annotations) can be used to annotate the methods of a class.

[0028] In step S1, the declarative fault-tolerant annotation is used to declare content such as degradation methods, retry strategies, and circuit breaker parameters. It is preferably configured using `@AIService` and nested annotations (e.g., directly using nested `@AIRetryConfig` and / or `@AICircuitBreakerConfig` annotations) to achieve concise and intuitive configuration. Specifically, the preset declarative fault-tolerant annotation refers to a predefined declarative fault-tolerant annotation, including but not limited to a core method annotation used to mark AI service call methods requiring fault tolerance. The core method annotation's attributes at least support configuring the name of the degradation method and support referencing circuit breaker and retry configurations defined in the application context through the configuration bean name, etc. The aforementioned bean is a core and fundamental concept in the Spring framework and the Java ecosystem it represents. It can be understood as a Java object instance created, assembled, and managed by the Spring IoC (Inversion of Control) container. In this embodiment, the `@AIService` annotation has two key attributes: `circuitBreakerConfig` and `retryConfig`. These attributes can point to the name of a custom configuration bean in the Spring context, thus ensuring compatibility with the Spring ecosystem and adapting to mainstream microservice development frameworks, reducing integration costs. Furthermore, to achieve precise exception matching, the declarative fault-tolerance annotation also includes independent retry strategy annotations and circuit breaker strategy annotations for fine-grained configuration of fault-tolerance behavior for individual methods. The retry strategy annotation's configuration items include a list of specific exception types for triggering retries (e.g., IO exceptions or timeout exceptions; IO exceptions specifically refer to exceptions represented by the `java.io.IOException` class and its subclasses in Java, indicating failures in input / output operations, which are the most common and fault-tolerant exception types when calling external AI services). The circuit breaker strategy annotation's configuration items include a list of exception types that are ignored and not included in failure statistics. This design reduces the probability of false triggers.

[0029] In step S1, the purpose of the bytecode enhancement processing is to implant fault tolerance interception logic so that fault tolerance capabilities can be enabled simply by annotation declaration without requiring business code to inherit from a parent class, implement an interface, or inject utility classes. Specifically, bytecode enhancement processing is performed on the loaded class and the methods marked with preset declarative fault tolerance annotations using Java Agent technology, including but not limited to the following steps S11 to S12.

[0030] S11. A bytecode converter initialized based on Java Agent technology scans each loaded class of the Java application to identify whether there are methods marked with preset declarative fault-tolerant annotations in each class.

[0031] In step S11, to achieve non-intrusive Agent loading, the Agent can be loaded before the application main program starts using the Premain method (which is the standard entry function of JavaAgent technology and a "startup hook" reserved by the JVM for the agent program). This eliminates the need to modify the application compilation process or packaging script. The bytecode converter is the core "scalpel" in the Java Agent mechanism. It is a class that implements a specific interface and can intercept the original bytecode of each class when the JVM loads it, providing an opportunity for modification (i.e., enhancement), thus achieving the aforementioned class scanning purpose.

[0032] S12. The target method identified and marked with the preset declarative fault tolerance annotation is subjected to bytecode enhancement processing through the bytecode manipulation framework to implant a unified fault tolerance logic interception entry point, thereby obtaining the enhanced loaded class and loading it.

[0033] In step S12, the bytecode manipulation framework (such as the ByteBuddy framework) is a specific tool library upon which the goal of Java bytecode enhancement technology depends. It provides a set of high-level APIs, allowing developers to read, analyze, and modify complex bytecode in a relatively easy and reliable way. To achieve precise bytecode enhancement, the ByteBuddy framework can specifically scan target classes annotated with the preset declarative fault-tolerant annotations and perform bytecode enhancement processing on the methods of those target classes (i.e., the target methods) to implant a unified fault-tolerant logic interception entry point. This ensures that only methods annotated with the @AIService annotation and nested annotations are enhanced, avoiding performance overhead caused by indiscriminate modification. Furthermore, if no target method annotated with the preset declarative fault-tolerant annotation is identified, the original class will be loaded directly.

[0034] S2. During the runtime of the Java application, when the target method is called by business code, the implanted fault-tolerant logic is executed.

[0035] In step S2, each method annotated with the preset declarative fault-tolerant annotation (e.g., @AIService annotation and nested annotations) can be assigned an independent circuit breaker and retryer instance to avoid resource contention and policy "collateral damage" caused by different methods sharing instances. This supports personalized fault-tolerant configuration for a single AI service. Specifically, the implanted fault-tolerant logic is executed, including but not limited to the following steps S21 to S24.

[0036] S21. The fault tolerance interceptor is invoked through the fault tolerance logic interception entry to intercept and parse the preset declarative fault tolerance annotation to obtain the fault tolerance strategy of the target method.

[0037] In step S21, the fault-tolerant interceptor is the "command center" and "policy execution engine" embedded in the enhanced bytecode and uniformly responsible for the execution of runtime fault-tolerant governance logic. It is the core hub connecting declarative intents and specific fault-tolerant behaviors, specifically an `AIServiceInterceptor` class. After the target method is enhanced by the bytecode, all calls to that method will first jump to this interceptor, thus making subsequent execution more efficient than dynamic proxies. Furthermore, the fault-tolerant strategy is cached after parsing (for example, cached in `MethodMetadata`, which is an object that caches all fault-tolerant governance-related configurations and states of a single method in memory; its core purpose is to trade space for time, reducing the expensive runtime reflection parsing overhead to almost zero), to avoid repeated reflection parsing with each call and reduce performance overhead.

[0038] S22. Based on the method identifier of the target method, obtain an independent fault-tolerant component instance for the target method.

[0039] In step S22, to implement the instance isolation mechanism, specifically, based on the method identifier of the target method, an independent fault-tolerant component instance is obtained for the target method. This includes, but is not limited to: first, generating a unique method identifier key based on the fully qualified name of the class containing the target method and the method name of the target method; then, using the method identifier key as an index, retrieving a circuit breaker instance specific to the target method from the circuit breaker registry and a retry instance specific to the target method from the retry registry; finally, summing the circuit breaker instance and the retry instance to obtain an independent fault-tolerant component instance obtained for the target method. The aforementioned circuit breaker registry and retry registry need to be pre-registered. Through these steps, it can be ensured that policy configurations do not interfere with each other.

[0040] S23. Construct and execute an enhanced call chain containing circuit breaker checks and retry mechanisms using the fault-tolerant component instance to execute the original business logic.

[0041] In step S23, the enhanced call chain including circuit breaker checks and retry mechanisms can specifically be a "circuit breaker → retryer → original method" call chain built using Decorators (a specific decorator for programming patterns and API designs used to build complex and multi-layered fault-tolerant call chains, which adds fault tolerance capabilities layer by layer by "wrapping" or "decorating" the original call). To achieve transparency and end-to-end observability in the governance process, preferably, during the execution of the enhanced call chain, the fault-tolerant interceptor automatically collects and reports fault-tolerant process indicators. These indicators include, but are not limited to, any one or any combination of call success / failure indicators (e.g., a value of "1" indicates a successful call, and "0" indicates a failed call), retry count, circuit breaker status, degradation trigger count, and call success rate. Furthermore, the fault-tolerant interceptor can support integration with monitoring tools such as Prometheus and Grafana to achieve visualized monitoring of fault tolerance effects and rapid problem localization.

[0042] S24. If the enhanced call chain fails to execute, the degradation method configured in the fault tolerance strategy is executed and the execution result is returned.

[0043] Before step S24, the success of the enhanced call chain can be determined based on the fault tolerance process indicators. If successful, the call result is returned and the fault tolerance process indicators are recorded; otherwise, the enhanced call chain is deemed to have failed. Furthermore, if no degradation method is configured in the fault tolerance strategy, the original exception will be thrown directly, and the fault tolerance process indicators will be recorded. The fault tolerance process indicators are also recorded when the execution result is returned.

[0044] In addition, to achieve dynamic configuration hot update, the method preferably includes the following dynamic policy update step: The fault-tolerant interceptor listens for configuration change messages issued by an external dynamic configuration center. When a configuration change message indicating that the fault-tolerant policy configuration associated with a certain method identifier key has been updated is detected, the policy information of the method corresponding to the method identifier key in the metadata cache is refreshed according to the new configuration, and the fault-tolerant component instance of the method is rebuilt, thereby achieving dynamic hot update of the fault-tolerant policy. The external dynamic configuration center can specifically be a dynamic configuration center that supports integration with Nacos or Apollo. Based on the aforementioned steps, parameters such as the number of retries and the circuit breaker threshold can be updated without restarting the application, which is particularly suitable for scenarios with frequent fluctuations in AI services.

[0045] Therefore, based on the AI ​​service intelligent fault tolerance and degradation method described in steps S1-S2 above, a new solution for non-intrusive, declarative, and method-level fine-grained AI service fault tolerance governance is provided. Specifically, during the class loading phase of a Java application startup, loaded classes are scanned to identify target methods annotated with declarative fault tolerance annotations. These target methods are then enhanced using a bytecode manipulation framework to embed a unified fault tolerance logic interception entry point. During runtime, when a target method is called, a fault tolerance interceptor is triggered through this interception entry point to parse the annotations and obtain the fault tolerance strategy. Simultaneously, an independent fault tolerance component instance is assigned based on the method's unique identifier, and an enhanced call chain containing circuit breaker checks and retry mechanisms is constructed and executed. Finally, if the call chain fails, the degradation method preset in the fault tolerance strategy is automatically executed. This achieves complete non-intrusive decoupling of AI service fault tolerance governance from business logic, supports method-level fine-grained strategy configuration, dynamic hot updates, and end-to-end observability, significantly improving system reliability, maintainability, and operational flexibility, facilitating practical application and promotion.

[0046] like Figure 2 As shown, the second aspect of this embodiment provides a virtual device for implementing the AI ​​service intelligent fault tolerance and degradation method described in the first aspect, including a method enhancement processing unit and a fault tolerance logic execution unit that are connected in communication. The method enhancement processing unit is used to perform bytecode enhancement processing on the loaded class and the method marked with a preset declarative fault tolerance annotation during the class loading period when the Java application starts, through Java Agent technology, and specifically includes a scanning and identification subunit and an enhancement processing subunit that are connected in communication. The scanning and identification subunit is used to scan each loaded class of the Java application by a bytecode converter initialized based on Java Agent technology, and to identify whether there are methods marked with preset declarative fault-tolerant annotations in each class. The enhancement processing subunit is used to perform bytecode enhancement processing on the identified target methods marked with the preset declarative fault tolerance annotation through the bytecode operation framework to implant a unified fault tolerance logic interception entry point, so as to obtain the enhanced loaded class and load it. The fault-tolerant logic execution unit is used to execute the implanted fault-tolerant logic during the runtime of the Java application when the target method is called by business code, and specifically includes a strategy parsing subunit, an instance acquisition subunit, a call execution subunit, and a degradation execution subunit. The strategy parsing subunit is used to call the fault tolerance interceptor through the fault tolerance logic interception entry to intercept and parse the preset declarative fault tolerance annotation to obtain the fault tolerance strategy of the target method; The instance acquisition subunit is connected to the policy parsing subunit and is used to obtain an independent fault-tolerant component instance based on the method identifier of the target method. The call execution subunit is connected to the instance acquisition subunit and is used to construct and execute an enhanced call chain containing circuit breaker checks and retry mechanisms to execute the original business logic using the fault-tolerant component instance. The degradation execution subunit is communicatively connected to the strategy parsing subunit and the call execution subunit, and is used to execute the degradation method configured in the fault tolerance strategy and return the execution result when the enhanced call chain fails.

[0047] The working process, working details and technical effects of the aforementioned device provided in the second aspect of this embodiment can be found in the AI ​​service intelligent fault tolerance and degradation method described in the first aspect, and will not be repeated here.

[0048] like Figure 3 As shown, the third aspect of this embodiment provides a computer device for executing the AI ​​service intelligent fault tolerance and degradation method as described in the first aspect. The device includes a storage module, a processing module, and a transceiver module connected in sequence. The storage module stores a computer program, the transceiver module sends and receives messages, and the processing module reads the computer program and executes the AI ​​service intelligent fault tolerance and degradation method as described in the first aspect. Specifically, the storage module may include, but is not limited to, random-access memory (RAM), read-only memory (ROM), flash memory, first-in-first-out (FIFO) memory, and / or first-in-last-out (FILO) memory, etc.; the processing module may, but is not limited to, use a microprocessor of the STM32F105 series. Furthermore, the computer device may also include, but is not limited to, a power supply module, a display screen, and other necessary components.

[0049] The working process, working details and technical effects of the aforementioned computer device provided in the third aspect of this embodiment can be found in the AI ​​service intelligent fault tolerance and degradation method described in the first aspect, and will not be repeated here.

[0050] This fourth aspect of the embodiment provides a computer-readable storage medium storing instructions comprising the AI ​​service intelligent fault tolerance and degradation method as described in the first aspect. Specifically, the computer-readable storage medium stores instructions that, when executed on a computer, perform the AI ​​service intelligent fault tolerance and degradation method as described in the first aspect. The computer-readable storage medium refers to a data storage medium, which may include, but is not limited to, floppy disks, optical disks, hard disks, flash memory, USB flash drives, and / or Memory Sticks. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.

[0051] The working process, working details and technical effects of the aforementioned computer-readable storage medium provided in the fourth aspect of this embodiment can be found in the AI ​​service intelligent fault tolerance and degradation method described in the first aspect, and will not be repeated here.

[0052] This fifth aspect of the embodiment provides a computer program product, including a computer program or instructions, which, when executed by a computer, implements the AI ​​service intelligent fault tolerance and degradation method as described in the first aspect. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.

[0053] Finally, it should be noted that the above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for intelligent fault tolerance and degradation of AI services based on Java bytecode enhancement technology, characterized in that, include: During the class loading phase of a Java application startup, bytecode enhancement processing is performed on methods of loaded classes marked with preset declarative fault tolerance annotations using Java Agent technology. Specifically, this includes: first, a bytecode converter initialized based on Java Agent technology scans each loaded class of the Java application to identify whether there are methods marked with preset declarative fault tolerance annotations in each class; then, the bytecode manipulation framework performs bytecode enhancement processing on the identified target methods marked with the preset declarative fault tolerance annotations to implant a unified fault tolerance logic interception entry point, resulting in the enhanced loaded class, which is then loaded. During the runtime of the Java application, when the target method is called by business code, the implanted fault tolerance logic is executed. Specifically, this includes: firstly, calling the fault tolerance interceptor through the fault tolerance logic interception entry to intercept and parse the preset declarative fault tolerance annotation to obtain the fault tolerance strategy of the target method; then, obtaining an independent fault tolerance component instance based on the method identifier of the target method; next, using the fault tolerance component instance to construct and execute an enhanced call chain containing circuit breaking checks and retry mechanisms to execute the original business logic; and finally, if the enhanced call chain fails, executing the degradation method configured in the fault tolerance strategy and returning the execution result.

2. The AI ​​service intelligent fault tolerance and degradation method according to claim 1, characterized in that, Based on the method identifier of the target method, an independent fault-tolerant component instance is obtained, including: Generate a unique method identifier key based on the fully qualified name of the class containing the target method and the name of the target method; Using the method identifier key as an index, retrieve the circuit breaker instance specific to the target method from the circuit breaker registry, and retrieve the retryer instance specific to the target method from the retryer registry; By combining the fuse instances and the retester instances, a unique fault-tolerant component instance is obtained for the target method.

3. The AI ​​service intelligent fault tolerance and degradation method according to claim 1 or 2, characterized in that, The method further includes the following dynamic policy update step: The fault-tolerant interceptor listens for configuration change messages issued by an external dynamic configuration center. When it detects a configuration change message indicating that the fault-tolerant policy configuration associated with a certain method identifier key has been updated, it refreshes the policy information of the method corresponding to the method identifier key in the metadata cache according to the new configuration, and triggers the reconstruction of the fault-tolerant component instance of the method, thereby realizing dynamic hot update of the fault-tolerant policy.

4. The AI ​​service intelligent fault tolerance and degradation method according to claim 1, characterized in that, During the execution of the enhanced call chain, the fault-tolerant interceptor automatically collects and reports fault-tolerant process indicators, which include any one or any combination of the following: call success / failure indicator bit, number of retries, circuit breaker status, number of degradation triggers, and call success rate.

5. The AI ​​service intelligent fault tolerance and degradation method according to claim 1, characterized in that, The preset declarative fault tolerance annotation refers to a predefined declarative fault tolerance annotation, which includes a core method annotation for marking AI service call methods that require fault tolerance. The attributes of the core method annotation at least support configuring the name of the degradation method, and support referencing the circuit breaker configuration and retry configuration defined in the application context by configuring the Bean name.

6. The AI ​​service intelligent fault tolerance and degradation method according to claim 5, characterized in that, The declarative fault tolerance annotation also includes independent retry strategy annotations and circuit breaker strategy annotations for fine-grained configuration of the fault tolerance behavior of individual methods. The configuration items of the retry strategy annotation include a list of specific exception types for triggering retries, and the configuration items of the circuit breaker strategy annotation include a list of exception types that are ignored and not included in the failure statistics.

7. An AI service intelligent fault tolerance and degradation device based on Java bytecode enhancement technology, characterized in that, This includes a method-enhanced processing unit and a fault-tolerant logic execution unit that are connected by communication. The method enhancement processing unit is used to perform bytecode enhancement processing on the loaded class and the method marked with a preset declarative fault tolerance annotation during the class loading period when the Java application starts, through Java Agent technology, and specifically includes a scanning and identification subunit and an enhancement processing subunit that are connected in communication. The scanning and identification subunit is used to scan each loaded class of the Java application by a bytecode converter initialized based on Java Agent technology, and to identify whether there are methods marked with preset declarative fault-tolerant annotations in each class. The enhancement processing subunit is used to perform bytecode enhancement processing on the identified target methods marked with the preset declarative fault tolerance annotation through the bytecode operation framework to implant a unified fault tolerance logic interception entry point, so as to obtain the enhanced loaded class and load it. The fault-tolerant logic execution unit is used to execute the implanted fault-tolerant logic during the runtime of the Java application when the target method is called by business code, and specifically includes a strategy parsing subunit, an instance acquisition subunit, a call execution subunit, and a degradation execution subunit. The strategy parsing subunit is used to call the fault tolerance interceptor through the fault tolerance logic interception entry to intercept and parse the preset declarative fault tolerance annotation to obtain the fault tolerance strategy of the target method; The instance acquisition subunit is connected to the policy parsing subunit and is used to obtain an independent fault-tolerant component instance based on the method identifier of the target method. The call execution subunit is connected to the instance acquisition subunit and is used to construct and execute an enhanced call chain containing circuit breaker checks and retry mechanisms to execute the original business logic using the fault-tolerant component instance. The degradation execution subunit is communicatively connected to the strategy parsing subunit and the call execution subunit, and is used to execute the degradation method configured in the fault tolerance strategy and return the execution result when the enhanced call chain fails.

8. A computer device, characterized in that, It includes a storage module, a processing module, and a transceiver module that are sequentially connected in communication. The storage module is used to store computer programs, the transceiver module is used to send and receive messages, and the processing module is used to read the computer programs and execute the AI ​​service intelligent fault tolerance and degradation method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that... The computer-readable storage medium stores instructions that, when executed on a computer, perform the AI ​​service intelligent fault tolerance and degradation method as described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or the instructions are executed by the computer, they implement the AI ​​service intelligent fault tolerance and degradation method as described in any one of claims 1 to 6.

Images