A non-intrusive method and system for automatically registering Zipkin services to Nacos

Abstract

This invention discloses a non-intrusive method and system for automatically registering Zipkin services to Nacos, belonging to the field of distributed microservice governance and distributed tracing technology, and applied to the Spring Cloud microservice architecture. Addressing the issue that Zipkin, by default using the Armeria web server, cannot adapt to Spring Cloud's native automatic registration logic, this invention constructs a service registration listener that listens for Zipkin startup completion events. After the service is ready, it proactively obtains instance information and calls the Nacos client interface to complete automatic registration. This solution requires no modification to the Zipkin core code, adapts to Zipkin's default deployment method, achieves non-intrusive integration, and supports encrypted configuration, multi-environment isolation, and containerized dynamic configuration, effectively reducing deployment and maintenance costs.

Description

Technical Field

[0001] This invention belongs to the field of distributed microservice governance and distributed tracing technology, specifically relating to a non-intrusive method and system for automatically registering Zipkin services to Nacos. Background Technology

[0002] With the widespread adoption of microservice architecture, distributed systems are broken down into multiple independently deployed microservice instances. To achieve automatic service discovery and unified configuration management, Spring Cloud Alibaba Nacos, as a core component integrating service registry and configuration center functions, is widely used in microservice architectures. Meanwhile, to troubleshoot microservice call chain anomalies and locate performance bottlenecks, Zipkin, as a mainstream open-source distributed tracing system, is often integrated into microservice systems to collect, store, and display end-to-end call data between microservices.

[0003] The standard service auto-registration capabilities provided by Spring Cloud (such as the registration logic implemented by the @EnableDiscoveryClient annotation) only support services deployed using standard Servlet containers such as Tomcat and Jetty. However, ZipkinServer is officially deployed using Armeria Web Server by default, which cannot adapt to Spring Cloud's native auto-registration logic and cannot directly register services with Nacos.

[0004] Currently, the solutions to this problem mainly fall into two categories: one is to deploy an additional independent registration proxy service, which handles the registration of Zipkin service with Nacos on behalf of Zipkin. This solution requires additional operation and maintenance of proxy nodes, increasing system complexity and the risk of single point of failure. The other is to modify the core startup code of Zipkin, replacing its web server with Tomcat or manually adapting the registration logic. This solution requires intrusive modification of the native Zipkin code, and subsequent Zipkin version upgrades require re-adaptation, resulting in high maintenance costs. Summary of the Invention

[0005] To address the problems mentioned above, this invention proposes a non-intrusive method and system for automatically registering Zipkin services to Nacos. This solves the problems of Zipkin's default Armeria web server being incompatible with Spring Cloud's native automatic registration logic, existing solutions requiring additional registration agents increasing system complexity and single point-of-failure risks, and the high cost of version upgrades and maintenance due to intrusive modifications to the Zipkin core code. The invention achieves non-intrusive automatic registration of Zipkin services to the Nacos registry, achieving a microservice tracing service governance effect that adapts to the official default deployment mode, reduces operational and maintenance costs, and balances security capabilities with deployment flexibility.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: A non-intrusive method for automatically registering Zipkin services to Nacos, applied to a Spring Cloud microservice architecture, includes the following steps: S1. Configure Nacos basic connection parameters, which are used to establish a communication connection with Nacos; S2. Construct a service registration listener, which is used to listen for the startup completion event of the Zipkin service, and the service registration listener is configured to obtain the instance information of the current Zipkin service after listening for the startup completion event. The instance information includes at least the host IP where the service is located, the service listening port, and the service identifier name. S3. Register the service registration listener and Nacos configuration parsing component to the Spring context loading chain of the Zipkin service, so that the initialization of the service registration listener and Nacos configuration parsing component is completed when the Zipkin service starts. S4. The service registration listener calls the service registration interface provided by the Nacos client to send the instance information to Nacos, thus completing the automatic registration of the Zipkin service.

[0007] Specifically, before step S1, there is also a dependency adaptation step: excluding the native Nacos client that comes with the Spring Cloud Alibaba Nacos component and introducing a Nacos client that is compatible with the Zipkin runtime environment.

