Microservices Engine:Migrate from cloud-native gateway to Cloud-native API Gateway

Domain names

Unlike in cloud-native gateway, domain names in Cloud-native API Gateway are public resources that do not belong to a specific instance. You bind a domain name to the corresponding gateway instance when you publish an API.

Cloud-native API Gateway supports all the domain management features of cloud-native gateway. To create a domain name for use in Cloud-native API Gateway, see Create a domain name. Similar to cloud-native gateway, adding a domain name in Cloud-native API Gateway does not automatically perform domain name registration or DNS resolution. You must register the domain name and configure its DNS resolution to point to the instance endpoint.

Sources and services

Similar to cloud-native gateway, sources and services in Cloud-native API Gateway are managed within an instance. Use the following tables to determine whether your backend services can be migrated to Cloud-native API Gateway.

To manage sources in Cloud-native API Gateway, see Manage service sources.

To manage services in Cloud-native API Gateway, see Services.

Table 1. Source support comparison

Table 2. Service support comparison

Routes

APIs are first-class citizens in Cloud-native API Gateway. In Cloud-native API Gateway, routes from cloud-native gateway are implemented as APIs, primarily HTTP APIs and REST APIs:

• HTTP API

HTTP APIs are route-centric interfaces based on the HTTP protocol. They are suitable for scenarios such as Kubernetes Ingress, microservice architectures, and AI (SSE) to quickly expose services externally.

If you do not need fine-grained API-level management, you can configure routes to define which backend service handles a specific request. Route paths are often coarser-grained than API operations, such as /user/*. This allows for rapid configuration of access paths and simplifies inter-system interactions. HTTP APIs are primarily for developer or operations teams. Routes provide flexibility, simplify call logic between systems, and make it easier to split business logic across services.

• REST API

REST APIs are resource-oriented interfaces based on the HTTP protocol. They use standard HTTP methods, such as GET and POST, to operate on resources. They are suitable for scenarios such as API-first development, cross-team collaboration, and fine-grained API management.

• API-first: A software development methodology that emphasizes starting with API design when developing an application. This approach encourages developers to define system boundaries and interactions between services by first defining and creating APIs, before building the backend services that implement them.

• Fine-grained API management: This approach is ideal when you expose APIs to partners, integrate internal and external systems, or support collaboration. In these scenarios, service providers must expose specific operations, apply traffic policies at the operation level, and provide consumers with complete API documentation.

REST APIs are primarily for business-centric development teams. They promote cross-team collaboration, enhance system flexibility, and drive rapid business iteration and agile development.

Based on your business needs, choose whether to migrate your routes to HTTP APIs or REST APIs. You can also flexibly split the routes from your cloud-native gateway into multiple APIs, using HTTP APIs for some and REST APIs for others, to manage them independently.

To migrate to an HTTP API, see Create an HTTP API. To configure policies for the HTTP API, see Routing policies.

To migrate to a REST API, see Create a REST API and add an operation. To configure policies for the REST API, see Configure policies and plugins.

Verification checkpoints:

• Domains are created and resolved correctly.

• Sources and services are configured and can access backend services.

• Routes are configured successfully, and requests are correctly forwarded to backend services.

Blacklist and whitelist

Cloud-native API Gateway offers the same blacklist and whitelist capabilities as cloud-native gateway, with rules applicable at the global, domain, and route levels. In addition, Cloud-native API Gateway offers a global Layer 4 blacklist and whitelist, which allows you to directly reject connections from specified IP addresses, further conserving gateway resources.

After migrating your routing management configurations, you can migrate the blacklist and whitelist. For specific instructions, see Configure an IP address blacklist or whitelist for a gateway.

Global authentication and authorization

Cloud-native API Gateway is compatible with the main authentication and authorization types of cloud-native gateway. See the table below for support status and migration procedures.

Table 3. Global authentication and authorization support comparison

Consumer authentication

In Cloud-native API Gateway, consumers exist independently of gateway instances. You only need to configure consumer information once to reuse it for authorization across different gateway instances and APIs. As a key part of API management, Cloud-native API Gateway enhances consumer management with support for more authentication methods, including API Key, JWT, and HMAC.

To manage consumers, see Manage consumers. After creating consumers, refer to Authorization management to configure their accessible API scope.

Official plugins

Cloud-native API Gateway is compatible with most of the official plugins from cloud-native gateway. Use the following table to determine if the official plugins you are using can be migrated to Cloud-native API Gateway.

Table 4. Official plugin support comparison

Custom plugins

Cloud-native API Gateway is fully compatible with the custom plugins of cloud-native gateway. To upload a custom Wasm plugin from your cloud-native gateway, see Upload a plugin. To migrate a custom Lua plugin, see Use a Lua plugin.

Cloud-native API Gateway also provides an online IDE for writing plugins. If you need to develop a new plugin, see Use WebIDE to develop a plugin to quickly develop prototypes in the Cloud-native API Gateway console.

Tracing

Cloud-native API Gateway integrates with Managed Service for OpenTelemetry to support tracing and is fully compatible with all tracing protocols from cloud-native gateway. To configure it on Cloud-native API Gateway, see Enable Tracing Analysis for a gateway.

Logs

Similar to cloud-native gateway, Cloud-native API Gateway also supports log shipping. To configure it, see Enable log shipping for a gateway. This allows you to ship gateway access logs to a specified Log Service project under your account.

Alerts

Cloud-native API Gateway integrates with CloudMonitor to support alerting capabilities. To create the alerts you need in Cloud-native API Gateway, see Create an alert rule.