Method for micro-service delayed registration in container environment

Abstract

The invention discloses a method for micro-service delayed registration in a container environment, and particularly relates to the technical field of micro-service delayed registration, which comprises the following steps of: closing a micro-service registration process during operation, and modifying a registration switch enable into false based on Spring operation enhancement capability; then a micro-service registration process is self-defined, an original registration mechanism is terminated under the processing of the A1 process, and the registration process is triggered once a self-defined micro-service registrar monitors a registration event, so that the effect of delaying registration is achieved; checking a micro-service registration process and a micro-service and container life cycle alignment process, and starting a probe by the container to perceive a micro-service registration state; and finally, on the basis of a micro-service registration inspection process, a new health inspection mechanism is introduced, and the registration state is dynamically adjusted by regularly detecting the health condition of the micro-service. And the self-defined micro-service registration process is expanded, so that the registration mechanism is more flexible and controllable.

Description

Technical Field

[0001] The present invention relates to the technical field of microservice delayed registration, and more specifically, to a method for microservice delayed registration in a container environment. Background Art

[0002] Microservice architecture is more popular in today's application architecture. Generally, open source enterprise-level microservice frameworks such as Spring Cloud and Spring CloudAlibaba are used, and they run in container environments such as Kubernetes, making full use of the elasticity of container orchestration and being able to have rapid horizontal expansion capabilities. Among them, the open source microservice components are ready to use, which greatly improves the convenience of business development for R&D personnel. The Web Server component will receive requests immediately after startup. If the application requires custom initialization to receive requests, the open source component does not provide a friendly time window for custom initialization, that is, there is no delayed registration capability, which causes the application to register with the registration center before custom initialization, which will cause traffic loss; in the Internet industry, many systems have high traffic, which is very fatal to core businesses; in addition, the timing of rolling updates deployed in container environments such as Kubernetes is also very critical, that is, the probe must sense whether some of the above series of initializations are completed, otherwise it will also face the problem of traffic loss, so delayed registration requires opening up all links between containers and microservices to allow applications to be customized and fully initialized, and receive traffic in the best application state.

[0003] However, it still has some shortcomings in actual use. For example, in the existing technology delayed registration solution, some small teams directly use the open source framework but do not expand and enhance the capabilities, and choose to tolerate the problem of traffic loss in the early stage of startup; some teams will directly choose the cloud vendor's commercial service microservice engine and directly use the whole set of microservice governance capabilities provided by the cloud vendor, but they will be bound by the cloud vendor's products. Subsequent multi-cloud deployment or migration to other clouds will face various constraints and low flexibility; in addition, there are also technical teams that rewrite the microservice SDK, such as Spring Cloud Alibaba NacosStarter, which can indeed support more customized requirements, but the workload is relatively large, and being separated from the open source community means that you cannot enjoy the benefits of the open source community and cannot quickly obtain new features from the open source community. Summary of the invention

[0004] In order to overcome the above defects of the prior art, the embodiments of the present invention provide x to solve the problems raised in the above background technology.

[0005] To achieve the above object, the present invention provides the following technical solution: a method for delayed registration of microservices in a container environment, comprising the following steps: A1: Close the microservice registration process at runtime. Based on Spring runtime enhancement capabilities, change the registration switch enable to false. A2: The custom microservice registration process terminates the original registration mechanism under the S1 process processing, and the custom microservice registrar triggers the registration process once it monitors the custom Register Event, thereby achieving the effect of delayed registration; A3: Microservice registration check process; A4: The microservice and container lifecycles are aligned, and the container startup probe senses the microservice registration status.

[0006] A5: Based on the microservice registration check process, a new health check mechanism is introduced to dynamically adjust the registration status by regularly checking the health status of microservices. A6: The custom microservice registration process has been expanded to support external configuration to dynamically adjust the triggering conditions of the registration event customRegister Event, making the registration mechanism more flexible and controllable.

[0007] Preferably, A1 includes the following steps: A11: Spring Boot application starts; A12: Use the Spring Bean Post Processor[6] mechanism to change the registration switch enable to false during runtime without changing the original configuration. A13: Web Server starts and initializes. After completion, it publishes the event Servlet Web ServerInitialized Event. A14: After Spring Cloud Auto Service Registration receives the Servlet WebServer Initialized Event event, it enters the Spring Cloud microservice registration process; A15: When executing the Spring Cloud microservice registration process, the first step is to check the registration switch enable. However, the value has been changed to false in A12. Therefore, the original Spring Cloud microservice registration process is invalid. That is, it will not be registered with the registration center immediately. The actual registration time is handled by the A2 process.