[0008] Specifically, in step S1, the Nacos basic connection parameters include at least the Nacos service address, access username, access password, and namespace identifier; the namespace identifier is used to register and isolate Zipkin services in different operating environments.

[0009] Specifically, in step S2, the service listening port and service identifier name are read from the environment variables of the Zipkin service's runtime environment.

[0010] Specifically, step S1 also includes: configuring remote configuration import rules so that the Zipkin service pulls the remaining running configuration from the Nacos side when it starts.

[0011] Specifically, the remote configuration import rule is configured to pull Zipkin service-specific configuration files and public shared configuration files from a specified configuration group in Nacos.

[0012] Specifically, in step S2, the instance information also includes custom metadata, which is sent to Nacos storage along with the instance information for service filtering and routing policy configuration.

[0013] Specifically, the dependency adaptation step further includes: introducing the Nacos encryption plugin dependency, which is used to automatically encrypt and decrypt the configuration content and service metadata transmitted to Nacos.

[0014] A non-intrusive system for automatically registering a Zipkin service to Nacos, employing the aforementioned method for automatically registering a Zipkin service to Nacos, the system comprising: The configuration module is used to store basic Nacos connection parameters; The listener module is used to listen for the Zipkin service startup completion event. After the event is triggered, the instance information of the current Zipkin service is obtained. The registration execution module is used to call the service registration interface of the Nacos client and send the instance information to Nacos to complete the registration; The configuration loading module is used to register the listener module and Nacos configuration parsing component into the Spring context loading chain of the Zipkin service.

[0015] In summary, the beneficial technical effects of the present invention are as follows: 1. Adaptation to native deployment mode: This invention completely bypasses Spring Cloud's native automatic registration dependency on standard Servlet containers such as Tomcat and Jetty by customizing the independent registration logic for listening to Zipkin startup completion events. It does not require replacing Zipkin's default Armeria web server or modifying the core Zipkin startup code. Integration can be completed solely based on Spring's extension mechanism. Subsequent Zipkin version upgrades only require adapting the dependency version, without adjusting the core registration logic, thus reducing long-term maintenance costs.

[0016] 2. Simple and stable architecture with no additional node overhead: This invention can complete automatic registration without the need to deploy an independent registration agent service, avoiding the operation and maintenance costs and single point of failure risks of agent nodes. The system architecture is simpler and the operation stability is higher.

[0017] 3. Multi-scenario adaptation and high deployment flexibility: This invention supports dynamic configuration of service identifiers and listening ports through environment variables, adapting to containerized deployment scenarios such as Docker and Kubernetes; it supports service registration isolation in multiple environments such as development, testing, and production through Nacos namespaces, avoiding service confusion in different environments; it supports pulling remote configurations from Nacos, achieving unified configuration management without the need to modify the local configuration of each Zipkin instance, resulting in higher operation and maintenance efficiency. Attached Figure Description

[0018] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a schematic diagram of the system architecture interaction corresponding to the present invention; Figure 3 This is a schematic diagram of the Maven dependency structure for invention. Detailed Implementation

[0019] To make the technical means, creative features, objectives and effects of this invention clearer and easier to understand, the invention will be further described below in conjunction with the accompanying drawings and specific embodiments.

[0020] Example The operating environment of this embodiment is based on: JDK 11 or above, Spring Cloud Alibaba 2021.0.5.0 as the microservice development framework, Nacos Server 2.5.1 or above as the service registry and configuration center, Zipkin Server 2.27.1 as the distributed tracing service, and Zipkin Server is deployed using the official default Armeria Web server without modifying the core Zipkin startup code.

[0021] like Figure 1 As shown, the method for automatically registering a non-intrusive Zipkin service to Nacos provided by this invention is specifically implemented as follows: S0, Dependency Adaptation.

[0022] To resolve the version conflict between the native Nacos client included with the Spring Cloud Alibaba Nacos component and the current Zipkin 2.27.1 runtime environment, the Maven dependencies were first adapted and adjusted. The dependency structure can be found in the following reference. Figure 3 .

