Cloud Native 11 min read

Migrating Service Registry from Eureka to Nacos with Dual Registration and Subscription in Spring Cloud Alibaba

This article demonstrates how to migrate a Spring Cloud microservice architecture from Eureka to Nacos using a dual‑registration/dual‑subscription model, covering configuration changes, code adjustments, graceful shutdown, load‑balancing behavior, and step‑by‑step deployment procedures.

Code Ape Tech Column
Code Ape Tech Column
Code Ape Tech Column
Migrating Service Registry from Eureka to Nacos with Dual Registration and Subscription in Spring Cloud Alibaba

Hello everyone, I am Chen. My "Spring Cloud Alibaba Practical Project" video tutorial is now complete, covering various Alibaba middleware implementations.

Why Migrate?

Nacos offers a configuration center, management UI, manual up/down‑line, and a real‑time service‑list push mechanism, making it more advanced than Eureka, which lacks these features and only supports AP mode without strong consistency guarantees.

Nacos provides both configuration management and service discovery with push notifications.

Eureka 1.x uses a pull‑based model, only supports AP, and cannot guarantee consistency; Nacos supports both AP and CP.

Spring Cloud announced the deprecation of Netflix components after 2019, and Eureka entered maintenance mode.

Eureka 2.x development was abandoned years ago and is not recommended for production.

Eureka Registration Center

A typical Eureka setup consists of three modules:

Registration Center: choose Eureka Server .

Provider: add Eureka Discovery Client and Spring Web .

Consumer: add Eureka Discovery Client and Spring Web .

Start the registration center, then the provider, and finally the consumer.

Dual Registration & Dual Subscription Mode

Clone the provider and consumer modules, add both Nacos and Eureka dependencies in pom.xml, and you will encounter an auto‑configuration conflict:

Field autoServiceRegistration in org.springframework.cloud.client.serviceregistry.AutoServiceRegistrationAutoConfiguration required a single bean, but 2 were found:
 - nacosAutoServiceRegistration ...
 - eurekaAutoServiceRegistration ...

Resolve it by excluding the conflicting auto‑configurations in application.properties:

# Disable dual‑registration auto‑config
spring.autoconfigure.exclude=org.springframework.cloud.client.serviceregistry.AutoServiceRegistrationAutoConfiguration,org.springframework.cloud.client.serviceregistry.ServiceRegistryAutoConfiguration

After exclusion, both Eureka and Nacos clients are created, and services are registered to both registries.

Small Experiment

Launch a new consumer that subscribes to both registries. By default, Nacos is queried first; if the service is found, Eureka is never consulted, which explains the lack of load‑balancing across both registries.

When the Nacos instance is taken offline, the consumer automatically falls back to Eureka without delay, thanks to Nacos's push‑based service‑list updates.

Graceful Shutdown

Use Spring Boot Actuator to perform graceful shutdown. Add the following configuration (available from Spring Boot 2.3):

# Graceful shutdown
server.shutdown=graceful
# Shutdown timeout
spring.lifecycle.timeout-per-shutdown-phase=20s

management.endpoints.web.exposure.include=service-registry

Expose the actuator endpoint and change the service status to DOWN via a POST request:

curl -X "POST" "http://localhost:8771/actuator/serviceregistry?status=down" -H "Content-Type: application/vnd.spring-boot.actuator.v2+json;charset=UTF-8"

After a short wait, the consumer refreshes its service list, and traffic shifts away from the stopped provider.

Deploying the New Consumer

Start the new dual‑subscription consumer, verify it receives traffic from Nacos first, then from Eureka if Nacos does not have the service.

Final Migration Steps

Once the new version is stable, sequentially shut down the old provider, the dual‑subscription consumer, and finally the Eureka server, optionally routing traffic through Nginx during the transition.

Overall Process

The migration follows a blue‑green/gray‑release style: bring up the new version, wait for stability, then retire the old version.

Summary

The code changes are minimal thanks to Spring Cloud's unified service‑registration API.

When using dual registration, remember to exclude the conflicting auto‑configuration; traffic will primarily flow through Nacos.

Nacos offers convenient up/down‑line operations and real‑time service‑list push, which eases migration.

Spring Boot's graceful shutdown prevents abrupt termination; avoid using kill -9 .

Source code: https://github.com/Java4ye/springcloud-alibaba-demo-4ye

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Microservicesservice discoveryNacosSpring CloudGraceful Shutdown
Code Ape Tech Column
Written by

Code Ape Tech Column

Former Ant Group P8 engineer, pure technologist, sharing full‑stack Java, job interview and career advice through a column. Site: java-family.cn

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.