Service instance offline method and device, storage medium and computer device

Abstract

The application provides a service instance offline method and device, a storage medium and a computer device, which are applied to a service end, and the method comprises the following steps: when a container group shutdown signal of a container platform is received, the running state of a service instance corresponding to the container group shutdown signal is changed, and a new request of the service instance is rejected; semantic analysis is performed on each to-be-processed request which has been received, and according to the semantic analysis result, the execution path of each to-be-processed request is determined; when each to-be-processed request is executed according to the corresponding execution path and is completed, the container platform is notified to complete the offline. Therefore, through semantic analysis and execution path tracking, the service instance can judge the exit condition based on the actual execution progress of each request, so as to realize fine control of the exit opportunity, ensure that all received requests are completely processed, avoid interruption of requests or loss of data caused by early exit, prevent unlimited waiting, and significantly improve the integrity and continuity of request processing.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, storage medium, and computer equipment for taking a service instance offline. Background Technology

[0002] With the development of cloud-native technologies, microservice architecture has been widely applied in fields such as the internet, finance, and telecommunications. To improve system scalability and operational efficiency, business services are typically deployed in a containerized manner, and automatic scheduling, elastic scaling, and version iteration release of service instances are achieved through container orchestration platforms such as Kubernetes.

[0003] In existing technologies, Kubernetes typically uses a rolling update approach to upgrade service versions, meaning that while new version instances are gradually deployed, older version instances are gradually decommissioned. After receiving a termination signal from the container platform, service instances usually complete their decommissioning based on a fixed grace period or a preset waiting time.

[0004] However, existing shutdown mechanisms lack the ability to detect the execution status of business requests. If a service instance is forcibly terminated after the grace period ends while there are still business requests being executed, it may lead to interrupted request execution and the inability of the business process to complete normally. Especially in scenarios involving long transaction processing or complex call chains, request execution times vary significantly, making it difficult for fixed waiting strategies to accurately match actual request processing needs.

[0005] Therefore, existing technologies cannot reasonably control the timing of service instance exit based on the actual execution of business requests, which can easily affect the integrity and continuity of request processing. Summary of the Invention

[0006] The purpose of this application is to at least address one of the aforementioned technical deficiencies, particularly the technical deficiency in the prior art where it is difficult to reasonably control the timing of service instance exit based on the actual execution of business requests, which can easily affect the integrity and continuity of request processing.

[0007] Firstly, this application provides a method for taking a service instance offline, applied to the server side, the method including:

[0008] When a container group shutdown signal is received from the container platform, the running status of the service instance corresponding to the container group shutdown signal is changed, and new requests to the service instance are rejected.

[0009] Semantic parsing is performed on each received request to be processed, and the execution path of each request to be processed is determined based on the semantic parsing results;

[0010] Once all pending requests have been executed according to their respective execution paths, notify the container platform to complete the decommissioning process.

[0011] In one embodiment, changing the running state of the service instance corresponding to the container group shutdown signal includes:

[0012] Call the registry center to mark the service instance corresponding to the container group shutdown signal as offline and modify the health check endpoint to unavailable.

[0013] In one embodiment, rejecting new requests to a service instance includes:

[0014] Set the global ingress switch to the status of "shutting down" and return a specific exception code when a new request arrives for the service instance.

[0015] In one embodiment, semantic parsing of each received pending request includes:

[0016] Intercept the business method corresponding to each received pending request, read the preset annotation markers on each business method, and obtain the semantic parsing results.

[0017] In one embodiment, the execution path for each pending request is determined based on the semantic parsing results, including:

[0018] If the semantic parsing result indicates an interruptible request, then the execution path is determined to be not to continue executing the current request;

[0019] If the semantic resolution result is an uninterruptible request, then the execution path is determined to continue executing the current request until it is completed.

[0020] In one embodiment, when all pending requests have been completed according to their corresponding execution paths, the container platform is notified to complete the decommissioning process, including:

[0021] For each pending request that can be interrupted, immediately interrupt it and return a specific exception code;

[0022] For each uninterruptible pending request, the active request counter is incremented when the pending request begins execution and decremented when the pending request completes execution.

[0023] When the active request counter reaches zero, it is determined that all pending requests have been completed, and an exit permission signal is sent to the container platform.

[0024] In one embodiment, a specific exception code is used by the caller to refresh the list of service instances and retry the request to a new service instance.

[0025] Secondly, this application provides a service instance offline device, applied to the server side, the device comprising:

[0026] The service instance shutdown module is used to change the running status of the service instance corresponding to the container group shutdown signal when a container group shutdown signal is received from the container platform, and to reject new requests to the service instance.

[0027] The execution path determination module is used to perform semantic parsing on each received request to be processed, and determine the execution path of each request to be processed based on the semantic parsing results.

[0028] The container platform decommissioning module is used to notify the container platform to complete the decommissioning process when all pending requests have been executed according to their corresponding execution paths.

[0029] Thirdly, this application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of any of the service instance offline methods described in the above embodiments.

[0030] Fourthly, this application provides a computer device, including: one or more processors, and a memory;

[0031] The memory stores computer-readable instructions that, when executed by one or more processors, perform the steps of any of the service instance offline methods described in the above embodiments.

