Control method, device, system, and medium for application service instance

Abstract

A method, apparatus, system, electronic device, and medium for controlling an application service instance are disclosed. The application service instance is deployed in a container and can act as a message consumer to receive messages pushed by a message middleware. The method includes: when the container is created in response to a scaling instruction, listening for a startup completion event of the application service instance; after listening for the startup completion event, establishing a connection between the application service instance and the message middleware, so that the application service instance begins to receive and process messages pushed by the message middleware; when the container enters a destruction process in response to a scaling instruction, disconnecting the connection between the application service instance and the message middleware, so that the application service instance stops receiving messages pushed by the message middleware; and destroying the application service instance after the connection between the application service instance and the message middleware is disconnected.

Description

Technical Field

[0001] This application relates to the field of distributed computing technology, and in particular to a control method, apparatus, system, electronic device and medium for an application service instance. Background Technology

[0002] In modern distributed service systems, message middleware is typically used for data interaction to achieve decoupling and asynchronous communication between services. To cope with changes in business load, these systems need to achieve elastic scaling by dynamically increasing (i.e., scaling up) or decreasing (i.e., scaling down) the number of service instances.

[0003] However, when performing service instance scaling operations, newly launched instances may experience timeouts or failures in the initial stages of processing external business requests. Similarly, runtime exceptions may occur when performing scaling down operations to destroy service instances, leading to message processing failures.

[0004] Therefore, message consumer control schemes in related technologies still have shortcomings in practice. Their implementation process may seriously affect the continuity of business and the stability of the system, and cannot meet the high availability requirements of modern distributed systems. Summary of the Invention

[0005] This application provides a method, apparatus, system, electronic device, and medium for controlling application service instances, in order to solve the problems in the related art where improper timing of message processing and application service instance startup affects business request processing during application service instance expansion, and runtime exceptions are caused by conflicts between message processing and application service instance destruction processes during scaling down.

[0006] According to one embodiment of this application, a method for controlling an application service instance is proposed. The application service instance is deployed in a container and can act as a message consumer to obtain messages pushed by a message management center. The method includes: If the container is created in response to a scaling instruction, listen for the startup completion event of the application service instance; After the startup completion event is detected, a connection is established between the application service instance and the message middleware, so that the application service instance can start receiving and processing messages pushed by the message middleware. If the container enters the destruction process in response to a scaling-down command, the connection between the application service instance and the message middleware is disconnected so that the application service instance stops receiving messages pushed by the message middleware. After the connection between the application service instance and the message middleware is broken, the application service instance is destroyed.

[0007] In some implementations, the application service instance startup completion event is triggered after the application service instance completes registration in the service registry.

[0008] In some implementations, the application service instance startup completion event is triggered after the application service instance has completed initialization and refresh in its application context and passed a preset health check.

[0009] In some embodiments, the method further includes: If a preset destruction method is detected, the container is determined to enter the destruction process.

[0010] In some implementations, messages that were pushed to the application service instance before it was deregistered and have not yet been processed are marked as unconsumed during the deregistration process. Messages in the unconsumed state can be rescheduled by the message middleware to other normally operating application service instances for processing.

[0011] According to one embodiment of this application, a control device for an application service instance is proposed. The application service instance is deployed in a container and can act as a message consumer to obtain messages pushed by a message management center. The device includes: The first listening module is configured to listen for the startup completion event of the application service instance when the container is created in response to a scaling instruction; The registration module is configured to establish a connection between the application service instance and the message middleware after listening to the startup completion event, so that the application service instance can start receiving and processing messages pushed by the message middleware. The second listening module is configured to disconnect the application service instance from the message middleware when the container enters the destruction process in response to the scaling-down instruction, so that the application service instance stops receiving messages pushed by the message middleware. The destruction module is configured to destroy the application service instance after the connection between the application service instance and the message middleware is broken.

[0012] According to one embodiment of this application, a distributed service system is proposed, comprising: The service orchestrator is used to send expansion or reduction commands; The service registry is used to manage the registration status of application service instances; Message Management Center; An application service instance, deployed in a container, can act as a message consumer to obtain messages pushed by the message management center. The application service instance has a startup component deployed thereon, which is used to execute the methods described in any of the above embodiments.

[0013] According to one embodiment of this application, an electronic device is provided, the device including a memory and a processor, the memory being used to store computer instructions executable on the processor, and the processor being used to implement the method as described in any of the preceding claims when executing the computer instructions.

[0014] According to one embodiment of this application, a computer-readable storage medium is provided that stores a computer program thereon, which, when executed by a processor, implements the method as described in any of the preceding claims.

