Smoothly migrate a Spring Cloud cluster (multi-application) to EDAS - Developer guides| Alibaba Cloud Documentation Center

Benefits of migration to EDAS

EDAS provides features for application deployment, including flexible configuration of startup parameters, process visualization, graceful service connection and disconnection, and phased release. This allows you to configure, query, and control application publishing processes.
EDAS provides the service discovery and configuration management features in its commercial release. This saves you from maintaining the middleware, such as Eureka, ZooKeeper, and Consul.
The EDAS console supports centralized service administration. This allows you to query the details of published and consumed services.
EDAS provides auto scaling. This allows you to dynamically scale your applications in or out based on traffic peaks and valleys.
In addition to instance information query, EDAS also provides advanced monitoring features, such as microservice trace query, query of the system call topology, and slow SQL query.
EDAS provides the throttling and degradation features to ensure the high availability of your applications.
EDAS provides the end-to-end phased release feature for small-scale validation when you iterate and upgrade your applications.

What is smooth migration?

Assume that your Spring Cloud cluster and its applications have been deployed in the production environment and run as expected. If you need to migrate the cluster to EDAS to have access to all the EDAS features, you can ensure service continuity through smooth migration.

Note If your Spring Cloud cluster is not deployed in the production environment or downtime migration is allowed, you can develop applications in your on-premises environment and deploy them to EDAS. For more information, see Implement service registration and discovery.

Procedure

(Required) Migrate applications
Applications to be migrated are typically stateless and can be migrated first. This topic focuses on describing how to migrate applications.
(Optional) Migrate the SLB instance or modify the domain name configuration
After the application migration is complete, you need to migrate the Server Load Balancer (SLB) instance or modify the domain name configuration.
- SLB
  - If the SLB instance is used before migration, you can reuse the SLB instance after migration.
  - If no SLB instance is used before migration, we recommend that you create and bind an SLB instance to the application (such as API Gateway in the preceding figure) after migration.
- Domain name
  - The domain name configuration can be retained if the SLB instance can be reused after migration.
  - To create and bind an SLB instance to migrated applications, you must add this SLB instance configuration to the domain name configuration and delete the original SLB instance. For more information, see Change DNS servers for a domain name.
Optional:(Optional) Migrate storage and message queues
- Applications deployed on Alibaba Cloud use Alibaba Cloud services, such as ApsaraDB RDS and Message Queue. Therefore, you do not need to migrate storage and message queues along with applications.
- If your applications are not deployed on Alibaba Cloud, submit a ticket or contact EDAS technical support to obtain a complete solution for migration to EDAS.

This topic describes how to migrate applications. If you need to smoothly migrate applications by using a demo, you can download a demo, and run a migration example based on Readme.

Migration solution

You can migrate applications by using two methods: registry switching, and dual registration and dual subscription. The two methods allow you to migrate applications during runtime without service discontinuity.

Note This topic describes the dual registration and dual subscription method.

Registry switching
Use Spring Cloud Alibaba to switch the original service registry to Nacos. Develop applications and deploy them to EDAS, and switch traffic by configuring the SLB and the domain name.

If you use the registry switching method to develop applications, see Implement service registration and discovery. You can skip the subsequent content of this topic.
Dual registration and dual subscription
Access the original service registry and the EDAS service registry when applications are migrated to enable mutual calling between migrated applications and non-migrated applications.
- Migrated applications and non-migrated applications can discover and call each other. This ensures service continuity.
- You need only to add dependencies and modify a line of code to implement dual registration and dual subscription.
- You can view the details of the list of consumer service calls, and view the migration progress in real time.
- You can dynamically modify the policies of service registration and subscription without restarting applications. Applications are restarted only once in the migration process.

Migrate the first application

Select the application to be migrated first.
We recommend that you start migration from the underlying provider. You can select an application to be migrated if the trace is complex and difficult to analyze. Migrate the selected application by performing the following steps:
Add dependencies to the application and modify its configuration.
Add dependencies to the application and modify its configuration before the application is migrated to EDAS.
1. Add the spring-cloud-starter-alibaba-nacos-discovery dependency to the pom.xml file.
```
<dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
     <version>{Version}</version>
 </dependency>                                
```
2. Add the address of Nacos Server to application.properties.
```
spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848                                
```
3. Under Spring Cloud, you can add only one registry to the dependencies in the pom.xml file by default. When you try to add multiple registries, an error may be returned. To support multiple registries under Spring Cloud, add the edas-sc-migration-starter dependency.
```
<dependency>
     <groupId>com.alibaba.edas</groupId>
     <artifactId>edas-sc-migration-starter</artifactId>
     <version>1.0.5</version>
 </dependency>                                
```
4. To allow an application to subscribe to services from multiple registries, you must modify the configuration of Ribbon that is used for load balancing. In the main class of application startup, set RibbonClients to MigrationRibbonConfiguration.
  Assume that the following main class code is available:
