Function interface implementation method and device based on extension management and medium

Abstract

The embodiment of the invention discloses a function interface implementation method and device based on extension management and a medium, relates to the technical field of interface extension, is applied to an extension manager, and comprises the following steps: in response to a call request of a client for a target function interface, generating a dynamic proxy object bound with the target function interface, intercepting a target method called by the client through the dynamic proxy object, and analyzing a target method signature of the target method; based on the target function interface identifier, acquiring a registered registration implementation class instance set from a pre-constructed registration information base, and scheduling and executing at least one implementation class instance method matched with the target method signature in the registration implementation class instance set through a pre-determined calling strategy; and obtaining a method execution return value executed by each implementation class instance method, aggregating at least one method execution return value, generating an aggregation execution result, and returning the aggregation execution result to the client through the dynamic proxy object.

Description

Technical Field

[0001] This specification relates to the field of interface extension technology, and in particular to a method, device and medium for implementing functional interfaces based on extension management. Background Technology

[0002] In the current software development field, the implementation of extended functions mainly adopts the reserved extension interface pattern. Its technical framework comprises two core layers: the interface layer and the implementation layer. The interface layer is defined by the original code provider (such as the framework developer) who defines the functional interfaces and abstract methods. The implementation layer consists of default function implementations written by the original code provider, explicitly reserving extension interfaces in pre-defined locations. Extension implementers develop extended functions based on these reserved interfaces. When third-party developers need to enhance or modify functions, they must strictly adhere to the pre-defined extension interface specifications during development.

[0003] In development scenarios where expansion requirements frequently change, when business users need to add functionality in locations without pre-defined interfaces, the original code provider has not pre-defined extension points in these areas. Therefore, the expansion provider cannot independently create access points or inject functionality through temporary configurations. Consequently, in traditional interface expansion implementations, because the code provider retains the authority to create extension entry points, the expansion provider can only perform limited operations within predetermined boundaries, failing to meet the development needs of scenarios with frequently changing expansion requirements. Summary of the Invention

[0004] This specification provides one or more embodiments of a functional interface implementation method, device, and medium based on extension management, which is used to solve the following technical problem: In the traditional implementation of interface extension, since the creation permission of the extension entry belongs to the code provider, the extension party can only perform limited operations within a predetermined boundary, which cannot meet the development needs of scenarios where extension requirements change frequently.

[0005] One or more embodiments of this specification employ the following technical solutions:

[0006] This specification provides one or more embodiments of a method for implementing a functional interface based on extension management, applied to an extension manager. The method includes: responding to a client's call request for a target functional interface, generating a dynamic proxy object bound to the target functional interface to intercept the target method called by the client through the dynamic proxy object, and parsing the target method signature of the target method; based on the target functional interface identifier, obtaining a set of registered implementation class instances from a pre-built registration information database, and scheduling the execution of at least one implementation class instance method in the set of registered implementation class instances that matches the target method signature through a predetermined calling strategy; obtaining the method execution return value of each implementation class instance method, aggregating at least one method execution return value to generate an aggregated execution result, and returning the aggregated execution result to the client through the dynamic proxy object.

[0007] This specification provides one or more embodiments of a device implementing a functional interface based on extended management, including:

[0008] At least one processor; and,

[0009] A memory communicatively connected to the at least one processor; wherein,

[0010] The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the above-described method.

[0011] This specification provides one or more embodiments of a non-volatile computer storage medium storing computer-executable instructions configured to perform the above-described method.

[0012] The above-mentioned at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects: Through the technical solutions of the embodiments of this specification, in the traditional reserved extension interface mode, the original code provider forms unilateral control by pre-embedding interface points, and the extension party can only insert functions in the predetermined slots. In view of the centralized characteristics of the traditional reserved extension interface framework, the embodiments of this specification construct a decentralized equal architecture through the three-element collaboration of dynamic proxy objects, registration information base and strategy scheduling engine; the dynamic proxy object intercepts all function call requests and strips away the differences between the framework's native methods and extension methods, so that the two are on equal footing at the call entry point; the registration information base constructs an open registration plane, homogenizes the framework's default implementation and third-party extensions into "implementation class instances", eliminates the concept of framework privileged code, and any class that implements the target interface can be freely registered, so that the extension point position is defined in real time by business requirements rather than predicted by the framework designer; the strategy scheduling engine forms a dynamic routing layer, which schedules native methods and extension methods according to a unified strategy, technically eliminating the difference in identity execution. Dynamic proxies act as a safety buffer, allowing clients to rely only on abstract interfaces while decoupling from concrete implementations. Default implementations can be seamlessly replaced during framework upgrades. The registration library enforces verification of method signatures between implementation classes and interfaces, dynamically validating call parameters at runtime to prevent extensions from violating interface contracts. Strategy scheduling ensures the sequentiality of sensitive operations through serial mode, avoids resource contention through thread isolation in parallel mode, and circuit breakers handle faulty instances without interrupting the main chain in exception handling. Attached Figure Description

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

[0014] Figure 1 A flowchart illustrating a method for implementing a functional interface based on extended management, provided in an embodiment of this specification;

[0015] Figure 2 A flowchart illustrating another method for implementing a functional interface based on extended management, provided in the embodiments of this specification;

