Migrate from Spring Cloud Gateway to a cloud-native gateway-Microservices Engine(MSE)-阿里云帮助中心

In a Kubernetes environment, Spring Cloud Gateway cannot automatically discover container services, offers lower performance than an NGINX Ingress gateway, and requires custom development to integrate observability and security features. In cloud migration or hybrid cloud scenarios, you might end up with a two-layer architecture of an Ingress gateway and a Spring Cloud Gateway. This setup increases network complexity, resource consumption, and operational overhead. A cloud-native gateway combines the functions of a traditional traffic gateway and a microservices gateway into a single service. This simplifies your architecture, reduces costs, and provides high performance, deep integration, and out-of-the-box functionality. This topic describes how to migrate your services from Spring Cloud Gateway to an MSE cloud-native gateway.

Prerequisites

Step 1: Identify the service source

If your setup meets any of the following conditions, you can skip to Step 2: Migrate Spring Cloud Gateway configurations.

You use Container Service for Kubernetes (ACK) and use Kubernetes Service for service discovery.
You use an MSE Nacos instance as your registry, and it has been upgraded to a version that supports Mesh Configuration Protocol (MCP).
You do not rely on a service discovery mechanism and use domain names and fixed IP addresses for your services.

If your setup matches one of the following scenarios, perform the corresponding migration steps to connect to the cloud-native gateway:

Self-managed registry
1. Purchase an MSE Nacos registry. For more information, see Create a Nacos engine.
2. Modify your configurations or code to register your services with the MSE Nacos instance. For more information, see Java SDK.
3. Optional: If you have a Java application, you can migrate your registry with the Microservices Engine (MSE) governance agent. For more information, see Migrate service registries with MSE Sync.
Shared registry from Enterprise Distributed Application Service (EDAS)

The cloud-native gateway supports EDAS registries. You can directly add the registry as a service source. For details, see Add a service source.
Shared registry from Serverless App Engine (SAE)

The cloud-native gateway supports SAE registries. You can directly add the registry as a service source. For details, see Add a service source.

Step 2: Migrate Spring Cloud Gateway configurations

The following are example configurations for a Spring Cloud Gateway:

Associated registry

spring:
  application:
    name: gateway-demo
  cloud:
    nacos:
      discovery:
        server-addr: nacos-server:8848
      config:
        enabled: false

Routing and other related configurations

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
service-a:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.WeightedResponseTimeRule
    ConnectTimeout: 1000
    ReadTimeout: 8000
    MaxAutoRetries: 3
    MaxAutoRetriesNextServer: 2
    MaxTotalConnections: 20000
    MaxConnectionsPerHost: 5000
hystrix:
  command:
    service-a:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 60000
          strategy: SEMAPHORE
          semaphore:
            maxConcurrentRequests: 60000

The following sections show how to map your Spring Cloud Gateway settings to operations on the MSE console:

Mapping registry configurations

With a cloud-native gateway, you manage registry connections as service sources. You can create a service source on the MSE console and associate it with your services for dynamic, real-time updates. For details, see Add a service source. In the Add service source dialog box, set Source type to MSE Nacos, select the corresponding Cluster name, enter NACOS for Registry type, and provide the Registry address. Prerequisite: In the parameter settings, you must set MCPEnabled to true. After you complete the configuration, click OK.

Mapping service associations

Add services by importing the services you want to subscribe to. For more information, see Add a service.
Set an appropriate version for each added service. For more information, see Manage service versions.

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

Mapping routing configurations

Configure a routing rule for the gateway. For details, see Create a routing rule.
```
spring:
  cloud:
    gateway:
      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
```
A cloud-native gateway supports multiple routing policies. For more information, see the following topics:

Step 3: Configure authentication and authorization

The cloud-native gateway supports several standard authentication and authorization methods. For more information, see the following topics:

Step 4: View global gateway data

You can view global data dashboards for your cloud-native gateway. For more information, see the following topics:

Step 5: Migrate traffic

The following are several strategies for migrating client traffic:

Iterative client migration: Select a few business scenarios, modify their access addresses, and then verify the migration.
Phased canary release at the proxy layer: At your existing proxy layer, create a phased change plan. Based on your division of core and non-core services, gradually switch traffic to the new address.
Full cutover via DNS resolution: After sufficient canary testing, switch the DNS record to the new cloud-native gateway's endpoint address.
(Recommended) Step-by-step migration:
1. Select a few business scenarios for acceptance testing.
2. Gradually migrate traffic for core scenarios through iterative canary releases.
3. After successful stress testing, perform a full migration by switching the DNS record.

Migration strategy	Cost	Risk
Iterative client migration	High	Low
Phased canary release at the proxy layer	Medium	Medium
Full cutover via DNS resolution	Low	High
Step-by-step migration	Relatively low	Relatively low