Migrate from Spring Cloud Gateway to Cloud Native API Gateway - API Gateway

In the Kubernetes architecture, Spring Cloud Gateway lacks the ability to discover container services, has lower performance than NGINX Ingress, and requires custom development and integration for observability and security. In cloud migration and hybrid cloud scenarios, a two-layer network architecture with both Ingress and Spring Cloud Gateway may exist, which increases network layers, resource consumption, and operation and maintenance costs. Cloud Native API Gateway combines traditional traffic gateway and microservice gateway scenarios, significantly reducing service costs while offering high performance, high integration, and out-of-the-box features. This topic describes how to migrate services from Spring Cloud Gateway to Cloud Native API Gateway.

Prerequisites

You need to create a Cloud Native API Gateway. For more information, see A Cloud Native API Gateway is created.

Step 1: Confirm the service source

You can skip to Step 2: Migrate the configurations of Spring Cloud Gateway if you are in one of the following situations:

Container Service for Kubernetes (ACK) is used, and Kubernetes service discovery is supported.
An MSE Nacos instance is purchased and used as a registry. The MSE Nacos instance is upgraded to a version that supports Mesh Configuration Protocol (MCP).
No service discovery mechanism is used, and domain names and fixed IP addresses are used to discover services.

If you use a self-managed registry, perform the following migration operations to connect to Cloud Native API Gateway:

Purchase an MSE Nacos registry. For more information, see Create a Nacos engine.
Modify the configuration or code to register services with MSE Nacos. For more information, see Java SDK.
Optional: For Java applications, you can use MSE governance Agent technology to migrate the registry. For more information, see MSE Sync migration solution.

Step 2: Migrate the configurations of Spring Cloud Gateway

When migrating to Cloud Native API Gateway, you need to carefully analyze your current configuration and functional requirements, and find equivalent configurations in the target gateway. The following example shows how to migrate the registry of Spring Cloud Gateway to Nacos:

Registry: Cloud Native API Gateway abstracts the association of registries as service source management. You can create a service source in the Cloud Native API Gateway console. Based on the configuration information below, create MSE Nacos as the service source, then create a service to ensure real-time dynamic effect.
```
spring:
  application:
    name: gateway-demo
  cloud:
    nacos:
      discovery:
        server-addr: nacos-server:8848
      config:
        enabled: false
```
Service association configuration: Based on the configuration items below, you need to find the Load Balancing Configuration section in the Policy Configuration tab of the service. When migrating from Spring Cloud Gateway to Cloud Native API Gateway, you need to migrate client configurations (such as the Ribbon client load balancing configuration in the items below) to the new environment to ensure services run normally and maintain original functionality.

service-a:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.WeightedResponseTimeRule
    ConnectTimeout: 1000
    ReadTimeout: 8000
    MaxAutoRetries: 3
    MaxAutoRetriesNextServer: 2
    MaxTotalConnections: 20000
    MaxConnectionsPerHost: 5000

Routing configuration: Based on the configuration items below, you need to first create the corresponding API, then configure routing policies for the API. You can refer to the documents in the Routing directory to create routes. Finally, configure circuit breaking policies. For more information, see Routing policies.

spring:
  cloud:
    gateway:
      default-filters:
        - AddResponseHeader=X-Response-Default-Foo, Default-Bar

      routes:
        - id: websocket_test
          uri: ws://localhost:9000
          order: 9000
          predicates:
            - Path=/echo
        - id: default_path_to_service-a
          uri: lb://service-a
          order: 10000
          predicates:
            - Path=/sleep
hystrix:
  command:
    service-a:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 60000
          strategy: SEMAPHORE
          semaphore:
            maxConcurrentRequests: 60000

Step 3: Configure an authentication method for a gateway

Cloud Native API Gateway supports multiple standard authentication systems. For more information, see:

Step 4: View the global data dashboards of a gateway

Cloud Native API Gateway allows you to view global data dashboards. For more information, see:

Step 5: Migrate traffic

Procedure for migrating traffic on the caller side:

Iterated migration on the caller side or client side: You can change the access URLs of several services to check the migration result.
Phased migration on the proxy side: You can create migration steps on the original proxy side based on service types. For example, you can create migration steps for core services and non-core services. Then, you can migrate the services based on the access URLs in phases.
DNS-based full migration: After sufficient phased migration, redirect the domain name to the new Cloud Native API Gateway entry address.
(Recommended) Procedural migration:
1. Migrate several services as a test and check the migration result.
2. Migrate core services in sequence.
3. Perform a Domain Name System (DNS)-based full migration after you complete stress testing.

Migration solution	Cost	Risk
Iterated migration	High	Low
Phased migration on the proxy side	Medium	Medium
DNS-based full migration	Low	High
Procedural migration	Relatively low	Relatively low