[0016] Figure 3 This is a schematic diagram of a device implemented based on an extended management function interface, as provided in an embodiment of this specification. Detailed Implementation

[0017] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0018] This specification provides a method for implementing a functional interface based on extension management. It should be noted that the execution entity in this specification can be a server or any device with data processing capabilities. Specifically, this method is applied to an extension manager deployed in a hardware environment equipped with a multi-core processor, large-capacity memory, and high-speed solid-state storage. By constructing a collaborative mechanism involving a registration management module, a dynamic proxy module, a policy scheduling module, and a security sandbox module, it achieves unified and equitable control over extension functions. The registration management module receives and stores the registration information of implementation class instances. Its core registration information database adopts an in-memory database structure, recording three key fields: fully qualified interface name, instance type (SPI / Spring / hybrid mode), and execution priority. When an extension implementer submits a JAR package containing a configuration file, this module automatically parses the configuration file and generates standardized registration records, breaking the traditional monopoly of framework providers on extension permissions.

[0019] When the dynamic proxy module receives a client's call request for the target function interface, it generates a proxy object bound to that interface in real time using Java reflection. This object embeds a method interceptor to capture the specific method signature and input parameters of the client's call, establishing a decoupling hub between business logic and extension management. The strategy scheduling module selects a serial or parallel execution path based on preset rules. In serial mode, instances are sorted by priority value, and chained data transfer is achieved through a context object. In parallel mode, instances are called concurrently based on a thread pool mechanism, obtaining the first valid result with a millisecond-level response time. The security sandbox module limits the CPU, memory, and network resource usage of each extension instance through operating system-level resource isolation technology. Combined with the circuit breaker strategy of the exception control module, this improves the fault isolation rate.

[0020] Figure 1 This specification provides a flowchart illustrating a method for implementing a functional interface based on extended management, as shown in the embodiments below. Figure 1 As shown, the main steps include the following:

[0021] Step S101: In response to the client's call request to the target function interface, a dynamic proxy object bound to the target function interface is generated to intercept the target method called by the client through the dynamic proxy object and parse the target method signature of the target method.

[0022] In response to a client's request to call a target functional interface, a dynamic proxy object bound to that target functional interface is generated. Specifically, this includes: in response to a client's request to call a target functional interface, extracting the class name identifier of the target functional interface; based on the class name identifier, creating a dynamic proxy object bound to the target functional interface through reflection; and embedding a method interceptor into the dynamic proxy object to intercept the target method called by the client.

[0023] In a software extension management system, a client's call to a target functional interface is essentially the entry point for interaction between business logic and extension capabilities. Without this proxy layer, the client would directly access the native implementation class, causing the extension management mechanism to fail. By extracting the class name identifier of the target functional interface (e.g., com.example.PaymentService), the abstract interface and concrete implementation are decoupled, granting the extension manager control over call interception. The implanted method interceptor serves as the sole entry point for extension calls, providing the execution foundation for subsequent method signature parsing, strategy scheduling, and exception handling. In a microservice architecture, this design physically isolates third-party payment plugins from the core transaction system. The default payment logic of the original framework provider and the risk control plugin of the extension provider are registered with the manager on an equal footing, eliminating the hierarchical barrier of framework dominance versus extension passivity and providing the technical foundation for an egalitarian architecture.

[0024] In one embodiment of this specification, when a client initiates a call request to a target functional interface (such as an order payment interface) via the HTTP / RPC protocol, the extension manager's communication adapter first receives and parses the request data packet, extracting the fully qualified class name string of the target functional interface. Based on this string identifier, the manager calls the Java reflection interface to load the bytecode definition of the target interface, and then instantiates a dynamic proxy object. During the construction of the dynamic proxy object, a method interceptor is implanted. The interceptor is essentially a callback handler for pre-defined hook functions, and its memory structure contains a method table mapping of the target interface and a reference to the extension manager's strategy execution engine. When the client calls any method of the proxy object, the interceptor automatically captures the method name, parameter type list, and actual parameter values, encapsulating them into a method signature object (such as pay(String orderId, BigDecimal amount)). This signature object, along with the calling context (such as request ID, user credentials), is passed to the extension manager's scheduling pipeline, triggering subsequent instance loading and strategy execution processes, while the client is completely unaware of this interception process.

[0025] Traditional methods require clients to directly call concrete implementation classes, leading to deep coupling between business code and the extended framework. The technical solution in this specification establishes an abstraction layer through dynamic proxy objects. Clients only rely on functional interface declarations, enabling independent system upgrades without modifying the caller's code, significantly reducing system maintenance complexity. Furthermore, while conventional solutions grant priority to the framework provider's implementation class, this specification's solution downgrades the original framework code to a regular extended instance. For example, in a bank transaction system, both the risk control plugin and the default payment logic must be registered through a proxy object, ensuring equal status in the call chain and breaking the traditional privileged architecture of frameworks. Additionally, method interceptors capture the execution context in real-time during invocation, allowing strategies such as traffic scheduling and circuit breaking to take effect dynamically. Interceptors, acting as a crucial checkpoint for all calls, form the entry barrier to the security sandbox, achieving global security control. The method signature parsing process automatically generates a call tracing ID, which persists throughout the entire subsequent extended execution chain.

