This topic describes how to smoothly migrate Dubbo applications in Alibaba Cloud to Enterprise Distributed Application Service (EDAS) and register and discover services. If your Dubbo applications have not been deployed to Alibaba Cloud, open a ticket or contact EDAS Customer Services to obtain a complete solution for migrating 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 Dubbo applications that are 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.
- (Required) Migrate applications
Applications to be migrated are typically stateless and can be migrated first. Migrating applications is our focus in this topic.
- (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.
- 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.
- Domains
- The domain name configuration can be retained if the SLB instance can be reused after migration.
- To create and bind an SLB instance to the applications after migration, you need to add this SLB instance configuration to the domain name configuration and delete the old SLB instance. For more information, see Modify DNS.
- SLB
- (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, submit 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 EDAS Config Server through Dubbo, develop a new set of applications and deploy them to EDAS, and switch traffic through Server Load Balancer (SLB) and domain name configuration.
If you use registry switching, see t1838891.dita#task_2320387 to develop applications. You can skip the subsequent content of this topic.
- 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
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-dubbo-migration-bom
dependency used by migration.
Modify the registry address by deleting the ZooKeeper configuration to ensure that consumers subscribe only from EDAS and that providers offer subscriptions only in EDAS. You can modify the registry address by using either of the following methods:
- Method 1: dynamic configuration
For more information, see Locally verify the results.
- Method 2: manual modification
Change the registry address to the address of EDAS Config Server after all applications are modified.
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=edas://127.0.0.1:8080&config-address=127.0.0.1:8848
Change the value of
reference-registry
fromzookeeper://172.31.20.219:2181
toedas://127.0.0.1:8080
. Then, deploy applications.Note Deletezookeeper://172.31.20.219:2181
from the registry configuration ifZooKeeper
is no longer required after applications are migrated. The final registry address is as follows.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 error rate of using registries in Dubbo. We recommend that you clear the ZooKeeper configuration after migration and restart applications in batches during idle hours.