[0032] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0033] The service instance shutdown method, apparatus, storage medium, and computer equipment provided in this application, upon receiving a container group shutdown signal from a container platform, first change the running state of the corresponding service instance and reject new requests, thereby avoiding receiving additional load during the shutdown process. Subsequently, semantic parsing is performed on each received pending request, and the execution path of each request is determined based on the parsing results, enabling the service instance to accurately grasp the scope of business logic required for each request. Finally, the container platform is notified to complete the shutdown only after all pending requests have been executed according to their respective execution paths. Thus, through semantic parsing and execution path tracing, the service instance can determine the exit conditions based on the actual execution progress of each request, rather than a fixed timeout or simple counting, thereby achieving fine-grained control over the exit timing. This ensures that all received requests are fully processed, avoiding request interruption or data loss due to premature exit, preventing unlimited waiting, significantly improving the integrity and continuity of request processing, and enhancing the reliability and automation level of service shutdown. Attached Figure Description

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

[0035] Figure 1 A flowchart illustrating the service instance offline method provided in this application embodiment;

[0036] Figure 2 A schematic diagram of the structure of the service instance offline device provided in the embodiments of this application;

[0037] Figure 3 This is a schematic diagram of the internal structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0038] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0039] like Figure 1 As shown, this application provides a method for taking a service instance offline, applied to the server side, the method including:

[0040] S101: When a container group shutdown signal is received from the container platform, the running status of the service instance corresponding to the container group shutdown signal is changed, and new requests to the service instance are rejected.

[0041] A container platform is a system used to orchestrate and manage the runtime environment of multiple container groups. A container group shutdown signal is a notification message issued by the platform when it decides to terminate a container group. A service instance is a program unit that runs inside a container group and provides the ability to process business requests to the outside world. The running status is used to indicate whether the service instance can currently receive new requests and execute corresponding business. A new request refers to a call instruction initiated from an external client to the service instance that has not yet been received or processed by the service instance.

[0042] In practice, the system continuously monitors various event messages emitted by the container platform. When the container platform prepares to shut down a container group, it sends a container group shutdown signal to the service instances within that group. Upon receiving this signal, the service instances immediately change their current running state from normal service to a waiting state before shutdown, for example, by setting an internal flag from "running" to "stop accepting new requests." Simultaneously, the service instances begin rejecting all subsequent new requests, which can be done by returning a specific status code or error message to the caller, informing them that the current service instance is no longer accepting new tasks and that the caller should instead request from other healthy instances.

[0043] In real-world deployments, service instances are typically registered with service discovery components. When their running state changes to rejecting new requests, service instances can proactively deregister themselves with the service discovery component or mark themselves as unavailable, preventing upstream callers from routing new requests to that instance. The specific implementation of rejecting new requests is not limited to directly refusing connections at the network layer; it can also involve checking a global close flag at the application layer. When this flag is valid, all newly arriving request handling methods will directly return a rejection response, preventing them from entering the business processing flow. This ensures that after the shutdown signal arrives, the service instance will not receive any new business load, thus reserving processing capacity entirely for requests that have already been received but not yet completed.

[0044] It's important to note that after a container platform issues a shutdown signal, service instances face an exit process. If the running state isn't changed and new requests aren't rejected, new requests will continue to flood in, causing some already received requests to lack sufficient resources for processing. Simultaneously, new requests may be interrupted halfway through processing before the instance exits. By immediately changing the running state and rejecting new requests upon receiving the signal, the exit process's boundaries can be effectively defined. New load is prevented from entering first, while existing requests are processed safely. This avoids service instances continuing to take on new tasks during the shutdown process, prevents incomplete request processing and business data loss, ensures that resources for existing requests are not preempted by new requests, and lays the foundation for smoothly processing all received requests subsequently, thereby improving the certainty of service shutdown and the continuity of request processing.

[0045] S102: Perform semantic parsing on each received pending request, and determine the execution path for each pending request based on the semantic parsing results.

[0046] Among them, pending requests refer to call instructions that the service instance has received but has not yet completed the execution of business logic. Semantic parsing is the process of analyzing the syntax and business meaning of the content of pending requests. The result of semantic parsing is the key information extracted from the request content, including operation type, operation object and business parameters. Execution path refers to the code call sequence, resource access order and other dependent services or storage systems required to complete the request.

[0047] In practice, after rejecting a new request, the service instance iterates through a queue of received requests maintained in memory. For each pending request in the queue, the service instance first extracts the raw data of the request, such as the Uniform Resource Locator path, request method, header fields, and message body in a Hypertext Transfer Protocol (HTTP) request, or the service name, method name, and parameter list in a Remote Procedure Call (RPC) request. Next, the service instance parses this data to identify the specific business operation the request intends to perform, such as creating an order, querying user information, or updating inventory quantities. This parsing process can be accomplished using predefined semantic rules, such as using regular expressions to match path patterns, or leveraging a lightweight parser to break down the request content.

[0048] After semantic parsing is completed, the service instance determines the execution path of the request based on the parsing results. Taking an order creation request in an e-commerce system as an example, semantic parsing reveals that the operation type is "create order," and the operation objects are product number and quantity. Therefore, the corresponding execution path includes calling the inventory service to deduct inventory, writing to the order database, and sending a message to the message queue to notify the logistics system. The service instance can maintain a mapping table internally, mapping different operation types and operation object combinations to predefined execution path templates, thereby quickly determining which functions to call, which data tables to access, and which external responses to wait for for each request. For requests with special markers in the semantic parsing results, such as transaction requests requiring collaboration across multiple microservices, the execution path also includes rollback steps and compensation operations.