[0015] The application service instance control scheme proposed in this application, in the scaling scenario, delays the process of establishing a connection between the application service instance and the message middleware until after the application service instance's startup completion event is detected. This ensures that the application service instance only begins receiving and processing messages after startup is complete, effectively avoiding resource contention during the initial container startup phase. This guarantees that newly added instances can independently and stably handle external business requests and eliminates the risk of request timeouts during the scaling process. In the shrinking scenario, by delaying the destruction process of the application service instance until the connection between the application service instance and the message middleware is disconnected, it ensures that the application runtime environment required for message processing stops receiving new messages before entering the destruction state. This avoids message processing anomalies caused by application destruction and significantly improves the stability and availability of the entire system.

[0016] Other features and advantages of the technical solution proposed in this application are described below. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this specification and, together with the description, serve to explain the principles of this specification.

[0018] Figure 1 This is a flowchart illustrating a control method for an application service instance according to an embodiment of this application.

[0019] Figure 2 This is a schematic diagram of the system architecture in the expansion and contraction scenarios of an exemplary embodiment of this application.

[0020] Figure 3 This is a schematic diagram of the structure of an electronic device shown in at least one embodiment of this application. Detailed Implementation

[0021] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0022] This application manages the timing of the application service instance startup process and the connection establishment process between the application service instance and the message middleware, as well as the timing of the application service instance destruction process and the connection disconnection process between the application service instance and the message middleware. This enables delayed message reception during scaling up and preemptive cessation of message reception during scaling down, thus seamlessly integrating the message processing flow into the service instance lifecycle management. This solves the business interruption and anomaly problems caused by lifecycle inconsistencies in related technologies, reduces the impact on business during scaling up and down, and achieves user-unobtrusive scaling up and down.

[0023] Reference Figure 1 This document illustrates a flowchart of a control method for an application service instance provided in an embodiment of this application. The application service instance is deployed in a container and can act as a message consumer to obtain messages pushed by a message middleware. This method is particularly suitable for various business middleware systems requiring high-concurrency message processing, such as payment middleware, order middleware, user middleware, and message middleware message handling scenarios. The method in this embodiment can be executed by a startup component, which is embedded within the application service instance and responsible for initializing and managing the connection with the message middleware, such as a Pulsar-starter, used to work in conjunction with the message middleware. This startup component can be an upgraded or modified version of, for example, an existing Pulsar-starter, enabling it to integrate and execute the event listening and lifecycle management functions proposed in this application.

[0024] like Figure 1 As shown, the method includes the following steps 101 to 104.

[0025] Step 101: If the container is created in response to the scaling instruction, listen for the startup completion event of the application service instance.

[0026] Step 101 describes the initial actions of this embodiment in the expansion scenario.

[0027] An application service instance typically refers to a functional unit that executes specific business logic within a distributed system, such as a microservice process. Scaling commands are usually issued by an external service orchestrator (such as Kubernetes) or cloud platform based on load conditions to launch new containers to run application service instances. An application service instance can run a message consumer service to establish communication connections with a message middleware. Message middleware is used for asynchronous communication between services, such as Apache Pulsar. The message consumer service can subscribe to messages on specified topics from the message middleware, and after establishing a communication connection, the message middleware can push the subscribed messages to the message consumer service.

[0028] According to this embodiment, after the application is deployed to the container, the startup component does not immediately initialize the message consumer service and establish a connection with the message middleware. Instead, it listens for the application service instance's startup completion event. This event can be seen as a signal indicating that the application service instance is fully ready to provide services.

[0029] In related technologies, scaling up typically follows a process of adding containers, deploying application service instances within the containers, and registering the application service instances with a service registry. However, due to the lack of fine-grained coordination of the lifecycles of the various service components within the application service instance, this process often results in the message consumer service within the application service instance prematurely starting to receive and process messages pushed by the message middleware before the application service instance is fully ready. This leads to preemption of worker threads. Therefore, when the application service instance successfully registers with the service registry and begins receiving external business requests, it may be unable to process them properly due to insufficient internal resources, ultimately causing some requests to experience 504 timeouts and other issues. In this embodiment, by listening for the application service instance's startup completion event instead of immediately establishing a connection with the message middleware, the process of the message consumer service starting to receive and process messages is delayed until the application service instance is truly ready. This fundamentally solves the aforementioned resource preemption problem and ensures smooth scaling up.

[0030] In some implementations, the application startup completion event is triggered after the application service instance completes registration with the service registry. In some examples, the service registry can be a Eureka registry, used to manage the addresses and states of various application service instances in the distributed system. According to this implementation, the subsequent message consumption process can only be triggered after the application service instance has publicly declared its availability.