[0026] Step S102: Based on the target function interface identifier, obtain the set of registered implementation class instances from the pre-built registration information database, and schedule the execution of at least one implementation class instance method in the set of registered implementation class instances that matches the target method signature through a pre-determined invocation strategy.

[0027] Based on the target function interface identifier, a set of registered implementation class instances is obtained from a pre-built registration information database. Specifically, this includes: extracting the fully qualified name of the target function interface bound to the dynamic proxy object; using the fully qualified name as the search key, querying the corresponding set of registration records in the registration information database, and determining the type identifier of the registration records in the set; when the type identifier is SPI type, loading all implementation class instances through the Java SPI service loader; when the type identifier is Spring type, obtaining all Bean instances implementing the interface from the Spring container; when the type identifier is a mixed type, merging the instances loaded by the SPI and Spring containers and removing duplicates, returning the deduplicated set of implementation class instances.

[0028] In modern software environments with diverse technology stacks, the methods for obtaining class instances are fragmented. This specification's embodiments address the fragmented extension issues caused by framework differences in traditional solutions by unifying the management of SPI, Spring, and a hybrid registration model. For example, when a financial platform needs to integrate a core banking system (a payment plugin based on SPI) and internet channels (preferential services in the form of Spring Beans), the inability to obtain instance sets through a standardized process forces developers to write adaptation layer code, resulting in resource waste and maintenance risks. The registration information repository, acting as a central hub, uses the fully qualified name of the target functional interface as the search key, enabling cross-framework extension instances to be scheduled equally. This eliminates framework binding risks at the source and ensures the sustainable evolution of the extension capabilities of heterogeneous systems such as the Internet of Things and fintech.

[0029] In one embodiment of this specification, after the extension manager completes the generation of the dynamic proxy object, it immediately extracts the fully qualified name string of the target functional interface (e.g., com.company.payment.TransactionService) from its bound metadata. This string is passed as the primary key to the query interface of the registration information database. The registration information database uses an in-memory database table structure to store three key elements: the fully qualified name of the interface (primary key), the registration type enumeration value (SPI / Spring / hybrid), and the instance priority value. After obtaining a matching record, the registration type identifier is parsed to trigger the differentiated loading process. If identified as an SPI type, the manager invokes the Java standard service loader to scan the configuration files corresponding to the interface name in the META-INF / services directory under the classpath, reading the fully qualified names of the implementation classes line by line. It then instantiates all declared classes through the class loader and injects default constructor parameters, forming a collection of instances. If identified as a Spring type, the manager accesses the Spring application context container, calls the getBeansOfType() interface to obtain all Bean instances implementing that interface, and automatically handles dependency injection and lifecycle states. When identified as a mixed type, SPI loading and Spring container retrieval are performed simultaneously, followed by a deduplication process. This involves comparing the instance memory address and the hash value of the class signature, removing duplicates, and returning the final collection. During this process, Spring container instances require special handling of proxy references due to container management. The manager uses AOP tools to strip the CGLIB proxy layer to obtain native Bean instances to ensure type consistency with SPI instances. After all instances are loaded, the manager pre-sorts them according to their priority values ​​in the registry, establishing an ordered execution foundation for subsequent strategy scheduling.

[0030] Traditional solutions force developers to bind specific extension frameworks, leading to a significant increase in the integration costs of legacy systems. This specification's embodiment utilizes a registration type-based diversion mechanism, allowing the same order processing interface to simultaneously manage both the Spring transaction beans of the bank's core system and the SPI encryption plugin of a third-party payment institution. This enables dynamic plug-and-play functionality of payment channels in cross-border e-commerce settlement scenarios. Conventional solutions require writing adaptation layer code for different technology stacks, while this embodiment completes the technology adaptation within the manager, completely transparent to the business layer. The instance deduplication mechanism in the hybrid mode fundamentally solves the memory waste problem of repeatedly loading the same service in traditional hybrid architectures. In microservice registry scenarios, when a service exists simultaneously as a Spring bean and SPI (e.g., during version transitions), conventional solutions create two independent instances, consuming double the thread resources. This solution intelligently identifies duplicates, reducing memory usage and preventing business logic conflicts caused by repeated execution of the same service. Based on precise interface identifier retrieval and dynamic loading mechanisms, extension plugins achieve runtime hot replacement.

[0031] Before retrieving the set of registered implementation class instances from the pre-built registration information repository, the method further includes: receiving an implementation class instance registration request, wherein the implementation class instance registration request includes an implementation class instance and a registration type identifier; determining the implementation class instance registration information based on the registration type identifier, wherein the implementation class instance includes instances loaded via the Java SPI mechanism, Bean instances injected via the Spring container, and instances compatible with both via a hybrid mode; and constructing a registration information repository based on the implementation class instance registration information. Determining the implementation class instance registration information based on the registration type identifier specifically includes: when the registration type identifier is in SPI mode, creating an SPI registration record and storing the SPI implementation class instance; when the registration type identifier is in Spring mode, creating a Spring registration record and associating it with a Bean instance in the container; and when the registration type identifier is in hybrid mode, creating a dual registration record and marking the association between SPI and Spring.

