Modèle Ambassadeur

Azure

Créez des services d’assistance qui envoient des requêtes réseau pour le compte d’applications ou d’un service consommateur. Un service ambassadeur peut être considéré comme un proxy hors processus qui est colocalisé avec le client.

Ce modèle peut être utile pour décharger les tâches courantes de connectivité client, telles que la surveillance, la journalisation, le routage, la sécurité (par exemple TLS) et les modèles de résilience d’une manière indépendante du langage. Il est souvent utilisé avec des applications héritées, ou d’autres applications difficiles à modifier, afin d’étendre leurs fonctionnalités de mise en réseau. Il peut également permettre à une équipe spécialisée d’implémenter ces fonctionnalités.

Contexte et problème

Les applications cloud résilientes nécessitent des fonctionnalités telles que la rupture de circuit, le routage, le contrôle et la surveillance, et la possibilité de mettre à jour la configuration liée au réseau. Il peut être difficile ou impossible de mettre à jour des applications héritées ou des bibliothèques de code existantes pour ajouter ces fonctionnalités, car le code n’est plus conservé ou ne peut pas être facilement modifié par l’équipe de développement.

Les appels réseau peuvent également nécessiter une configuration importante pour la connexion, l’authentification et l’autorisation. Si ces appels sont utilisés sur plusieurs applications, générés à l’aide de plusieurs langages et infrastructures, les appels doivent être configurés pour chacune de ces instances. En outre, les fonctionnalités réseau et de sécurité peuvent être gérées par une équipe centrale au sein de votre organisation. Avec une base de code volumineuse, il peut être risqué pour cette équipe de mettre à jour le code d’application qu’elle ne connaît pas.

Solution

Placez les infrastructures clientes et les bibliothèques dans un processus externe qui joue le rôle de proxy entre votre application et les services externes. Déployez le proxy sur le même environnement hôte que votre application pour autoriser le contrôle sur le routage, la résilience, les fonctionnalités de sécurité et pour éviter toute restriction d’accès liée à l’hôte. Vous pouvez également utiliser le modèle ambassadeur pour normaliser et étendre l’instrumentation. Le proxy peut surveiller les métriques de performances telles que la latence ou l’utilisation des ressources, et cette surveillance se produit dans le même environnement hôte que l’application.

Les fonctionnalités qui sont déchargées vers l’ambassadeur peuvent être gérées indépendamment de l’application. Vous pouvez mettre à jour et modifier l’ambassadeur sans déranger la fonctionnalité héritée de l’application. Il permet également aux équipes distinctes et spécialisées d’implémenter et de maintenir la sécurité, la mise en réseau ou les fonctionnalités d’authentification qui ont été déplacées vers l’ambassadeur.

Les services Ambassadeur peuvent être déployés en tant que side-car pour accompagner le cycle de vie d’une application ou d’un service consommant. Sinon, si un ambassadeur est partagé par plusieurs processus distincts sur un hôte commun, il peut être déployé en tant que démon ou service Windows. Si le service consommateur est conteneurisé, l’ambassadeur doit être créé en tant que conteneur distinct sur le même hôte, avec les liens appropriés configurés pour la communication.

Problèmes et considérations

• Le proxy ajoute une surcharge de latence. Déterminez si une bibliothèque cliente, appelée directement par l’application, est une meilleure approche.
• Tenez compte de l’impact possible de l’inclusion de fonctionnalités généralisées dans le proxy. Par exemple, l’ambassadeur peut gérer les nouvelles tentatives, mais cela peut ne pas être sûr, sauf si toutes les opérations sont idempotentes.
• Envisagez un mécanisme permettant au client de passer un contexte au proxy et de revenir au client. Par exemple, incluez les en-têtes de requête HTTP pour refuser la nouvelle tentative ou spécifier le nombre maximal de tentatives.
• Réfléchissez à la façon dont vous allez empaqueter et déployer le proxy.
• Déterminez s’il faut utiliser une instance partagée unique pour tous les clients ou une instance pour chaque client.

Quand utiliser ce modèle

Utilisez ce modèle lorsque vous procédez comme suit :

• Vous devez créer un ensemble commun de fonctionnalités de connectivité client pour plusieurs langages ou infrastructures.
• Vous devez décharger les problèmes de connectivité client multi-coupe aux développeurs d’infrastructure ou à d’autres équipes plus spécialisées.
• Vous devez prendre en charge les exigences de connectivité cloud ou de cluster dans une application héritée ou une application difficile à modifier.

