Migrate from Spring Cloud Gateway to API Gateway
API Gateway unifies traffic and microservice gateways, eliminating the dual-layer architecture that Spring Cloud Gateway often requires in Kubernetes environments. You can migrate your services, configurations, and traffic to reduce resource consumption, operational costs, and custom development effort.
Prerequisites
Step 1: Identify the service source
If any of the following apply, skip to Step 2: Migrate Spring Cloud Gateway configurations.
-
You use Kubernetes Service for service discovery in Alibaba Cloud Container Service for Kubernetes (ACK).
-
You use an MSE Nacos service registry upgraded to a version that supports MCP.
-
You use services with fixed domain names or addresses, without service discovery.
To connect a self-managed service registry to API Gateway:
-
Purchase an MSE Nacos service registry. Create a Nacos engine.
-
Update your configuration or code to register services with MSE Nacos. Java SDK.
-
Optional: For Java applications, use the MSE governance agent to migrate your service registry. MSE Sync migration solution.
Step 2: Migrate Spring Cloud Gateway configurations
Analyze your Spring Cloud Gateway configurations and map them to API Gateway equivalents.
-
Service registry: API Gateway uses a service source to connect to a service registry. In the API Gateway console, create a service source for MSE Nacos, then create a service that uses it.
spring: application: name: gateway-demo cloud: nacos: discovery: server-addr: nacos-server:8848 config: enabled: false -
Service association configuration: On the Policy Configuration tab of your service, find the Load Balancing Configurations section and configure load balancing. This replaces client-side configurations such as Ribbon load balancing.
service-a: ribbon: NFLoadBalancerRuleClassName: com.netflix.loadbalancer.WeightedResponseTimeRule ConnectTimeout: 1000 ReadTimeout: 8000 MaxAutoRetries: 3 MaxAutoRetriesNextServer: 2 MaxTotalConnections: 20000 MaxConnectionsPerHost: 5000-
Routing configuration: Create the corresponding API, configure routes using the Route settings, and apply Route policies for circuit breaking.
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 authentication and authorization
API Gateway supports multiple authentication and authorization methods:
Step 4: View global gateway data
API Gateway provides a global monitoring dashboard:
Step 5: Migrate traffic
Common strategies for migrating traffic to API Gateway:
-
Iterative client-side migration: Incrementally update service endpoints for specific business scenarios to validate the migration.
-
Canary release at the proxy layer: Configure the existing proxy layer to gradually forward traffic to API Gateway, for example by splitting traffic between core and non-core services.
-
Full switchover using DNS: After sufficient canary testing, update the DNS record to point to API Gateway.
-
(Recommended) Phased migration:
-
Select a few services for initial testing and acceptance.
-
Gradually migrate traffic for core scenarios by using a canary release approach.
-
After thorough performance and stress testing, update the DNS record to complete the migration.
-
|
Migration strategy |
Cost |
Risk |
|
Iterative migration |
High |
Low |
|
Canary release at the proxy layer |
Medium |
Medium |
|
Full switchover using DNS |
Low |
High |
|
Phased migration |
Relatively low |
Relatively low |