Microservices Engine:Routage

Routage vers un service unique

La passerelle cloud-native transfère les requêtes vers un service backend spécifique selon des règles de routage. Pour plus d'informations sur la configuration des services, consultez la rubrique Ajouter un service.

La passerelle applique les règles de routage configurées aux requêtes entrantes. Par exemple :

• Elle transfère toutes les requêtes correspondant à la règle de routage /user vers le service user.

• Elle transfère toutes les requêtes correspondant à la règle de routage /order vers le service order.

Routage basé sur un pourcentage

La passerelle cloud-native répartit les requêtes entre plusieurs services backends en fonction du poids configuré pour chaque service. Voici les scénarios courants :

• Multiple Registry Centers

  Lors d'un changement de registre de services, déployez une réplique du service utilisant le nouveau registre tout en conservant le service et le registre d'origine. Transférez progressivement le trafic du service d'origine vers le nouveau. Après avoir vérifié la stabilité du nouveau service, basculez l'intégralité du trafic vers celui-ci. La migration permet un retour arrière si le nouveau service ne répond pas à vos exigences.

  La figure suivante illustre un exemple où le service user passe de Nacos à CoreDNS intégré pour Kubernetes. CoreDNS doit être utilisé conjointement avec les ressources de service.

  

• O&M System Differences

  Traditionnellement, la plupart des services s'exécutent sur des machines virtuelles telles que les instances Elastic Compute Service (ECS) d'Alibaba Cloud. À mesure que les entreprises migrent vers des plateformes basées sur Kubernetes comme Container Service for Kubernetes (ACK) d'Alibaba Cloud, vous pouvez déployer une réplique du service sur un cluster Kubernetes et l'enregistrer sous un nouveau nom dans le registre. Deux services aux fonctionnalités identiques coexistent alors : l'un sur une instance ECS et l'autre sur un cluster Kubernetes. Transférez progressivement le trafic d'ECS vers Kubernetes ; vous pouvez ajuster le pourcentage ou effectuer un retour arrière à tout moment.

  Par exemple, supposons que vous souhaitiez migrer un service user utilisant Nacos comme registre, d'ECS vers la plateforme Alibaba Cloud ACK.

  

Routage basé sur des tags

La passerelle cloud-native transfère les requêtes vers différentes versions d'un service en fonction du poids configuré pour chaque version. Pour plus d'informations sur la configuration des versions de service, consultez la rubrique Gérer les versions de service. Voici les scénarios courants :

• Canary release

  Une version canari transfère une petite partie du trafic vers une nouvelle version de service à des fins de vérification. Si le résultat correspond aux attentes, migrez progressivement le reste du trafic vers la nouvelle version.

  Par exemple, le service user déployé sur un cluster ACK exécute actuellement la version v1, et la version v2 est prévue pour publication. Vous pouvez effectuer une version canari de l'une des manières suivantes :

  • By ratio

    Le routage basé sur des tags transfère les requêtes /user vers le service user v1. Ajoutez le service user v2 sur la page de gestion des services dans la console Microservices Engine (MSE), puis ajoutez-le aux services de destination pour le routage basé sur des tags. Configurez un poids pour déterminer le pourcentage de trafic transféré vers le service user v2.

    

  • Tags

    Le routage basé sur des tags transfère les requêtes /user vers le service user v1. Ajoutez une route /user et configurez un tag indiquant que cette route sert à une version canari. Par exemple, le tag peut être l'en-tête stage avec la valeur gray. La route transfère les requêtes contenant ces en-têtes vers le service user v2.

    

• Tag-based routing

  Dans un environnement de production, plusieurs versions d'un service peuvent coexister pendant une période prolongée, chaque version gérant différents types de requêtes. Par exemple, transférez les requêtes ayant différentes valeurs d'en-tête vers différentes versions de service. Le routage basé sur des tags s'applique également lorsque plusieurs environnements (test, staging et production) coexistent, en utilisant des tags pour distinguer les requêtes destinées à chaque environnement.

  Par exemple, dans l'application suivante, un service user utilise le service de conteneurs K8s pour la découverte de services et dispose de trois environnements de développement (test, pre et online). Les paramètres pour les requêtes vers /user sont les suivants :

  • Si la valeur de l'en-tête stage est test, le trafic est transféré vers le service user dans l'environnement de test.

  • Si la valeur de l'en-tête stage est pre, le trafic est transféré vers le service user dans l'environnement de staging.

  • Si la valeur de l'en-tête stage est online, le trafic est transféré vers le service user dans l'environnement de production.

  

• High-availability deployment

  Pour garantir la disponibilité du service, déployez des services identiques sur plusieurs clusters Kubernetes. Gérez les instances de service par cluster en fonction des métadonnées des nœuds et ajustez le poids pour répartir le trafic entre les clusters. En cas de panne d'un cluster, définissez son poids sur 0 pour transférer tout le trafic vers les clusters restants.

  Par exemple, dans le système d'application suivant, la découverte de services est effectuée sur le service user déployé sur les clusters ACK A et B. Pour les requêtes /user , 80 % du trafic est transféré vers le service user déployé sur le cluster A, et 20 % du trafic est transféré vers le service user déployé sur le cluster B.

  

Routage mock

Le routage mock renvoie une réponse fixe pour une route, ce qui permet de vérifier si les requêtes sont correctement transférées. Cela permet au développement frontend et backend de se dérouler en parallèle.

Par exemple, lorsque le service backend user n'est pas encore terminé, configurez une réponse fixe pour ses opérations API afin que les développeurs frontend puissent tester le processus de routage. Une fois le service backend prêt, modifiez le type de route de Mock vers le service réel pour le débogage conjoint.

Routage par redirection

La passerelle cloud-native peut rediriger les requêtes vers un nom de domaine ou un chemin différent. Cette fonctionnalité est couramment utilisée pour les migrations de noms de domaine et les modifications d'API.

Par exemple, le nom de domaine actuel du service est old.example.com et le chemin actuel est /test. La passerelle cloud-native redirige une requête de old.example.com/test vers new.example.com/dev.