Migrate an existing API Gateway instance to Cloud-native API Gateway

2.2.1. Configure domain names and certificates

After you create a Cloud-native API Gateway instance, configure the service domain name and its corresponding certificate on the instance. For more information, see the following documents:

Create a domain name

Change domain protocol and certificate

Cloud-native API Gateway provides more flexible Secure Sockets Layer (SSL) encryption configuration. You can configure equivalent settings based on the TLS version and cipher suite in the HTTPS security policy of the original API Gateway group:

1. Log on to the original API Gateway console.

2. In the navigation pane on the left, click API Management > Group Management. Click the group name to go to the group details page and find the HTTPS security policy type.

3. For details about the corresponding TLS version and cipher suite, see HTTPS security policies.

4. Configure the equivalent settings in the cloud-native API Gateway. For more information, see Set a specific HTTPS cipher suite.

2.2.2. Import API definitions

Both the original API Gateway and Cloud-native API Gateway support the standard OAS protocol. You can export API definitions from the original API Gateway as an OAS-compliant file, and then import the file into Cloud-native API Gateway.

1. Export the API definitions of an entire group from the original API Gateway. For more information, see Export standard OAS definitions.

   1. Log on to the API Gateway console.

   2. In the navigation pane on the left, choose API Management > Group Management.

   3. On the Group List page, select the target API group. In the Actions column, click Export API Definition.

   4. In the Export API Definition dialog box, specify the data format for the export.

2. Import the API definition file that you exported from the original API Gateway into the cloud-native API Gateway.

   2. Log on to the cloud-native API Gateway console. In the navigation pane on the left, choose APIs, and select a region in the top menu bar.

   3. Click Create API. In the REST API section, click Import and upload the API definition file that you exported in the previous step.

2.2.3. Configure backend services

Next, configure backend services on the instance. The backend services supported by the original API Gateway and Cloud-native API Gateway differ slightly:

For common backend services such as ECS and CLB, create a fixed-address service in Cloud-native API Gateway:

1. Log on to the cloud-native API Gateway console.

2. In the navigation pane on the left, choose Instances, and select a region in the top menu bar.

3. On the Instances page, click the ID of the target gateway instance.

4. In the navigation pane on the left, choose Services, and click Create Service. In the Create Service panel, set Service Source to Fixed Address, configure the related parameters, and then click OK.

2.2.4. Publish APIs

After you complete the preceding configurations, publish the API to the purchased instance for testing. The publishing logic of Cloud-native API Gateway differs significantly from that of the original API Gateway.

Publishing in the original API Gateway:

• An API group is bound to a specific instance. You cannot select the instance during publishing. The API is published to the instance of its group by default.

• The backend service for the API is preconfigured. You do not need to specify it each time you publish.

• The request domain name is configured on the group and cannot be modified during publishing.

• You must specify an environment for each publication. You can only publish to one environment at a time.

• You can only publish a single API from a group at a time.

Publishing in Cloud-native API Gateway:

• When you publish an API, you must select the hosting instance. The published content takes effect only on the selected instance. An API can be published to multiple instances.

• You must specify the backend service each time you publish. You can change the backend service during publishing.

• You must select the request domain name each time you publish. If multiple domain names provide the service, you must select all of them during publishing.

• There is no concept of environments. Instances are generally used to differentiate environments.

• All operations under an API are published at once. You cannot publish a single operation.

2.2.5. Configure plugins

After an API is published to an instance, you can configure policies for the API or its operations. The policies supported by Cloud-native API Gateway and the plugins supported by the original API Gateway differ significantly. The following table lists the main differences.

2.2.6. Configure application authorization information

1. Application (APP) migration

The concept of an "application" in the original API Gateway is called a "consumer" in Cloud-native API Gateway. Their capabilities are equivalent, and you can smoothly migrate this feature. For more information about managing consumers in Cloud-native API Gateway, see Manage consumers.

2. Authorization relationship migration

Consumer authorization in Cloud-native API Gateway is based on operations, which is consistent with the original API Gateway. You can configure authorization relationships for specific API operations on the API operations page. You can also grant batch authorization for API operations to a consumer on the consumer page.

3. Function verification

After you configure all API metadata, begin functional verification. Because the official domain name is currently in production on the original API Gateway, you have two options for testing:

• Configure a test domain name on Cloud-native API Gateway and create a CNAME record that maps the test domain name to the instance's endpoint for testing.

• Modify the host configuration of your test machine to use the original production domain name for testing.

After you resolve the endpoint issue, perform system integration. Cloud-native API Gateway provides SDKs for download. You can download sample code for calling all operations under an API directly from the API details page.

4. Grayscale migration of production services

After thorough functional verification, you can gradually migrate your services from the original API Gateway to Cloud-native API Gateway. Use a grayscale plan throughout the migration process. Migrate slowly so that you can roll back all services to the original API Gateway at any time if you encounter problems. We recommend that you gradually migrate production services by changing the resolution weight of your production domain name. For more information, see Configure weights.

1. On the instance's Basic Information page, find the endpoint of the Cloud-native API Gateway instance.

2. Create a CNAME record that maps your production domain name to the endpoint of the Cloud-native API Gateway instance. Start with a weight of 1 and then gradually increase it.

3. Service monitoring

You can view the operational status of your services in the Observation & Analysis module of the instance. For more information, see View gateway monitoring data. If there are no abnormalities during service monitoring, you can continue to gradually increase the traffic weight.

4. Rollback

If you find an abnormality during grayscale migration, immediately delete the CNAME record for the Cloud-native API Gateway endpoint from your production domain name. This rolls back your services. After you resolve the issue, you can resume the migration.