[0049] It's important to note that the actual execution processes of different business requests vary significantly. Some requests can be completed simply by reading from the local cache, while others require multiple interactions across multiple network nodes. Without semantic parsing of requests and determination of execution paths, service instances cannot know the specific steps involved in each request, and therefore cannot determine when execution is truly complete. By obtaining the execution path through semantic parsing, service instances can transform the ambiguous "processing request" into a clear sequence of steps, providing a basis for subsequently verifying the completion of each step. This allows for differentiation of the execution complexity and dependencies of different requests, avoiding the confusion between simple and complex requests that could lead to misjudgments of exit timing. Furthermore, it provides personalized completion criteria for each request, enabling service instances to focus only on the truly necessary steps while waiting to exit, improving the accuracy of the shutdown process and resource utilization efficiency.

[0050] S103: When all pending requests have been completed according to their corresponding execution paths, notify the container platform to complete the decommissioning process.

[0051] In practice, the service instance continuously monitors the execution status of all pending requests. After obtaining the execution path for each pending request through semantic parsing, the service instance creates an independent completion counter or status tracking object for that request. This object records whether each atomic operation on the execution path has returned successfully. When an atomic operation is completed, the corresponding status bit is marked as completed. The service instance internally maintains a global set of pending requests, which contains the identifiers of all requests that have not yet been completed, and periodically scans the completion status of the execution path corresponding to each request in this set.

[0052] When all nodes in a request's execution path are marked as completed, the service instance removes the request from the global set of pending requests. The service instance continues to wait until the global set of pending requests becomes empty. While the set is not empty, the service instance repeatedly checks, either by polling at short intervals or by using an event-driven mechanism to automatically check if the set is empty whenever a request completes its last operation step.

[0053] When the global set of pending requests is detected to be empty, meaning all pending requests have been completed according to their respective execution paths, the service instance sends a shutdown completion notification message to the container platform. This message can be a Hypertext Transfer Protocol (HTTP) interface call, or a call to a command-line tool or application programming interface (API) method provided by the container platform. Upon receiving this notification, the container platform can safely terminate the container group and reclaim the computing and storage resources it occupies. In actual deployments, to prevent notification failures due to network jitter, the service instance can adopt a message sending method with a retry mechanism. That is, if no acknowledgment response is received from the container platform, the notification is repeatedly sent at increasing intervals until a successful response is obtained. Additionally, the service instance can open a short-term daemon window after sending the notification, during which the process does not exit, so that the notification can be resent if the container platform experiences a temporary failure.

[0054] It's important to note that service instances cannot decide when to terminate themselves; they must wait for the container platform to perform the final shutdown operation. The container platform, in turn, is unaware of the actual progress of request processing within the service instance. Notifying the service instance of shutdown before all pending requests are completed, or forcibly terminating it due to timeout without any notification, will result in incomplete request processing. By proactively notifying the container platform of the shutdown completion after all pending requests have been executed according to their execution paths, the service instance synchronizes its internal request processing progress with the external container platform, ensuring consistency in their states. This avoids premature termination of the container group by the container platform, preventing the interruption of incomplete requests, and also avoids the waste caused by service instances occupying resources for extended periods. It achieves precise alignment of shutdown timing, ensuring the integrity and continuity of request processing while improving the determinism and automation of container platform resource scheduling.

[0055] In the above embodiments, when a container group shutdown signal is received from the container platform, the running state of the corresponding service instance is first changed and new requests are rejected, thereby avoiding receiving additional load during the exit process. Subsequently, semantic parsing is performed on each received pending request, and the execution path of each request is determined based on the parsing results, enabling the service instance to accurately grasp the scope of business logic required for each request. Finally, the container platform is notified to complete the shutdown only when all pending requests have been executed according to their respective execution paths. Thus, through semantic parsing and execution path tracing, the service instance can determine the exit conditions based on the actual execution progress of each request rather than a fixed timeout or simple count, thereby achieving fine-grained control over the exit timing, ensuring that all received requests are fully processed, avoiding request interruption or data loss due to premature exit, preventing unlimited waiting, significantly improving the integrity and continuity of request processing, and enhancing the reliability and automation level of service shutdown.

[0056] In one embodiment, changing the running state of the service instance corresponding to the container group shutdown signal includes:

[0057] Call the registry center to mark the service instance corresponding to the container group shutdown signal as offline and modify the health check endpoint to unavailable.

[0058] The registry is a centralized component used to maintain the network addresses and operational status of service instances, allowing other services or clients to find available instances by service name; marking a service instance as offline means setting its status to undiscoverable or unroutable in the registry; a health check endpoint is a network address that the registry or load balancer periodically accesses to detect whether a service instance is healthy and alive; unavailable means that the health check endpoint returns a failure status when accessed, thus causing the registry or load balancer to determine that the service instance is no longer providing services.

[0059] In practice, upon receiving a container group shutdown signal from the container platform, a service instance immediately establishes a network connection with the registry. The registry typically provides a set of application programming interfaces (APIs), such as service registration and discovery interfaces based on the Hypertext Transfer Protocol (HTTP). The service instance calls the registry's offline interface, passing its unique identifier as a parameter. Upon receiving this request, the registry changes the service instance's status in the service registry from available to offline. Afterward, when other services or clients query the registry for the list of instances corresponding to that service name, that instance will no longer appear in the returned results.

[0060] Meanwhile, the service instance modifies its own health check endpoint. In a typical microservice architecture, each service instance exposes a dedicated health check Uniform Resource Locator (URL) path, such as " / health" or " / ready". The registry or load balancer initiates probe requests to this path at configured time intervals. Upon receiving a shutdown signal, the service instance changes the processing logic of the health check endpoint from returning a success status code to returning a failure status code, for example, changing the HIPOL response code from 200 to 503. The service instance can set an internal flag; when this flag is valid, the health check endpoint's processing function directly returns an unavailable response, without executing any health probe logic.