[0032] In extended management architectures, traditional solutions lack standardized registration mechanisms. For example, when a financial payment system needs to integrate both a core bank Spring transaction bean and a third-party risk control SPI plugin, developers are forced to write two sets of loading logic. This not only generates redundant code but also introduces transaction consistency risks due to differences in instance initialization timing. Furthermore, in hot update scenarios in cloud-native environments, if a precise mapping between registration records and implementation class instances is not established, the new version of the algorithm plugin will be unable to recognize the lifecycle state of the old instance, leading to memory leaks. Additionally, in hybrid modes, the same service may be registered repeatedly (e.g., the Spring container and SPI load the same implementation class simultaneously), causing thread resource consumption to double. The embodiments in this specification construct a typed registration record structure by receiving instance registration requests carrying registration type identifiers, thus establishing a precise metadata index for subsequent instance acquisition.

[0033] In one embodiment of this specification, the extension manager receives an implementation class instance registration request. The request includes the implementation class instance object to be registered, and a registration type identifier declaring the loading method (SPI mode, Spring mode, or hybrid mode). The manager first parses the registration type identifier, triggering a differentiated processing flow: when the identifier is SPI mode, the extension manager creates an SPI registration record. This record contains the fully qualified name of the implementation class, a class loader reference, and instance initialization parameters. Then, it calls the Java service loader interface, scans the configuration files of the corresponding interface in the META-INF / services directory under the classpath, reads the implementation class name line by line, instantiates the object using reflection, and writes the instance memory address and configuration parameters into the record. When the identifier is Spring mode, the manager creates a Spring registration record. This record is associated with the target Bean name in the Spring application context container, utilizing Spring's BeanFactor... The `ctory` interface retrieves initialized Bean instances and records their scope (Singleton / Prototype) and dependency injection state. It handles CGLIB proxy classes specially to remove the proxy layer and obtain native instances. When in hybrid mode, the manager synchronously loads instances from both SPI and Spring, creating dual registration records. This records a cross-reference mapping table containing the SPI instance set and the Spring instance set. By calculating the hash value and memory address of the instance class signature, it marks the association of duplicate instances (e.g., a `PaymentServiceImpl` instance in the Spring container and an instance of the same name loaded from SPI are considered duplicates). All registration records are grouped by fully qualified interface names and stored in an in-memory database, forming a tree-like index structure. The root node is the hash value of the fully qualified interface name, and child nodes hold pointers to implementation class instances ordered by priority. For example, during a medical image analysis system upgrade, when a new version of the lung nodule detection algorithm (SPI mode) is registered, the manager automatically establishes a version association with the same functional instance in the old Spring container, creating a topology foundation for hot replacement.

[0034] Before scheduling the execution of at least one instance method of an implementation class in the registered implementation class instance set that matches the signature of the target method according to a predetermined invocation strategy, the method further includes: reading preset global strategy parameters from a preset configuration center service, wherein the global strategy parameters include global invocation strategy parameters and global exception handling strategy parameters; parsing the bytecode of the target method to detect whether there is a strategy annotation, wherein the strategy annotation includes an invocation strategy annotation and an exception handling strategy annotation; when the strategy annotation exists, overriding the corresponding global strategy parameters with the strategy parameters declared in the strategy annotation to determine the invocation strategy and exception handling strategy corresponding to the target method, and binding them to the target method.

[0035] In the policy control of extended management systems, traditional extended frameworks use hard-coded policy configurations. In financial transaction scenarios, payment interfaces need to strictly execute risk control audits and fund deductions serially, while discount calculation interfaces need to be called in parallel to improve response speed. However, static policies cannot support differentiated needs. In medical image analysis scenarios, lesion detection algorithms need to switch to a degradation strategy when the GPU fails, but the mechanism of restarting the service to change the configuration delays the treatment of critically ill patients. More seriously, when third-party plugins have security vulnerabilities, traditional solutions lack real-time circuit breaking capabilities, which may lead to financial losses or data leaks.

[0036] In one embodiment of this specification, the extension manager initiates a remote query request to a separately deployed configuration center before the call is executed. The configuration center loads a predefined global policy configuration file from persistent storage (such as a ZooKeeper cluster). This global policy configuration file includes a global call policy (such as the default parallel mode) and a global exception handling policy (such as the default exception ignoring). After temporarily storing the policy parameters in thread-local variables, the extension manager starts the bytecode parsing engine of the target method, obtains the byte stream of the class to which the method belongs through the Java Instrumentation API, parses the method body structure using the ASM framework, and scans the annotation metadata at the method declaration. If @CallPolicy(strategy="SERIAL") or

[0037] For policy annotations such as `@ExceptionPolicy(action="BREAK")`, the annotation value is extracted to generate policy overriding instructions. Overriding rules follow a priority order: method-level, interface-level, and global-level, with priority decreasing. For example, if a method annotation declares serial calls but the global configuration is parallel, the final policy will be serial. During the policy binding phase, the determined policy type, such as serial or circuit breaker, is encapsulated into a policy context object. The context object includes a policy enumeration identifier and associated parameters. These associated parameters can be timeout thresholds in serial mode, and a strong association mapping is established with the target method through the method signature hash value. For example, in a real-time anti-fraud scenario in a bank, when the `validateTransaction()` method is marked...

