Smoothly migrate a Dubbo application to EDAS

Benefits of migrating to EDAS

• EDAS provides features for application deployment, such as flexible startup parameter configuration, process visualization, graceful service publishing and unpublishing, and phased releases. These features make your application releases configurable, traceable, and controllable.

• EDAS provides service discovery and configuration management. You do not need to maintain middleware components such as Eureka, ZooKeeper, or Consul. You can directly use the commercial service discovery and configuration management features provided by EDAS.

• The EDAS console provides unified service administration. You can query the details of published and consumed services.

• EDAS provides dynamic scale-out and scale-in features. You can scale your application in or out in real time based on traffic peaks and troughs.

• EDAS provides advanced monitoring features. In addition to basic instance information queries, it supports advanced features such as microservice trace queries, system call topology graphs, and slow SQL statement queries.

• EDAS provides throttling and degradation features to ensure the high availability of your application.

• EDAS provides an end-to-end canary release feature. This lets you perform small-scale verification using canary releases during application iterations and updates.

What is a smooth migration

If your Dubbo application is deployed in a production environment and running normally, you may want to migrate it to EDAS to use its full range of features. During this migration, the top priority is to ensure that your business continues to run without interruption. A smooth migration is a migration to EDAS that does not cause service interruptions.

Migration process

The following figure shows a typical application architecture. The migration process is divided into three steps.

1. Required: Migrate applications

   Applications to be migrated are typically stateless and can be migrated first. This topic focuses on how to migrate applications.

2. Optional: Migrate the SLB instance or modify the domain name configuration

   After the application migration is complete, you must migrate the SLB instance or modify the domain name configuration.

   • SLB

     • If your application already uses an SLB instance before migration, you can reuse the SLB instance after migration. You can select a policy to attach the SLB instance as needed. For more information, see Server Load Balancer overview.

     • If your application does not use an SLB instance before migration, you must create and attach a new SLB instance to the entry application, such as the API Gateway in the preceding figure, after the migration.

   • Domain name

     • If the migrated application can reuse the SLB instance, you do not need to modify the domain name configuration.

     • If you create a new SLB instance and attach it to the application, you must add the new SLB configuration to your domain name and delete the original, unused SLB configuration. For more information, see Modify DNS servers.

3. Optional: Migrate storage and message queues

   • If your applications are already deployed on Alibaba Cloud and use related Alibaba Cloud products such as RDS and Message Queue (MQ), you do not need to migrate the storage and message queues after the application migration.

   • If your applications are not deployed on Alibaba Cloud, join the DingTalk group (ID: 31723701) and contact a product technical expert for a complete solution for migrating to the cloud and to EDAS.

This topic focuses on how to migrate applications. To test the smooth migration process, you can download the Demo and run the migration sample by following the instructions in the Readme file.

Migration solutions

There are two solutions for application migration: traffic-shifting migration, and dual registration and dual subscription migration. Both solutions ensure that your application can be migrated without interrupting services.

• Traffic-shifting migration solution

  Use Dubbo to switch the original service registry to EDAS Configserver. Then, develop a new set of applications and deploy them to EDAS. Finally, shift traffic using SLB and domain name configurations.

  If you choose this solution, you can develop your application by following the instructions in Develop a Dubbo microservice application using Spring Boot. You do not need to read the rest of this topic.

• Dual registration and dual subscription migration solution

  The dual registration and dual subscription migration solution involves connecting to two service registries simultaneously during application migration: the original service registry and the EDAS service registry. This ensures that migrated and non-migrated applications can call each other.

  The following figure shows the architecture for a smooth migration using dual registration and dual subscription:

  

  • Migrated and non-migrated applications can discover and call each other. This ensures business continuity.

  • This method is simple to use. You only need to add a dependency and modify one line of code to implement dual registration and dual subscription.

  • You can view the details of the consumer service call list to monitor the migration progress in real time.

  • You can dynamically change the service registration and subscription policies without restarting the application. You only need to restart the application once to complete the migration.

Migrate the first application

1. Select the first application to migrate.

   Start the migration from the lowest-level provider. However, if the call chain is too complex to analyze, you can select any application to migrate. After you make your selection, follow the steps in this section to migrate the first application.