[0008] Preferably, A2 comprises the following steps: A21: The application performs a series of custom initializations, such as application preheating, business configuration loading, and so on. After the initialization is completed, the registration event custom Register Event is published with the help of Spring Event mechanism. A22: Custom microservice registrar custom Auto Service Registration monitors specific registration events custom Register Event in real time; A23: After monitoring the event, the registration switch enable is changed to true, and then the Spring Cloud microservice registration process is executed; A24: When executing the Spring Cloud microservice registration process, the first step still checks the registration switch enable, and the value is changed to true in [S22], so the registration process can be executed normally; A25: During the execution of the custom Auto Service Registration, it is necessary to record whether it has been executed and whether the registration is successful, which is used for subsequent A3 and A4 process processing.

[0009] Preferably, A3 includes the following steps: A31: The customRegister Command Line Runner, a microservice registration checker implemented based on Spring Boot Command Line Runner, periodically checks the execution status of the custom microservice registrar custom Auto ServiceRegistration; its execution order Order is the last to ensure that other Command Line Runners are not blocked; A32: When executed is false, it blocks and rechecks periodically; A33: When it is checked that executed is true and success is false, the application is terminated, ensuring the same mechanism as the original microservice registration process of Spring Cloud, that is, the application is terminated if the registration fails; A34: When both executed and success are true, the application is released and runs normally.

[0010] Preferably, A4 comprises the following steps: A41: Customize the microservice registrar monitoring indicator custom Register Health Indicator and automatically integrate it into the Spring Boot Actuator Health Endpoint; this Health Indicator provides real-time feedback on whether the A2 process has been executed and whether the registration is successful.

[0011] A42: When the container Pod is started, Kubelet periodically detects the container's startup probe Start Probe interface SpringBoot Actuator Health Endpoint.

[0012] A43: When the S2 process fails or is not executed, the Spring Boot Actuator Health Endpoint status is not 200. If the startup probe fails, it will enter the next detection cycle. If it exceeds a certain number of times, it will restart. A44: When the S2 process is executed successfully, the Spring Boot Actuator Health Endpoint status is 200. At this time, the startup probe passes, and the container Pod starts normally and then updates the Pod status. At this time, the ready state of the microservice is aligned with the container startup ready state, which can avoid a series of problems caused by life cycle misalignment.

[0013] A45: Update the Service Endpoint. The Pod can provide external services through the Service Endpoint.

[0014] A46: The Deployment enters the rolling update of the next batch of Pods.

[0015] Preferably, in step A5, the implementation of the health check mechanism is not limited to the running status of the microservices, but also focuses on the communication stability between services; by regularly detecting the network connection quality between microservices, potential communication failures are discovered in time, and fault isolation and rapid recovery are achieved; at the same time, an adaptive algorithm is introduced to dynamically adjust the inspection frequency according to historical performance data to ensure that the system remains efficient and stable under high load; this new health check mechanism injects more intelligent elements into the robustness of the microservice architecture.

[0016] Preferably, in step A6, in order to further expand the custom microservice registration process and enhance the flexibility and controllability of the registration mechanism, the specific expansion measures are: Dynamically adjust the trigger conditions of registration events based on external configuration: With the introduction of an external configuration mechanism, users can dynamically adjust the trigger conditions of registration events as needed; flexibly set the trigger conditions through configuration files or other means, and adjust them at any time according to business needs; in this way, you can dynamically change the trigger conditions of registration events according to actual conditions to adapt to different scenarios and changes in needs; Support flexible registration event definition: Provides the ability to customize registration events; through custom registration events, you can define your own registration events according to business and system requirements; you can set different registration trigger events according to specific business indicators, status changes of external systems or other conditions, and flexibly configure and adjust them as needed; Support for monitoring and management tools: Manage and monitor the custom microservice registration process, and provide corresponding tools and interfaces; through these tools, you can view the triggering conditions of registration events in real time, monitor the status and statistics of registration; at the same time, you can manage and adjust registration events and triggering conditions to ensure the normal operation of the system, and optimize and adjust as needed.

[0017] By extending the custom microservice registration process and supporting external configuration to dynamically adjust the registration event trigger conditions, the registration mechanism is made more flexible and controllable.

