Serverless App Engine:Migration d'applications

Pourquoi migrer vers SAE ?

SAE réduit la charge liée à l'infrastructure afin que votre équipe se concentre sur le développement des applications. Après la migration, vous bénéficiez des avantages suivants :

• Contrôle flexible du déploiement : configuration des paramètres de démarrage, visualisation du processus de déploiement, arrêt et mise hors service en douceur, ainsi que déploiement progressif.

• Découverte de services et gestion de la configuration intégrées remplaçant les intergiciels auto-gérés tels qu'Eureka, ZooKeeper et Consul.

• Gouvernance centralisée des services : consultez les détails des services publiés et consommés depuis la console SAE.

• Auto Scaling : ajustez dynamiquement le nombre d'instances à la hausse ou à la baisse en fonction des fluctuations du trafic.

• Surveillance avancée : consultez les métriques des instances, les traces des microservices, la topologie des appels système et les requêtes SQL lentes.

• Limitation de débit et dégradation : maintenez une haute disponibilité pour les applications Spring Cloud sous charge.

• Déploiement canari de bout en bout : déployez de nouvelles versions sur un sous-ensemble d'applications Spring Cloud avant une publication complète.

Qu'est-ce que la migration transparente ?

Processus de migration

1. Migration des applications

   Commencez par les applications elles-mêmes ; la plupart sont sans état et doivent être migrées en premier.

2. Facultatif : Migrez l'instance Server Load Balancer (SLB) ou mettez à jour les paramètres de nom de domaine

   Une fois les applications migrées, mettez à jour la liaison de l'instance SLB ou les paramètres de nom de domaine pour acheminer le trafic vers le nouvel environnement.

   • Instance SLB

     • Si une instance SLB était utilisée avant la migration, réutilisez-la. Choisissez une méthode de liaison selon vos besoins. Pour plus d'informations, consultez la rubrique Lier une instance CLB pour un accès public ou privé.

     • Si aucune instance SLB n'était utilisée avant la migration, créez-en une et liez-la à l'application d'entrée (telle qu'une passerelle API) après la migration.

     • Lors de la migration, activez la double inscription et la double souscription pour réduire les coûts Elastic Compute Service (ECS). Si une instance ECS existante ne peut pas être réutilisée (par exemple, parce que son port d'origine est occupé), utilisez la solution de migration avec répartition du trafic et ajoutez de nouvelles instances ECS. Après la migration, réutilisez l'instance SLB existante ou créez-en une nouvelle et liez-la à l'application migrée.

   • Nom de domaine

     • Si l'instance SLB est réutilisée, aucune modification du nom de domaine n'est nécessaire.

     • Si une nouvelle instance SLB est créée, ajoutez-la aux paramètres de nom de domaine et supprimez l'ancienne. Pour plus d'informations, consultez la rubrique Modifier les serveurs DNS.

3. Facultatif : Migrez le stockage et les files d'attente de messages

   • Si votre application est déployée sur Alibaba Cloud et utilise des services Alibaba Cloud tels qu'ApsaraDB RDS et Message Queue, aucune migration du stockage ou des files d'attente de messages n'est requise.

   • Si votre application n'est pas hébergée sur Alibaba Cloud, rejoignez le groupe DingTalk (ID : 32874633) pour obtenir une assistance technique.

Solutions de migration

SAE prend en charge deux solutions de migration : la répartition du trafic et la double inscription/double souscription. Les deux permettent de maintenir les applications en cours d'exécution tout au long de la migration.

• Répartition du trafic

  Basculez le registre de services original vers SAE Config Server en utilisant Dubbo, développez un nouvel ensemble d'applications, puis déployez-les sur SAE. Ensuite, utilisez SLB et les noms de domaine pour rediriger le trafic.

  Pour les étapes de développement des applications liées à la solution de répartition du trafic, consultez la rubrique Scénarios de microservices.

• Double inscription et double souscription

  Avec la double inscription et la double souscription, les applications s'inscrivent auprès et s'abonnent simultanément au registre de services original et au registre de services SAE. Cela permet aux applications migrées et non migrées de se découvrir et de s'appeler mutuellement tout au long de la fenêtre de migration.

  La figure suivante illustre l'architecture de la solution de migration par double inscription et double souscription.

  

  Principaux avantages de la double inscription et de la double souscription :

  • Les applications migrées et non migrées peuvent se découvrir et s'appeler mutuellement, garantissant ainsi la continuité des activités.

  • Seul l'ajout d'une petite dépendance et des modifications minimales du code sont nécessaires.

  • Consultez les détails des appels de services consommateurs et suivez la progression de la migration en temps réel.

  • Ajustez dynamiquement les politiques d'inscription et de souscription des services sans redémarrages répétés des applications. Un seul redémarrage suffit lors de l'ensemble du processus de migration.

Références

Pour des guides de migration spécifiques à différentes architectures de microservices, consultez les rubriques suivantes :

• Migrer transparentement les applications Spring Cloud vers SAE

• Migrer les applications Dubbo vers SAE