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 colocalisé avec le client.
Ce modèle peut être utile pour décharger des tâches de connectivité client courantes telles que la surveillance, la journalisation, le routage, la sécurité (par exemple, TLS), mais aussi des modèles de résilience sans dépendance à un quelconque langage. Il est souvent utilisé avec des applications héritées ou d’autres applications qui sont difficiles à modifier afin d’étendre leurs capacités de mise en réseau. Il peut également être utilisé par une équipe spécialisée pour 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, ainsi que la possibilité d’effectuer des mises à jour de configuration au niveau du réseau. Il peut être difficile, voire impossible, de mettre à jour les applications héritées ou les bibliothèques de code existantes pour ajouter ces fonctionnalités, car le code n’est pas conservé ou qu’il est difficilement modifiable par l’équipe de développement.
Les appels réseau peuvent également nécessiter une configuration importante en matière de connexion, d’authentification et d’autorisation. Si ces appels sont utilisés dans plusieurs applications et générés à l’aide de plusieurs langages et infrastructures, ils doivent être configurés pour chacune de ces instances. En outre, il est possible que les fonctionnalités réseau et de sécurité doivent être gérées par une équipe centrale au sein de votre organisation. En présence d’une base de code volumineuse, il peut être risqué pour cette équipe de mettre à jour un code d’application qu’elle ne connait pas bien.
Solution
Placez les bibliothèques et les infrastructures client dans un processus externe qui agit comme un proxy entre votre application et les services externes. Déployez le proxy dans le même environnement d’hôte que votre application pour pouvoir contrôler les fonctionnalités de routage, de résilience et de sécurité, et é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 analyser les indicateurs de performance tels que la latence ou l’utilisation des ressources, et ce dans le même environnement que celui de 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 que cela n’ait d’incidence sur les fonctionnalités héritées de l’application. Les différentes équipes spécialisées peuvent également implémenter et gérer les fonctionnalités de sécurité, de mise en réseau ou 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 consommateur. Si un ambassadeur est partagé par plusieurs processus distincts sur un ordinateur hôte commun, vous pouvez aussi le déployer en tant que démon ou service Windows. Si le service consommateur est exécuté en conteneur, l’ambassadeur doit être créé en tant que conteneur distinct sur le même ordinateur hôte et les liaisons appropriées doivent être configurées pour établir la communication entre les deux instances.
Problèmes et considérations
- Le proxy provoque une augmentation de la latence. Demandez-vous si une bibliothèque cliente, appelée directement par l’application, pourrait être une meilleure approche.
- Demandez-vous quel impact pourrait avoir l’intégration de fonctionnalités généralisées au proxy. L’ambassadeur pourrait par exemple gérer de nouvelles tentatives, mais cela pourrait s’avérer risqué, sauf si toutes les opérations sont idempotentes.
- Envisagez de déployer un mécanisme qui permettrait au client de transférer du contexte au proxy, et inversement. Par exemple, ajoutez des en-têtes de requête HTTP pour refuser de nouvelles tentatives ou spécifiez le nombre maximal de tentatives autorisées.
- Déterminez de quelle manière vous allez empaqueter et déployer le proxy.
- Choisissez d’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 dans les situations suivantes :
- Vous devez générer un ensemble commun de fonctionnalités de connectivité client pour plusieurs langages ou infrastructures.
- Vous devez décharger des problèmes de connectivité client transversaux vers les développeurs d’infrastructure ou d’autres équipes plus spécialisées.
- Vous devez répondre à des exigences de connectivité cloud ou de cluster dans une application héritée ou une application qui est difficile à modifier.
Ce modèle peut ne pas convenir :
- Lorsque la latence des requêtes réseau est critique. Un proxy introduit un surcroît de latence qui, bien que minimal, pourrait dans certains cas affecter l’application.
- Lorsque les fonctionnalités de connectivité client sont consommées par un seul langage. Dans ce cas, il peut être plus judicieux d’utiliser une bibliothèque cliente qui est distribuée aux équipes de développement sous la forme d’un package.
- Lorsque les fonctionnalités de connectivité ne peuvent pas être généralisées et nécessitent une intégration plus étroite avec 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 leurs charges de travail pour se conformer aux objectifs et principes abordés dans les piliers d’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é à ces dernières, notamment une 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 permet d’augmenter la sécurité au niveau des communications réseau qui n’ont pas pu être gérées directement par le client. - Se :06 Contrôles de réseau - SE :07 Chiffrement. |
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 illustre une application envoyant une requête à un service distant via un proxy Ambassadeur. L’ambassadeur assure le routage, la rupture de circuit et la journalisation. Il appelle le service distant, puis renvoie la réponse à l’application cliente :