Ce modèle peut ne pas convenir :

• Lorsque la latence des requêtes réseau est critique. Un proxy introduit une surcharge, bien que minimale et, dans certains cas, cela peut affecter l’application.
• Lorsque les fonctionnalités de connectivité du client sont consommées par une seule langue. Dans ce cas, une meilleure option peut être une bibliothèque cliente distribuée aux équipes de développement en tant que package.
• Lorsque les fonctionnalités de connectivité ne peuvent pas être généralisées et nécessitent une intégration plus approfondie à l’application cliente.

Conception de la charge de travail

Un architecte doit évaluer la façon dont le modèle Ambassadeur peut être utilisé dans la conception de leur charge de travail pour répondre aux objectifs et principes abordés dans les piliers Azure Well-Architected Framework. Par exemple:

Pilier	Comment ce modèle soutient les objectifs des piliers.
Les décisions relatives à la fiabilité contribuent à rendre votre charge de travail résiliente aux dysfonctionnements et à s’assurer qu’elle retrouve un état de fonctionnement optimal après une défaillance.	Le point de médiation des communications réseau facilité par ce modèle permet d’ajouter des modèles de fiabilité aux communications réseau, telles que la nouvelle tentative ou la mise en mémoire tampon. - RE :07 Auto-conservation
Les décisions relatives à la conception de la sécurité permettent de garantir la confidentialité, l’intégrité et la disponibilité des données et des systèmes de votre charge de travail.	Ce modèle offre la possibilité d’augmenter la sécurité sur les communications réseau qui n’ont pas pu être gérées directement par le client. - Se :06 Contrôles de réseau - Chiffrement SE :07

Comme pour toute autre décision de conception, il convient de prendre en compte les compromis par rapport aux objectifs des autres piliers qui pourraient être introduits avec ce modèle.

Exemple :

Le diagramme suivant montre une application qui effectue une demande à un service distant via un proxy d’ambassadeur. L’ambassadeur fournit le routage, le circuit cassant et la journalisation. Il appelle le service distant, puis retourne la réponse à l’application cliente :

Ressources associées

• Modèle side-car

Créez des services d’assistance qui envoient des requêtes réseau pour le compte d’applications ou d’un service consommateur. Un service ambassadeur peut être considéré comme un proxy hors processus qui est colocalisé avec le client.

Ce modèle peut être utile pour décharger les tâches courantes de connectivité client, telles que la surveillance, la journalisation, le routage, la sécurité (par exemple TLS) et les modèles de résilience d’une manière indépendante du langage. Il est souvent utilisé avec des applications héritées, ou d’autres applications difficiles à modifier, afin d’étendre leurs fonctionnalités de mise en réseau. Il peut également permettre à une équipe spécialisée d’implémenter ces fonctionnalités.

Contexte et problème

Les applications cloud résilientes nécessitent des fonctionnalités telles que la rupture de circuit, le routage, le contrôle et la surveillance, et la possibilité de mettre à jour la configuration liée au réseau. Il peut être difficile ou impossible de mettre à jour des applications héritées ou des bibliothèques de code existantes pour ajouter ces fonctionnalités, car le code n’est plus conservé ou ne peut pas être facilement modifié par l’équipe de développement.

Les appels réseau peuvent également nécessiter une configuration importante pour la connexion, l’authentification et l’autorisation. Si ces appels sont utilisés sur plusieurs applications, générés à l’aide de plusieurs langages et infrastructures, les appels doivent être configurés pour chacune de ces instances. En outre, les fonctionnalités réseau et de sécurité peuvent être gérées par une équipe centrale au sein de votre organisation. Avec une base de code volumineuse, il peut être risqué pour cette équipe de mettre à jour le code d’application qu’elle ne connaît pas.

Solution

Placez les infrastructures clientes et les bibliothèques dans un processus externe qui joue le rôle de proxy entre votre application et les services externes. Déployez le proxy sur le même environnement hôte que votre application pour autoriser le contrôle sur le routage, la résilience, les fonctionnalités de sécurité et pour éviter toute restriction d’accès liée à l’hôte. Vous pouvez également utiliser le modèle ambassadeur pour normaliser et étendre l’instrumentation. Le proxy peut surveiller les métriques de performances telles que la latence ou l’utilisation des ressources, et cette surveillance se produit dans le même environnement hôte que l’application.

