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

3.2.1. Configure domain names and certificates

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

Create a domain name

Change the protocol and certificate of a domain name

The cloud-native API Gateway provides more flexible configuration for Secure Sockets Layer (SSL) encryption. You can configure equivalent settings in the cloud-native API Gateway 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.

3.2.2. Import API definitions

Both the original API Gateway and the cloud-native API Gateway support the standard OAS protocol. You can export the API definitions from the original API Gateway to an API definition file in the OAS protocol, and then import the file into the 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.

3.2.3. Configure backend services

Next, configure the backend services in the instance. The backend services supported by the original API Gateway and the cloud-native API Gateway are slightly different:

For common backend services, such as ECS and CLB, you can create a fixed-address service in the 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.

3.2.4. Publish APIs

After you complete the preceding configurations, you can publish the API to the instance that you just purchased for testing. The publishing logic of the cloud-native API Gateway is significantly different 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 pre-configured. 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 the cloud-native API Gateway:

• When you publish an API, you must select the instance that will host it. 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 an API. 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.

3.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 the cloud-native API Gateway and the plugins supported by the original API Gateway are significantly different. The following table lists the main differences for your reference.

3.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 the cloud-native API Gateway. Their capabilities are equivalent, and you can smoothly migrate this feature. For more information about managing consumers in the cloud-native API Gateway, see Manage consumers.

2. Authorization relationship migration

Consumer authorization in the 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 of the cloud-native API Gateway. You can also grant batch authorization for API operations to a consumer on the consumer page.

4. Function verification

After you configure all the API metadata, you can 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 the 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, you need to perform system integration. The cloud-native API Gateway provides software development kits (SDKs) for download. You can download sample code for calling all operations under an API directly from the API details page.

5. Grayscale migration of production services

After you perform strict functional verification, you can gradually migrate your services from the original API Gateway to the cloud-native API Gateway. You must use a grayscale plan for the entire migration process. The migration should be performed 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 to the cloud-native API Gateway 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. We recommend that you 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 the grayscale migration, immediately delete the CNAME record for the cloud-native API Gateway endpoint that you added to your production domain name. This rolls back your services. After you resolve the issue, you can resume the migration.