Enterprise Distributed Application Service:Migración de un clúster de Spring Cloud con múltiples aplicaciones a EDAS

Razones para migrar a EDAS

EDAS reemplaza la carga operativa de la infraestructura de Spring Cloud autogestionada por una plataforma gestionada. Después de la migración:

• Despliegue flexible: configure los parámetros de inicio, supervise visualmente el progreso del despliegue y utilice la conexión y desconexión gradual de servicios para evitar solicitudes perdidas.

• Descubrimiento de servicios integrado: EDAS proporciona descubrimiento de servicios y gestión de configuración en su versión comercial, lo que elimina la necesidad de gestionar Eureka, ZooKeeper o Consul por cuenta propia.

• Administración centralizada de servicios: consulte los servicios publicados y consumidos desde la consola de EDAS. Además de consultar información de instancias, acceda a trazas de microservicios, topología de llamadas del sistema y análisis de SQL lentas.

• Auto Scaling: escale dinámicamente las instancias de la aplicación hacia adentro o hacia afuera según el tráfico.

• Versiones graduales: ejecute versiones graduales de extremo a extremo para validaciones a pequeña escala antes de implementar actualizaciones en todas las instancias.

• Limitación de tasa y degradación: aplique limitación de tasa y degradación de servicios para mantener la estabilidad de la aplicación bajo cargas elevadas.

Elección del método de migración

EDAS admite dos métodos de migración. Ambos preservan la continuidad del servicio.

Si elige el cambio de registro, siga la configuración estándar en Implement service registration and discovery. El resto de esta guía aborda el registro dual y la suscripción dual.

Descripción general de la migración

La migración consta de tres fases:

1. Migrar aplicaciones (obligatorio): las aplicaciones sin estado se migran primero, una por una.

2. Migrar la instancia de Server Load Balancer (SLB) o actualizar DNS (opcional): dirija el tráfico hacia el nuevo despliegue.

3. Migrar almacenamiento y colas de mensajes (opcional): solo es necesario si sus aplicaciones no utilizan ya servicios de Alibaba Cloud como ApsaraDB RDS y Message Queue.

Esta guía se centra en la fase 1.

Fase 1: Migrar aplicaciones

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    <version>{Version}</version>
</dependency>

spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848
ribbon.nacos.enabled=false

<dependency>
    <groupId>com.alibaba.edas</groupId>
    <artifactId>edas-sc-migration-starter</artifactId>
    <version>1.0.5</version>
</dependency>

@SpringBootApplication
public class ConsumerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args);
    }
}

@SpringBootApplication
@RibbonClients(defaultConfiguration = MigrationRibbonConfiguration.class)
public class ConsumerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args);
    }
}

Fase 2: Migrar la instancia de SLB o actualizar DNS (opcional)

Una vez migradas todas las aplicaciones, actualice el enrutamiento de red:

• Si se utilizaba una instancia de SLB antes de la migración, reutilícela . Puede seleccionar una directiva para adjuntar la instancia de SLB según sea necesario. Para más información, consulte SLB binding overview.

• Si no se utilizaba ninguna instancia de SLB, cree una y vincúlela a su aplicación de punto de entrada (por ejemplo, API Gateway).

• Configuración de nombre de dominio:

  • Si se reutiliza la instancia de SLB, no se requieren cambios de DNS.

  • Si se crea una nueva instancia de SLB, actualice el DNS para que apunte a la nueva instancia de SLB y elimine la anterior. Consulte Change DNS servers for a domain name.

Fase 3: Migrar almacenamiento y colas de mensajes (opcional)

Si sus aplicaciones ya utilizan servicios de Alibaba Cloud como ApsaraDB RDS y Message Queue, no es necesario migrar el almacenamiento ni las colas de mensajes.

Si sus aplicaciones no están en Alibaba Cloud, póngase en contacto con el soporte técnico de EDAS para obtener un plan de migración completo.

Ajuste dinámico de directivas de registro y suscripción

Durante la migración, puede ajustar a qué registros se registra o se suscribe una aplicación sin necesidad de reiniciar. Utilice la función de gestión de configuración de EDAS, Spring Cloud Config o Nacos Config para actualizar las siguientes propiedades en tiempo de ejecución.

# Subscribe to both Eureka and Nacos
spring.cloud.edas.migration.subscribes=nacos,eureka

# Subscribe to Nacos only
spring.cloud.edas.migration.subscribes=nacos

# Register with all registries (default)
spring.cloud.edas.migration.registry.excludes=

# Stop registering with Eureka
spring.cloud.edas.migration.registry.excludes=eureka

# Stop registering with both Nacos and Eureka
spring.cloud.edas.migration.registry.excludes=nacos,eureka

Limpieza posterior a la migración

Una vez que todas las aplicaciones se ejecuten en EDAS, elimine la configuración específica de la migración:

1. Elimine la dependencia edas-sc-migration-starter del archivo pom.xml (o build.gradle) de cada aplicación.

2. Quite la anotación @RibbonClients(defaultConfiguration = MigrationRibbonConfiguration.class) de la clase principal.

3. Elimine la dependencia y la configuración del registro de servicios original (por ejemplo, la configuración del cliente de Eureka o Consul).

4. Elimine ribbon.nacos.enabled=false de application.properties.

5. Reinicie las aplicaciones en lotes durante horas de baja demanda.

Proyecto de demostración

EDAS proporciona un proyecto de ejemplo que demuestra el registro dual y la suscripción dual. Descargue el proyecto y siga el archivo README incluido para ejecutarlo localmente.