[0031] Furthermore, in some implementations, the application startup completion event is triggered after the application service instance completes registration in the service registry, and after the application context of the application service instance completes initialization and refresh and passes a preset health check. This implementation provides a more stringent guarantee for the readiness of the application service instance, ensuring that all dependency injection and initialization work within the application has been completed, and that the application service instance itself is in a healthy state, thereby enabling it to reliably handle message processing loads.

[0032] For example, in an exemplary embodiment of an application development framework based on Spring Boot, the application service instance's startup completion event can be a system event issued by the application development framework indicating that the application is ready. This event is a standard signal emitted after the application service instance's application context has been refreshed and all relevant callbacks have been processed, accurately indicating that the application is fully ready. Alternatively, the event can also be a custom event emitted by the application's own logic after passing verification by a preset health check component.

[0033] Step 102: After listening to the startup completion event, establish a connection between the application service instance and the message middleware so that the application service instance can start receiving and processing messages pushed by the message middleware.

[0034] After listening and waiting in step 101, once the application startup completion event is received, the startup component can immediately establish a connection between the application service instance and the message middleware, and execute preset logic, such as initializing the message consumer service, subscribing to the message middleware, and officially starting to pull messages for processing. This ensures that the newly added application service instance can immediately and stably handle external business requests and internal message tasks, avoiding business impact caused by resource contention.

[0035] Step 103: If the container enters the destruction process in response to the scaling-down command, disconnect the connection between the application service instance and the message middleware, so that the application service instance stops receiving messages pushed by the message middleware.

[0036] This step describes the initial actions of this embodiment in a scaled-down scenario.

[0037] Scaling down commands are typically issued by an external service orchestrator to destroy containers. A problem with this technology is that when a container destruction command is received, the application service instance deployed within the container begins its destruction process. However, the message consumer service may still be receiving and processing messages at this time. If it attempts to retrieve a business component (Bean) from a destroying application service instance, an exception will occur. This embodiment overcomes the aforementioned shortcomings of the technology by first disconnecting the application service instance from the message middleware before destroying the application service instance when the container enters the destruction process in response to a scaling down command.

[0038] In some implementations, the entry of a container into the destruction process can be determined by calling a preset destruction method. In many application frameworks, a preset destruction method is called before the container is destroyed. By listening to the call to this method, it is possible to accurately capture the signal that the container is about to be destroyed.

[0039] In one exemplary embodiment, the destruction method is configured with a preset destruction flag, such as an annotation or interface definition. This destruction flag is a standard way used in application development frameworks such as Java and Spring to mark callback methods before resource destruction. By listening to the execution of the method with the destruction flag, the startup component can accurately capture signals that the application is about to be destroyed. Alternatively, the container can be determined to enter the destruction process based on system-level shutdown events or notifications issued by the application development framework when closing the application context.

[0040] Current scaling solutions that first shut down external traffic and then release resources can only handle traffic control for external synchronous requests and cannot address conflicts in internal asynchronous message processing. Based on related technologies, even if external traffic is cut off, internal message consumers may still run during the application's runtime environment destruction process, leading to exceptions. The monitoring scheme proposed in this embodiment achieves precise and early capture of destruction signals by monitoring internal method calls, enabling lossless processing of asynchronous messages.

[0041] According to this procedure, in a scaling-down scenario, when the container enters the destruction process in response to a scaling-down command, the startup component will immediately and proactively disconnect the application service instance from the message middleware, for example, by calling the `close()` method, thus closing the connection with the message middleware and ceasing to receive any new messages. This preemptive destruction step ensures that the message consumer service's lifecycle is safely terminated before, for example, the JVM's application runtime environment destruction process renders its internal state unavailable, thereby completely avoiding runtime exceptions.

[0042] In some implementations, the message middleware may also mark messages that were pushed to the application service instance before the application service instance was deregistered and have not yet been processed as unconsumed, and reschedule messages in the unconsumed state to other normally operating message consumers for processing.

[0043] After the connection between the application service instance and the message middleware is broken, messages that have been received by the application service instance but have not yet been successfully processed and acknowledged will revert to an unconsumed state for the message middleware. The fault tolerance mechanism of the message middleware can ensure that these messages are rescheduled to other healthy application service instances for processing, thereby guaranteeing zero loss of message data and achieving true lossless scaling.

[0044] Step 104: After the connection between the application service instance and the message middleware is broken, the application service instance is destroyed.

[0045] In some implementations, the message middleware can be the Pulsar message middleware, and the startup component can be the Pulsar startup component. This embodiment has been fully verified and implemented thereon.