[0061] In specific deployment scenarios, service instances may be registered with multiple registry centers simultaneously, such as using both service discovery components and the service discovery functionality of a distributed configuration center. In this case, the service instance needs to traverse all known registry center addresses and call the offline interface for each registry center. Similarly, if a service instance exposes multiple health check endpoints, such as a health endpoint for liveness detection and a ready endpoint for readiness detection, the service instance needs to modify all of these endpoints to return an unavailable status. After completing the above operations, the registry center and load balancer will find that the health check endpoints are unavailable in the next detection cycle, thereby completely removing the service instance from the traffic scheduling list.

[0062] It's important to note that simply rejecting new requests locally on the service instance doesn't prevent upstream callers from continuing to send traffic, as they typically rely on a registry center to obtain a list of available instances. If the registry center isn't actively called to mark an instance as offline, the upstream caller's local cache will still retain the instance's address, causing new requests to continue being routed to that instance and rejected locally, resulting in an erroneous response. Simultaneously, setting the health check endpoint to unavailable allows the load balancer or registry center's health check mechanism to automatically detect that the instance is no longer providing service, triggering removal logic and providing dual protection. Therefore, blocking new requests at the service discovery source prevents callers from sending requests to soon-to-be-offline instances due to outdated caches, reducing invalid calls and error returns. Furthermore, the health check mechanism enables automated state synchronization, improving the smoothness of service shutdown and overall system stability.

[0063] In one embodiment, rejecting new requests to a service instance includes:

[0064] Set the global ingress switch to the status of "shutting down" and return a specific exception code when a new request arrives for the service instance.

[0065] Among them, the global entry switch is a globally visible control flag used to uniformly manage whether a service instance is allowed to receive new business requests; "Shutting down" means that the service instance has entered the offline process and no longer accepts new requests; and the specific exception code is a predefined error code used to clearly inform the caller that the current service instance is being shut down and should not continue to send requests.

[0066] In practice, upon receiving a container group shutdown signal from the container platform, the service instance immediately modifies the value of a global memory variable. This global variable can be a boolean flag, initially set to false (indicating normal operation) and then set to true upon receiving the shutdown signal, corresponding to the shutdown process. This modification of the global variable must be visible in a multi-threaded environment, for example, by using atomic assignment or volatile variable writes, ensuring that all subsequent request processing threads can immediately read the latest status value.

[0067] At the entry point where a service instance provides services, such as the handler function for a Hypertext Transfer Protocol (HTTP) request or the interceptor method for a Remote Procedure Call (RPC) request, the current value of the global switch at this entry point is read before executing business logic. If the read status is "shutting down," the service instance will not continue executing any subsequent business code such as database queries, cache access, or remote calls, but will directly construct a response message. This response message carries a specific error code, such as the HTTP status code 503 representing service unavailable, or a custom business error code such as 2003 indicating that the service instance is shutting down. The service instance can add a brief text description in the response header or message body, such as "The instance is shutting down; please try other nodes."

[0068] In practical implementation, the global switch check at the entry point must be placed at the very beginning of the request processing flow. Taking a microservice based on the Hypertext Transfer Protocol (HTTP) as an example, middleware or filtering mechanisms can be used to check the switch before processing any routing logic. For Remote Procedure Call (RPC) services, a pre-interceptor can be added to the server-side request dispatcher. The service instance should also ensure that for entry points with different protocol types—for example, simultaneously exposing both an HTTP and a Transmission Control Protocol (TCP) interface—each entry point shares the same global switch variable, ensuring that all new requests are consistently rejected.

[0069] Once a service instance returns a specific exception code, the processing of the request is complete and will not consume any subsequent business resources. Pending requests received but not yet completed within the service instance are unaffected by this global ingress switch, as those requests have already passed the ingress check and entered the business processing flow. Setting the global ingress switch, along with modifying the registry's offline flag and health check endpoints, can be done simultaneously. These three are independent yet complementary, forming a multi-layered protection system. In actual operation, even if there is a brief delay in the registry's state synchronization, as long as the global ingress switch is set to be shut down, any newly arriving requests will be rejected immediately, thus preventing these requests from penetrating to the business processing layer.

[0070] It's important to note that simply relying on the registry's offline marker or health check endpoint modifications cannot instantly block new requests. This is because upstream callers may cache service instance addresses, and load balancer probing has time intervals. Without setting a global ingress switch and returning a specific exception code, these new requests will still reach the service instance's business processing layer within a short time window after the shutdown process begins, consuming valuable resources such as thread pools and database connections, while interfering with the normal execution of already received requests. By checking the switch at the front end and directly returning a specific exception code, the rejection operation is completed with minimal overhead. This achieves immediate blocking of new requests, preventing them from preempting computing and storage resources during shutdown and ensuring resource supply for already received and pending requests. Simultaneously, the specific exception code provides callers with clear error semantics, facilitating failover or retry strategies and improving the collaborative efficiency and overall stability of the distributed system during service shutdown.

[0071] In one embodiment, semantic parsing of each received pending request includes:

[0072] Intercept the business method corresponding to each received pending request, read the preset annotation markers on each business method, and obtain the semantic parsing results.

[0073] Among them, business methods are functions or procedures in service instances that are responsible for handling specific business logic; the pre-defined annotation tags are metadata tags that are added to the source code of business methods during the development phase, used to declare the operation type, dependent resources, or execution characteristics of the business performed by the method.