[0018] Technical effects and advantages of the present invention: The delayed registration is performed by the method of the present invention, strictly following the open source Spring Cloud registration logic, only changing the timing of registration, and the registration timing is decided by the application engineering, so as to have the ability of general delayed registration; delayed registration allows the service instance to perform self-health check, application preheating, business configuration loading and other initializations after startup, and ensures that it is running normally before registering, receiving traffic in the best application state, and ensuring that the traffic is lossless. In this way, if the service instance fails to start or fails, it will not be regarded as an available instance by the registration center, thereby avoiding the inclusion of the faulty instance in the service discovery and load balancing mechanism. At the same time, the life cycle of the container environment is opened up to avoid the rolling update ignoring the unavailability of the service caused by the ready state of the application. Delayed registration is used in combination with the automated deployment process to simplify and accelerate the deployment process of the service, especially the coexistence stage of microservice discovery and container discovery mechanisms such as Kubernetes, which plays a key role, so that the startup of microservices and containers is aligned, and the traffic is ensured to be lossless in many aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 It is a schematic diagram of the method flow of the present invention.

[0020] Figure 2 Schematic diagram of the method flow of step A1 of the present invention.

[0021] Figure 3 Schematic diagram of the method flow of step A2 of the present invention.

[0022] Figure 4 Schematic diagram of the method flow of step A3 of the present invention.

[0023] Figure 5 Schematic diagram of the method flow of step A4 of the present invention. DETAILED DESCRIPTION

[0024] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0025] This embodiment provides Figure 1 A method for delayed registration of microservices in a container environment is shown, comprising the following steps: A1: Close the microservice registration process at runtime. Based on Spring runtime enhancement capabilities, change the registration switch enable to false. Further, in step A1, Figure 2 As shown, the following steps are included: A11: Spring Boot application starts; A12: Use the Spring Bean Post Processor[6] mechanism to change the registration switch enable to false at runtime without changing the original configuration. A13: Web Server starts and initializes. After completion, it publishes the event Servlet Web ServerInitialized Event. A14: After Spring Cloud Auto Service Registration receives the Servlet WebServer Initialized Event event, it enters the Spring Cloud microservice registration process; A15: When executing the Spring Cloud microservice registration process, the first step is to check the registration switch enable. However, the value has been changed to false in A12. Therefore, the original Spring Cloud microservice registration process is invalid. That is, it will not be registered with the registration center immediately. The actual registration time is handled by the A2 process.

[0026] A2: The custom microservice registration process terminates the original registration mechanism under the S1 process processing, and the custom microservice registrar triggers the registration process once it monitors the custom Register Event, thereby achieving the effect of delayed registration; Further, in step A2, if Figure 3 As shown, the following steps are included: A21: The application performs a series of custom initializations, such as application preheating, business configuration loading, and so on. After the initialization is completed, the registration event custom Register Event is published with the help of Spring Event mechanism. A22: Custom microservice registrar custom Auto Service Registration monitors specific registration events custom Register Event in real time; A23: After monitoring the event, the registration switch enable is changed to true, and then the Spring Cloud microservice registration process is executed; A24: When executing the Spring Cloud microservice registration process, the first step still checks the registration switch enable, and the value is changed to true in [S22], so the registration process can be executed normally; A25: During the execution of the custom Auto Service Registration, it is necessary to record whether it has been executed and whether the registration is successful, which is used for subsequent A3 and A4 process processing.

[0027] A3: Microservice registration check process; Further, in A3, if Figure 4 As shown, the following steps are included: A31: The customRegister Command Line Runner, a microservice registration checker implemented based on Spring Boot Command Line Runner, periodically checks the execution status of the custom microservice registrar custom Auto ServiceRegistration; its execution order Order is the last to ensure that other Command Line Runners are not blocked; A32: When executed is false, it blocks and rechecks periodically; A33: When it is checked that executed is true and success is false, the application is terminated, ensuring the same mechanism as the original microservice registration process of Spring Cloud, that is, the application is terminated if the registration fails; A34: When both executed and success are true, the application is released and runs normally.

[0028] A4: Microservices and container lifecycles are aligned, and the container startup probe senses the microservice registration status; Further, in A4, if Figure 5 As shown, the following steps are included: A41: Customize the microservice registrar monitoring indicator custom Register Health Indicator and automatically integrate it into the Spring Boot Actuator Health Endpoint; this Health Indicator provides real-time feedback on whether the A2 process has been executed and whether the registration is successful.

[0029] A42: When the container Pod is started, Kubelet periodically detects the container's startup probe Start Probe interface SpringBoot Actuator Health Endpoint.