[0023] In the pom.xml configuration file of the Zipkin service project, import the official Spring Cloud Nacos service discovery component spring-cloud-starter-alibaba-nacos-discovery (version 2021.0.5.0). Under the exclusions tag of this dependency, exclude two conflicting dependencies: the first is the native Nacos client dependency with groupId com.alibaba.nacos and artifactId nacos-client, and the second is the log conflicting dependency with groupId org.slf4j and artifactId slf4j-simple.

[0024] We introduce the official Nacos configuration center component from Spring Cloud, spring-cloud-starter-alibaba-nacos-config (version 2021.0.5.0). Similarly, under the exclusions tag of this dependency, we exclude the native Nacos client dependency with groupId com.alibaba.nacos and artifactId nacos-client.

[0025] After eliminating native dependencies, a customized version of nacos-client (version 2.5.1_starmo in this embodiment) adapted to the current Zipkin runtime environment is introduced. At the same time, Nacos encryption plugin dependencies are introduced: nacos-starmo-encryption-plugin and nacos-starmo-encryption-plugin-client (version 1.0.0 in this embodiment), which are used for automatic encryption and decryption of configuration content and service metadata transmitted to Nacos in the future.

[0026] S1. Configure basic Nacos connection parameters.

[0027] After completing dependency adaptation, configure the Nacos basic connection parameters. These parameters are used to establish a communication connection between the Zipkin service and the Nacos service. In this embodiment, the Nacos basic connection parameters are stored in the local configuration file `zipkin-server.yml` of the Zipkin service. They can also be injected through operating system environment variables, service startup parameters, etc., depending on the deployment scenario (e.g., Docker, Kubernetes containerized deployment). The parameters include at least the following: (1) Nacos service address server-addr: The format is the IP address of the host where the Nacos service is deployed plus the port number; (2) Nacos access username: The login account assigned to the Nacos service; (3) Nacos access password: The login password corresponding to the access username; (4) Namespace identifier: A unique ID for a namespace pre-created in the Nacos service. Different runtime environments (development, testing, production) correspond to different namespace IDs, which are used to register and isolate Zipkin services in different runtime environments to avoid confusion in cross-environment service calls.

[0028] Furthermore, remote configuration import rules can be configured according to requirements: add two import paths to the spring.config.import configuration item of zipkin-server.yml, namely optional:nacos:zipkin-server.yml and optional:nacos:zipkin-server-shared.yml. This allows the Zipkin service to pull the Zipkin service-specific configuration file and the public shared configuration file under the corresponding namespace from the DEFAULT_GROUP configuration group of Nacos when it starts up, and use them as the remaining runtime configuration. This eliminates the need to store all runtime configurations locally, achieving unified configuration management.

[0029] S2, Construct a service registration listener.

[0030] After completing the parameter configuration, construct the service registration listener. In this embodiment, the service registration listener is an implementation of the Spring framework's ApplicationListener. <applicationreadyevent>The Java class for the interface is named NacosDirectRegistration. The listener listens for the Spring framework's ApplicationReadyEvent event. This event is triggered after the Zipkin service has completed the initialization of all built-in components (including the Armeria web server, link data storage component, call chain query interface, etc.) and is ready to provide services to the outside world. This prevents unready Zipkin instances from being registered with Nacos to receive traffic.

[0031] The service registration listener is configured to automatically obtain the instance information of the current Zipkin service after listening for the startup completion event. The specific acquisition logic is as follows: The IP address of the host where the Zipkin service is located can be automatically obtained using the InetAddress utility class built into the Spring framework. The service listening port and service identifier name are first read from the environment variables of the Zipkin service's runtime environment. In this embodiment, the corresponding environment variables are SERVER_PORT and ZIPKIN_SERVICE_NAME, respectively. If the corresponding environment variables are not detected, the default port and default service name configured in the local configuration file are read. The final instance information obtained includes at least the host IP address where the service is located, the service listening port, and the service identifier name.

