Présentation de l’architecture de référence pour les microservices de NGINX

Chris Stetson

Note de l’auteur – Cet article de blog est le premier d’une série :

1. Présentation de l’architecture de référence NGINX pour les microservices (cet article)
2. MRA, partie 2 : le modèle proxy
3. MRA, partie 3 : le modèle de maillage de routeurs
4. MRA, partie 4 : le modèle Fabric
5. MRA, partie 5 : adapter l’application Twelve-Factor aux microservices
6. MRA, partie 6 : mise en œuvre du modèle de disjoncteur avec NGINX Plus

Les six articles de blog, ainsi qu’un article consacré aux interfaces web pour les applications de microservices<.htmla>, ont été réunis dans un ebook gratuit.

Consultez également ces autres ressources NGINX sur les microservices :

• Une série très utile et populaire de Chris Richardson sur la conception d’applications basées sur des microservices
• Les articles de Chris Richardson réunis dans un ebook gratuit, avec des conseils supplémentaires sur la mise en œuvre de microservices avec NGINX et NGINX Plus
• Autres articles de blog sur les microservices
• Webinaires sur les microservices
• Page des solutions de microservices
• Thème : microservices

Introduction

NGINX participe au mouvement des microservices depuis ses débuts. Sa légèreté, ses hautes performances et sa flexibilité en font une solution parfaitement adaptée aux microservices.

L’image Docker NGINX est l’image d’application la plus téléchargée sur Docker Hub, et la plupart des plateformes de microservices disponibles aujourd’hui sur le Web proposent une démonstration qui déploie NGINX sous une forme ou une autre et se connecte à la page d’accueil.

Parce que nous sommes convaincus que la transition vers les microservices est essentielle à la réussite de nos clients, nous avons lancé chez NGINX un programme dédié au développement de fonctionnalités et de pratiques visant à accompagner cette transformation majeure du développement et de la mise à disposition des applications web. Nous sommes également conscients qu’il existe de nombreuses approches différentes pour mettre en œuvre les microservices, dont beaucoup sont novatrices et propres aux besoins de chaque équipe de développement. Nous pensons que des modèles sont nécessaires pour permettre aux entreprises de développer et de mettre à disposition plus facilement leurs propres applications basées sur des microservices.

Dans cette optique, l’équipe des services professionnels de NGINX développe l’architecture de référence NGINX pour les microservices (MRA), un ensemble de modèles que vous pouvez utiliser pour créer vos propres applications basées sur des microservices.

La MRA se compose de deux éléments : une description détaillée de chacun des trois modèles, ainsi que du code téléchargeable mettant en œuvre notre exemple d’application de partage de photos, Ingenious. La seule différence entre les trois modèles réside dans le code de configuration utilisé pour configurer NGINX Plus pour chacun d’eux. Cette série d’articles de blog donnera un aperçu de chacun des modèles ; des descriptions détaillées, le code de configuration et le code de l’application d’exemple Ingenious seront mis à disposition plus tard dans l’année.

Notre objectif en élaborant cette architecture de référence est triple :

• Fournir aux clients et au secteur des modèles prêts à l’emploi pour concevoir des systèmes basés sur des microservices, afin d’accélérer et d’améliorer le développement
• Créer une plateforme permettant de tester les nouvelles fonctionnalités de NGINX et NGINX Plus, qu’elles soient développées en interne ou en externe et distribuées dans le cœur du produit ou sous forme de modules dynamiques
• Nous aider à comprendre les systèmes et composants de nos partenaires afin d’acquérir une vision globale de l’écosystème des microservices

L’architecture de référence pour les microservices constitue également une part importante des offres de services professionnels destinées aux clients NGINX. Dans la MRA, nous utilisons, dans la mesure du possible, des fonctionnalités communes à NGINX Open Source et NGINX Plus, ainsi que des fonctionnalités propres à NGINX Plus lorsque cela est nécessaire. La dépendance à NGINX Plus est plus forte dans les modèles plus complexes, comme décrit ci-dessous. Nous pensons que de nombreux utilisateurs de la MRA tireront parti de l’accès aux services professionnels de NGINX et au support technique inclus dans un abonnement NGINX Plus.

Présentation de l’architecture de référence des microservices

Nous concevons l’architecture de référence conformément aux principes de l’application à douze facteurs. Les services sont conçus pour être légers, éphémères et sans état.

