Serverless App Engine:Migración de aplicaciones

¿Por qué migrar a SAE?

SAE reduce la sobrecarga de infraestructura para que su equipo se enfoque en el desarrollo de aplicaciones. Después de la migración, obtiene lo siguiente:

• Controles de despliegue flexibles: configuración de parámetros de inicio, proceso de despliegue visual, liberación y apagado controlados, además de liberación por fases.

• Tras la versión comercial, incluye detección de servicios y gestión de configuración integradas. Estas funciones reemplazan al middleware autoadministrado como Eureka, ZooKeeper y Consul.

• Gobernanza centralizada de servicios: consulte los detalles de los servicios publicados y consumidos desde la consola de SAE.

• Escalado automático: escale instancias de forma dinámica según las fluctuaciones del tráfico.

• Monitoreo avanzado: consulte métricas de instancias, trazas de microservicios, topología de llamadas al sistema y consultas SQL lentas.

• Limitación de velocidad y degradación: mantenga la alta disponibilidad de las aplicaciones Spring Cloud bajo carga.

• Liberación canary integral: implemente nuevas versiones en un subconjunto de aplicaciones Spring Cloud antes de publicarlas por completo.

¿Qué es la migración fluida?

Proceso de migración

1. Migrar las aplicaciones

   Comience por las propias aplicaciones. La mayoría carece de estado y debe migrarse primero.

2. Opcional: migrar la instancia de Server Load Balancer (SLB) o actualizar la configuración del nombre de dominio

   Una vez migradas las aplicaciones, actualice el vínculo de la instancia de SLB o la configuración del nombre de dominio para dirigir el tráfico al nuevo entorno.

   • Instancia de SLB

     • Si utilizaba una instancia de SLB antes de la migración, puede reutilizarla después. Elija un método de vinculación según sus necesidades. Para obtener más información, consulte Bind a CLB instance for public or private access.

     • Si no utilizaba ninguna instancia de SLB antes de la migración, cree una y vincúlela a la aplicación de entrada (como una puerta de enlace de API) después de la migración.

     • Durante la migración, habilite el registro dual y la suscripción dual para reducir los costos de Elastic Compute Service (ECS). Si no es posible reutilizar una instancia de ECS existente (por ejemplo, porque su puerto original está ocupado), utilice la solución de migración por división de tráfico y agregue nuevas instancias de ECS. Al terminar, reutilice la instancia de SLB existente o cree una nueva y vincúlela a la aplicación migrada.

   • Nombre de dominio

     • Si reutiliza la instancia de SLB, no necesita modificar el nombre de dominio.

     • Si crea una nueva instancia de SLB, agréguela a la configuración del nombre de dominio y elimine la anterior. Para obtener más información, consulte Modify DNS servers.

3. Opcional: migrar el almacenamiento y las colas de mensajes

   • Si su aplicación está desplegada en Alibaba Cloud y utiliza servicios como ApsaraDB RDS y Message Queue, no es necesario migrar el almacenamiento ni las colas de mensajes.

   • Si su aplicación no está en Alibaba Cloud, únase al grupo de DingTalk (ID: 32874633) para recibir asistencia técnica.

Soluciones de migración

SAE admite dos soluciones de migración: división de tráfico, y registro dual con suscripción dual. Ambas mantienen las aplicaciones en ejecución durante todo el proceso.

• División de tráfico

  Cambie el registro de servicios original a SAE Config Server mediante Dubbo. Luego, desarrolle un nuevo conjunto de aplicaciones y despliéguelas en SAE. Por último, utilice SLB y nombres de dominio para redirigir el tráfico.

  Para conocer los pasos de desarrollo de aplicaciones con la solución de división de tráfico, consulte Microservice scenarios.

• Registro dual y suscripción dual

  Con el registro dual y la suscripción dual, las aplicaciones se registran y se suscriben de forma simultánea tanto al registro de servicios original como al de SAE. Esto permite que las aplicaciones migradas y las no migradas se descubran y se llamen entre sí durante toda la ventana de migración.

  A continuación se muestra la arquitectura de la solución de migración por registro dual y suscripción dual.

  

  Principales ventajas del registro dual y la suscripción dual:

  • Las aplicaciones migradas y las no migradas pueden descubrirse y llamarse entre sí, lo que mantiene la continuidad del negocio.

  • Solo requiere agregar una dependencia pequeña y modificar mínimamente el código.

  • Consulte los detalles de las llamadas a los servicios consumidores y dé seguimiento al progreso de la migración en tiempo real.

  • Ajuste las directivas de registro y suscripción de servicios de forma dinámica, sin reiniciar las aplicaciones repetidamente. Solo se necesita un reinicio durante toda la migración.

Referencias

Para consultar las guías de migración específicas de cada arquitectura de microservicios, vea lo siguiente:

• Smoothly migrate Spring Cloud applications to SAE

• Migrate Dubbo applications to SAE