[0032] Furthermore, custom metadata can be added according to management needs, such as the Zipkin service version number, the business line identifier, and the deployment cluster identifier. Custom metadata is sent to Nacos storage along with instance information for subsequent service filtering and routing strategy configuration.

[0033] S3. Register the service registration listener and Nacos configuration parsing component to the Spring context loading chain of the Zipkin service.

[0034] Component loading logic corresponding Figure 2 The system architecture interaction diagram shown illustrates that, specifically, the Nacos configuration parsing component is the NacosConfigProperties class provided by Spring Cloud Alibaba Nacos. Its function is to automatically parse the basic Nacos connection parameters configured in step S1. Utilizing Spring's native @Import extension mechanism, the parameter list of the @Import annotation in the official Zipkin startup configuration class InternalZipkinConfiguration is expanded to include NacosConfigProperties.class and the custom service registration listener class NacosDirectRegistration.class constructed in step S2. This requires no modification to other existing code in the InternalZipkinConfiguration class and does not intrude on the core Zipkin startup logic.

[0035] After completing the above configuration, when the Zipkin service starts, the Spring context will automatically initialize two types of components while loading the native configuration: one is the NacosConfigProperties instance, which completes the parsing and validation of all Nacos basic connection parameters; the other is the NacosDirectRegistration instance, which is the service registration listener, and starts listening for the Zipkin service startup completion event after initialization.

[0036] S4. The service registration listener calls the service registration interface provided by the Nacos client to send the instance information to Nacos, thus completing the automatic registration of the Zipkin service.

[0037] When the Zipkin service completes the initialization of all built-in components, including the Armeria web server, the linked data storage component, and the call chain query interface, and is ready to provide services, the Spring framework triggers the ApplicationReadyEvent startup completion event. Upon hearing this event, the service registration listener executes the registration operation according to the following logic: (1) Read all the basic Nacos connection parameters configured in step S1 from the NacosConfigProperties instance that has been initialized, including Nacos service address, access username, access password and namespace identifier; (2) Call the static method createNamingService of the com.alibaba.nacos.api.naming.NamingFactory class provided by the Nacos client, pass in the read Nacos basic connection parameters, and construct a NamingService instance. This instance is the native service registration operation entry point of the Nacos client. (3) Construct the com.alibaba.nacos.api.naming.pojo.Instance instance object provided by the Nacos client, and fill the host IP where the service is located, the service listening port, and the service identifier name obtained in step S2 into the corresponding properties of the Instance object; if custom metadata is configured in step S2, fill the custom metadata into the metadata property of the Instance object in the form of key-value pairs; (4) Call the registerInstance interface of the NamingService instance, and pass in the service identifier name, namespace identifier, and the constructed Instance object in sequence. The Nacos client will automatically send the instance data to the corresponding Nacos server to complete the service registration.

[0038] Meanwhile, since the Nacos encryption plugin dependency was introduced in the previous dependency adaptation steps, the encryption plugin will automatically take effect at this time: it encrypts the sensitive metadata contained in the Instance object before transmitting it to the Nacos server, and automatically decrypts the remote configuration content pulled from Nacos later, without the need to write additional encryption and decryption logic, thus avoiding the leakage of sensitive information.

[0039] After registration, the Nacos console under the corresponding namespace can query the instance information of the Zipkin service. Operations personnel can filter services based on custom metadata, and can also implement extended governance functions such as cluster deployment and canary traffic routing of Zipkin services based on Nacos' service discovery capabilities.