[0030] A43: When the S2 process fails or is not executed, the Spring Boot Actuator Health Endpoint status is not 200. If the startup probe fails, it will enter the next detection cycle. If it exceeds a certain number of times, it will restart. A44: When the S2 process is executed successfully, the Spring Boot Actuator Health Endpoint status is 200. At this time, the startup probe passes, and the container Pod starts normally and then updates the Pod status. At this time, the ready state of the microservice is aligned with the container startup ready state, which can avoid a series of problems caused by life cycle misalignment.

[0031] A45: Update the Service Endpoint. The Pod can provide external services through the Service Endpoint.

[0032] A46: The Deployment enters the rolling update of the next batch of Pods.

[0033] A5: Based on the microservice registration check process, a new health check mechanism is introduced to dynamically adjust the registration status by regularly checking the health status of microservices. Furthermore, in step A5, the implementation of the health check mechanism is not limited to the running status of microservices, but also focuses on the communication stability between services. By regularly detecting the quality of network connections between microservices, potential communication failures can be discovered in a timely manner to achieve fault isolation and rapid recovery. At the same time, an adaptive algorithm is introduced to dynamically adjust the inspection frequency based on historical performance data to ensure that the system remains efficient and stable under high load. This new health check mechanism injects more intelligent elements into the robustness of the microservice architecture.

[0034] A6: The custom microservice registration process has been expanded to support external configuration to dynamically adjust the triggering conditions of the registration event customRegister Event, making the registration mechanism more flexible and controllable.

[0035] Furthermore, in step A6, in order to further expand the custom microservice registration process and enhance the flexibility and controllability of the registration mechanism, the specific expansion measures are as follows: Dynamically adjust the trigger conditions of registration events based on external configuration: With the introduction of an external configuration mechanism, users can dynamically adjust the trigger conditions of registration events as needed; flexibly set the trigger conditions through configuration files or other means, and adjust them at any time according to business needs; in this way, you can dynamically change the trigger conditions of registration events according to actual conditions to adapt to different scenarios and changes in needs; Support flexible registration event definition: Provides the ability to customize registration events; through custom registration events, you can define your own registration events according to business and system requirements; you can set different registration trigger events according to specific business indicators, status changes of external systems or other conditions, and flexibly configure and adjust them as needed; Support for monitoring and management tools: Manage and monitor the custom microservice registration process, and provide corresponding tools and interfaces; through these tools, you can view the triggering conditions of registration events in real time, monitor the status and statistics of registration; at the same time, you can manage and adjust registration events and triggering conditions to ensure the normal operation of the system, and optimize and adjust as needed.

[0036] By extending the custom microservice registration process and supporting external configuration to dynamically adjust the registration event trigger conditions, the registration mechanism is made more flexible and controllable.

[0037] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for delayed registration of microservices in a container environment, characterized in that: The following steps are involved: A1: Close the microservice registration process at runtime. Based on Spring runtime enhancement capabilities, change the registration switch enable to false. A2: Customized microservice registration process. The original registration mechanism is terminated under the processing of A1 process. Once the custom microservice registrar monitors the registration event custom Register Event, the registration process is triggered, thereby achieving the effect of delayed registration. A3: Microservice registration check process; A4: Microservices and container lifecycles are aligned, and the container startup probe senses the microservice registration status; A5: Based on the microservice registration check process, a new health check mechanism is introduced to dynamically adjust the registration status by regularly checking the health status of microservices. A6: The custom microservice registration process has been expanded to support external configuration to dynamically adjust the triggering conditions of the registration event custom RegisterEvent, making the registration mechanism more flexible and controllable.

2. According to claim 1, a method for delayed registration of microservices in a container environment is characterized in that: The step A1 includes the following steps: A11: Spring Boot application starts; A12: Use the Spring Bean Post Processor[6] mechanism to change the registration switch enable to false during runtime without changing the original configuration. A13: Web Server starts and initializes. After completion, it publishes the event Servlet Web Server InitializedEvent. A14: After Spring Cloud Auto Service Registration receives the Servlet Web ServerInitialized Event event, it enters the Spring Cloud microservice registration process; A15: When executing the Spring Cloud microservice registration process, the first step is to check the registration switch enable. However, the value has been changed to false in A12. Therefore, the original Spring Cloud microservice registration process is invalid. That is, it will not be registered with the registration center immediately. The actual registration time is handled by the A2 process.