[0038] When using `@CallPolicy("PARALLEL")`, even if the global policy is serial, the engine will still create a parallel policy context and bind it to the memory address of this method, ensuring accurate execution by subsequent scheduling modules. All policy metadata is stored in the manager's policy cache pool, and invalid references are automatically cleaned up through a garbage collection-aware mechanism.

[0039] By employing a two-tiered overriding mechanism of global and annotation strategies, policy decisions are extended from the coding phase to runtime, enabling the extension manager to dynamically adjust execution logic based on business scenarios. Traditional solutions hard-code invocation strategies at the framework layer; for example, the OSGi specification mandates synchronous invocation for all extensions, preventing high-concurrency payment gateways from leveraging multi-core advantages. In contrast, the embodiments described in this specification utilize a dynamic overriding mechanism based on bytecode annotations, allowing for differentiated configurations of different methods within the same interface. Furthermore, the overriding rules of global and annotation strategies provide emergency mitigation channels for critical business operations.

[0040] Using a pre-determined invocation strategy, the execution of at least one implementation class instance method from the registered implementation class instance set that matches the signature of the target method is scheduled. Specifically, this includes: determining the execution mode based on the invocation strategy type, where the execution mode includes serial mode or parallel mode; when the execution mode is serial mode, sorting the implementation class instances in ascending order of priority to determine the invocation order; creating a context object containing the initial input parameters of the target method; sequentially invoking the target method of each implementation class instance according to the invocation order, writing the return value of the previous invocation to the context object and passing it to the next implementation class instance; when the execution mode is parallel mode, creating a thread group equal in number to the implementation class instances; submitting the target method of each implementation class instance to an independent thread for execution, monitoring the first non-empty valid result returned by the thread group and marking it as an intermediate result.

[0041] During the execution of the extended management system, the traditional extended framework uses a static call chain, which cannot meet the needs of complex business scenarios. For example, in financial transaction scenarios, the payment interface needs to be executed in strict order to ensure transaction consistency, while the discount calculation interface needs to call multiple marketing plugins in parallel to improve response speed. However, the static call chain cannot dynamically adapt to differentiated needs. When high-concurrency traffic surges, the traditional solution cannot switch from serial to parallel to improve throughput.

[0042] In one embodiment of this specification, after the extension manager completes policy binding, it executes according to the policy call type. If the policy is in serial mode, the extension manager first scans the set of implementation class instances, extracts the priority value field (range 1-100) preset during the registration phase, and stably sorts the instances according to ascending order, and sorts those with the same priority according to registration time, generating a linear call sequence. Then, a context object is created, containing a deep copy of the initial input parameters of the target method, a unique identifier for the call chain, and a snapshot of environment variables. The execution engine sequentially calls the target method of each instance in the sequence, using the context object as input for the first instance, capturing its execution result and writing it to the "lastResult" field of the context object; when the next instance executes, the updated context object is automatically injected, forming a data transfer chain. In a bank transfer scenario, the risk control instance outputs a risk score and writes it to the context, and the payment instance reads this score to adjust the deduction policy, achieving cross-instance data collaboration.

[0043] If the strategy is in parallel mode, the manager first calculates the cardinality of the instance set and selects a thread resource allocation scheme accordingly: a fixed thread pool is used when the number of instances is small, and ForkJoinPool is enabled to optimize resource utilization when the number of instances is large. The target method of each instance is encapsulated as an independent task and submitted to the thread pool. The manager starts a timeout control thread group to monitor the task execution status. When a task returns a non-null valid result, such as a non-null object or a non-zero primitive type value, the result is immediately marked as an intermediate result, and an attempt is made to interrupt other threads (but not forcibly terminate them). In an ad bidding system, when ten ad sources are called in parallel, the first thread to return a valid bid triggers result aggregation, and the remaining threads terminate naturally after completing their current calculations, avoiding resource idleness.

[0044] Through the embodiments described in this specification, a dynamic decision-making mechanism based on execution mode enables the extension manager to construct the optimal execution path in real time based on policy configuration. Traditional solutions require hard-coding the call order in the business code, resulting in deep coupling between the core payment logic and the extension framework. The embodiments in this specification, through automatic sorting and context passing mechanisms in serial mode, allow the risk control plugin and the payment plugin to evolve independently. The intelligent thread management in parallel mode avoids the limitations of static allocation in traditional thread pools. For example, in e-commerce flash sale scenarios, when thousands of discounts are calculated and extended concurrently, the manager dynamically divides the task into groups (e.g., 100 instances / group) and submits them to the ForkJoinPool in segments, avoiding the overhead of excessive thread switching. In contrast, traditional solutions require pre-allocating a fixed number of threads, which often leads to thread starvation or memory overflow problems due to improper configuration.

[0045] Using a pre-determined invocation strategy, at least one instance method of an implementation class in the registered implementation class instance set that matches the signature of the target method is scheduled for execution. Specifically, this includes: obtaining the exception object thrown when executing the instance method of the implementation class; reading the bound exception handling strategy type; if the strategy type is ignore mode, writing the exception object information to the system log file and continuing to execute subsequent instance methods; if the strategy type is circuit breaker mode, interrupting the execution of the current call chain, generating an exception response message and returning it to the client through a dynamic proxy object.