2. Add dependencies and modify configurations in your application for dual registration and dual subscription.

   To migrate your application to EDAS, you must add the required dependencies and modify the configurations in your application.

   1. In the pom.xml file, add the edas-dubbo-migration-bom dependency.

          <dependency>
                  <groupId>com.alibaba.edas</groupId>
                  <artifactId>edas-dubbo-migration-bom</artifactId>
                  <version>2.6.5.1</version>
                  <type>pom</type>
              </dependency>                                

   2. In the application.properties file, add the address of the service registry.

      dubbo.registry.address = edas-migration://30.5.124.15:9999?service-registry=edas://127.0.0.1:8080,zookeeper://172.31.20.219:2181&reference-registry=zookeeper://172.31.20.219:2181&config-address=127.0.0.1:8848             

      Note

      For non-Spring Boot applications, configure this in the dubbo.properties file or the corresponding Spring configuration file.

      • edas-migration://30.5.124.15:9999

        You do not need to change the header of the multi-registry address. When the application starts, a WARN log may be generated if the log level is WARN or lower. This occurs because Dubbo validates the IP address and port. You can ignore this log.

      • service-registry

        The address of the service registry for service registration. By default, the service is registered with multiple registries. Each registry address must be in the standard Dubbo registry format. Separate multiple addresses with commas (,). The ZooKeeper address 172.31.20.219 is an example. Replace the example with your actual ZooKeeper address and port.`

      • reference-registry

        The address of the service registry for service subscription. You can subscribe to multiple registries or subscribe to the old registry first. Each registry address must be in the standard Dubbo registry format. Separate multiple addresses with commas (,).

      • config-address

        The address for dynamic pushes. If you want to test this locally, you need to download Nacos. EDAS transforms this address.

   3. Other modifications.

      For Spring applications that are not based on Spring Boot, add com.alibaba.edas.dubbo.migration.controller.EdasDubboRegistryRest to your scan path.

3. Perform local verification.

   If you want to modify the configuration only once, use dynamic configuration.

   1. Preparations.

      • Download ZooKeeper

      • Download and start Nacos

   2. Check whether the service is successfully registered.

      • Log on to the lightweight configuration center and check that the service appears in the service provider list.

      • Log on to ZooKeeper and check the service registration and consumption information.

   3. (Optional) Log on to Nacos and configure the service registration information.

      Note

      If you do not need dynamic configuration, you can skip this step.

      • DataId: dubbo.registry.config

      • Group: The name of the Dubbo application (applicationName), for example, dubbo-migration-demo-server. The configuration is at the application dimension, so application names must be unique.

      • Configuration content: Includes two types: application-level and instance IP-level. Multiple network interface cards may cause issues with IP-level configurations.

        • Application-level

          dubbo.reference.registry=edas://127.0.0.1:8080   ## The service registry for service subscription
          dubbo.service.registry=edas://127.0.0.1:8080,zookeeper:127.0.0.1:2181   ## The service registry for service registration                                                

        • Instance IP-level

          169.254.15.86.dubbo.reference.registry=edas://127.0.0.1:8080,zookeeper:127.0.0.1:2181
          169.254.15.86.dubbo.service.registry=edas://127.0.0.1:8080                                                

        When you verify the cluster, you can first verify the configuration at the instance IP level and then at the application level to confirm that the settings take effect.

   4. Check that the application calls are successful and view the registration and subscription relationships in the service registry.

      • Spring Boot 1.x: http://ip:port/dubboRegistry

      • Spring Boot 2.x: http://ip:port/actuator/dubboRegistry

      

4. Deploy the modified application to EDAS.

   You can deploy the application to an ECS cluster or a Container Service for Kubernetes (ACK) cluster as needed. You can deploy the application using the console or tools. For more information, see Overview of application creation and deployment and Overview of application creation and deployment.

   • To save costs, you can continue to use your existing ECS instances. However, you must import the ECS instances into EDAS. For more information, see Create an ECS cluster in the console.

     Important

     If you are prompted to convert the ECS instance before importing it, back up your important data.

   • If you create new resources such as ECS instances or clusters, make sure to create them within the original VPC. This ensures network connectivity between applications before and after migration, which is crucial for a smooth process. For more information, see Overview of ECS resource management.

   • In products such as databases, caches, and message queues, you must configure IP address whitelists for the new ECS instances. This ensures that the third-party components that the application depends on can be accessed.

5. Verify the result.

   1. Check that the business is running normally.

   2. Check the service subscription monitoring.

      If you have enabled Spring Boot Actuator monitoring for your application, you can access the Actuator to view the RibbonServerList information for each service to which the application subscribes. The Actuator addresses are as follows:

      • Spring Boot 1.x: http://ip:port/dubboRegistry

      • Spring Boot 2.x: http://ip:port/actuator/dubboRegistry

      

      • dubbo.orig.** shows the service registry information that is configured in the application.

      • dubbo.effective.** shows the service registry information that is in effect.

Migrate all other applications

Follow the steps in the previous section to migrate all other applications to EDAS one by one.

Clean up migration configurations

After the migration is complete, delete the configuration of the original service registry and the edas-dubbo-migration-bom dependency that was used for the migration process.

Modify the corresponding service registry address. This means deleting the ZooKeeper configuration to ensure that consumers subscribe only from EDAS and providers register only with EDAS. You can do this in one of two ways:

• Method 1: Dynamic configuration

  You can refer to the configuration modifications described in the local verification section.

• Method 2: Manual modification

  After all applications are migrated, change the service registry address of the applications. Set the subscription address to EDAS Configserver.

  dubbo.registry.address = edas-migration://30.5.XXX.XXX:9999?service-registry=edas://127.0.0.1:8080,zookeeper://172.31.20.219:2181&reference-registry=edas://127.0.0.1:8080&config-address=127.0.0.1:8848                   

  Change the value of reference-registry from zookeeper://172.31.20.219:2181 to edas://127.0.0.1:8080. After the modification is complete, you can deploy the application.

  Note

  After the application migration is complete, if you no longer use ZooKeeper, delete zookeeper://172.31.20.219:2181 from the service registry configuration. The final address is as follows.

  dubbo.registry.address = edas://127.0.0.1:8080                        

Clean up the configuration after the migration is complete. Although long-term use of this configuration does not affect the stability of your business, it increases the complexity of using the service registry with Dubbo and the potential for errors. Then, restart the applications in batches during off-peak hours.