La MRA utilise des composants standard du secteur, tels que les conteneurs Docker, un large éventail de langages – Java, PHP, Python, NodeJS/JavaScript et Ruby – ainsi qu’une infrastructure réseau basée sur NGINX.

L’un des changements majeurs dans la conception et l’architecture des applications lors du passage aux microservices consiste à utiliser le réseau pour assurer la communication entre les composants fonctionnels de l’application. Dans les applications monolithiques, les composants communiquent en mémoire. Dans une application basée sur des microservices, cette communication s’effectue via le réseau, ce qui rend la conception et la mise en œuvre du réseau absolument essentielles.

Pour en tenir compte, la MRA a été mise en œuvre selon trois modèles de mise en réseau différents, qui utilisent tous NGINX ou NGINX Plus. Ces modèles vont du plus simple au plus complexe et riche en fonctionnalités :

• Modèle proxy – Un modèle réseau simple adapté à l’utilisation de NGINX Plus comme contrôleur ou passerelle d’API pour une application de microservices. Ce modèle repose sur Docker Cloud.
• Modèle de maillage de routeurs – Une approche plus robuste de la mise en réseau, avec un répartiteur de charge sur chaque hôte et une gestion des connexions entre les systèmes. Ce modèle est similaire à l’architecture de Deis 1.0.
• Modèle Fabric – Véritable joyau de la MRA, le modèle Fabric intègre NGINX Plus dans chaque conteneur afin de gérer l’ensemble du trafic entrant et sortant. Il est particulièrement adapté aux systèmes à forte charge et prend en charge SSL/TLS à tous les niveaux, NGINX Plus offrant une latence réduite, des connexions SSL/TLS persistantes, la découverte de services et le modèle de disjoncteur pour l’ensemble des microservices.

Nous souhaitons que vous utilisiez ces modèles comme point de départ pour vos propres implémentations de microservices, et vos suggestions pour améliorer la MRA sont les bienvenues. (Vous pouvez commencer par les ajouter dans la section Commentaires ci-dessous.)

Vous trouverez ci-dessous une brève description de chaque modèle. Nous vous conseillons de lire toutes les descriptions afin de commencer à déterminer comment utiliser au mieux un ou plusieurs de ces modèles. De futurs articles de blog présenteront chaque modèle en détail, à raison d’un modèle par article.

Le modèle Proxy en bref

Le modèle Proxy est un modèle de mise en réseau relativement simple. Il constitue un excellent point de départ pour une première application de microservices, ou un modèle cible lors de la conversion d’une application monolithique existante de complexité moyenne.

Dans le modèle Proxy, NGINX ou NGINX Plus fait office de contrôleur d’entrée et achemine les requêtes vers les microservices. NGINX Plus peut utiliser le DNS dynamique pour la découverte de services à mesure que de nouveaux services sont créés. Le modèle Proxy peut également servir de modèle lors de l’utilisation de NGINX comme passerelle d’API.

Si une communication interservices est nécessaire – ce qui est le cas pour la plupart des applications présentant un certain niveau de complexité – le registre de services fournit le mécanisme requis au sein du cluster. (Consultez cet article de blog pour obtenir une liste détaillée des mécanismes de communication interservices.) Docker Cloud utilise cette approche par défaut : pour se connecter à un autre service, un service interroge le DNS et obtient une adresse IP à laquelle envoyer une requête.

En règle générale, le modèle de proxy convient aux applications simples à modérément complexes. Ce n’est pas l’approche ni le modèle le plus efficace pour l’équilibrage de charge, en particulier à grande échelle ; utilisez l’un des modèles décrits ci-dessous si vos besoins en matière d’équilibrage de charge sont importants. (La « grande échelle » peut désigner aussi bien un grand nombre de microservices que des volumes de trafic élevés.)

Note de l’éditeur – Pour une analyse approfondie de ce modèle, consultez « MRA, partie 2 – Le modèle proxy ».

Passer au modèle de maillage de routeurs

Le modèle Router Mesh est d’une complexité modérée et convient parfaitement à la conception de nouvelles applications robustes, ainsi qu’à la conversion d’applications monolithiques existantes plus complexes qui ne nécessitent pas les fonctionnalités du modèle Fabric.

Le modèle Router Mesh adopte une approche plus robuste de la mise en réseau que le modèle Proxy, en exécutant un équilibreur de charge sur chaque hôte et en gérant activement les connexions entre les microservices. Le principal avantage du modèle Router Mesh réside dans un équilibrage de charge plus efficace et plus robuste entre les services. Si vous utilisez NGINX Plus, vous pouvez mettre en œuvre des contrôles d’intégrité actifs afin de surveiller les différentes instances de service et de réduire progressivement le trafic lorsqu’elles sont mises hors service.