[0046] In the process of achieving stability in distributed extended systems, traditional solutions adopt a "one-size-fits-all" strategy, such as global circuit breaking or complete ignoring. This can easily lead to serious problems in complex business scenarios. For example, in financial transaction scenarios, if a third-party risk control plugin malfunctions and causes the entire payment chain to break down, it will cause widespread transaction paralysis. In medical emergency scenarios, if a non-core image enhancement algorithm malfunctions and interrupts the main CT scan process, it will delay the treatment of critically ill patients.

[0047] When the extension manager schedules the execution of an instance method of an implementation class, it captures exception objects in the execution context in real time through exception monitoring hooks provided by the Java Virtual Machine. The exception object includes the exception type (e.g., NullPointerException), the error message, and complete call stack information. The extension manager immediately suspends the current execution thread and reads the exception handling strategy type pre-bound to the target method. The exception handling strategy type is dynamically determined by global parameters in the configuration center or method annotations. If the strategy type is ignore mode, the extension manager calls the asynchronous write interface of the log service, encapsulating the key attributes of the exception object (exception type, occurrence time, thread ID) and the unique tracer of the call chain into a structured log entry, and writes it to persistent storage (e.g., a distributed log cluster) through a file system buffer queue. During log writing, the current thread is in a waiting state to ensure record integrity; after completion, the exception instance resources are immediately released, and the execution flow of subsequent implementation class methods resumes.

[0048] If the strategy type is circuit breaker mode, the extension manager first interrupts all related tasks in the current thread group, sends a Thread.interrupt() signal for parallel mode, and directly terminates the call chain for serial mode. Then, it cleans up the allocated memory and network resources. Next, it constructs a standardized exception response message, which includes an exception summary (error code, readable description), the location of the occurrence (class name + method name), and a snapshot of the security-de-identified input parameters. Finally, it encapsulates the message into an HTTP 503 response or an RPC exception object and returns it to the client through a dynamic proxy object.

[0049] Through the embodiments in this specification, the dynamic adaptation mechanism of circuit breaker and ignore policies solves the dilemma of "excessive circuit breaking" or "abnormal propagation" in traditional solutions; the deep integration of structured logs and call chain tracing enables accurate anomaly diagnosis; the proactive resource reclamation mechanism in circuit breaker mode avoids memory leaks caused by traditional "abnormal swallowing"; and through a policy-driven differentiated processing mechanism, the extension manager can dynamically select fault tolerance schemes based on business importance, with core financial operations implementing circuit breaker protection and non-critical services enabling anomaly degradation.

[0050] Step S103: Obtain the method execution return value of each implementation class instance method, aggregate the method execution return values ​​of at least one method to generate an aggregated execution result, and return the aggregated execution result to the client through a dynamic proxy object.

[0051] In one embodiment of this specification, after the instance method execution is complete, the extension manager extracts the original return value object from the execution context. The extension manager first detects the current invocation strategy type. If it is serial mode, it obtains the final result value from the "lastResult" field of the context object (this field is updated at the last execution of the chained calls); if it is parallel mode, it reads the first valid intermediate result marked by the thread monitoring module. Then, it starts the aggregation engine, which includes three components: a type adapter, a rule processor, and a security validator. The type adapter parses the runtime type of the return value object. When it detects a mismatch between the basic type (e.g., int) and the wrapper type declared by the target method (e.g., Integer), it automatically performs a boxing operation. The rule processor transforms the data according to a pre-defined aggregation strategy, using accumulation rules (e.g., stacking discount amounts) in financial scenarios and spatial fusion rules (e.g., overlaying tumor location and blood vessel coordinates into a 3D model) in medical scenarios. The security validator verifies the boundary of the result value, such as ensuring the payment amount is non-negative and the medical coordinates are within a reasonable anatomical range. If the verification fails, it triggers retry or degradation logic. Finally, the aggregation result is serialized into JSON to generate a standardized response body, which is injected into the return channel of the dynamic proxy object.

[0052] Figure 2 A flowchart illustrating another method for implementing a functional interface based on extended management, as provided in the embodiments of this specification, is shown below. Figure 2As shown, when a client calls a method of the target functional interface through a dynamic proxy object, such as PaymentService.processOrder(), the extension manager initiates a three-layer parallel resolution process. First, it resolves the instance registration type of the interface implementation class configured on the proxy object's bound interface. Then, it calls the instance acquisition factory corresponding to the registration type to generate a specific instance acquisition machine. If the registration type is in SPI mode, the factory returns an acquisition machine based on the Java service loader, scanning the META-INF / services directory to load the implementation class; if it is in Spring mode, the factory returns a container-aware acquisition machine, extracting the Bean instance from the application context. Next, the invocation strategy and exception handling strategy configured in the interface method are parsed. The strategy resolver detects the `@CallStrategy` annotation (such as "PARALLEL") in the method bytecode and instantiates the corresponding strategy executor through the extended caller factory (creating a thread pool scheduler in parallel mode and generating a chained context passer in serial mode). The exception strategy resolver reads the `@ExceptionPolicy` annotation (such as "IGNORE") and constructs a specific strategy handler through the exception handling strategy factory (when the client calls the `analyze(image)` method of the target function interface through a dynamic proxy object (such as the DICOM analysis interface in a medical imaging system), the extension manager initiates a triple parallel parsing process). The registration type parsing branch, based on the `@RegistryType("HYBRID")` annotation in the interface metadata, calls the interface implementation class getter factory to generate a hybrid mode getter, which synchronously triggers Java. The SPI loader scans the META-INF / services directory (loading third-party AI lesion recognition plugins) and simultaneously accesses the Spring application context container to extract DICOM engine bean instances developed in-house. When merging instances, duplicates are removed using class signature hash values, resulting in a deduplicated set of instances. The `@CallPolicy("PARALLEL")` annotation is used to check the call policy branch, driving the extended caller factory to create a thread pool scheduler, initializing thread groups according to the number of instances, setting GPU memory isolation rules, and implementing a first-result competition mechanism. The `@ExceptionPolicy("BREAK")` annotation is used to parse the exception policy branch, constructing a circuit breaker through the exception handling policy factory, configuring exception log desensitization rules, and resource reclamation hook functions.

