Migrate services from a Zuul gateway to a cloud-native gateway - Microservices Engine

Microservices framework selection is evolving with the development of cloud-native technology. In the cloud era, Kubernetes reshapes the O&M system. Zuul gateways do not support container service discovery and have poor performance in comparison with NGINX Ingress gateways. In terms of observability and security, Zuul gateways require custom development and integration. These disadvantages limit technological development of Zuul gateways. Cloud-native gateways are developed by integrating traditional traffic gateways with microservice gateways. Cloud-native gateways can help reduce service costs and have the advantages of high performance, high integration, and out-of-the-box. This topic describes how to migrate services from a Zuul gateway to a 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

If one of the following conditions is met, directly go to Step 2: Migrate the configurations of a Zuul gateway.

Container Service for Kubernetes (ACK) is used, and services can be discovered by using Kubernetes.
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 Zuul gateway

Sample configurations of a Zuul gateway:

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 a Zuul gateway in the MSE console, perform the following operations:

Configure a registry
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.
Associate services
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
```
Configure routing parameters
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.

Table 1. Differences among various traffic migration solutions
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.