3. According to claim 1, a method for delayed registration of microservices in a container environment is characterized in that: The step A2 includes the following steps: A21: The application performs a series of custom initializations, such as application preheating, business configuration loading, and so on. After the initialization is completed, the registration event custom Register Event is published with the help of Spring Event mechanism. A22: Custom microservice registrar custom Auto Service Registration monitors specific registration events custom Register Event in real time; A23: After monitoring the event, the registration switch enable is changed to true, and then the Spring Cloud microservice registration process is executed; A24: When executing the Spring Cloud microservice registration process, the first step still checks the registration switch enable, and the value is changed to true in [S22], so the registration process can be executed normally; A25: During the execution of the custom Auto Service Registration, it is necessary to record whether it has been executed and whether the registration is successful, which is used for subsequent A3 and A4 process processing.

4. According to claim 1, a method for delayed registration of microservices in a container environment is characterized in that: A3 includes the following steps: A31: The customRegister Command Line Runner, a microservice registration checker implemented based on Spring Boot Command Line Runner, periodically checks the execution status of the custom microservice registrar custom Auto ServiceRegistration; its execution order Order is the last to ensure that other Command Line Runners are not blocked; A32: When executed is false, it blocks and rechecks periodically; A33: When it is checked that executed is true and success is false, the application is terminated, ensuring the same mechanism as the original microservice registration process of SpringCloud, that is, the application is terminated if the registration fails; A34: When both executed and success are true, the application is released and runs normally.

5. According to claim 1, a method for delayed registration of microservices in a container environment is characterized in that: A4 includes the following steps: A41: Customize the microservice registrar monitoring indicator custom Register Health Indicator and automatically integrate it into the Spring Boot Actuator Health Endpoint; this Health Indicator provides real-time feedback on whether the A2 process has been executed and whether the registration is successful; A42: When the container Pod is started, Kubelet periodically detects the container's startup probe Start Probe interface Spring Boot Actuator Health Endpoint; A43: When the S2 process fails or is not executed, the Spring Boot Actuator Health Endpoint status is not 200. If the startup probe fails, it will enter the next detection cycle. If it exceeds a certain number of times, it will restart. A44: When the S2 process is executed successfully, the Spring Boot Actuator Health Endpoint status is 200. At this time, the startup probe passes, and the container Pod starts normally and then updates the Pod status. At this time, the ready state of the microservice is aligned with the container startup ready state, which can avoid a series of problems caused by life cycle misalignment. A45: Update the Service Endpoint. The Pod can provide external services through the Service Endpoint. A46: The Deployment enters the rolling update of the next batch of Pods.

6. According to claim 1, a method for delayed registration of microservices in a container environment is characterized in that: In step A5, the implementation of the health check mechanism is not limited to the running status of microservices, but also focuses on the communication stability between services; By regularly detecting the quality of network connections between microservices, potential communication failures can be discovered in a timely manner, and fault isolation and rapid recovery can be achieved. At the same time, an adaptive algorithm is introduced to dynamically adjust the inspection frequency based on historical performance data to ensure that the system remains efficient and stable under high load. This new health check mechanism injects more intelligent elements into the robustness of the microservice architecture.

7. According to claim 1, a method for delayed registration of microservices in a container environment is characterized in that: In step A6, in order to further expand the custom microservice registration process and enhance the flexibility and controllability of the registration mechanism, the specific expansion measures are as follows: Dynamically adjust the trigger conditions of registration events based on external configuration: With the introduction of an external configuration mechanism, users can dynamically adjust the trigger conditions of registration events as needed; flexibly set the trigger conditions through configuration files or other means, and adjust them at any time according to business needs; In this way, you can dynamically change the triggering conditions of the registration event according to the actual situation to adapt to different scenarios and changes in requirements; Support flexible registration event definition: Provides the ability to customize registration events; through custom registration events, you can define your own registration events according to business and system requirements; you can set different registration trigger events according to specific business indicators, status changes of external systems or other conditions, and flexibly configure and adjust them as needed; Support for monitoring and management tools: Manage and monitor the custom microservice registration process and provide corresponding tools and interfaces; Through these tools, you can view the triggering conditions of registration events in real time, monitor the status and statistics of registration; at the same time, you can manage and adjust registration events and triggering conditions to ensure the normal operation of the system, and optimize and adjust as needed; By extending the custom microservice registration process and supporting external configuration to dynamically adjust the registration event trigger conditions, the registration mechanism is made more flexible and controllable.

Images