[0074] In practice, after receiving a container group shutdown signal and rejecting new requests, the service instance locates the corresponding business method entry point for each pending request recorded in memory. In a typical application framework, each Hypertext Transfer Protocol (HTTP) request or Remote Procedure Call (RPC) request is ultimately routed to a specific method of a business class, such as the "Create Order" method in the "Order Service" class or the "Query User Information" method in the "User Service" class. The service instance uses aspect-oriented programming (AOP) or dynamic proxy mechanisms to insert an interceptor before or during the business method call. This interceptor can obtain the object of the business method to be executed without modifying the original business code.

[0075] After the interceptor obtains the business method object, it checks whether the method contains predefined annotation markers using reflection or metadata reading. Taking Java as an example, developers can define a custom annotation called "Business Semantics," which includes operation type and resource type attributes. When writing business methods, developers add this annotation to the method header and fill in specific values. For example, annotating the "Create Order" method with operation type equal to "Write to Database" and resource type equal to "Order Table," and the "Query Inventory" method with operation type equal to "Read-Only" and resource type equal to "Cache." After reading these annotation markers, the interceptor extracts the attribute values ​​from the annotations and assembles them into a semantic parsing result object.

[0076] For the same pending request, its business method might be located at the top of the call chain or within a deeply nested sub-method. The service instance only intercepts the top-level business method because its annotations already encompass the overall business semantics of the request. If a business method lacks a pre-defined annotation, the service instance will search upwards along the method call stack until it finds a method with an annotation. Once all the top-level business methods corresponding to all pending requests have been intercepted and their annotations read, the service instance obtains the semantic resolution result for each request.

[0077] In practice, annotation tags only need to be read once. The service instance intercepts and parses a request the first time it receives it, binding the parsing result to the request. Subsequent execution path determinations directly use the already bound result, eliminating the need for repeated parsing. Since the interception occurs before the actual execution of the business method, it does not affect the normal operation of the business logic. In this way, the service instance does not need to parse the request's message body or Uniform Resource Locator (URL) string; it can quickly obtain the request's semantic information solely based on the annotation tags determined at compile time.

[0078] It's important to note that directly performing semantic parsing on the raw data of the requests to be processed requires handling various data formats and protocol types. The parsing logic is complex and error-prone, and it consumes additional CPU time. In contrast, annotations on business methods are pre-defined structured information with a clear format and limited possible values, offering fast reading speeds and high reliability. By intercepting business methods and reading annotations to obtain semantic parsing results, complex semantic understanding can be transformed into simple metadata reading operations. This significantly reduces the implementation complexity and runtime overhead of semantic parsing, improves the accuracy and consistency of parsing results, and tightly couples the definition of business semantics with the business code, facilitating development and maintenance. It also provides efficient and reliable input for subsequently determining the execution path of each request to be processed.

[0079] In one embodiment, the execution path for each pending request is determined based on the semantic parsing results, including:

[0080] If the semantic parsing result indicates an interruptible request, then the execution path is determined to be not to continue executing the current request;

[0081] If the semantic resolution result is an uninterruptible request, then the execution path is determined to continue executing the current request until it is completed.

[0082] Interruptible requests refer to request types that can be terminated early during the service instance shutdown process without affecting business consistency, such as read-only queries or idempotent operations; non-interruptible requests refer to request types that must be completed completely or otherwise will result in data errors or business interruption, such as order payment or database write operations.

[0083] In practice, after obtaining the semantic parsing result of each pending request, the service instance first checks the interruption policy field in the result. If this field indicates that the current request is interruptible, the service instance determines that the execution path of the request should not continue. According to this execution path, the service instance will immediately retrieve the request from the pending request queue, but will not call any of its corresponding business methods, nor will it perform subsequent operations such as database queries, remote calls, or message sending. The service instance can directly clean up the context resources occupied by the request, such as releasing the temporary buffer or network connection handle associated with the request, and then mark the request as completed and remove it from the pending queue. The entire process does not require returning any response to the caller. Alternatively, a general prompt message can be returned to inform the caller that the request has been actively skipped, but this is not a core action in determining the execution path.

[0084] If the interruption policy field in the semantic parsing result indicates that the current request is uninterruptible, the service instance determines the execution path of the request to continue until completion. Following this execution path, the service instance keeps the request in the processing queue and executes it step-by-step according to the normal request processing flow. For example, for a database write request, the service instance will sequentially start a transaction, execute a structured query language statement, commit the transaction, and then generate a success response to return to the caller. For a call chain request involving multiple microservices, the service instance will initiate remote calls sequentially according to the dependency order, waiting for each sub-call to return before proceeding to the next step. The service instance will continuously track the execution status of the request until all business operations have completed normally and the response has been sent to the caller, at which point the request will be removed from the processing queue.

[0085] In its implementation, a service instance can maintain a request execution path mapping table, where each request's unique identifier corresponds to a path type tag. After semantic resolution, the service instance sets the path tag for interruptible requests to 0 and the path tag for non-interruptible requests to 1. During the processing loop, the service instance iterates through the queue of requests to be processed. For requests with a path tag of 0, its status is directly updated to "ignored" and the request is dequeued; for requests with a path tag of 1, they are handed over to the business execution thread pool for further processing. This approach ensures that interruptible requests do not enter the business execution process, thus avoiding the consumption of thread resources, database connection pool resources, and CPU time.

