This topic describes how to migrate services from Zuul to Cloud-native Gateway.

Background information

The architecture of microservices rapidly evolves with the development of cloud-native technologies. Despite being one of the most popular gateways in the past, Zuul has lost leadership in the gateway market. In the cloud era in which Kubernetes reforms the O&M system, Zuul cannot discover container services or provide the same performance as NGINX Ingress. Custom development is required for use of Zuul in terms of observability and security. These disadvantages prevent Zuul from progressing. Cloud-native Gateway integrates traditional traffic gateways with microservice gateways, helps significantly reduce service costs, and provides multiple benefits that allow you to upgrade the cloud architecture for your services. The benefits include high performance, high integration, and out-of-the-box features.

Step 1: Confirm the service source

If one of the following conditions is met, you can skip to Step 2: Migrate the configurations of Zuul.

  • Container Service for Kubernetes (ACK) is used, and services can be discovered by using Kubernetes.
  • MSE Nacos is purchased as a registry and updated 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.

If one of the following conditions is met, you can perform condition-specific operations to migrate services to Cloud-native Gateway.

  • A custom registry is used.
    1. Purchase an MSE Nacos registry. For more information, see Create a Nacos engine.
    2. Configure the parameters or modify code and register your services in MSE Nacos. For more information, see Java SDK.
    3. Optional:You can migrate Java applications to a new registry based on MSE governance and Java Agent. For more information, see Migration solution.
  • A shared registry of Enterprise Distributed Application Service (EDAS) is used.
  • A shared registry of Serverless App Engine (SAE) is used.
    1. Purchase an MSE Nacos registry. For more information, see Create a Nacos engine.

Step 2: Migrate the configurations of Zuul

Sample configurations of Zuul:

  • Configurations for an associated registry
    spring:
      application:
        name: zuul-demo
      cloud:
        nacos:
          discovery:
            server-addr: nacos-server:8848
          config:
            enabled: false
  • Configurations for routing services
    zuul:
      routes:
        demo:
          path: /test/a
          serviceId: service-a
        pre:
          path: /auth/validation/**
          serviceId: service-a
        header:
          path: /auth/test
          requestHeadersToAdd:
          - key: debug_tag
            value: true
        retry:
          path: /app/try/**
          stripPrefix: false
          retryable: true
          serviceId: service-a
      retryable: true
      ignoredPatterns:
      - /login/api/a/v3/a
      - /auth/api/b
    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 Zuul in the MSE console, perform the following operations:

  • Configure a registry

    Cloud-native Gateway manages various types of registries by using service sources. You can create a service source and import services in the MSE console. The configuration takes effect in real time. For more information, see Add a service source.

  • Associate services
    1. Add a service source and import a microservice that you want to subscribe from the service source. For more information, see Add a service.
    2. Specify an appropriate service version for the added microservice. 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
  • Configure routing parameters

    Configure a routing policy for a cloud-native 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 Gateway supports multiple routing policies. For more information, see the following topics:

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

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

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

Cloud-native Gateway allows you to 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 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 a new 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 Domain Name System (DNS)-based full migration after you complete stress testing.
Table 1. Differences among various traffic migration plans
Migration plan 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