Smoothly migrate a Spring Cloud cluster (multi-application) to EDAS

Benefits of migrating to EDAS

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

What is smooth migration?

You can ensure service continuity through smooth migration when you migrate your Spring Cloud cluster in the normal running state from the production environment to EDAS for access to all functions provided by EDAS.

Migration process

The following figure shows a typical application architecture, in which migration is divided into three steps.

1. (Required) Migrate applications

   Applications to be migrated are typically stateless and can be migrated first. Migrating applications is our focus in this topic.

2. (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
     • You can reuse the existing SLB instance after migration. You can select a policy for binding an SLB instance as needed. For more information, see Overview.
     • If no SLB instance is used before migration, we recommend that you create and bind an SLB instance to the ingress application (such as API Gateway in the preceding figure) after migration.
     • We recommend that you enable dual registration and dual subscription when migrating applications to reduce the costs of using Elastic Compute Service (ECS). If the existing ECS instance cannot be reused due to reasons such as occupation of the ECS port, you need to adopt the registry switching solution and add new ECS instances. After application migration is complete, reuse the existing SLB instance or create and bind an SLB instance as needed.
   • 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 need to add this SLB instance configuration to the domain name configuration and delete the old SLB instance. For more information, see Change DNS servers for a domain name.
3. (Optional) Migrate storage and message queues
   • Applications deployed on Alibaba Cloud use Alibaba Cloud products, such as ApsaraDB for RDS and Message Queue (MQ). Therefore, you do not need to migrate storage and message queues along with applications.
   • If your applications are not deployed on Alibaba Cloud, open a ticket or contact EDAS Customer Services to obtain a complete solution for migrating to EDAS.

This topic describes how to migrate applications. You can smoothly migrate applications by using this demo and running a migration example based on Readme.

Migration solution

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

• Registry switching

  Switch the old service registry to Nacos through Spring Cloud Alibaba. Develop applications and deploy them to EDAS, and switch traffic through SLB and domain name configuration.

  If you use the registry switching method, you can develop applications by following the instructions in Host Spring Cloud applications to EDAS.

• Dual registration and dual subscription

  Access the old service registry and the EDAS service registry when migrating applications to enable mutual calling between migrated applications and non-migrated applications.

  The following figure shows the architecture of smooth migration through dual registration and dual subscription.

  • Migrated applications and non-migrated applications can discover and call each other, ensuring service continuity.
  • You simply need to add dependencies and modify a line of code.
  • You can view the details of a consumer service call list and 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 during the migration process.

Migrate the first application

1. Select the application to be migrated first.
   We recommend that you start migration from the underlying provider. You can select any application to be migrated first if the trace is complex and difficult to analyze. Migrate the selected application as follows.
2. Add dependencies to the application and modify its configuration.
   Add dependencies to the application and modify its configuration before hosting it 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 pom.xml by default. An error may be returned when you try to add multiple registries. 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.2</version>
       </dependency>                                

   4. To allow an application to subscribe to services from multiple registries, you need to modify the configuration of Ribbon, which is used for load balancing. In the main class of application startup, set RibbonClients to MigrationRibbonConfiguration.
      Assume that the main class code is as follows:

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

      The modified main class code is as follows:

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

      Note

      You can control applications after they are locally modified or deployed to EDAS, such as registering the applications to specific registries or subscribing to services from specific registries. To do so, dynamically adjust configuration through Spring Cloud Config or Nacos Config by following the instructions in Dynamically adjust service registries and service subscription policies. Application restart is not required.

      To use Spring Cloud Config or Nacos Config, you need to add the configuration management dependency to the applications and modify related configuration. When using Spring Cloud Config, see open-source documentation. When using Nacos Config, see Implement configuration management.

3. Deploy the modified application to EDAS
   You can deploy the application to an ECS cluster or a Container Service for Kubernetes cluster as needed, by using the EDAS console or related tool. For more information, see Overview of application deployment.

   • We recommend that you reuse the existing ECS instance by importing it to EDAS to save costs. For more information, see Create an ECS cluster.
   • 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) to ensure network interoperability between applications before and after migration. For more information, see Create resources
   • Configure an IP address whitelist for the new ECS instance in database, cache, and message queue products to ensure normal access to the application-dependent third-party components.
4. Verify the result.
   1. Check whether services are normal.
   2. View service subscription monitoring data.
      If Spring Boot Actuator is enabled for the application, you can access Actuator to view 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 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 old registry configuration and the edas-sc-migration-starter dependency used by migration, and restart applications in batches during idle hours.

edas-sc-migration-starter does not affect service stability but it limits the load balancing effect of Ribbon. We recommend that it be cleared after migration.

Dynamically adjust service registries and service subscription policies

You can dynamically adjust service registries and service subscriptions during migration by using the configuration management function of EDAS.

• Dynamically adjust the service subscription policy

  The default subscription policy is to subscribe from all registries and aggregate data.

  You can choose to subscribe data from specific registries by modifying the spring.cloud.edas.migration.subscribes property through the configuration management function of EDAS.

  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 registries.

  You can adjust service registries through the configuration management function of EDAS.

  Specify the registry you want to disable through the spring.cloud.edas.migration.registry.excludes property.

  spring.cloud.edas.migration.registry.excludes=   #The default value is Null, which indicates registration with all 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.                    

  To dynamically modify the registries to which an application is registered when running, you can use the Spring Cloud configuration management function to modify the preceding property at runtime.

Migration help

If an exception occurs during the migration process, join DingTalk group for help.