Smoothly migrate Dubbo applications 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 Dubbo applications have been deployed in the production environment and run as expected. If you need to migrate the applications to EDAS to have access to all the EDAS features, you can ensure service continuity through smooth migration.

Note If your Dubbo applications are 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 Get started with EDAS.

Procedure

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

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

Registry switching
Use Dubbo to switch the original service registry to EDAS Config Server, and develop a new set of applications and deploy them to EDAS. Then, use Server Load Balancer (SLB) and configure domain names to switch traffic.

If you use registry switching, see Use Spring Boot to develop Dubbo microservice applications. 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.

The following figure shows the architecture of smooth migration that is implemented through dual registration and dual subscription.
- 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 (applicable to dual registration and dual subscription).
Add dependencies to the application and modify its configuration before the application is migrated to EDAS.
1. Add the edas-dubbo-migration-bom dependency to the pom.xml file.
```
    <dependency>
            <groupId>com.alibaba.edas</groupId>
            <artifactId>edas-dubbo-migration-bom</artifactId>
            <version>2.6.5.1</version>
            <type>pom</type>
        </dependency>                                
```
2. Add the registry address to application.properties.
```
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 the application is not a Spring Boot application, configure the application in dubbo.properties or in the Spring profile.
  
  edas-migration://30.5.124.15:9999
  You do not need to modify the header if the application is registered to multiple registries. If the log level is WARN or lower, a WARN log may be thrown during startup because Dubbo verifies the IP address and port. The log can be ignored.
  
  service-registry
  It indicates the address of the registry to which the application is registered. By default, the application is registered to multiple registries. Therefore, multiple registry addresses are written. Each registry address is in the standard format of a Dubbo registry address. Separate multiple registry addresses with commas (,). Enter the actual ZooKeeper address and port number for the instance that is marked by using the ZooKeeper address 172.31.20.219. `
  
  reference-registry
  It indicates the registry address for service subscription. You can register with multiple registries or with the original registry first. Each registry address is in the standard format of a Dubbo registry address. Separate multiple registry addresses with commas (,).
  
  config-address
  It indicates the dynamically pushed address. To implement dynamic push in your on-premises environment, download Nacos. EDAS converts this address.
3. Complete other modifications.
  If an application is not a Spring application of Spring Boot, add com.alibaba.edas.dubbo.migration.controller.EdasDubboRegistryRest to the scan path.
Verify the result in your on-premises environment.
Use dynamic configuration for one-time modification.
1. Complete preparations.
2. Check whether the service is registered.
  - Log on to the lightweight configuration center to view the service in the service provider list.
  - Log on to ZooKeeper to view the information about service registration and consumption.
3. (Optional) Log on to Nacos to configure the service registration information.
  Note Skip this step if dynamic configuration is not required.
  - Set DataId to dubbo.registry.config.
  - Group corresponds to the Dubbo application name that is specified by applicationName, such as dubbo-migration-demo-server. The application name must be unique because the service registration information is configured at the application level.
  - Configuration Content can be at the application level or the instance IP address level. When more than one network interface controller (NIC) is used, an error may occur for the instance IP address level.
    - Application level
      dubbo.reference.registry=edas://127.0.0.1:8080 ## The registry to which the service is registered dubbo.service.registry=edas://127.0.0.1:8080,zookeeper:127.0.0.1:2181 ## The registry for service subscription
    - Instance IP address 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 validate the cluster, you can check whether the configuration at the instance IP address level and that at the application level take effect in sequence.
4. Check whether the application call is normal and check the registration and subscription relationship of the registry.
  - Spring Boot 1.x: http://ip:port/dubboRegistry
  - Spring Boot 2.x: http://ip:port/actuator/dubboRegistry
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 Overview and Create and deploy applications (Kubernetes).
- 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.
  
  Notice If you are prompted to perform conversion when you import the ECS instance, back up important data.
- 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 the service is 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/dubboRegistry
  - Spring Boot 2.x: http://ip:port/actuator/dubboRegistry
  - dubbo.orig.** indicates the registry information that is configured in the application.
  - dubbo.effective.** indicates the effective registry information.

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-dubbo-migration-bom dependency that is used by migration.

Modify the registry address by deleting the ZooKeeper configuration. This ensures that consumers subscribe only from EDAS and that providers offer subscriptions only in EDAS. You can modify the registry address by using the following methods:

Method 1: dynamic configuration
For more information, see Verify the result in your on-premises environment.
Method 2: manual modification
Change the registry address to the address of EDAS Config Server after all the applications are modified.
```
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. Then, deploy applications.
Note Delete zookeeper://172.31.20.219:2181 from the registry configuration if ZooKeeper is no longer required after migration. The following content shows the final registry address.
```
dubbo.registry.address = edas://127.0.0.1:8080                        
```

From the long-term perspective, ZooKeeper has no impact on service stability but increases the complexity and the error rate of using registries in Dubbo. We recommend that you clear the ZooKeeper configuration after migration and restart applications in batches during off-peak hours.