[0086] It's important to note that interruptible requests pose no risk to business consistency; continuing their execution only consumes resources and delays the service instance's shutdown time. However, if uninterruptible requests are interrupted, they can lead to serious problems such as data inconsistency, difficulties in transaction rollback, or prolonged waiting times for the caller. By directly determining two different execution paths based on semantic parsing results—choosing not to continue execution for interruptible requests and continuing execution until completion for uninterruptible requests—limited processing resources can be concentrated on critical requests that must be completed. This ensures the integrity of uninterruptible requests and the consistency of business data while avoiding unnecessary resource consumption by interruptible requests. It significantly shortens the waiting time required for a service instance to go from receiving a shutdown signal to actual shutdown, and reduces retry storms or error accumulation caused by forced interruption of requests.

[0087] In one embodiment, when all pending requests have been completed according to their corresponding execution paths, the container platform is notified to complete the decommissioning process, including:

[0088] For each pending request that can be interrupted, immediately interrupt it and return a specific exception code;

[0089] For each uninterruptible pending request, the active request counter is incremented when the pending request begins execution and decremented when the pending request completes execution.

[0090] When the active request counter reaches zero, it is determined that all pending requests have been completed, and an exit permission signal is sent to the container platform.

[0091] The active request counter is an integer variable used to record the number of uninterruptible requests currently being executed; zeroing means that the value of the counter becomes 0; the exit permission signal is a notification message sent by the service instance to the container platform, indicating that all uninterruptible requests have been processed and that the container platform is allowed to perform the final shutdown operation.

[0092] In practice, after completing semantic parsing and marking each pending request with either interruptible or non-interruptible attributes, the service instance executes its processing logic according to the different processing logic for the two types of requests. For each pending request marked as interruptible, the service instance does not send the request into the business processing flow but immediately terminates any further processing of the request. Specifically, in the entry interceptor or dispatcher of request processing, once it is determined that the current request is interruptible, the service instance directly constructs a response object containing a specific exception code, such as the Hypertext Transfer Protocol status code 503 or a custom business error code 4001, and returns the response to the caller. After sending the response, the service instance immediately removes the request record from the pending request queue in memory, no longer occupying any threads, database connections, or other system resources. The entire process does not involve calls to business code or generate any persistent changes.

[0093] For each pending request marked as uninterruptible, the service instance will normally send it into the business processing flow. Before invoking the business method corresponding to the request, the service instance first performs an atomic increment operation on the active request counter. To ensure accurate counting in a concurrent environment, atomic integer types or locking mechanisms can be used to ensure that the counter can be correctly accumulated when multiple threads are processing different uninterruptible requests simultaneously. Subsequently, the service instance executes all the logic in the business method, including database operations, remote service calls, file read / write, etc. After the business method of the request has completed its execution normally and returned a response to the caller, the service instance then performs an atomic decrement operation on the active request counter. If an exception is thrown during the execution of the business method, the service instance will also perform a decrement operation after the exception is caught and handled, ensuring that the counter is correctly decremented regardless of success or failure.

[0094] After each decrement of the active request counter, the service instance immediately checks if the latest value of the counter is 0. This check and decrement should be performed consecutively to prevent other threads from inserting new increment operations before the check. When the service instance finds that the active request counter has reached zero, it means that all uninterruptible requests have been completed without any omissions. At this point, the service instance sends an exit permission signal to the container platform. This signal can be a Hypertext Transfer Protocol (HTTP) interface call or a call to an API method provided by the container platform, such as sending a null request to a specific endpoint of the container platform. The exit permission signal should explicitly inform the container platform that the current service instance has no critical requests that need protection running and can safely terminate the container group and reclaim resources. After sending the signal, the service instance can either enter a brief waiting state or directly exit the process according to further instructions from the container platform.

[0095] In a specific deployment scenario, the initial value of the active request counter is 0. After receiving a shutdown signal and rejecting new requests, the service instance only counts those requests that have been received and marked as uninterruptible. For interruptible requests, the counter is neither incremented nor decremented because they have been interrupted before execution began. This approach ensures that the counter's value purely reflects the actual execution load of uninterruptible requests. When the service instance handles a large number of uninterruptible requests simultaneously, the counter dynamically increases and decreases, and the zeroing condition is only triggered after the last uninterruptible request completes and decrements.

[0096] It's important to note that interruptible requests don't need to wait for completion; immediately interrupting them and returning an exception code prevents them from consuming valuable threads and resources, thus accelerating the shutdown process. Uninterruptible requests, on the other hand, must execute completely, and their progress can be precisely tracked using an active request counter. If a counter is used for all requests, including interruptible requests, the counter will never reach zero, even if all uninterruptible requests have already completed. This prevents the service instance from sending an exit permission signal. Conversely, simply waiting for a fixed time without a counter might prematurely signal and force uninterruptible requests to terminate. By differentiating between these two types of requests, using a counter only for uninterruptible requests, and sending an exit permission signal when the counter reaches zero, precise control over the shutdown timing is achieved. This avoids interference from interruptible requests, ensuring that the exit permission signal is only issued after all uninterruptible requests have truly completed. This guarantees the integrity and data consistency of critical requests, releases resources occupied by interruptible requests in a timely manner, improves the reliability and efficiency of service shutdown, and provides a clear and safe termination signal for the container platform.

[0097] In one embodiment, a specific exception code is used by the caller to refresh the list of service instances and retry the request to a new service instance.

[0098] The caller is the upstream service or client program that initiates the business request; the service instance list is the collection of available service instance addresses that the caller has cached locally or obtained from the registry center; and the new service instance refers to another available instance that the caller selects after refreshing the list, which is different from the original target instance.