Deis Workflow utilise une approche similaire au modèle Router Mesh pour acheminer le trafic entre les services, avec des instances de NGINX s’exécutant dans un conteneur sur chaque hôte. À mesure que de nouvelles instances d’application sont lancées, un processus extrait les informations sur les services du registre de services etcd et les charge dans NGINX. NGINX Plus peut également fonctionner dans ce mode, en utilisant différents emplacements et les groupes de serveurs en amont qui leur sont associés.

Note de l’éditeur – Pour une analyse approfondie de ce modèle, consultez « MRA, partie 3 – Le modèle de maillage de routeurs ».

Et enfin – Le modèle Fabric, avec SSL/TLS en option

Chez NGINX, c’est le modèle Fabric qui nous enthousiasme le plus. Il concrétise certaines des promesses les plus intéressantes des microservices, notamment des performances élevées, une grande souplesse en matière d’équilibrage de charge et l’omniprésence du protocole SSL/TLS jusqu’au niveau de chaque microservice. Le modèle Fabric convient aux applications sécurisées et peut évoluer pour prendre en charge des applications de très grande envergure.

Dans le modèle Fabric, NGINX Plus est déployé dans chaque conteneur et sert de proxy pour l’ensemble du trafic HTTP entrant et sortant des conteneurs. Pour toutes les connexions aux services, les applications communiquent avec une adresse localhost et s’appuient sur NGINX Plus pour assurer la découverte des services, l’équilibrage de charge et les contrôles d’intégrité.

Dans notre configuration, NGINX Plus interroge ZooKeeper pour rechercher toutes les instances des services auxquels l’application doit se connecter. Par exemple, lorsque le paramètre de fréquence DNS valid est défini sur 1 seconde, NGINX Plus recherche chaque seconde les changements d’instances dans ZooKeeper et achemine le trafic en conséquence.

Grâce aux puissantes capacités de traitement HTTP de NGINX Plus, nous pouvons utiliser des connexions persistantes pour maintenir des connexions avec état aux microservices, ce qui réduit la latence et améliore les performances. Cette fonctionnalité est particulièrement utile lorsque le protocole SSL/TLS est utilisé pour sécuriser le trafic entre les microservices.

Enfin, nous utilisons les contrôles d’intégrité actifs de NGINX Plus pour diriger le trafic vers les instances saines et, en substance, intégrer gratuitement le modèle de disjoncteur.

Note de l’éditeur – Pour une analyse approfondie de ce modèle, consultez « MRA, partie 4 – Le modèle Fabric ».

Une application de démonstration ingénieuse pour la MRA

Le MRA comprend une application exemple à des fins de démonstration : l’application de partage de photos Ingenious. Ingenious est mise en œuvre dans chacun des trois modèles : Proxy, Router Mesh et Fabric. L’application de démonstration Ingenious sera mise à la disposition du public dans le courant de l’année.

Ingenious est une version simplifiée d’une application de stockage et de partage de photos, à l’image de Flickr ou Shutterfly. Nous avons choisi une application de partage de photos pour plusieurs raisons :

• Les utilisateurs comme les développeurs peuvent facilement comprendre son fonctionnement.
• Il faut gérer plusieurs dimensions de données.
• Il est facile d’intégrer un design élégant à l’application.
• Elle présente des besoins de calcul asymétriques — combinant des traitements à forte et à faible intensité —, ce qui permet de tester de manière réaliste les fonctionnalités de basculement, de mise à l’échelle et de surveillance sur différents types de fonctions.

Conclusion

L’architecture de référence NGINX pour les microservices constitue une avancée passionnante pour nous, ainsi que pour les clients et partenaires avec lesquels nous l’avons partagée jusqu’à présent. Au cours des prochains mois, nous publierons une série d’articles de blog qui la présenteront en détail, et nous la rendrons disponible plus tard dans l’année. Nous l’aborderons également en détail lors de nginx.conf 2016, qui se tiendra du 7 au 9 septembre à Austin, au Texas. N’hésitez pas à nous faire part de vos commentaires. Au plaisir de vous y retrouver.

En attendant, testez vous-même la MRA avec NGINX Plus : commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation.

À propos de l’auteur

Chris Stetson

Autres articles de Chris Stetson