[0053] When the outputs of the three main branches converge to the extended caller, they form a policy execution pipeline. This pipeline is bound to an instance set, a thread scheduler, and a circuit breaker. Upon inputting raw DICOM image data, the caller submits data fragments to the execution engine. The thread pool concurrently starts the lesion segmentation and image enhancement algorithms, while the circuit breaker monitors memory usage and abnormal signals in real time. If the lesion segmentation algorithm throws a GPUResourceException due to memory overflow, the circuit breaker immediately performs a circuit breaker operation: sending an interrupt signal to the image enhancement algorithm, releasing memory resources via the JNI interface, and recording the exception stack and input data fingerprint to the encrypted log system. Simultaneously, the caller generates a structured error message (containing exception encoding and security-de-identified image hash values), which is returned to the doctor's workstation via a dynamic proxy object. If execution is successful, the caller captures the 3D coordinate set returned by the lesion segmentation algorithm and the contrast parameters of the image enhancement algorithm, fuses them through an aggregation engine into a standardized diagnostic report (including lesion localization maps and quantitative indicators), and finally returns it to the radiology terminal through the proxy channel.

[0054] It should be noted that, Figure 2 The interface implementation class getter factory in the middle is used to implement the hybrid registration mechanism, the SPI loader isolates the third-party AI algorithm sandbox environment through the class loader, and the Spring container extractor retains the transaction consistency guarantee of the internal engine; Figure 2 The extended caller factory in the middle is used for dynamic strategy execution, the thread pool scheduler realizes parallel control of tens of thousands of instances, and the first effective result competition mechanism meets the timeliness requirements of emergency rescue scenarios; Figure 2 The exception handling strategy factory in the middle is used for tiered circuit breaking, resource reclamation hooks completely eliminate memory leakage, encrypted logs and de-identification mechanisms comply with HIPAA medical privacy specifications, and a logger is generated in the circuit breaking mode (the call chain interruptor is constructed in the circuit breaking mode). Finally, the instance set, the call strategy executor and the exception strategy handler converge to the extended caller, which binds the target method parameters and exception policies to the call execution pipeline.

[0055] Through the technical solutions of the embodiments in this specification, in the traditional reserved extension interface mode, the original code provider forms unilateral control by pre-embedding interface points, and the extension party can only insert functions in the predetermined slots. In response to the centralized characteristics of the traditional reserved extension interface framework, the embodiments in this specification construct a decentralized and equal architecture through the three-element collaboration of dynamic proxy objects, registration information base and strategy scheduling engine. The dynamic proxy object intercepts all function call requests and separates the differences between the framework's native methods and extension methods, so that the two are on equal footing at the call entry point. The registration information base constructs an open registration plane, homogenizing the framework's default implementation and third-party extensions into "implementation class instances", eliminating the concept of framework privileged code. Any class that implements the target interface can be freely registered, so that the extension point position is defined in real time by business requirements rather than predicted by the framework designer. The strategy scheduling engine forms a dynamic routing layer, which schedules native methods and extension methods according to a unified strategy, technically eliminating the difference in identity execution. Dynamic proxies act as a safety buffer, allowing clients to rely only on abstract interfaces while decoupling from concrete implementations. Default implementations can be seamlessly replaced during framework upgrades. The registration library enforces verification of method signatures between implementation classes and interfaces, dynamically validating call parameters at runtime to prevent extensions from violating interface contracts. Strategy scheduling ensures the sequentiality of sensitive operations through serial mode, avoids resource contention through thread isolation in parallel mode, and circuit breakers handle faulty instances without interrupting the main chain in exception handling.

[0056] This specification also provides an embodiment of a device based on an extended management functional interface, such as... Figure 3 As shown, the device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the above-described method.

[0057] This specification also provides a non-volatile computer storage medium storing computer-executable instructions configured to perform the above-described method.

[0058] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0059] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0060] The devices, media, and methods provided in the embodiments of this specification are one-to-one correspondences. Therefore, the devices and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be repeated here.

[0061] Those skilled in the art will understand that embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0062] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0063] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0064] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0065] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0066] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0067] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0068] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Without further limitation, the phrase "comprising a…" … ” The definition of a specific element does not preclude the presence of other identical elements in the process, method, product, or apparatus that includes the element.