[0099] In practice, after initiating a request, the caller waits for a response from the service instance. When the caller receives a specific exception code, such as the Hypertext Transfer Protocol status code 503 or a custom error code 2003, the caller first parses the status code field in the response to determine if it belongs to the predefined category of "service instance is shutting down." If a match is found, the caller will not treat the exception code as a normal business error and directly throw it to the upper layer, but will trigger a special failover process.

[0100] According to this failover process, the caller immediately sends a query request to the registry center to obtain the addresses of all healthy service instances under the current service name. The list returned by the registry center may have removed the instance that is being shut down, or it may still contain that instance due to state synchronization delays. The caller uses this newly obtained list to replace the old list cached locally, thus completing the service instance list refresh operation. After refreshing, the caller reselects a service instance from the new list. The selection strategy can be round-robin, random, or determined based on load weight, but the instance that just returned a specific exception code must be excluded. Subsequently, the caller re-initiates the original request using the newly selected instance address, i.e., retrying the request to the new service instance. Throughout the process, the caller should set a maximum number of retries and a timeout period to avoid infinitely retries of the same request.

[0101] In specific deployment scenarios, the caller can integrate this logic into the interceptors or client proxies of its network communication framework. For example, in microservice calls based on the Hypertext Transfer Protocol (HTTP), the caller uses a client with a retry mechanism and configures a specific exception code as the condition for triggering a retry. The caller also needs to ensure the idempotency of the retry request to ensure that repeated execution does not produce side effects. For requests that are not idempotent, the caller can determine whether to allow retry based on the business context, or simply refresh the list without automatically retrying, leaving the subsequent operation to be determined by the upper-layer business logic. When multiple callers simultaneously receive a specific exception code returned by the same service instance, each caller independently refreshes its own local list, thereby gradually migrating traffic to other healthy service instances.

[0102] It's important to note that if the caller treats specific exception codes as ordinary errors, it might log the error and fail immediately, or repeatedly retries to the same unavailable instance, leading to continuous and unrecoverable request failures. By defining the semantics of specific exception codes to trigger a refresh of the list and retries to a new instance, the caller can proactively detect the offline status of service instances and correct its routing targets from the source. This enables the caller to have automatic failover capabilities, switching requests to healthy instances without manual intervention, reducing the call failure rate caused by service instance offline, and avoiding invalid retries to closed instances, thus improving the self-healing capability and request processing success rate of the distributed system.

[0103] To better understand this application, in one example, in a Kubernetes-based system, an order service instance runs within a Pod. When Kubernetes initiates a Pod rolling update, it sends a SIGTERM signal to this instance. Upon receiving the signal, the service instance immediately and proactively calls the Nacos registry's application programming interface to mark its health status as offline. This operation ensures that approximately 80% of new requests from upstream callers are no longer routed to this instance after the service list is refreshed. However, a small number of requests still arrive because the caller's local cache has not been updated in time. The service instance then activates a global shutdown switch at the traffic ingress layer, checking each new request in a remote procedure call filter or Hypertext Transfer Protocol interceptor. Intercepted requests directly return a 503 status code with a retry exception flag. Upon receiving this, the caller recognizes the error code, proactively refreshes the service instance list from the registry, removes the current instance, and retryes the request to a new order service instance. For the few requests that had already entered the business processing flow before the shutdown signal arrived, the service instance enters a method-level interception layer to parse the business semantics of each request. In this process, requests to query product inventory are classified as interruptible requests, with a semantic result value of 0. The service instance immediately interrupts the processing of this request, returns a 503 status code, and guides the caller to retry. Requests to create an order, on the other hand, are classified as uninterruptible requests, with a semantic result value of 1. The service instance continues to execute this request, sequentially completing database writes, inventory deductions, and message sending. Simultaneously, an active request counter is maintained, incrementing when a request begins execution and decrementing when it completes. Once all uninterruptible requests have been executed and the counter has reached zero, the service instance notifies the Kubernetes platform to terminate the Pod. This entire shutdown process ensures the consistency of critical business data while also enabling rapid failure and automatic retries for non-critical requests.

[0104] In another example, a user service instance is preparing to go offline. The instance first removes its address from the registry and notifies the upstream order service to update its service list. At this point, a new request from the order service arrives at the user service instance. The service instance detects the shutdown flag at the L2 barrier layer and immediately returns a 503 error code and a custom ServiceRejectException exception. The order service, as the caller, catches this exception, waits briefly using an exponential backoff strategy, then retrieves a new list of user service instances from the registry, selects a new instance, and retryes the original request. If the request again enters the same instance that is being shut down, the L2 barrier intercepts it again, triggering a refresh and retries. Once the retry request successfully reaches a healthy instance, it is processed normally. For requests that have entered the L3 method-level barrier before the shutdown signal arrives, the service instance resolves their semantics: if it is a read-only query to retrieve user information, the semantic result is 0, indicating an interruptible request. The service instance immediately interrupts execution and returns a 503 response with a retry flag, and the caller automatically retryes on another instance. If it is a write operation to update user points, the semantic result is 1, indicating an uninterruptible request. The service instance increments the active request counter by 1, decrements the counter by 1 after executing the points update logic, and continues waiting for the counter to reach zero. Finally, when the active request counter becomes 0, the service instance notifies the container platform to complete the Pod deletion, thus achieving an adaptive closed-loop shutdown process at the call chain level.

[0105] The service instance shutdown apparatus provided in the embodiments of this application is described below. The service instance shutdown apparatus described below can be referred to in correspondence with the service instance shutdown method described above. Figure 2 As shown, this application provides a service instance offline device, applied to the server side, the device including:

[0106] The service instance offline module 201 is used to change the running status of the service instance corresponding to the container group shutdown signal when a container group shutdown signal is received from the container platform, and to reject new requests from the service instance.

[0107] The execution path determination module 202 is used to perform semantic parsing on each received request to be processed, and determine the execution path of each request to be processed based on the semantic parsing results.

[0108] The container platform decommissioning module 203 is used to notify the container platform to complete the decommissioning process when all pending requests have been executed according to their corresponding execution paths.

[0109] In one embodiment, the service instance offline module 201 includes:

[0110] The runtime status change unit is used to call the registry center to mark the service instance corresponding to the container group shutdown signal as offline and modify the health check endpoint to unavailable.

[0111] In one embodiment, the service instance offline module 201 includes:

[0112] The New Request Rejection unit is used to set the state of the ingress global switch to "shutting down" and return a specific exception code when a new request arrives at the service instance.

[0113] In one embodiment, the execution path determination module 202 includes:

[0114] The semantic parsing unit is used to intercept the business method corresponding to each received pending request, read the preset annotation tags on each business method, and obtain the semantic parsing result.

[0115] In one embodiment, the execution path determination module 202 includes:

[0116] The first execution path determination unit is used to determine the execution path as not continuing to execute the current request if the semantic parsing result is an interruptible request;

[0117] The second execution path determination unit is used to determine the execution path as continuing to execute the current request until execution is completed if the semantic parsing result is an uninterruptible request.

[0118] In one embodiment, the container platform decommissioning module 203 includes:

[0119] The interrupt execution unit is used to immediately execute an interrupt for each pending request that can be interrupted, and return a specific exception code.

[0120] The counter counting unit is used to increment the active request counter when each uninterruptible request begins to be processed, and decrement the active request counter when the processing request is completed.

[0121] The exit permission signal sending unit is used to determine that all pending requests have been completed when the active request counter reaches zero, and to send an exit permission signal to the container platform.

[0122] In one embodiment, a specific exception code is used by the caller to refresh the list of service instances and retry the request to a new service instance.

[0123] In one embodiment, this application also provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the service instance offline method as described in any of the above embodiments.

[0124] In one embodiment, this application also provides a computer device storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the service instance offline method as described in any of the above embodiments.

[0125] Indicatively, such as Figure 3 As shown, Figure 3 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 3 The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as application programs, that can be executed by the processing component 302. The application programs stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the service instance offline method of any of the above embodiments.

[0126] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.

[0127] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0128] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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 a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. In this document, "a," "an," "the," "the," and "its" may also include plural forms unless the context clearly indicates otherwise. "Multiple" refers to at least two, such as 2, 3, 5, or 8, etc. "And / or" includes any and all combinations of the related listed items.

[0129] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0130] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A service instance offline method, characterized in that, Applied to the server side, the method includes: When a container group shutdown signal is received from the container platform, the running status of the service instance corresponding to the container group shutdown signal is changed, and new requests from the service instance are rejected. Semantic parsing is performed on each received request to be processed, and the execution path of each request to be processed is determined based on the semantic parsing results; Once all pending requests have been completed according to their corresponding execution paths, the container platform is notified to complete the decommissioning process.

2. The method of claim 1, wherein, The change of the running status of the service instance corresponding to the container group shutdown signal includes: The registry center is invoked to mark the service instance corresponding to the container group shutdown signal as offline and to modify the health check endpoint to unavailable.

3. The method of claim 1, wherein, The rejection of new requests to the service instance includes: Set the global ingress switch to the status of "shutting down" and return a specific exception code when a new request arrives for the service instance.

4. The method of claim 1, wherein, The semantic parsing of each received pending request includes: Intercept the business method corresponding to each received pending request, read the preset annotation tags on each business method, and obtain the semantic parsing result.

5. The method of claim 1, wherein, The step of determining the execution path for each request to be processed based on the semantic parsing results includes: If the semantic parsing result indicates an interruptible request, then the execution path is determined to be not to continue executing the current request; If the semantic resolution result is an uninterruptible request, then the execution path is determined to continue executing the current request until it is completed.

6. The method of claim 1, wherein, When all the pending requests have been completed according to their corresponding execution paths, the container platform is notified to complete the decommissioning process, including: For each pending request that can be interrupted, immediately interrupt it and return the specific exception code; For each uninterruptible pending request, the active request counter is incremented when the pending request begins execution and decremented when the pending request completes execution. When the active request counter reaches zero, it is determined that all pending requests have been completed, and an exit permission signal is sent to the container platform.

7. The method according to claim 3, 5 or 6, characterized in that, The specific exception code is used by the caller to refresh the service instance list and retry the request to a new service instance.

8. A service instance offline device, characterized in that, Applied to the server side, the device includes: The service instance offline module is used to change the running status of the service instance corresponding to the container group shutdown signal when a container group shutdown signal is received from the container platform, and to reject new requests from the service instance. The execution path determination module is used to perform semantic parsing on each received request to be processed, and determine the execution path of each request to be processed based on the semantic parsing results. The container platform decommissioning module is used to notify the container platform to complete the decommissioning process when all the pending requests have been executed according to their corresponding execution paths.

9. A storage medium, characterized in that: The storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the service instance offline method as described in any one of claims 1 to 7.

10. A computer device, characterized in that, include: One or more processors, and memory; The memory stores computer-readable instructions that, when executed by the one or more processors, perform the steps of the service instance offline method as described in any one of claims 1 to 7.

Images