If your applications are deployed in a production environment and run as expected, you can smoothly migrate your applications to Serverless Application Engine (SAE). This ensures business continuity and prevents data loss.
Benefits of application migration to SAE
SAE provides multiple features, which you can use to configure, query, and manage the release process of your applications, such as flexible startup parameter configuration, visualized deployment process, graceful release and shutdown, and phased release.
After the commercial release, SAE provides the service discovery and configuration management features. You do not need to maintain middleware, such as Eureka, ZooKeeper, and Consul.
You can govern services in the SAE console in a centralized manner. This allows you to query the details of released and consumed services.
SAE provides the auto scaling feature, which you can use to dynamically scale in and scale out the instances in your applications based on fluctuations.
SAE provides the advanced monitoring feature, which you can use to query the basic information about instances, microservice traces, the system call topology, and slow SQL queries.
SAE provides the throttling and degradation feature to ensure the high availability of your Spring Cloud applications.
SAE provides the end-to-end canary release feature that allows you to perform canary releases to test a new version on a small number of instances during application iterations.
What is smooth migration?
For example, your Spring Cloud cluster and the applications in the cluster are deployed in a production environment and run as expected. If you want to migrate the cluster to SAE to access all SAE features, you can use the smooth migration method to ensure business continuity.
If your Spring Cloud cluster is not deployed in a production environment or downtime migration is acceptable, you can develop applications in your on-premises environment and deploy the applications on SAE. For more information, see the following topics:
Spring Cloud applications: Deploy a Spring Cloud application on SAE
Dubbo applications: Deploy a Dubbo application on SAE
Migration process
Migrate an application.
In most cases, an application to be migrated is stateless and must be migrated first.
Optional: Migrate the bound Server Load Balancer (SLB) instance or modify the domain name configuration.
After the application is migrated, you must migrate the SLB instance that is bound to the application or modify the domain name configuration.
SLB
If an SLB instance is used before migration, you can reuse the SLB instance after migration. You can select a method to bind an SLB instance to your application based on your business scenario. For more information, see Bind an SLB instance to an application.
If no SLB instance is used before migration, we recommend that you create an SLB instance and bind it to the ingress application such as an API gateway after migration, as shown in the preceding figure.
We recommend that you enable dual-registration and dual-subscription to reduce the costs of using Elastic Compute Service (ECS) when you migrate applications. If the existing ECS instance cannot be used due to specific causes (for example, the original port configured for the ECS instance is occupied), you must use the traffic-splitting migration solution and add new ECS instances. After the application is migrated, reuse the existing SLB instance or create an SLB instance and bind it to the migrated application based on your business requirements.
Domain name
If the SLB instance can be reused after migration, you do not need to modify the domain name.
If you want to create an SLB instance and bind it to the migrated application, you must add the new SLB instance to the domain name configuration. For more information, see Change DNS servers for a domain name. You must delete the SLB instance that is no longer required.
Optional: Migrate storage and message queues.
If your application is deployed on Alibaba Cloud and uses Alibaba Cloud services, such as ApsaraDB RDS and Message Queue, you do not need to migrate storage or message queues.
If the application is not deployed on Alibaba Cloud before migration, join the DingTalk group 32874633 for technical support.
Migration solutions
You can use the following solutions to migrate applications: traffic-splitting, and dual-registration and dual-subscription. Both solutions can be used to ensure smooth migration of applications without business interruption. This section describes the dual-registration and dual-subscription migration solution.
Registry switching
Use Dubbo to switch the original service registry to SAE Config Server, develop a new set of applications, and then deploy the applications on SAE. Then, use SLB and configure domain names to switch traffic.
For information about the application development of the traffic-splitting migration solution, see Introduction to microservice scenarios.
Dual-registration and dual-subscription
To enable migrated and non-migrated applications to call each other, access the original service registry and the SAE service registry when the applications are being migrated.
The dual-registration and dual-subscription migration solution provides the following benefits:
Migrated applications and non-migrated applications can discover and call each other. This ensures business continuity.
You only need to add dependencies and modify a small amount of code to implement dual-registration and dual-subscription.
You can view the details 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.