This document describes how to migrate services from Spring Cloud Gateway to the Cloud Native Gateway.
Step 1: Clarifying the Service Source
SCG configurations can be migrated directly if your services come from the following sources:
Kubernetes services (using TKE or EKS)
Registry services (using TSF or self-built Nacos/Consul/Polaris)
Use domain names/fixed IP addresses/IP address lists without relying on any service discovery mechanism.
If your services come from other types of registries, perform migration to register the services to Nacos/Consul/Polaris, and then migrate SCG configurations.
Step 2: Migrating SCG Configurations
SCG-related features can be configured in the console.
1. Registry/Kubernetes cluster
Cloud Native Gateway associates your registry or Kubernetes cluster through service sources. After adding a service source of the corresponding type, you can add the corresponding services as gateway services. For service source configuration, refer to the following document: Service Sources. 2. Service configuration
The service in Spring Cloud Gateway corresponds to the service in Cloud Native Gateway. For service configuration, refer to the following document: Service. 3. Route configuration
The routes in Spring Cloud Gateway correspond to the routes in Cloud Native Gateway. For route configuration, refer to the following document: Routes. 4. Common predicate configuration
Host/Method/Path Route Predicate: Cloud Native Gateway supports route matching based on Host, Method, or Path. You can set matching conditions when creating a route.
Header/Cookie/Query Route Predicate: Cloud Native Gateway supports routing based on these parameters, which can be implemented through canary rules. For configuration, refer to the following document: Canary Release. 5. Default Filter
The filter in Spring Cloud Gateway corresponds to the following configuration in Cloud Native Gateway:
|
AddRequestHeader, RemoveRequestHeader, AddRequestParameter, AddResponseHeader, SetResponseHeader | Using the tse-proxy-rewrite plugin | |
Hystrix, RequestRateLimiter | Traffic throttling | |
PrefixPath | Route matching based on the default prefix matching mode | - |
PreserveHostHeader, StripPath, Retry | Retaining the Host and StripPath options and setting the retry times during route creation | |
SetPath, RewritePath | Using the Request Transformer/Response Transformer plugin | - |
6. Custom Filter
For authentication and authorization, Cloud Native Gateway supports mainstream authentication and authorization methods. For configuration, refer to the following document.
7. Custom Filter
Cloud Native Gateway supports custom logic processing using custom plugins. You need to code and implement the logic of custom Filters through custom plugins. For details, refer to Custom Plugin. Step 3: Configuring Gateway Monitoring and Alarms
Cloud Native Gateway supports monitoring and alarm viewing. You can configure relevant monitoring information to understand the current gateway status. For using monitoring and alarms, see the following document.
Step 4: Migrating Traffic
After the preceding preparation is complete, gradually switch traffic in the grayscale method and eventually complete traffic migration.
Phase 1: Configure services and routes for some non-core business scenarios and modify the access addresses for small-scale verification.
Phase 2: Gradually change the configurations of core businesses and migrate traffic in some core scenarios.
Phase 3: After full verification, switch to the new DNS address and perform full migration.