[0040] Therefore, this invention provides a non-intrusive method and system for automatically registering Zipkin services to Nacos. The core logic involves constructing a custom service registration listener to monitor the Zipkin service startup completion event, non-intrusively registering the listener and Nacos configuration parsing component to the Spring context loading chain, and actively calling the Nacos client's native interface to complete registration after the service is ready. Combined with optional Nacos dependency version adaptation, encrypted plugin integration, custom metadata enhancement, dynamic environment variable parameter configuration, and namespace isolation, this invention solves the native compatibility issues of Spring Cloud's automatic registration logic, which only supports standard Servlet containers such as Tomcat and Jetty and cannot adapt to the default Armeria server used by Zipkin. It also avoids the increased system complexity and single-point-of-failure risk caused by additional registration agent deployment in existing solutions, as well as the high version upgrade and maintenance costs resulting from intrusive modifications to the Zipkin core code. This approach retains the advantages of unaffected native Zipkin functionality and compatibility with the official default deployment mode, while also providing capabilities for encrypted transmission of configuration and metadata, multi-environment registration isolation, and flexible containerized deployment. This makes it suitable for Spring Cloud applications. Distributed tracing service governance under the cloud microservice architecture provides low operation and maintenance costs, high stability, and security compliance with automatic registration support.

[0041] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. The above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.< / applicationreadyevent>

Claims

1. A non-intrusive method for automatically registering Zipkin services to Nacos, applied to a Spring Cloud microservice architecture, characterized in that... Includes the following steps: S1. Configure Nacos basic connection parameters, which are used to establish a communication connection with Nacos; S2. Construct a service registration listener, which is used to listen for the startup completion event of the Zipkin service, and the service registration listener is configured to obtain the instance information of the current Zipkin service after listening for the startup completion event. The instance information includes at least the host IP where the service is located, the service listening port, and the service identifier name. S3. Register the service registration listener and Nacos configuration parsing component to the Spring context loading chain of the Zipkin service, so that the initialization of the service registration listener and Nacos configuration parsing component is completed when the Zipkin service starts. S4. The service registration listener calls the service registration interface provided by the Nacos client to send the instance information to Nacos, thus completing the automatic registration of the Zipkin service.

2. The method for automatically registering a non-intrusive Zipkin service to Nacos according to claim 1, characterized in that, Before step S1, there is also a dependency adaptation step: excluding the native Nacos client that comes with the Spring Cloud Alibaba Nacos component and introducing a Nacos client that is compatible with the Zipkin runtime environment.

3. The method for automatically registering a non-intrusive Zipkin service to Nacos according to claim 1, characterized in that, In step S1, the Nacos basic connection parameters include at least the Nacos service address, access username, access password, and namespace identifier; the namespace identifier is used to register and isolate Zipkin services in different operating environments.

4. The method for non-intrusive automatic registration of Zipkin service to Nacos according to claim 1, characterized in that, In step S2, the service listening port and service identifier name are read from the environment variables of the Zipkin service's runtime environment.

5. The method for automatically registering a non-intrusive Zipkin service to Nacos according to claim 1, characterized in that, Step S1 also includes: configuring remote configuration import rules so that the Zipkin service pulls the remaining runtime configuration from the Nacos side when it starts.

6. The method for automatically registering a non-intrusive Zipkin service to Nacos according to claim 5, characterized in that, The remote configuration import rule is configured to pull Zipkin service-specific configuration files and public shared configuration files from a specified configuration group in Nacos.

7. The method for automatically registering a non-intrusive Zipkin service to Nacos according to claim 1, characterized in that, In step S2, the instance information also includes custom metadata, which is sent to Nacos storage along with the instance information for service filtering and routing policy configuration.

8. A method for automatically registering a non-intrusive Zipkin service to Nacos according to claim 2, characterized in that, The dependency adaptation step also includes: introducing the Nacos encryption plugin dependency, which is used to automatically encrypt and decrypt the configuration content and service metadata transmitted to Nacos.

9. A non-intrusive system for automatically registering Zipkin services to Nacos, applied to a Spring Cloud microservice architecture, characterized in that... The system employs a non-intrusive Zipkin service automatic registration method to Nacos according to any one of claims 1-8, the system comprising: The configuration module is used to store basic Nacos connection parameters; The listener module is used to listen for the Zipkin service startup completion event. After the event is triggered, the instance information of the current Zipkin service is obtained. The registration execution module is used to call the service registration interface of the Nacos client and send the instance information to Nacos to complete the registration; The configuration loading module is used to register the listener module and Nacos configuration parsing component into the Spring context loading chain of the Zipkin service.

Images