Steps | Operation Details | Operator |
1 | You provide the information of the service to be migrated, including region, appId , and service ID, such as Guangzhou, 123688xxx, and service-0x6u6xxx. | You |
2 | API Gateway evaluates the configuration of the service to be migrated and outputs an evaluation report. | API Gateway |
3 | If migration is feasible as evaluated in step 2, you need to evaluate the dedicated instance's specification (based on the business QPS) and VPC parameters (if the original service backend is across VPCs, you also need to configure a CCN instance for VPC interconnection). | You and API Gateway |
4 | After creating a dedicated instance in step 3, you provide the instance ID to API Gateway for double check. | API Gateway |
5 | After step 4 is completed, you confirm the migration time. | You |
6 | At the scheduled time, API Gateway initiates the service migration (usually completed in 1 minute), and you observe the business monitoring data. If the service goes exceptional during or after the migration, API Gateway will roll back the service immediately. | API Gateway and you |
7 | After the migration is completed, API Gateway will continue to observe the service for a period of time. If there is any exception, it will roll back the service immediately and notify you. | API Gateway |
apigateway.myqcloud.com
, we recommend you not migrate it currently, as migration will be perceptible. However, there is an alternative: you can create a service in the dedicated instance, and then use API Gateway's existing API replication feature to sync the API configuration of the original service to the new service. If the myqcloud
domain name is configured in a custom domain name or WAF or hardcoded in the client, it needs to be updated synchronously.
Was this page helpful?