Microservices Engine:Migrate services from Spring Cloud Gateway to a cloud-native gateway

When to skip this step

Skip to Step 2 if any of the following applies:

• You use Container Service for Kubernetes (ACK) with Kubernetes service discovery

• You use an MSE Nacos instance that has been upgraded to a version supporting Mesh Configuration Protocol (MCP)

• You do not use a service discovery mechanism and rely on domain names or fixed IP addresses

Set up a service source by registry type

Choose the option that matches your current registry:

MSE Nacos instance

1. Purchase an MSE Nacos instance. See Create a Nacos engine.

2. Register your services with the MSE Nacos instance by updating your application configuration or code. See the Nacos Java SDK documentation.

3. (Optional) For Java applications, use the Microservices Governance agent of MSE to automate registration migration. See Migration solution based on MSE Sync.

Enterprise Distributed Application Service (EDAS) registry

Add your EDAS registry as a service source directly. See Add a service source.

Serverless App Engine (SAE) registry

Add your SAE registry as a service source directly. See Add a service source.

Verify the service source

After you add a service source, open the MSE console and navigate to your cloud-native gateway. Confirm that the service source appears in the service source list and is working correctly.

Example Spring Cloud Gateway configuration

Registry binding:

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

Routes and load balancing:

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

Migrate each configuration section

Perform the following operations in the MSE console:

Verify the routing configuration

After you create the routing rules, send a test request to the cloud-native gateway's endpoint for each migrated route. Confirm that the request reaches the correct backend service and returns the expected response.

# Test the /echo WebSocket route
curl -v http://<cloud-native-gateway-endpoint>/echo

# Test the /sleep route
curl -v http://<cloud-native-gateway-endpoint>/sleep

Verify authentication

After you configure authentication, send a request without valid credentials and confirm that the gateway returns a 401 Unauthorized response. Then send a request with valid credentials and confirm that it reaches the backend service.

# Expect 401 Unauthorized
curl -v http://<cloud-native-gateway-endpoint>/sleep

# Expect 200 OK with valid token
curl -v -H "Authorization: Bearer <valid-token>" http://<cloud-native-gateway-endpoint>/sleep

Verify observability

After you enable monitoring and log shipping, generate test traffic. Confirm that metrics appear on the gateway dashboard and that logs reach the target destination.

Recommended procedure

1. Back up your configuration. Confirm that you have a copy of all Spring Cloud Gateway configuration files (application.yml, bootstrap.yml, and any externalized config). This backup serves as your rollback baseline.

2. Test with a small batch. Migrate a few non-critical services to the cloud-native gateway and validate the routing, authentication, and response behavior.

3. Migrate core services sequentially. After the test batch passes validation, migrate core services one by one. Monitor error rates and latency on the gateway dashboard after each service is migrated.

4. Run stress tests. Before switching all traffic, run stress tests against the cloud-native gateway to confirm it handles your expected throughput.

5. Perform DNS-based full migration. Associate your original domain name with the cloud-native gateway's access URL to switch all remaining traffic.

6. Keep the original gateway running. Maintain the Spring Cloud Gateway deployment for a rollback window. If issues arise, revert the DNS record to point back to the original gateway.

Rollback

If you encounter issues after switching traffic, revert the DNS record to point back to the Spring Cloud Gateway. Because the original configuration and service registrations remain intact during the migration, rolling back requires only a DNS change.