```
@SpringBootApplication
 public class ConsumerApplication {
     public static void main(String[] args) {
         SpringApplication.run(ConsumerApplication.class, args);
     }
 }                                
```
  The following code is the modified main class code:
```
@SpringBootApplication
 @RibbonClients(defaultConfiguration = MigrationRibbonConfiguration.class)
 public class ConsumerApplication {
     public static void main(String[] args) {
         SpringApplication.run(ConsumerApplication.class, args);
     }
 }                                
```
  Note
  After applications are modified in your on-premises environment or deployed to EDAS, you can manage the applications. For example, you can register the applications to specific registries or subscribe to services from specific registries. To meet the requirements, use Spring Cloud Config or Nacos Config to dynamically adjust the configurations of the applications. In this case, you do not need to restart applications. For more information, see Dynamically adjust service registries and service subscription policies.
  
  To use Spring Cloud Config or Nacos Config, you must add the configuration management dependency to the applications and modify related configuration. When you use Spring Cloud Config, see open source documentation. When you use Nacos Config, see Manage application configurations.
Deploy the modified application to EDAS.
You can deploy the application to an ECS cluster or a Container Service for Kubernetes cluster based on your requirements. You can use the EDAS console or the related tool to deploy the application. For more information, see Create and deploy applications (Kubernetes) and Overview.
- We recommend that you reuse the existing ECS instance by importing the instance to EDAS. This saves costs. For more information, see Create an ECS cluster by using the console.
- If you do not reuse the existing ECS instance, you must create an ECS instance, a cluster, and other resources in the existing virtual private cloud (VPC). This makes the network between applications before and after migration connected so that applications can be migrated. For more information, see Manage ECS-related resources.
- Configure an IP address whitelist for the new ECS instance in products, such as a database, cache, and message queue, to ensure normal access to the application-dependent third-party components.
Verify the result.
1. Check whether services are normal.
2. View data about service subscription monitoring.
  If Spring Boot Actuator is enabled for the application, you can access Actuator to view the information about RibbonServerList of each application-subscribed service. You can access Actuator in the following URLs:
  - Spring Boot 1.x: http://ip:port/migration_server_list
  - Spring Boot 2.x: http://ip:port/actuator/migration-server-list
  The serverGroup field in metaInfo indicates the service registry for the node.

Migrate all the other applications

Migrate the other applications to EDAS by repeating the procedure of migrating the first application.

Clear the migration configuration

After migration, delete the original registry configuration and the edas-sc-migration-starter dependency that is used by migration, and restart applications in batches during off-peak hours.

edas-sc-migration-starter is a starter that is dedicated to migration. If you use the starter for a long time, it does not affect service stability. However, the starter limits the load balancing effect of Ribbon. We recommend that you clear the starter after migration and restart applications in batches during off-peak hours.

Dynamically adjust service registries and service subscription policies

You can dynamically adjust service registries and service subscription policies during migration by using the configuration management feature of EDAS.

Dynamically adjust the service subscription policy
The default subscription policy is to subscribe from all the registries and aggregate data.

To subscribe to data from specific registries, you can use the configuration management feature of EDAS to modify the spring.cloud.edas.migration.subscribes property.
```
spring.cloud.edas.migration.subscribes=nacos,eureka # Subscribes to services from Eureka and Nacos.

spring.cloud.edas.migration.subscribes=nacos        # Subscribes to services only from Nacos.                    
```
Dynamically adjust service registries
The default registration policy is to register with all the registries.

You can adjust service registries by using the configuration management feature of EDAS.

Specify the registry that you want to disable by using the spring.cloud.edas.migration.registry.excludes property.
```
spring.cloud.edas.migration.registry.excludes=   # The default value is Null. The value indicates registration with all the service registries.

spring.cloud.edas.migration.registry.excludes=eureka   # Disables registration with Eureka.

spring.cloud.edas.migration.registry.excludes=nacos,eureka   # Disables registration with Nacos and Eureka.                    
```
Assume that you need to dynamically modify the registries to which an application is registered when the application is running. You can use the Spring Cloud configuration management feature to modify the property at run time.