Scénario de développement : Isoler les environnements à l'aide de Message Queue for Apache RocketMQ - Serverless App Engine

Serverless App Engine (SAE) s'intègre à ApsaraMQ for RocketMQ pour étendre l'isolation complète des environnements aux chemins de messages asynchrones, sans modifier le code métier.

Fonctionnement

dg_rocket_mq_workflow

Lorsque la fonctionnalité de déploiement canari est activée, SAE utilise les propriétés des messages RocketMQ pour router les messages selon le tag d'environnement. Le tag apposé sur chaque message détermine le groupe de consommateurs qui le reçoit :

Tag d'environnement	Groupe de consommateurs (exemple)	Messages routés vers
(aucun — baseline)	`group1`	Uniquement les consommateurs de l'environnement de base (baseline)
`gray`	`group1_gray`	Uniquement les consommateurs du déploiement canari

L'environnement de base peut consommer des messages provenant des deux environnements. Les appels déclenchés par la consommation de messages suivent les mêmes règles de routage que le trafic synchrone : les requêtes issues de l'environnement canari sont dirigées vers les services en aval canaris, tandis que les requêtes de base sont acheminées vers les services en aval de base.

La fonctionnalité de déploiement canari n'est effective pour les messages que si elle est activée à la fois sur les producteurs et les consommateurs. Si un seul côté l'active, la fonctionnalité ne produit aucun effet.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

Une version prise en charge de Message Queue for Apache RocketMQ. Versions prises en charge : 4.2.0 et ultérieures.

Variante de RocketMQ	Exigence de version
Apache RocketMQ (open source)	Serveur RocketMQ et client RocketMQ 4.5.0 ou version ultérieure
ApsaraMQ for RocketMQ (commercial)	Édition Platinum ; Ons Client 1.8.0.Final ou version ultérieure. Pour plus d'informations, consultez la présentation du guide de démarrage rapide.

Le filtrage SQL92 activé sur le broker. Définissez enablePropertyFilter=true dans broker.conf et redémarrez le broker.
Les modes pull et push sont tous deux pris en charge.
Après activation de la fonctionnalité de déploiement canari basée sur RocketMQ, SAE modifie les groupes de consommateurs de messages. Par exemple, si votre groupe de consommateurs d'origine est group1 et que votre tag d'environnement est gray, SAE le renomme en group1_gray une fois la fonctionnalité activée. Si vous utilisez ApsaraMQ for RocketMQ, créez au préalable tous les groupes de consommateurs qui seront renommés par la fonctionnalité de déploiement canari avant de l'activer.

Étape 1 : Déployer les applications de démonstration

Téléchargez le package de démonstration.
Déployez les applications principales : Application A, Application B et Application C. Pour plus de détails, consultez Héberger des applications Spring Cloud sur SAE.
Déployez les applications de déploiement canari : Application A-gray, Application B-gray et Application C-gray. Ajoutez -Dalicloud.service.tag=gray à la commande de démarrage de chaque application canari afin de les distinguer des applications principales.

Si vous utilisez un registre de services autre que celui intégré à SAE, ajoutez les paramètres de démarrage suivants à chaque application : -Dnacos.use.endpoint.parsing.rule=false -Dnacos.use.cloud.namespace.parsing=false .

Étape 2 : Activer la fonctionnalité de déploiement canari

Dans cette démonstration, spring-cloud-c est le producteur et spring-cloud-a est le consommateur. Activez la fonctionnalité de déploiement canari sur les deux en ajoutant le paramètre de démarrage suivant :

-Dprofiler.micro.service.mq.gray.enable=true

Ajoutez ce paramètre à la commande de démarrage de spring-cloud-c et de spring-cloud-a, puis redéployez chaque application depuis la console SAE.

Pour désactiver la fonctionnalité, supprimez le paramètre et redéployez les applications.

Étape 3 : Vérifier l'isolation des environnements

dg_implement_end_to_end_canary_release_via_rocket_mq

La chaîne d'appels fonctionne comme suit :

spring-cloud-zuul reçoit une requête vers /A/dubbo et la transfère à spring-cloud-a.
spring-cloud-a appelle spring-cloud-b via le protocole Dubbo ; spring-cloud-b appelle ensuite spring-cloud-c.
spring-cloud-c produit un message RocketMQ et renvoie son tag d'environnement ainsi que son adresse IP.
spring-cloud-a consomme le message et appelle simultanément spring-cloud-b via le protocole Spring Cloud ; spring-cloud-b appelle à nouveau spring-cloud-c.
Les résultats apparaissent dans les journaux.

Envoyez une requête de test vers /A/dubbo. La réponse attendue et la sortie des journaux sont les suivantes :

# Response:
A[10.25.xx.xx] -> B[10.25.xx.xx] -> C[10.25.xx.xx]

# Log on spring-cloud-a after consuming the message:
c.a.mse.demo.service.MqConsumer: topic:TEST_MQ,producer:C[10.25.xx.xx],invoke result:A[10.25.xx.xx] -> B[10.25.xx.xx] -> C[10.25.xx.xx]

Pour consulter les journaux, connectez-vous à la console SAE et ouvrez les journaux de l'application spring-cloud-a.

Vérifiez que :

Les messages produits par une application de déploiement canari sont uniquement consommés par des consommateurs canaris.
Les messages produits par une application de base sont uniquement consommés par des consommateurs de base.
L'environnement de base peut également consommer des messages produits par des applications de déploiement canari.