Tous les produits
Search

Ce produit

    ApsaraMQ for RabbitMQ:Migrating from open-source

    Centre de documentation

    ApsaraMQ for RabbitMQ:Migrating from open-source

    Dernière mise à jour :Aug 11, 2026

    Migrez votre cluster RabbitMQ autonome vers Message Queue for RabbitMQ pour résoudre les problèmes de stabilité tels que l'accumulation de messages et le partitionnement (split-brain), tout en bénéficiant d'une haute concurrence, d'une architecture distribuée et d'une mise à l'échelle flexible.

    Avant de commencer

    Message Queue for RabbitMQ est un service de messagerie développé par Alibaba Cloud sur la base d'une technologie propriétaire de stockage distribué des messages. Il respecte le protocole AMQP 0-9-1, mais n'est pas simplement une version gérée de RabbitMQ open source. Son architecture prévient les problèmes de stabilité tels que les fuites de mémoire et les pannes de serveur causées par l'accumulation de messages, et élimine le problème de split-brain dans les systèmes distribués. Il offre également une grande extensibilité et une facturation flexible au paiement à l'utilisation pour réduire les coûts.

    Toutefois, Message Queue for RabbitMQ diffère de RabbitMQ open source sur certaines fonctionnalités. Avant la migration, évaluez les capacités techniques et le rapport coût-bénéfice afin de vous assurer que le service répond à vos besoins.

    Évaluation avant migration

    Évaluation technique

    • Message Queue for RabbitMQ et RabbitMQ open source présentent des différences en termes de fonctionnalités, de service, de performances, d'exchanges et de files d'attente. Avant la migration, examinez ces différences pour déterminer si Message Queue for RabbitMQ répond à vos besoins. Pour une comparaison détaillée, consultez Comparaison avec RabbitMQ open source.

    • Message Queue for RabbitMQ impose des limites sur les clusters, les appels API et les caractères. Avant la migration, évaluez si ces limites sont compatibles avec vos exigences métier. Pour plus d'informations, consultez Types d'instances.

    • Nous vous recommandons de choisir une instance serverless dédiée. Ces instances prennent en charge l'authentification et les autorisations open source, ce qui permet une migration transparente de RabbitMQ open source vers le cloud.

    Évaluation des coûts

    Message Queue for RabbitMQ propose des instances sous abonnement et serverless avec diverses spécifications. Pour connaître les différences entre les spécifications, consultez Types d'instances.

    Par rapport aux instances sous abonnement, les instances serverless offrent une meilleure élasticité et un meilleur rapport qualité-prix. Pour les règles de facturation, consultez Facturation des instances serverless.

    Estimez les opérations d'envoi/réception, le nombre de files d'attente et le volume de messages de votre cluster RabbitMQ autonome à l'aide des méthodes suivantes.

    • Nombre de files d'attente : sur la page Overview de la console RabbitMQ open source, consultez Global counts pour obtenir le nombre d'objets de métadonnées tels que Queues et Exchanges.

    • Nombre d'opérations d'envoi/réception et volume de messages :

      • Méthode 1 : sur la page Overview de la console de gestion RabbitMQ open source, consultez Message rates et calculez la somme des métriques Publish, Deliver (manual ack)/Deliver (auto ack) et Redelivered.image

      • Méthode 2 : utilisez un tableau de bord Prometheus Grafana pour consulter le QPS à l'échelle du cluster et le volume de messages pour le trafic entrant et sortant.

    Procédure de migration

    Migrer les métadonnées

    Pour migrer les métadonnées, exportez-les depuis votre cluster RabbitMQ open source et importez-les dans votre instance Message Queue for RabbitMQ. Après une importation réussie, Message Queue for RabbitMQ crée les vhosts, files d'attente, exchanges et bindings correspondants dans l'instance Message Queue for RabbitMQ cible. Pour les étapes détaillées, consultez Migrer les métadonnées vers le cloud.

    Créer des utilisateurs

    Les clients open source doivent utiliser un nom d'utilisateur et un mot de passe pour s'authentifier auprès d'un courtier Message Queue for RabbitMQ. Les connexions ne sont établies qu'après une authentification réussie. Message Queue for RabbitMQ prend en charge les deux modes suivants de gestion des identités et des autorisations. Pour plus d'informations, consultez Gestion des utilisateurs et des autorisations.

    • Authentification et autorisation open source

      Créez des noms d'utilisateur et des mots de passe personnalisés, et gérez les autorisations en important les métadonnées .

    • Resource Access Management (RAM)

      Générez des noms d'utilisateur et des mots de passe à partir de l'AccessKey ID et de l'AccessKey Secret d'un utilisateur RAM.

    Établir une connexion réseau

    Message Queue for RabbitMQ fournit un endpoint PrivateLink qui vous permet de vous connecter au cloud via Cloud Enterprise Network (CEN).

    Si vous utilisez le mode d'authentification et d'autorisation open source et avez déjà configuré un endpoint PrivateLink, ignorez cette étape.

    Migrer les données de message

    Stratégie de migration

    Pour garantir une migration fluide, migrez les données de message par vhost en modifiant les configurations de connexion client et en utilisant le plug-in RabbitMQ Shovel.

    Avantages

    • Garantit une migration métier sans interruption.

    • Garantit l'absence de perte de données.

    • Élimine la nécessité de mapper des topologies maillées complexes d'appels inter-applications.

    Étapes de migration

    Choisissez les étapes de migration appropriées en fonction de votre scénario :

    • Pour une migration sans temps d'arrêt :

      • Si les producteurs et les consommateurs d'une file d'attente se trouvent dans la même application, consultez Scénario 1.

      • Si les producteurs et les consommateurs d'une file d'attente se trouvent dans des applications distinctes, consultez Scénario 2.

      • Pour les scénarios complexes où le cluster RabbitMQ autonome exécute déjà des tâches Shovel, consultez Scénario 3 .

    • Pour une migration avec fenêtre de maintenance : si votre activité peut tolérer une brève interruption, consultez Scénario 4.

    Scénario 1 : Migration sans temps d'arrêt (applications unifiées)
    image

    1. Commencez par un déploiement canari : basculez quelques nœuds de service vers l'instance cloud en mettant à jour leurs configurations client. Vérifiez les points suivants :

      1. Les producteurs peuvent envoyer des messages à la file d'attente cloud.

      2. Les consommateurs peuvent consommer des messages depuis la file d'attente cloud.

      3. La fonctionnalité et les performances de bout en bout répondent aux attentes.

    2. Après avoir confirmé que les nœuds canaris fonctionnent correctement, configurez et activez le plug-in Shovel sur votre cluster RabbitMQ autonome. Cela permettra de migrer les messages accumulés existants depuis les files d'attente du vhost spécifié vers les files d'attente correspondantes dans l'instance cloud.

    3. Basculez la configuration de connexion RabbitMQ vers l'instance cloud pour tous les nœuds de service restants en utilisant une mise à jour progressive. À ce stade :

      1. Tous les nouveaux messages sont écrits directement dans les files d'attente cloud.

      2. Tous les consommateurs récupèrent les messages depuis les files d'attente cloud.

      3. Le cluster autonome ne reçoit plus de nouveaux messages et sert uniquement de source au Shovel pour vider l'accumulation restante.

    4. Surveillez l'accumulation de messages dans les files d'attente du cluster autonome. Une fois l'accumulation vidée, arrêtez la tâche Shovel.

    5. Vérifiez l'accumulation pour les files d'attente d'un vhost dans la console de gestion de votre cluster RabbitMQ autonome. L'accumulation d'une file d'attente est considérée comme vidée lorsque les comptes de messages prêts (ready) et non acquittés (unacknowledged) sont tous deux à 0.

      Dans la console RabbitMQ Management, sur la page Queues, le groupe Messages affiche le nombre de messages prêts dans la colonne Ready et le nombre de messages non acquittés dans la colonne Unacked.

      Important

      Si votre code envoie des messages différés à un exchange x-delayed-message, ces messages n'entrent pas dans la file d'attente et ne comptent pas dans l'accumulation tant que leur période de délai n'est pas expirée. Avant d'arrêter la tâche Shovel, attendez au moins la durée du délai maximal configuré pour les messages afin de vous assurer que tous les messages différés entrent dans leurs files d'attente respectives.

    Scénario 2 : Migration sans temps d'arrêt (applications séparées)
    image

    1. Configurez et activez le plug-in Shovel sur votre cluster RabbitMQ autonome pour migrer les messages accumulés existants depuis toutes les files d'attente pertinentes du vhost cible vers les files d'attente correspondantes dans l'instance cloud.

    2. Démarrez les services consommateurs pour l'instance RabbitMQ cloud afin qu'ils commencent à récupérer les messages depuis les files d'attente cloud.

    3. Après avoir vérifié que les consommateurs cloud fonctionnent correctement, arrêtez les services consommateurs connectés au cluster autonome.

    4. Démarrez les services producteurs pour l'instance RabbitMQ cloud. Vérifiez que les nouveaux messages sont publiés avec succès dans les files d'attente cloud et traités par les consommateurs.

    5. Après avoir confirmé que les nouveaux messages circulent correctement dans les files d'attente cloud et sont consommés, arrêtez les services producteurs connectés au cluster autonome.

    6. À ce stade, tous les nouveaux messages vont directement dans les files d'attente cloud, tandis que le Shovel continue de déplacer les messages restants depuis le cluster autonome.

    7. Surveillez l'accumulation de messages dans les files d'attente du cluster autonome. Une fois l'accumulation vidée, arrêtez la tâche Shovel.

    Scénario 3 : Migration sans temps d'arrêt (avec des tâches Shovel existantes)
    image

    1. Arrêtez les services producteurs et consommateurs connectés au cluster autonome, et mettez à jour leurs configurations pour qu'elles pointent vers l'instance RabbitMQ cloud.

    2. Démarrez les services producteurs et consommateurs connectés à l'instance cloud et vérifiez qu'ils fonctionnent correctement.

    3. Sur le cluster autonome, configurez une nouvelle tâche Shovel (Shovel A) pour migrer l'accumulation de messages depuis toutes les files d'attente pertinentes du vhost A vers les files d'attente correspondantes dans l'instance cloud.

    4. Suspendez la tâche Shovel existante (Shovel B) qui déplace les messages du vhost B vers le vhost A. Modifiez la destination de Shovel B pour qu'elle pointe vers la file d'attente correspondante dans l'instance RabbitMQ cloud, puis réactivez Shovel B.

    5. Surveillez l'accumulation de messages dans les files d'attente du vhost B sur le cluster autonome. Une fois l'accumulation vidée, supprimez la tâche Shovel B.

    6. Surveillez l'accumulation de messages dans les files d'attente du vhost A sur le cluster autonome. Une fois l'accumulation vidée, supprimez la tâche Shovel A.

    Scénario 4 : Migration avec temps d'arrêt
    image

    1. Arrêtez les services producteurs et consommateurs connectés au cluster autonome.

    2. Mettez à jour la configuration RabbitMQ dans vos services pour qu'elle pointe vers l'instance RabbitMQ cloud.

    3. Démarrez les services producteurs et consommateurs pour l'instance cloud et vérifiez qu'ils fonctionnent correctement.

    4. Sur votre cluster RabbitMQ autonome, configurez et activez le plug-in Shovel pour migrer tous les messages restants depuis les files d'attente vers les files d'attente correspondantes dans l'instance cloud.

    5. Surveillez l'accumulation de messages dans les files d'attente du cluster autonome. Une fois l'accumulation vidée, arrêtez la tâche Shovel.

    Utilisation du plug-in Shovel

    1. Connectez-vous à votre cluster autonome et exécutez la commande suivante en ligne de commande pour activer le plug-in Shovel :

      rabbitmq-plugins enable rabbitmq_shovel rabbitmq_shovel_management

    1. Connectez-vous à la console de gestion de votre cluster RabbitMQ autonome. Dans la barre de navigation supérieure, cliquez sur Admin, puis cliquez sur Shovel Management à droite. Dans la section Add a new shovel, configurez Source et Destination, puis cliquez sur Add shovel.

      1. Format de configuration Source : pour URI, saisissez amqp://{username}:{password}@{ip}:{port}/{vhost}. Dans cet URI : username et password sont vos identifiants, ip est l'adresse IP de votre cluster autonome, port est le port de communication (généralement 5672), et vhost est le vhost source.

      2. Format de configuration Destination : pour URI, saisissez amqp://{username}:{password}@{endpoint}:{port}/{vhost}. Dans cet URI : username et password sont les identifiants statiques créés dans la console Message Queue for RabbitMQ, endpoint est l'adresse endpoint de votre instance Message Queue for RabbitMQ, port est 5672, et vhost est le vhost de destination.

      Vous devez également configurer Virtual host, un Name obligatoire, le protocole (tel que AMQP 0.9.1), ainsi que les noms des files d'attente source et destination. Les autres paramètres incluent Prefetch count, Auto-delete (par défaut Never), Add forwarding headers (par défaut No), Reconnect delay et Acknowledgement mode (par défaut On confirm).

    2. Une fois le Shovel ajouté, accédez à la page Shovel Status pour vérifier son état. Un état en cours d'exécution indique que la tâche a démarré avec succès.

    3. Une fois l'accumulation de messages dans les files d'attente de votre cluster RabbitMQ autonome vidée, supprimez la tâche Shovel.

      Sur la page des détails du Shovel, développez la section Delete this shovel en bas et cliquez sur le bouton Delete this shovel.

    Références

    Pour plus d'informations sur le plug-in Shovel, consultez la documentation Shovel Plugin.