K8s integration-oriented system interface reentrant idempotent implementation method and K8s integration-oriented system interface reentrant idempotent implementation device
By collaboratively designing the encapsulated interface caller and executor, the compatibility issues of interface non-idempotence and non-reentrancy in K8s integration are resolved, enabling efficient and reliable integration of K8s and enterprise systems.
Patent Information
- Application Number
- CN202510853408.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-24
- Publication Date
- 2025-10-28
AI Technical Summary
Existing technologies make it difficult to resolve compatibility issues between the horizontal trigger mechanism and the non-idempotence and non-reentrancy of enterprise system interfaces during the K8s integration process, which affects integration efficiency and stability.
By encapsulating the target system's interface as an interface caller, and using the executor to traverse and process the interface caller list in order, combined with status checking and error handling mechanisms, the idempotence and reentrancy of the interface call process are ensured.
It achieves two-way integration between K8s and enterprise systems, ensures the idempotence and reentrancy of the interface calling process, avoids repeated calls and status anomalies, and improves the efficiency and stability of system integration.
Smart Images
Figure CN120848987A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of system integration technology, specifically to a method, apparatus, and computer-readable storage medium for implementing a reentrant idempotent system interface for Kubernetes integration. Background Technology
[0002] Kubernetes (K8s) is an open-source container orchestration platform primarily used for automating the deployment, scaling, and management of containerized applications. By encapsulating applications within containers, it enables efficient resource scheduling, service discovery, load balancing, and other functionalities, helping enterprises manage and run distributed systems more conveniently. As an open-source container orchestration platform, K8s needs to integrate and interact with existing enterprise systems (such as resource management, service discovery, monitoring, and log collection) to adapt to the enterprise's unique business processes and architecture, avoid redundant development, and support business operations.
[0003] Kubernetes (K8s) is designed with a level-triggered mechanism. It compares the current system state with the desired system state, continuously initiating calculations to bring the current state closer to the desired state. If the desired state is not reached, multiple automatic retries occur. However, most enterprise systems are generally non-idempotent and non-reentrant. The current technical challenge lies in resolving the compatibility issue between K8s' level-triggered mechanism (continuous retries) and the non-idempotent and non-reentrant nature of enterprise system interfaces.
[0004] Existing technologies include several mechanisms for achieving idempotency, such as optimistic locking, anti-duplicate tables, and state machine idempotency. However, these primarily focus on server-side idempotency. Requiring the server to implement and provide idempotent interfaces incurs high coordination costs due to the involvement of multiple systems, leading to significant duplication of development work. Furthermore, existing technologies cannot implement level-triggered mechanisms in enterprise systems. Modifying existing system interfaces to adapt to Kubernetes retry mechanisms incurs substantial development costs. This makes it difficult for enterprises to properly handle Kubernetes retry operations when integrating existing systems into Kubernetes, impacting the efficiency and stability of system integration.
[0005] Therefore, how to achieve reliable integration between Kubernetes and multiple legacy systems within an enterprise is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention
[0006] In view of the above-mentioned defects or deficiencies in the prior art, it is desirable to provide a method, apparatus and computer-readable storage medium for implementing a reentrant idempotent system interface for K8s integration, which can solve the compatibility problem when multiple systems interact and realize bidirectional integration of K8s with multiple historical systems within an enterprise.
[0007] In a first aspect, embodiments of this application provide a method for implementing a reentrant and idempotent system interface for Kubernetes integration, including:
[0008] Each interface to be called in each target system is encapsulated into an interface caller, and each of the interface callers is added to the interface caller list of the executor;
[0009] When the executor receives a retry request initiated by K8s, it iterates through the list of interface callers and triggers the interface callers in the list one by one in sequence.
[0010] After the interface caller is triggered, it reads the corresponding target system, queries the target status of the interface, and determines whether the interface has completed the target status based on the returned query result. If it has been completed, it returns to the executor to trigger the next interface caller in sequence. If it has not been completed, it executes the actual interface logic and modifies the target status of the target system.
[0011] In one embodiment, after the interface caller is triggered, the method further includes:
[0012] Check whether any errors occur in the step of executing the read target system and querying the target status of the interface;
[0013] If an error occurs, K8s will retry.
[0014] If no error is reported, proceed to the step of determining whether the interface has completed the target state based on the returned query results.
[0015] In one embodiment, after the execution of the actual interface logic, the method further includes:
[0016] Check for errors during the execution of the actual interface logic steps;
[0017] If an error occurs, K8s will retry.
[0018] If no error is reported, return to the executor to trigger the next interface caller in sequence.
[0019] In one embodiment, before the executor executes the interface callers in the interface caller list sequentially, the method further includes:
[0020] The executor checks whether the entire list of interface callers has been processed;
[0021] If so, return the completed result;
[0022] If not, perform the step of triggering the interface callers in the interface caller list one by one in sequence.
[0023] In one embodiment, before the executor executes the interface callers in the interface caller list sequentially, the method further includes:
[0024] The executor checks whether the currently triggered interface caller is marked as requiring intervention;
[0025] If so, trigger the corresponding intervention action based on the marked intervention type.
[0026] If not, perform the step of triggering the interface callers in the interface caller list one by one in sequence.
[0027] In one embodiment, triggering the corresponding intervention operation based on the marked intervention type includes:
[0028] If the marked intervention type is suspended, an error return is triggered, and the executor is returned to trigger the next interface caller in sequence.
[0029] In one embodiment, triggering the corresponding intervention operation based on the marked intervention type includes:
[0030] If the marked intervention type is skip, return to the executor to trigger the next interface caller in sequence from the current interface caller.
[0031] In one embodiment, triggering the corresponding intervention operation based on the marked intervention type includes:
[0032] If the intervention type marked is rollback, the executed interface call is rolled back, and the executor is returned to trigger the next interface caller in sequence.
[0033] Secondly, embodiments of this application provide a reentrant idempotent implementation device for a system interface for K8s integration, including: an interface caller and an executor;
[0034] The executor is used to maintain a list of interface callers. When it receives a retry request initiated by K8s, it is used to: traverse the list of interface callers and trigger the interface callers in the list one by one in order.
[0035] The interface caller encapsulates the interfaces to be called in the target system. After the interface caller is triggered, it is used to: read the corresponding target system, query the target status of the interface, and determine whether the interface has completed the target status based on the returned query result; if it has been completed, return to the executor to trigger the next interface caller in sequence; if it has not been completed, execute the actual interface logic and modify the target status of the target system.
[0036] Thirdly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements steps such as a reentrant idempotent implementation method for a system interface for Kubernetes integration.
[0037] The reentrant and idempotent implementation method for system interfaces in Kubernetes integration provided in this application first queries the target system state after the interface caller is triggered. If the target state of the interface has been achieved, the actual call logic is skipped, and the process directly proceeds to the next interface. This operation avoids the impact of repeated calls on the system state and ensures consistent results across multiple executions. Simultaneously, regardless of whether the interface itself is idempotent, unified idempotency control is achieved through the encapsulated interface caller. For non-idempotent interfaces, repeated calls are avoided through state checks, converting non-idempotent interfaces into idempotent behaviors. Furthermore, when the executor traverses the list of interface callers, it processes each interface sequentially. If an interface fails and triggers a Kubernetes retry, the list is re-traversed, starting the check from the first interface. Through state checks, completed interfaces are not executed repeatedly, while incomplete interfaces continue processing, ensuring reentrancy without errors. This method, through unified state checks and executor scheduling, ensures that different interfaces achieve idempotency and reentrancy during Kubernetes retries.
[0038] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description
[0039] Other features, objects and advantages of the present application will become more apparent upon reading the detailed description of non-limiting embodiments made with reference to the following drawings:
[0040] Figure 1 The illustration shows a flowchart of a reentrant idempotent implementation method for a system interface for Kubernetes integration provided in an embodiment of this application.
[0041] Figure 2 The illustration shows a schematic diagram of a system interface reentrant idempotent implementation process provided in an embodiment of this application. Detailed Implementation
[0042] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.
[0043] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present application will now be described in detail with reference to the accompanying drawings and embodiments. Although the embodiments of this application provide method operation instruction steps as shown in the following embodiments or drawings, more or fewer operation instruction steps may be included in the method based on conventional or non-inventive effort. In steps where there is no logically necessary causal relationship, the execution order of these steps is not limited to the execution order provided in the embodiments of this application. In actual processing or when the device executes, the method may be executed sequentially or in parallel according to the method shown in the embodiments or drawings.
[0044] Example 1:
[0045] This embodiment proposes a reentrant and idempotent implementation method for system interfaces in Kubernetes (K8s). Operations requiring K8s to call external interfaces (interfaces of enterprise legacy systems) are encapsulated within this framework. Please refer to [reference needed]. Figure 1 , Figure 1 This embodiment illustrates a flowchart of a reentrant idempotent implementation method for a system interface oriented towards Kubernetes integration. Figure 1 As shown, the method includes:
[0046] S101. Encapsulate the interfaces to be called in each target system into interface callers, and add each interface caller to the interface caller list of the executor;
[0047] For each target system interface that needs to be integrated with Kubernetes (such as the allocation interface of a resource management system, the registration interface of a service discovery system, etc.), it is abstracted into a component that implements the interface caller (Reentrant) interface. The interface caller is an abstraction and encapsulation of calling an external interface. Specifically, the interface caller encapsulates a single interface of the enterprise system, mainly including the following three methods:
[0048] 1. String: Used to return the name of the API caller, facilitating logging and problem localization.
[0049] 2. `IsFinished`: A pure read operation that does not affect any system state. It returns a boolean value (query result) and an error (indicating whether an error occurred). It indicates whether the desired result of calling this interface has been achieved. For example, calling an interface for forward and reverse registration will return success if registration has already been completed.
[0050] 3. Run: Indicates calling an interface to execute the actual interface logic, changing the actual state to the desired state. For example, when registering user information, the state is unregistered before the call, and becomes registered after the call.
[0051] The encapsulated API callers are added to the API caller list in sequence using methods such as Add() or AddByCondition() of the executor (ReentrantRunner). The executor is responsible for driving the API callers in the list. When a Kubernetes retry request is received, each API caller is triggered in sequence to ensure that the call process meets the requirements of idempotency and reentrancy.
[0052] S102. When the executor receives a retry request initiated by K8s, it iterates through the list of interface callers and triggers the interface callers in the list one by one in order.
[0053] Kubernetes employs a level-triggered mechanism. When the system's current state does not meet the expected state, it continuously initiates retry requests, driving the executor to reprocess the interface call flow. To address this, when the executor receives a retry request from Kubernetes, it starts from the first element of the interface caller list and sequentially visits each interface caller, ensuring that each interface is checked and processed. This ensures that all interfaces can be executed safely and idempotently during Kubernetes retries, avoiding duplicate operations or abnormal states.
[0054] The executor (ReentrantRunner) is used to manage a group of Reentrant interface callers and drive their execution. Its core function is to implement the reentrancy and idempotency of interface calls.
[0055] The actuator mainly includes the following four methods:
[0056] 1.Add(Reentrant)ReentrantRunner
[0057] Function: Adds a Reentrant interface caller (which encapsulates the external interface logic) to the executor.
[0058] Return value: Returns the executor itself, supporting chained calls (e.g., runner.Add(r1).Add(r2)).
[0059] Example: runner.Add(user-registered API caller) adds the API caller to the execution list.
[0060] 2. Run() error
[0061] Function: Triggers the executor to call all added interface callers in sequence. During execution, it can check the idempotency state and adapt to K8s retry.
[0062] Return value: Returns nil if all API calls are successful, otherwise returns an error (such as a failed API call or rate limiting).
[0063] 3. LastIndex() int
[0064] Function: Returns the index of the last successfully executed API caller, used to record execution progress (e.g., locating incomplete APIs during retries).
[0065] Example: If execution fails at the 3rd interface, LastIndex() returns 2 (index starts from 0).
[0066] 4. AddByCondition(bbool,rReentrant)ReentrantRunner
[0067] Function: Determines whether to add the interface caller r based on condition b: if b is true, then call Add(r); otherwise, do not add it.
[0068] Example: runner.AddByCondition(environment is test, test API caller) adds the API only if the environment is test.
[0069] Furthermore, after the executor traverses the list of interface callers and before triggering each interface caller in the list sequentially, a preliminary check can be performed: to determine whether the entire list of interface callers has been processed.
[0070] The executor verifies whether each interface caller in the interface caller list has completed its status query and actual call (if necessary). If all interface callers have completed processing (i.e., the target state of each interface has been achieved), the executor directly returns the completed result and does not perform any further triggering operations. If there are any interface callers that have not completed processing (i.e., at least one interface's target state has not been achieved), the executor triggers the interface callers in the list sequentially to continue the process. This mechanism ensures that the executor triggers interface callers only when necessary, avoiding invalid operations, while ensuring that the target state of all interfaces is confirmed one by one, ultimately achieving the integrity and reliability of the process. Of course, this pre-check can be omitted, and this embodiment does not limit this.
[0071] S103. After the interface caller is triggered, the corresponding target system is read, the target status of the interface is queried, and the target status of the interface is determined based on the returned query result. If it has been completed, the executor is returned to trigger the next interface caller in sequence. If it has not been completed, the actual interface logic is executed and the target status of the target system is modified.
[0072] Once the API caller is triggered, it can use the IsFinished() method to read the current state of the target system without side effects and determine whether the API has achieved the target state (such as whether the user has registered).
[0073] If the target state has been completed (IsFinished() returns true), the actual interface logic is not executed, and control is directly returned to the executor, which then triggers the next interface caller in the list in sequence.
[0074] If the target state is not completed (IsFinished() returns false), the Run() method of the interface caller is called to execute the actual interface logic (such as registering a user), modify the state of the target system, and then the executor triggers the next interface caller.
[0075] The target state of the interface refers to the final state that the call to the interface expects to achieve. Specifically, it depends on whether the current system state meets the target state of the interface, as determined by the interface's business logic. Two specific scenarios are illustrated below:
[0076] Example 1: User Registration Interface
[0077] Interface target status: User has registered.
[0078] Query logic: The IsFinished() method queries the user database to determine if the current user ID exists and if its status is registered.
[0079] If it exists and its status is correct, return true (no need to register again);
[0080] If it does not exist or its status is unregistered, return false (you need to execute Run() to register).
[0081] Example 2: Resource Allocation Interface
[0082] Interface target status: Resources have been allocated to the specified container.
[0083] Query logic: The IsFinished() method queries the resource management system to determine whether the target container has acquired the specified resources (such as CPU and memory quotas).
[0084] If the allocation has already been made, return true (skip the allocation operation);
[0085] If not allocated, return false (Run() needs to be executed to allocate).
[0086] This step achieves idempotency through state pre-checking, avoids repeated calls to completed interfaces, ensures consistent results across multiple triggers, and adapts to Kubernetes' level trigger retry mechanism.
[0087] Based on the above description, the reentrant and idempotent implementation method for system interfaces for Kubernetes integration provided in this embodiment first queries the target system state after the interface caller is triggered. If the target state of the interface has been achieved, the actual call logic is skipped, and the process directly proceeds to the next interface. This operation avoids the impact of repeated calls on the system state and ensures consistent results across multiple executions. Simultaneously, regardless of whether the interface itself is idempotent, unified idempotency control is achieved through the encapsulated interface caller. For non-idempotent interfaces, repeated calls are avoided through state checks, converting non-idempotent interfaces into idempotent behaviors. Furthermore, when the executor traverses the interface caller list, it processes each interface sequentially. If an interface fails and triggers a Kubernetes retry, the list is re-traversed, starting the check from the first interface. Through state checks, completed interfaces are not executed repeatedly, while incomplete interfaces continue processing, ensuring reentrancy without errors. This method, through unified state checks and executor scheduling, ensures that different interfaces achieve idempotency and reentrancy during Kubernetes retries.
[0088] Example 2:
[0089] To improve the reliability of API calls, this embodiment introduces two exception handling mechanisms to avoid processing interruptions caused by temporary errors.
[0090] One error handling method is as follows:
[0091] During the process of the API caller reading the corresponding target system and querying the target status of the API, it continuously checks for errors. If an exception occurs (such as network connection failure, system service unavailability, etc.), it can be determined as an error.
[0092] If an error occurs during the query process, it means that the current interface status cannot be obtained normally. At this time, the K8s retry mechanism is triggered, and K8s re-initiates the call process to ensure that the interface status can be correctly checked.
[0093] If no errors are reported during the query process, the subsequent logic continues to be executed. The returned query results are used to determine whether the interface has completed the target state, and then it is decided whether to execute the actual interface logic.
[0094] This error handling method captures exceptions during the status query phase in real time, ensuring that the process can be restored with the help of Kubernetes retry capabilities when the system encounters an error, while also avoiding processing interruptions caused by temporary errors.
[0095] Another error handling method is as follows:
[0096] While the API caller executes the actual API logic, it checks for any exceptions that may occur during the execution of the API logic (such as API call failure, internal system errors, etc.). For example, when calling the user registration API, execution may fail due to network interruption or incorrect parameters.
[0097] If an error occurs during execution, it means that the current interface operation has not been completed successfully. At this time, the Kubernetes retry mechanism is triggered. Kubernetes will re-initiate the call process to ensure that the interface can be executed again to cope with temporary failures (such as network fluctuations).
[0098] If no error is reported during execution, it means that the interface logic has successfully modified the system state (such as successful user registration). At this time, control is returned to the executor, which triggers the next interface in the interface caller list in sequence to continue processing subsequent logic.
[0099] This error handling method captures exceptions during the interface execution phase in real time, leverages Kubernetes' retry capabilities to ensure the eventual consistency of interface operations, and ensures that the process proceeds in sequence when successful, thereby improving the reliability and robustness of system integration.
[0100] Based on the above introduction, the two error handling methods provided in this embodiment comprehensively cover the entire process of interface calls through layered error handling, which can reduce the failure rate caused by system anomalies. Both methods implement error handling through framework layer encapsulation, without the need to modify the target system interface, reducing integration costs and making them suitable for error handling of various heterogeneous system interfaces.
[0101] Example 3:
[0102] Based on the above embodiments, in order to flexibly intervene in the interface call process to cope with different business needs or abnormal situations, this embodiment proposes an intervention mechanism.
[0103] Specifically, before the executor triggers the interface caller in sequence, it checks whether the interface caller is marked as needing intervention. If it is marked as needing intervention, the executor performs the corresponding operation according to the intervention type and does not perform subsequent status queries and actual calls. If it is not marked as needing intervention, the interface caller is triggered according to the normal process.
[0104] In complex business scenarios, intervention strategies can be used to temporarily skip an interface (e.g., WithSkip) or suspend the interface call and return an error (e.g., WithSuspend), adapting to business changes without modifying code logic. When an interface experiences a temporary failure, intervention strategies can be used to temporarily suspend that interface, preventing the entire process from being blocked due to a single interface problem. It should be noted that this embodiment does not limit the type of intervention and can be set according to the actual application scenario.
[0105] Furthermore, the intervention strategy can be uniformly managed through the executor without modifying the specific implementation of the interface caller.
[0106] The intervention mechanism provided in this embodiment can quickly adjust the process through intervention strategies at the executor layer without modifying the interface implementation, thereby improving the system's scalability and fault tolerance.
[0107] Furthermore, this embodiment proposes three types of intervention and their corresponding intervention operations.
[0108] 1. When the executor detects that the interface caller is marked as a suspended intervention, the following logic is executed:
[0109] Trigger error return: Immediately terminate the processing flow of the current interface caller, return an error signal to the caller, indicating that the interface call has been suspended.
[0110] Proceed with subsequent interface processing: After an error is returned, the executor will not interrupt the entire process, but will instead trigger the next interface in the interface caller list in sequence to ensure that subsequent interfaces continue to be processed.
[0111] This mechanism enables flexible control over specific interfaces, clearly indicating the suspended state through error returns while ensuring that other interfaces are unaffected, maintaining the continuity of the process. For example, when an interface requires temporary maintenance, suspension intervention can temporarily skip that interface without blocking the entire call chain.
[0112] 2. When the executor detects that an interface caller is marked as a skipped intervention, it will directly skip all processing steps of that interface (including status query and actual call) and immediately return control to the executor, which will then trigger the next interface caller in the list in sequence.
[0113] The core of this mechanism is to dynamically skip API calls through intervention flags. It's suitable for scenarios where a particular API needs to be temporarily ignored (such as API maintenance or quick skipping when conditions are not met). Unlike suspension, skipping doesn't return an error; instead, it silently skips the current API call and continues the subsequent process, ensuring the continuity of the overall call chain. For example, in conditional API calls, by combining AddByCondition with skip intervention, you can directly skip the API call when the condition is not met and continue executing the next logic.
[0114] 3. When the executor detects that the interface caller has been marked as a rollback type intervention, perform the following operations:
[0115] Rollback of executed interface operations: Undoes operations previously performed by the current interface caller (e.g., undoes completed state changes), restoring the system to its state before the call.
[0116] Proceed with subsequent interface processing: After the rollback is complete, control is returned to the executor, which triggers the next interface in the interface caller list in sequence to ensure that the subsequent process continues to execute.
[0117] This mechanism is primarily used in scenarios involving exceptions or requiring undoing (such as when a transaction fails). It ensures system consistency through rollback intervention without blocking the overall call chain. For example, in a multi-interface transaction, if an interface needs to be undone after execution, a rollback can be triggered using the WithRollback flag, allowing subsequent interfaces to continue processing.
[0118] Example 4:
[0119] The above embodiments described the main implementation process and its branching methods. This embodiment describes an overall backend implementation process. Figure 2 The diagram illustrates the process of implementing a reentrant and idempotent system interface. This process specifically includes the following steps:
[0120] Step 1: Initialization and Preparation (Background Startup Process)
[0121] The backend creates an instance of the InterventionalReentrantRunner executor (e.g., runner) and encapsulates the enterprise system interfaces that need to be called into a Reentrant interface caller (implementing the String(), IsFinished(), and Run() methods), and adds them to the executor's interface caller list using Add() or AddByCondition().
[0122] Step 2: Start the execution process (traverse the list of API callers)
[0123] The background calls the executor's Run() method, triggering a traversal of the list of API callers and starting to process each API caller one by one.
[0124] Step 3: Check if the process is complete.
[0125] The backend checks whether the list of API callers has been fully processed (e.g., whether the index has been traversed to the end of the list).
[0126] Yes (End): The executor terminates the process and returns the result;
[0127] No (Not finished): Continue processing the current API caller.
[0128] Step 4: Check if intervention is needed
[0129] The backend checks whether the current API caller is marked as requiring intervention (e.g., intervention strategies registered via WithSuspend() / WithSkip()).
[0130] Yes (intervention required): Execute the trigger intervention action (such as suspending the interface and directly reporting an error, or skipping the interface without execution), and then return to the list of interface callers to process the next interface;
[0131] No (no intervention required): Continue executing the logic of the current API caller.
[0132] Step 5: Pre-check the status (call IsFinished())
[0133] The background calls the IsFinished() method of the current API caller (a pure read operation to query the target status of the API).
[0134] Error (Yes): The executor reports an error directly, the process terminates, and K8s retry is triggered;
[0135] No error reported (No): Based on the returned boolean value, determine whether the target status of the interface has been completed.
[0136] Step 6: Determine if the task is complete.
[0137] The backend determines whether the target state of the interface has been achieved based on the return value (bool) of IsFinished().
[0138] Completed (Yes): Skip the Run() method and go directly back to traversing the list of interface callers to process the next interface (to achieve idempotency and avoid repeated execution);
[0139] Incomplete (No): The Run() method is executed, calling the actual interface logic.
[0140] Step 7: Execute the interface logic (call Run())
[0141] The background calls the Run() method of the current API caller (write operations, modifying system state, such as registering users or allocating resources).
[0142] Error (Yes): The executor reports an error, the process terminates, and a K8s retry is triggered;
[0143] No error reported (No): Return to the list of interface callers and process the next interface.
[0144] Step 8: K8s retry loop closure
[0145] If the process terminates due to an error (such as an error in IsFinished() or Run()), Kubernetes triggers a level-triggered retry. The background then restarts from step 2 (traversing the list of API callers) and repeats the above process until all APIs are executed successfully or the retry limit is reached.
[0146] This embodiment achieves the following key capabilities in the background through a closed-loop process: pre-checking state (IsFinished()) → on-demand execution (Run()) → adapting for retry: Idempotency: Skipping completed interfaces via IsFinished() avoids redundant operations; Reentrancy: Supporting multiple retries in Kubernetes, automatically skipping completed interfaces in each retry; Dynamic intervention: Adjusting interface execution strategies in real time via WithSuspend() / WithSkip(); Non-intrusive integration: Achieving compatibility through framework encapsulation without modifying enterprise system interfaces.
[0147] Example 5
[0148] The above embodiments introduced the implementation process of general idempotency and reentrancy. To deepen understanding, this embodiment uses an execution flow containing 5 interfaces as an example to illustrate the implementation process of reentrancy and idempotency of system interfaces. The success condition is that all interfaces execute successfully; otherwise, Kubernetes will trigger a retry mechanism. Specifically:
[0149] Interface semantic definition:
[0150] Interface 1: Implements the transition from state a to state b;
[0151] Interface 2: Implements the transition from state c to state d.
[0152] Initial state: The system state is (a, c, e).
[0153] First execution:
[0154] Interface 1 executed successfully, and state a transitioned to state b;
[0155] Interface 2 failed to execute, but state c remains unchanged;
[0156] Because some interfaces failed to execute, the system returned a failure result to Kubernetes, triggering a retry.
[0157] Second execution:
[0158] Idempotency handling for Interface 1:
[0159] If interface 1 is an idempotent interface, it can be called again directly, since the state will still be b after the call with the same parameters;
[0160] If interface 1 is a non-idempotent interface, the encapsulated interface caller first checks the state: if it is already b, then skip the actual call to avoid state abnormalities (such as conversion to an unexpected state g).
[0161] Interface 2 execution: The state c successfully transitions to d. Subsequent interfaces are executed in sequence until all are successful. The system reaches the expected state, and K8s terminates the retry.
[0162] Example 6:
[0163] This embodiment provides a reentrant and idempotent implementation device for system interfaces for Kubernetes integration, which mainly includes an interface caller and an executor. This reentrant and idempotent implementation device for system interfaces for Kubernetes integration adopts a modular design and realizes bidirectional integration between Kubernetes and multiple historical systems within the enterprise through two core units.
[0164] The executor is used to maintain the list of interface callers. When it receives a retry request initiated by K8s, it is used to: traverse the list of interface callers and trigger the interface callers in the list one by one in order.
[0165] The interface caller encapsulates the interfaces to be called in the target system. It abstracts and encapsulates the interfaces to be called in the target system. After the interface caller is triggered, it is specifically used to: read the corresponding target system, query the target status of the interface, and determine whether the interface has completed the target status based on the returned query result; if it has been completed, it returns to the executor to trigger the next interface caller in sequence; if it has not been completed, it executes the actual interface logic and modifies the target status of the target system.
[0166] It should be noted that the reentrant idempotent implementation device for Kubernetes integrated system interface provided in this embodiment and the reentrant idempotent implementation method for Kubernetes integrated system interface provided in the above embodiment can refer to each other, and the repeated parts will not be described again in this embodiment.
[0167] This embodiment provides a reentrant and idempotent implementation device for system interfaces in Kubernetes integration. Through the collaborative design of the interface caller and the executor, it achieves general support for interface idempotency and reentrancy in Kubernetes integration scenarios. The interface caller encapsulates the target system interface into a component with String(), IsFinished(), and Run() methods. By pre-checking the state, it avoids repeated calls, enabling non-idempotent interfaces to achieve idempotency. The executor maintains a list of interfaces and adapts to the Kubernetes level triggering mechanism. Upon receiving a retry request, it triggers the interfaces sequentially, first checking the state and then deciding whether to execute the actual logic, ensuring consistent results across multiple calls. This design does not require modification of existing system interfaces, reduces integration costs through client-side layered decoupling, and supports dynamic adjustment of processes through intervention strategies, improving system compatibility, reliability, and maintainability.
[0168] It should be noted that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operational instructions of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two connected blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operational instructions, or using a combination of dedicated hardware and computer instructions.
[0169] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be located in a processor. The names of these units or modules do not, in certain circumstances, constitute a limitation on the unit or module itself.
[0170] In another aspect, this application also provides a computer-readable storage medium, which may be included in the server described in the above embodiments, or may exist independently and not assembled into the server. The aforementioned computer-readable storage medium stores one or more programs that, when used by one or more processors, execute the data balancing method described in this application.
[0171] The computer-readable medium described in this application may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.
[0172] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.
Claims
1. A method for implementing a reentrant and idempotent system interface for Kubernetes integration, characterized in that, include: Each interface to be called in each target system is encapsulated into an interface caller, and each of the interface callers is added to the interface caller list of the executor; When the executor receives a retry request initiated by K8s, it iterates through the list of interface callers and triggers the interface callers in the list one by one in sequence. After the interface caller is triggered, it reads the corresponding target system, queries the interface target status, and determines whether the interface has completed the target status based on the returned query result; if it has been completed, it returns to the executor to trigger the next interface caller in sequence. If not completed, execute the actual interface logic to modify the target state of the target system.
2. The method as described in claim 1, characterized in that, After the interface caller is triggered, the following is also included: Check whether any errors occur in the step of executing the read target system and querying the target status of the interface; If an error occurs, K8s will retry. If no error is reported, proceed to the step of determining whether the interface has completed the target state based on the returned query results.
3. The method as described in claim 1, characterized in that, After executing the actual interface logic, the following is also included: Check for errors during the execution of the actual interface logic steps; If an error occurs, K8s will retry. If no error is reported, return to the executor to trigger the next interface caller in sequence.
4. The method as described in claim 1, characterized in that, Before the executor executes the sequential triggering of the interface callers in the interface caller list, the method further includes: The executor checks whether the entire list of interface callers has been processed; If so, return the completed result; If not, perform the step of triggering the interface callers in the interface caller list one by one in sequence.
5. The method according to any one of claims 1 to 4, characterized in that, Before the executor executes the sequential triggering of the interface callers in the interface caller list, the method further includes: The executor checks whether the currently triggered interface caller is marked as requiring intervention; If so, trigger the corresponding intervention action based on the marked intervention type; If not, perform the step of triggering the interface callers in the interface caller list one by one in sequence.
6. The method as described in claim 5, characterized in that, The step of triggering the corresponding intervention operation based on the marked intervention type includes: If the marked intervention type is suspended, an error return is triggered, and the executor is returned to trigger the next interface caller in sequence.
7. The method as described in claim 5, characterized in that, The step of triggering the corresponding intervention operation based on the marked intervention type includes: If the marked intervention type is skip, return to the executor to trigger the next interface caller in sequence from the current interface caller.
8. The method as described in claim 5, characterized in that, The step of triggering the corresponding intervention operation based on the marked intervention type includes: If the intervention type marked is rollback, the executed interface call is rolled back, and the executor is returned to trigger the next interface caller in sequence.
9. A reentrant idempotent implementation device for a system interface for Kubernetes integration, characterized in that, include: Interface caller and executor; The executor is used to maintain a list of interface callers. When it receives a retry request initiated by K8s, it is used to: traverse the list of interface callers and trigger the interface callers in the list one by one in order. The interface caller encapsulates the interface to be called in the target system. After the interface caller is triggered, it is used to: read the corresponding target system, query the target status of the interface, and determine whether the interface has completed the target status based on the returned query result; if it has been completed, it returns to the executor to trigger the next interface caller in sequence. If not completed, execute the actual interface logic to modify the target state of the target system.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the method as described in any one of claims 1 to 8.