Les fonctionnalités qui sont déchargées vers l’ambassadeur peuvent être gérées indépendamment de l’application. Vous pouvez mettre à jour et modifier l’ambassadeur sans déranger la fonctionnalité héritée de l’application. Il permet également aux équipes distinctes et spécialisées d’implémenter et de maintenir la sécurité, la mise en réseau ou les fonctionnalités d’authentification qui ont été déplacées vers l’ambassadeur.

Les services Ambassadeur peuvent être déployés en tant que side-car pour accompagner le cycle de vie d’une application ou d’un service consommant. Sinon, si un ambassadeur est partagé par plusieurs processus distincts sur un hôte commun, il peut être déployé en tant que démon ou service Windows. Si le service consommateur est conteneurisé, l’ambassadeur doit être créé en tant que conteneur distinct sur le même hôte, avec les liens appropriés configurés pour la communication.

Problèmes et considérations

• Le proxy ajoute une surcharge de latence. Déterminez si une bibliothèque cliente, appelée directement par l’application, est une meilleure approche.
• Tenez compte de l’impact possible de l’inclusion de fonctionnalités généralisées dans le proxy. Par exemple, l’ambassadeur peut gérer les nouvelles tentatives, mais cela peut ne pas être sûr, sauf si toutes les opérations sont idempotentes.
• Envisagez un mécanisme permettant au client de passer un contexte au proxy et de revenir au client. Par exemple, incluez les en-têtes de requête HTTP pour refuser la nouvelle tentative ou spécifier le nombre maximal de tentatives.
• Réfléchissez à la façon dont vous allez empaqueter et déployer le proxy.
• Déterminez s’il faut utiliser une instance partagée unique pour tous les clients ou une instance pour chaque client.

Quand utiliser ce modèle

Utilisez ce modèle lorsque vous procédez comme suit :

• Vous devez créer un ensemble commun de fonctionnalités de connectivité client pour plusieurs langages ou infrastructures.
• Vous devez décharger les problèmes de connectivité client multi-coupe aux développeurs d’infrastructure ou à d’autres équipes plus spécialisées.
• Vous devez prendre en charge les exigences de connectivité cloud ou de cluster dans une application héritée ou une application difficile à modifier.

Ce modèle peut ne pas convenir :

• Lorsque la latence des requêtes réseau est critique. Un proxy introduit une surcharge, bien que minimale et, dans certains cas, cela peut affecter l’application.
• Lorsque les fonctionnalités de connectivité du client sont consommées par une seule langue. Dans ce cas, une meilleure option peut être une bibliothèque cliente distribuée aux équipes de développement en tant que package.
• Lorsque les fonctionnalités de connectivité ne peuvent pas être généralisées et nécessitent une intégration plus approfondie à l’application cliente.

Conception de la charge de travail

Un architecte doit évaluer la façon dont le modèle Ambassadeur peut être utilisé dans la conception de leur charge de travail pour répondre aux objectifs et principes abordés dans les piliers Azure Well-Architected Framework. Par exemple:

Pilier	Comment ce modèle soutient les objectifs des piliers.
Les décisions relatives à la fiabilité contribuent à rendre votre charge de travail résiliente aux dysfonctionnements et à s’assurer qu’elle retrouve un état de fonctionnement optimal après une défaillance.	Le point de médiation des communications réseau facilité par ce modèle permet d’ajouter des modèles de fiabilité aux communications réseau, telles que la nouvelle tentative ou la mise en mémoire tampon. - RE :07 Auto-conservation
Les décisions relatives à la conception de la sécurité permettent de garantir la confidentialité, l’intégrité et la disponibilité des données et des systèmes de votre charge de travail.	Ce modèle offre la possibilité d’augmenter la sécurité sur les communications réseau qui n’ont pas pu être gérées directement par le client. - Se :06 Contrôles de réseau - Chiffrement SE :07

Comme pour toute autre décision de conception, il convient de prendre en compte les compromis par rapport aux objectifs des autres piliers qui pourraient être introduits avec ce modèle.

Exemple :

Le diagramme suivant montre une application qui effectue une demande à un service distant via un proxy d’ambassadeur. L’ambassadeur fournit le routage, le circuit cassant et la journalisation. Il appelle le service distant, puis retourne la réponse à l’application cliente :

Ressources associées

• Modèle side-car