Smooth migration can ensure service continuity in the following scenario: Your Dubbo applications have been deployed in the production environment and run as expected and you need to migrate the applications to Enterprise Distributed Application Service (EDAS) to have access to all the EDAS features. This topic describes how to smoothly migrate Dubbo applications to EDAS and register and discover services.
Prerequisites
Your Dubbo applications are deployed on Alibaba Cloud.
- If your Dubbo applications are not deployed on Alibaba Cloud, join the DingTalk group (ID: 31723701) to contact EDAS technical support to obtain a complete solution for migration to EDAS.
- 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.
Benefits of migration to EDAS
Category | Description |
---|---|
Application deployment | EDAS provides features for application deployment, such as flexible configuration of startup parameters, process visualization, graceful service connection and disconnection, and phased release. This allows you to configure, query, and control application release processes. |
Service discovery and configuration management | The commercial release of EDAS provides the service discovery and configuration management features. This saves you from maintaining middleware, such as Eureka, ZooKeeper, or Consul. |
Service governance | You can query the details of released and consumed services in the EDAS console. |
Auto scaling | EDAS provides the auto scaling feature. This allows you to dynamically scale your applications in or out based on traffic peaks and off-peak periods. |
Advanced monitoring | 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. |
Throttling and degradation | EDAS provides throttling and degradation features to ensure the high availability of your applications. |
End-to-end canary release | EDAS provides the end-to-end canary release feature for small-scale validation when you iterate and update your applications. |
Migration process
- Required. Migrate applications.
Applications to be migrated are typically stateless and can be migrated first. This topic focuses on how to migrate applications.
- Optional. Migrate the Server Load Balancer (SLB) instance or modify the domain name configuration.
After the application migration is complete, you need to migrate the SLB instance or modify the domain name configuration.
- SLB
- If an SLB instance is used before migration, you can reuse the SLB instance after migration.Overview.
- If no SLB instance is used before migration, we recommend that you create and bind an SLB instance to the entry 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.
- SLB
- 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. EDAS provides a demo to show you how to smoothly migrate applications. You can download this demo and run the demo by referring to Readme.
Migration solution
You can use the following two methods to migrate applications without service discontinuity.
Registry switching
Use Dubbo to switch the original service registry to EDAS ConfigServer, develop a new set of applications, and then deploy them to EDAS. Then, use Server Load Balancer (SLB) and configure domain names to switch traffic.
If you use the registry switching method, you can skip the remaining content of this topic. You can use Spring Boot to develop Dubbo microservices applications. For more information, see Use Spring Boot to develop Dubbo microservice-oriented applications.
Dual registration and dual subscription
Access the original service registry and the EDAS service registry when applications are being migrated to enable mutual calling between migrated applications and non-migrated applications.
Dual registration and dual subscription provides the following benefits:
- Migrated applications and non-migrated applications can discover and call each other. This ensures service continuity.
- You need to only 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 the need to repeatedly restart applications. You need to restart applications only once in the migration process.
Migrate the first application
We recommend that you start migration from the underlying provider. You can randomly select an application to be migrated if the trace is complex and difficult to analyze. Migrate the selected application by performing the subsequent steps.
- Add dependencies to the application and modify its configurations. You must modify the configurations when you use the dual registration and dual subscription method. Add dependencies to the application and modify its configurations before the application is migrated to EDAS.
- Verify the result in your on-premises environment. Use dynamic configuration for one-time modification.
- Deploy the modified application to EDAS. You can deploy the application to an Elastic Compute Service (ECS) cluster or a Container Service for Kubernetes (ACK) 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 Overview.
- We recommend that you reuse an existing ECS instance by importing the instance to EDAS. This saves costs. For more information, see Create an ECS cluster in the EDAS console. Important If you are prompted to perform conversion when you import the ECS instance, back up important data to prevent service impacts caused by data loss.
- If you do not reuse an existing ECS instance, you must create resources such as an ECS instance and a cluster 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 Overview.
- Configure an IP address whitelist for the new ECS instance in products such as a database, a cache, and a message queue. This ensures normal access to the application-dependent third-party components.
- We recommend that you reuse an existing ECS instance by importing the instance to EDAS. This saves costs. For more information, see Create an ECS cluster in the EDAS console.
- Verify the result.
Migrate all the other applications
Migrate the other applications to EDAS by referring to Migrate the first application.
Clear the migration configurations
After migration, delete the original service registry configurations and the edas-dubbo-migration-bom
dependency that is used during migration.
Modify the registry address by deleting the ZooKeeper configurations. 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.XX.XX:9999?service-registry=edas://127.0.XX.XX:8080,zookeeper://172.31.XX.XX:2181&reference-registry=edas://127.0.XX.XX:8080&config-address=127.0.0.1:8848
Change the value of
reference-registry
fromzookeeper://172.31.XX.XX:2181
toedas://127.0.XX.XX:8080
. Then, deploy applications.NoteDelete
zookeeper://172.31.XX.XX:2181
from the service registry configurations ifZooKeeper
is no longer required after migration.From the long-term perspective, ZooKeeper has no impact on service stability but increases the complexity and the error rate of using service registries in Dubbo. We recommend that you clear the ZooKeeper configurations after migration and restart applications in batches during off-peak hours. The following sample code shows the final registry address.
dubbo.registry.address = edas://127.0.XX.XX:8080