[0046] To further understand the various implementation details of this application, the following will refer to... Figure 2 The system architecture diagram shown is illustrated, and the technical solution of this application is illustrated through an end-to-end business scenario example. Figure 2 The demonstration showcased the interaction flow between the three core components—the "Payment" application service, the service registry, and the pulsar-starter—in both scaling up and scaling down scenarios.

[0047] This example uses a high-concurrency online payment system. Under normal load, the system runs several payment application service instances (Pods), each of which embeds the pulsar-starter based on this application and is registered in the service registry.

[0048] Suppose that due to a promotional activity, the number of payment requests surges suddenly. Upon detecting the load pressure, the service orchestrator (such as Kubernetes) issues a scaling command to start a new payment service. (See reference...) Figure 2 The upper part of the process is as follows: When a new Pod starts, its internal application service instances begin initialization. During this process, two logical threads occur in parallel. The first is the interaction with the service registry. The agent within the instance communicates with the service registry to register the new application service instance's information, enabling it to be discovered and invoked by other application service instances in the system. The second is the loading of the application service instance itself. The application service instance executes its internal startup process, such as initializing the application context, performing dependency injection, and conducting health checks. In related technologies, pulsar-starter attempts to register and start the message consumer service early in the application startup process, thus triggering resource contention.

[0049] However, according to the scheme proposed in this application, such as Figure 2 As shown in the "Service Loading and Startup Complete" node, pulsar-starter will wait until the application service instance is fully ready. Once the application service instance confirms that it has successfully initialized, it will emit an internal application startup complete event signal, such as... Figure 2 The signal pointing from the payment terminal to the pulsar-starter is shown in the diagram. Only after receiving this signal does the pulsar-starter begin executing its logic: successful consumer registration indicates a connection has been established with the Pulsar message middleware and a subscription has been completed; then, message reception and consumption begin, officially starting to pull messages from the message middleware's queue for processing. Through this lazy loading and event-driven mechanism, this application ensures that the start of message processing tasks does not conflict with the service's own initialization process, thereby guaranteeing that newly started instances can smoothly and seamlessly handle business traffic.

[0050] After the promotional campaign ended, payment request volume decreased, and the service orchestrator issued a scaling-down command, destroying the previously expanded payment service Pods. (See reference...) Figure 2 The second half of the process is as follows: When a Pod receives a scaling-down command, two logical threads can be triggered in parallel. The first thread disconnects the application service instance from the message middleware, safely closing its connection with Pulsar and stopping it from receiving requests. This ensures the safe separation of message processing components before the application runtime environment becomes unstable. Any messages that have not yet been acknowledged in this consumer will be rescheduled by the Pulsar server to other healthy consumers, thus guaranteeing zero message loss.

[0051] The second step is to execute the application service instance's own destruction process. For example... Figure 2As shown in the `destroy` node at the start of execution, the application's destruction method is invoked. At this moment, according to this application, the pulsar-starter can immediately listen for the signal indicating that the destruction method has been invoked. Figure 2 As shown by the corresponding signal line, after pulsar-starter receives this signal, it will execute the application destruction logic. The application service instance can be taken offline from the service registry, preventing other application service instances from calling it. After this, the operating system will allow a shutdown waiting time (95 seconds as shown in the figure) before finally executing the kill process to forcibly shut down the application service instance. Because the connection between the application service instance and the message middleware has been safely disconnected, no exceptions will occur during this waiting time due to accessing the resources of the destroyed application runtime environment, achieving true lossless scaling.

[0052] It should be noted that although the exemplary embodiments of this application are described in detail using a payment middleware as the main example scenario, the concept of this application is not limited to this. The application service instance control scheme proposed in this application has good versatility and can be widely applied to other business scenarios that heavily rely on message middleware for asynchronous processing, such as various message processing platforms such as technology middleware, user middleware, order middleware, and message middleware. As long as there is a problem of coordinating the dynamic scaling of service instances with the message processing lifecycle, the ideas of this application can be applied to improve the stability and availability of the system.

[0053] This application also proposes a control device for an application service instance, which is deployed in a container and can act as a message consumer to obtain messages pushed by a message management center; the device includes: The first listening module is configured to listen for the startup completion event of the application service instance when the container is created in response to a scaling instruction; The registration module is configured to establish a connection between the application service instance and the message middleware after listening to the startup completion event, so that the application service instance can start receiving and processing messages pushed by the message middleware. The second listening module is configured to disconnect the application service instance from the message middleware when the container enters the destruction process in response to the scaling-down instruction, so that the application service instance stops receiving messages pushed by the message middleware. The destruction module is configured to destroy the application service instance after the connection between the application service instance and the message middleware is broken.