[0069] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for implementing a functional interface based on extended management, characterized in that, Applied to an extension manager, the method includes: In response to a client's request to call a target function interface, a dynamic proxy object bound to the target function interface is generated to intercept the target method called by the client through the dynamic proxy object and parse the target method signature of the target method. Based on the target function interface identifier, a set of registered implementation class instances is obtained from a pre-built registration information database. Through a pre-determined calling strategy, at least one implementation class instance method in the set of registered implementation class instances that matches the target method signature is scheduled for execution. Obtain the method execution return value of each instance method of the implementation class, aggregate at least one method execution return value to generate an aggregated execution result, and return the aggregated execution result to the client through the dynamic proxy object.

2. The method for implementing a functional interface based on extended management according to claim 1, characterized in that, Before retrieving the collection of registered implementation class instances from the pre-built registration information repository, the method further includes: Receive an implementation class instance registration request, wherein the implementation class instance registration request includes an implementation class instance and a registration type identifier; Based on the registration type identifier, the registration information of the implementation class instance is determined, wherein the implementation class instance includes instances loaded through the Java SPI mechanism, Bean instances injected through the Spring container, and instances that are compatible with both through a hybrid mode; A registration information database is constructed based on the registration information of the implementation class instance.

3. The method for implementing a functional interface based on extended management according to claim 1, characterized in that, Before scheduling the execution of at least one instance method of an implementation class in the registered implementation class instance set that matches the signature of the target method using a predetermined invocation strategy, the method further includes: Read the preset global policy parameters from the preset configuration center service, wherein the global policy parameters include global invocation policy parameters and global exception handling policy parameters; Parse the bytecode of the target method to detect whether there are strategy annotations, wherein the strategy annotations include call strategy annotations and exception handling strategy annotations; When the strategy annotation exists, the strategy parameters declared in the strategy annotation override the corresponding global strategy parameters to determine the invocation strategy and exception handling strategy corresponding to the target method, and bind them to the target method.

4. The method for implementing a functional interface based on extended management according to claim 1, characterized in that, Using a pre-determined invocation strategy, at least one instance method of an implementation class in the registered implementation class instance set that matches the signature of the target method is scheduled for execution, specifically including: The execution mode is determined based on the invocation strategy type, wherein the execution mode includes serial mode or parallel mode; When the execution mode is serial mode, the calling order is determined by sorting the implementation class instances in ascending order of priority value; Create a context object containing the initial input parameters of the target method; The target method of each implementation class instance is called sequentially according to the calling order, and the return value of the previous call is written to the context object and passed to the next implementation class instance. When the execution mode is parallel mode, a thread group is created with the same number of instances of the implementation class. The target method of each implementation class instance is submitted to an independent thread for execution, and the first non-empty valid result returned by the thread group is monitored and marked as an intermediate result.

5. The method for implementing a functional interface based on extended management according to claim 3, characterized in that, Using a pre-determined invocation strategy, at least one instance method of an implementation class in the registered implementation class instance set that matches the signature of the target method is scheduled for execution, specifically including: Obtain the exception object thrown when executing an instance method of the implementation class; Read the bound exception handling strategy type. If the strategy type is ignore mode, write the exception object information to the system log file and continue to execute the subsequent instance methods. If the strategy type is circuit breaker mode, the execution of the current call chain is interrupted, an exception response message is generated and returned to the client through a dynamic proxy object.

6. The method for implementing a functional interface based on extended management according to claim 1, characterized in that, In response to a client's request to call a target functional interface, a dynamic proxy object bound to the target functional interface is generated, specifically including: In response to a client's request to call the target function interface, extract the class name identifier of the target function interface; Based on the class name identifier, a dynamic proxy object bound to the target functional interface is created using reflection. A method interceptor is embedded in the dynamic proxy object to intercept the target method called by the client.

7. The method for implementing a functional interface based on extended management according to claim 1, characterized in that, Based on the target function interface identifier, a set of registered implementation class instances is obtained from a pre-built registration information database, specifically including: Extract the fully qualified name of the target function interface bound to the dynamic proxy object; Using the fully qualified name as the search key, query the corresponding set of registration records in the registration information database to determine the type identifier of the registration record in the set of registration records; When the type is identified as SPI, all implementation class instances are loaded via the Java SPI service loader; When the type is identified as Spring, obtain all Bean instances that implement the interface from the Spring container; When the type is identified as a mixed type, merge the SPI and Spring container-loaded instances and remove duplicates, returning a collection of deduplicated implementation class instances.

8. A method for implementing a functional interface based on extended management according to claim 2, characterized in that, Based on the registration type identifier, the registration information of the implementation class instance is determined, specifically including: When the registration type is identified as SPI mode, an SPI registration record is created and an instance of the SPI implementation class is stored. When the registration type is identified as Spring mode, a Spring registration record is created and associated with a Bean instance in the container; When the registration type is identified as a mixed mode, a dual registration record is created and the association between SPI and Spring is marked.

9. A device implementing a functional interface based on extended management, characterized in that, The device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method as described in any one of claims 1-8.

10. A non-volatile computer storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are configured to perform the method as described in any one of claims 1-8.

Images