Enterprise Distributed Application Service:Migrate a multi-application Spring Cloud cluster to EDAS

Why migrate to EDAS

EDAS replaces the operational overhead of self-managed Spring Cloud infrastructure with a managed platform. After migration:

• Flexible deployment -- Configure startup parameters, track deployment progress visually, and use graceful service connection and disconnection to avoid dropped requests.

• Built-in service discovery -- EDAS provides service discovery and configuration management in its commercial release, replacing self-managed Eureka, ZooKeeper, or Consul.

• Centralized service administration -- Query published and consumed services from the EDAS console. In addition to instance information query, access microservice traces, system call topology, and slow SQL analysis.

• Auto scaling -- Dynamically scale application instances in or out based on traffic.

• Phased releases -- Run end-to-end phased releases for small-scale validation before rolling out updates to all instances.

• Throttling and degradation -- Apply throttling and service degradation to maintain application stability under heavy load.

Choose a migration method

EDAS supports two migration methods. Both preserve service continuity.

If you choose registry switching, follow the standard setup in Implement service registration and discovery. The rest of this guide covers dual registration and dual subscription.

Migration overview

The migration consists of three phases:

1. Migrate applications (required) -- Stateless applications are migrated first, one at a time.

2. Migrate the Server Load Balancer (SLB) instance or update DNS (optional) -- Point traffic to the new deployment.

3. Migrate storage and message queues (optional) -- Only needed if your applications are not already using Alibaba Cloud services like ApsaraDB RDS and Message Queue.

This guide focuses on phase 1.

Phase 1: Migrate applications

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    <version>{Version}</version>
</dependency>

spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848
ribbon.nacos.enabled=false

<dependency>
    <groupId>com.alibaba.edas</groupId>
    <artifactId>edas-sc-migration-starter</artifactId>
    <version>1.0.5</version>
</dependency>

@SpringBootApplication
public class ConsumerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args);
    }
}

@SpringBootApplication
@RibbonClients(defaultConfiguration = MigrationRibbonConfiguration.class)
public class ConsumerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args);
    }
}

Phase 2: Migrate the SLB instance or update DNS (optional)

After all applications are migrated, update network routing:

• If an SLB instance was used before migration, reuse it.

• If no SLB instance was used, create one and bind it to your entry-point application (for example, API Gateway).

• Domain name configuration:

  • If the SLB instance is reused, no DNS changes are needed.

  • If a new SLB instance is created, update DNS to point to the new SLB instance and remove the old one. See Change DNS servers for a domain name.

Phase 3: Migrate storage and message queues (optional)

If your applications already use Alibaba Cloud services such as ApsaraDB RDS and Message Queue, no storage or message queue migration is needed.

If your applications are not on Alibaba Cloud, contact EDAS technical support for a complete migration plan.

Dynamically adjust registration and subscription policies

During migration, you can adjust which registries an application registers with or subscribes to -- without restarting. Use the EDAS configuration management feature, Spring Cloud Config, or Nacos Config to update the following properties at runtime.

# Subscribe to both Eureka and Nacos
spring.cloud.edas.migration.subscribes=nacos,eureka

# Subscribe to Nacos only
spring.cloud.edas.migration.subscribes=nacos

# Register with all registries (default)
spring.cloud.edas.migration.registry.excludes=

# Stop registering with Eureka
spring.cloud.edas.migration.registry.excludes=eureka

# Stop registering with both Nacos and Eureka
spring.cloud.edas.migration.registry.excludes=nacos,eureka

Post-migration cleanup

After all applications are running on EDAS, remove the migration-specific configuration:

1. Delete the edas-sc-migration-starter dependency from each application's pom.xml (or build.gradle).

2. Remove the @RibbonClients(defaultConfiguration = MigrationRibbonConfiguration.class) annotation from the main class.

3. Remove the original service registry dependency and configuration (for example, Eureka or Consul client settings).

4. Remove ribbon.nacos.enabled=false from application.properties.

5. Restart applications in batches during off-peak hours.

Demo project

EDAS provides a sample project that demonstrates dual registration and dual subscription. Download the project and follow the included README to run it locally.