[0054] This application also proposes a distributed service system, including: The service orchestrator is used to send expansion or reduction commands; The service registry is used to manage the registration status of application service instances; Message middleware; An application service instance, deployed in a container, can act as a message consumer to obtain messages pushed by the message management center. The application service instance has a startup component deployed in it, which is used to execute the control method of the application service instance as described above.

[0055] Figure 3 This is a schematic diagram of an electronic device provided according to one embodiment of this application. The electronic device may be a server, a personal computer, a mobile terminal, or other device with data processing capabilities. As shown, the device includes a processor and a memory. The memory stores computer instructions that can run on the processor, and the processor, when executing the computer instructions, implements the message consumer control method described in any embodiment of this application.

[0056] One embodiment of this application also provides a computer-readable storage medium on which a computer program is stored. This computer-readable storage medium includes all forms of non-volatile memory, media, and devices, such as semiconductor storage devices (e.g., EPROM, flash memory devices), magnetic disks, magneto-optical disks, and CD-ROMs and DVD-ROMs. When the program is executed by a processor, it can implement the control method for the application service instance described in any embodiment of this application.

[0057] The processing and logic flow described in this specification can be implemented by one or more programmable processors executing one or more computer programs, or by special-purpose logic circuits (such as FPGAs or ASICs). The processor used to execute the computer program can be a general-purpose or special-purpose microprocessor. Typically, the processor receives instructions and data from read-only memory or random access memory. The basic components of a computer include a processor for executing instructions and one or more storage devices for storing instructions and data.

[0058] While this specification contains numerous specific implementation details, these should not be construed as limiting the scope of the invention. Certain features described in multiple embodiments may also be implemented in combination in a single embodiment; conversely, various features described in a single embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination. Similarly, although the operational flows in the accompanying drawings are depicted in a specific order, this does not require that they be performed in the indicated order or serially to achieve the desired result; in some cases, multitasking or parallel processing may be equally feasible or more advantageous.

[0059] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for controlling application service instances, characterized in that, The application service instance is deployed in a container and can act as a message consumer to obtain messages pushed by the message middleware; the method includes: If the container is created in response to a scaling instruction, listen for the startup completion event of the application service instance; After the startup completion event is detected, a connection is established between the application service instance and the message middleware, so that the application service instance can start receiving and processing messages pushed by the message middleware. If the container enters the destruction process in response to a scaling-down command, the connection between the application service instance and the message middleware is disconnected so that the application service instance stops receiving messages pushed by the message middleware. After the connection between the application service instance and the message middleware is broken, the application service instance is destroyed.

2. The method according to claim 1, characterized in that, The application service instance startup completion event is triggered after the application service instance completes registration in the service registry.

3. The method according to claim 1, characterized in that, The startup completion event of the application service instance is triggered after the application service instance has completed initialization and refresh in the application context and passed the preset health check.

4. The method according to claim 1, characterized in that, The method further includes: Upon detecting a call to a preset destruction method, the container is determined to enter the destruction process.

5. The method according to claim 1, characterized in that, Messages pushed to the application service instance before it is deregistered and have not yet been processed are marked as unconsumed during the deregistration process. Messages in the unconsumed state can be rescheduled by the message middleware to other normally operating application service instances for processing.

6. A control device for an application service instance, characterized in that, The application service instance is deployed in a container and can act as a message consumer to obtain messages pushed by the message management center; the device includes: The first listening module is configured to listen for the startup completion event of the application service instance when the container is created in response to a scaling instruction; The registration module is configured to establish a connection between the application service instance and the message middleware after listening to the startup completion event, so that the application service instance can start receiving and processing messages pushed by the message middleware. The second listening module is configured to disconnect the application service instance from the message middleware when the container enters the destruction process in response to the scaling-down instruction, so that the application service instance stops receiving messages pushed by the message middleware. The destruction module is configured to destroy the application service instance after the connection between the application service instance and the message middleware is broken.

7. A distributed service system, characterized in that, include: The service orchestrator is used to send expansion or reduction commands; The service registry is used to manage the registration status of application service instances; Message middleware; An application service instance, deployed in a container, is capable of acting as a message consumer to obtain messages pushed by the message management center. The application service instance has a startup component deployed thereon, which is used to execute the method described in any one of claims 1 to 5.

8. An electronic device, characterized in that, The device includes a memory and a processor, the memory being used to store computer instructions that can be executed on the processor, and the processor being used to implement the method of any one of claims 1 to 5 when executing the computer instructions.

9. 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 method described in any one of claims 1 to 5.

Images