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

In the Kubernetes architecture, the Spring Cloud Gateway is unable to discover container services, and provides lower performance than the NGINX Ingress gateway. Custom development and integration are required for the Spring Cloud Gateway in terms of observability and security. In scenarios such as cloud migration and hybrid cloud deployment, a two-layer network architecture may exist. One layer is for Ingress gateways, and the other layer is for Spring Cloud Gateways. This increases network layers, resource consumption, and O&M costs. The cloud-native gateway combines the traditional traffic gateway and microservices gateway. This can greatly reduce service costs. The cloud-native gateway provides the advantages of high performance, high integration, and out-of-the-box. This topic describes how to migrate services from a Spring Cloud Gateway to a Microservices Engine (MSE) cloud-native gateway.

Prerequisites

A cloud-native gateway is created. For more information, see Create a cloud-native gateway.
You are familiar with cloud-native gateways. For more information, see Dive deeper into cloud-native gateways

Step 1: Confirm the service source

You can directly go to Step 2: Migrate the configurations of a Spring Cloud Gateway in 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.

You can perform migration operations based on the type of the service source.

Use an MSE Nacos instance
1. Purchase an MSE Nacos instance. For more information, see Create a Nacos engine.
2. Modify configurations or code and register your services with the MSE Nacos instance. For more information, see Java SDK.
3. Optional. If your application is a Java application, perform migration operations by using the Microservices Governance agent of MSE. For more information, see Migration solution based on MSE Sync.
Use a shared registry of Enterprise Distributed Application Service (EDAS)
Cloud-native gateways support EDAS registries. You can directly add an EDAS registry as a service source. For more information, see Add a service source.
Use a shared registry of Serverless App Engine (SAE)
Cloud-native gateways support SAE registries. You can directly add an SAE registry as a service source. For more information, see Add a service source.

Step 2: Migrate the configurations of a Spring Cloud Gateway

Sample configurations of a Spring Cloud Gateway:

Configurations of an associated registry

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

Configurations of routing services

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

To migrate the configurations of a Spring Cloud Gateway in the MSE console, perform the following operations:

Registry-related operations
Cloud-native gateways use service sources to associate registries. You can use the MSE console to add a service source and then associate the service source with services. The configuration takes effect in real time. For more information about how to add a service source, see Add a service source.
Service association operations
1. Add a service that you want to subscribe by importing the service. For more information about how to add a service, see Add a service.
2. For more information about how to configure an appropriate route version for the added service, see Manage service versions.
```
service-a:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.WeightedResponseTimeRule
    ConnectTimeout: 1000
    ReadTimeout: 8000
    MaxAutoRetries: 3
    MaxAutoRetriesNextServer: 2
    MaxTotalConnections: 20000
    MaxConnectionsPerHost: 5000
```
Routing configuration operations
Configure a routing policy for the gateway. For more information, 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
```
Cloud-native gateways support multiple routing policies. For more information, see the following topics:

Step 3: Configure an authentication method for a cloud-native gateway

Cloud-native gateways support multiple authentication methods. For more information, see the following topics:

Step 4: View the global data dashboards of a cloud-native gateway

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

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 separately 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 you complete the phased migration, you can associate the original domain name with the access URL of your cloud-native gateway.
(Recommended) Procedural migration:
1. Migrate several services as a test and check the migration result.
2. Migrate core services in sequence.
3. Perform a 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

References

For more information about cloud-native gateways, see Overview of cloud-native gateways.