Présentation de l'architecture de référence des microservices de NGINX

Note de l'auteur – Ce billet de blog est le premier d'une série :

1. Présentation de l'architecture de référence des microservices NGINX (ce post)
2. MRA, partie 2 : Le modèle proxy
3. MRA, partie 3 : Le modèle de maillage du routeur
4. MRA, partie 4 : Le modèle en tissu
5. MRA, partie 5 : Adaptation de l'application à douze facteurs pour les microservices
6. MRA, partie 6 : Mise en œuvre du modèle de disjoncteur avec NGINX Plus

Les six blogs, ainsi qu'un blog sur les interfaces Web pour les applications de microservices<.htmla>, ont été rassemblés dans un livre électronique 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 de microservices
• Les articles de Chris Richardson rassemblés 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 de solutions de microservices
• Sujet: Microservices

Introduction

NGINX est impliqué dans le mouvement des microservices depuis le tout début. La nature légère, performante et flexible de NGINX convient parfaitement aux microservices.

L' image Docker NGINX est l'image d'application la plus téléchargée sur Docker Hub, et la plupart des plates-formes de microservices que vous trouvez sur le Web aujourd'hui incluent une démonstration qui déploie NGINX sous une forme ou une autre et se connecte à la page d'accueil.

Parce que nous pensons que le passage aux microservices est essentiel au succès de nos clients, nous avons lancé chez NGINX un programme dédié pour développer des fonctionnalités et des pratiques à l'appui de ce changement sismique dans le développement et la diffusion d'applications Web. Nous reconnaissons également qu’il existe de nombreuses approches différentes pour mettre en œuvre des microservices, dont beaucoup sont nouvelles et spécifiques aux besoins des équipes de développement individuelles. Nous pensons qu’il est nécessaire de disposer de modèles permettant aux entreprises de développer et de fournir plus facilement leurs propres applications basées sur des microservices.

Avec tout cela à l’esprit, nous, chez NGINX Professional Services, développons l’architecture de référence des microservices NGINX (MRA) – un ensemble de modèles que vous pouvez utiliser pour créer vos propres applications de microservices.

Le MRA est composé de deux éléments : une description détaillée de chacun des trois modèles, ainsi qu'un code téléchargeable qui implémente notre exemple de programme de partage de photos, Ingenious. La seule différence entre les trois modèles est le code de configuration utilisé pour configurer NGINX Plus pour chacun d’eux. Cette série d'articles de blog fournira des descriptions générales de chacun des modèles ; des descriptions détaillées, le code de configuration et le code de l'exemple de programme Ingenious seront disponibles plus tard cette année.

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

• Fournir aux clients et à l'industrie des plans prêts à l'emploi pour la création de systèmes basés sur des microservices, accélérant et améliorant le développement
• Créer une plateforme permettant de tester de nouvelles fonctionnalités dans NGINX et NGINX Plus, qu'elles soient développées en interne ou en externe et distribuées dans le noyau du produit ou sous forme de modules dynamiques
• Pour nous aider à comprendre les systèmes et composants des partenaires afin que nous puissions acquérir une perspective holistique sur l'écosystème des microservices

L'architecture de référence des microservices constitue également un élément important des offres de services professionnels pour les clients NGINX. Dans le MRA, nous utilisons des fonctionnalités communes à NGINX Open Source et NGINX Plus lorsque cela est possible, et des fonctionnalités spécifiques à NGINX Plus lorsque cela est nécessaire. Les dépendances NGINX Plus sont plus fortes dans les modèles plus complexes, comme décrit ci-dessous. Nous prévoyons que de nombreux utilisateurs du MRA bénéficieront de l’accès aux services professionnels NGINX et au support technique, fourni avec un abonnement NGINX Plus.

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

Nous construisons l'architecture de référence pour qu'elle soit conforme aux principes de l' application à douze facteurs . Les services sont conçus pour être légers, éphémères et sans état.

Le MRA utilise des composants standard de l’industrie tels que des conteneurs Docker, une large gamme de langages (Java, PHP, Python, NodeJS/JavaScript et Ruby) et un réseau basé sur NGINX.

L’un des changements les plus importants dans la conception et l’architecture des applications lors du passage aux microservices est l’utilisation du réseau pour communiquer entre les composants fonctionnels de l’application. Dans les applications monolithiques, les composants de l'application communiquent en mémoire. Dans une application de microservices, cette communication s'effectue via le réseau. La conception et la mise en œuvre du réseau deviennent donc d'une importance cruciale.

Pour refléter cela, le MRA a été mis en œuvre à l’aide de trois modèles de réseau différents, qui utilisent tous NGINX ou NGINX Plus. Elles vont du relativement simple au riche en fonctionnalités et plus complexe :

• Modèle proxy – Un modèle de réseau simple adapté à la mise en œuvre de NGINX Plus en tant que contrôleur ou passerelle API pour une application de microservices. Ce modèle est construit sur Docker Cloud.
• Modèle de maillage de routeur – Une approche plus robuste de la mise en réseau, avec un équilibreur 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 – Le joyau de la couronne du MRA, le modèle Fabric intègre NGINX Plus dans chaque conteneur, gérant tout le trafic entrant et sortant. Il fonctionne bien pour les 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 sur tous les microservices.

Notre intention est que vous utilisiez ces modèles comme point de départ pour vos propres implémentations de microservices, et nous apprécions vos commentaires sur la manière d'améliorer le MRA. (Vous pouvez commencer par ajouter des commentaires ci-dessous.)

Voici une brève description de chaque modèle. Nous vous suggérons de lire toutes les descriptions pour commencer à vous faire une idée de la meilleure façon d'utiliser un ou plusieurs modèles. Les prochains articles de blog décriront chacun des modèles en détail, un par article de blog.

Le modèle proxy en bref

Le modèle proxy est un modèle de réseau relativement simple. C'est un excellent point de départ pour une application de microservices initiale, ou comme modèle cible pour la conversion d'une application héritée monolithique moyennement complexe.

Dans le modèle proxy, NGINX ou NGINX Plus agit comme un contrôleur d'entrée, acheminant 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 être utilisé comme modèle lors de l'utilisation de NGINX comme passerelle API .

Si une communication interservices est nécessaire – et c’est le cas pour la plupart des applications, quel que soit leur niveau de complexité – le registre de services fournit le mécanisme au sein du cluster. (Consultez cet article de blog pour 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 proxy est utilisable pour des applications simples à moyennement complexes. Ce n’est pas l’approche/le modèle le plus efficace pour équilibrer la charge, en particulier à grande échelle ; utilisez l’un des modèles décrits ci-dessous si vous avez des besoins importants en matière d’équilibrage de charge. (« Échelle » peut faire référence à un grand nombre de microservices ainsi qu’à des volumes de trafic élevés.)

Éditeur – Pour une exploration approfondie de ce modèle, voir MRA, Partie 2 – Le modèle proxy .

Passer au modèle de maillage de routeur

Le modèle de maillage de routeur est modérément complexe et convient parfaitement aux nouvelles conceptions d'applications robustes, ainsi qu'à la conversion d'applications héritées monolithiques plus complexes qui n'ont pas besoin des capacités du modèle Fabric.

Le modèle de maillage de routeur adopte une approche de mise en réseau plus robuste 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 de maillage de routeur est 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 de santé actifs pour surveiller les instances de service individuelles et limiter le trafic de manière élégante lorsqu'elles sont supprimées.

Deis Workflow utilise une approche similaire au modèle de maillage de routeur pour acheminer le trafic entre les services, avec des instances de NGINX exécutées dans un conteneur sur chaque hôte. Au fur et à mesure que de nouvelles instances d'application sont créées, un processus extrait les informations de service du registre de services etcd et les charge dans NGINX. NGINX Plus peut également fonctionner dans ce mode, en utilisant divers emplacements et leurs amonts associés.

Éditeur – Pour une exploration approfondie de ce modèle, voir MRA, Partie 3 – Le modèle de maillage de routeur .

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

Chez NGINX, nous sommes particulièrement enthousiasmés par le modèle Fabric. Il donne vie à certaines des promesses les plus enthousiasmantes des microservices, notamment des performances élevées, une flexibilité dans l’équilibrage de charge et SSL/TLS omniprésent jusqu’au niveau des microservices individuels. Le modèle Fabric est adapté aux applications sécurisées et évolutif vers de très grandes applications.

Dans le modèle Fabric, NGINX Plus est déployé dans chaque conteneur et devient le proxy pour tout le trafic HTTP entrant et sortant des conteneurs. Les applications communiquent avec un emplacement localhost pour toutes les connexions de service et s'appuient sur NGINX Plus pour effectuer la découverte de service, l'équilibrage de charge et la vérification de l'état.

Dans notre configuration, NGINX Plus interroge ZooKeeper pour toutes les instances des services auxquels l'application doit se connecter. Avec le paramètre de fréquence DNS, valide , défini sur 1 seconde, par exemple, NGINX Plus analyse ZooKeeper, change par exemple toutes les secondes et oriente le trafic de manière appropriée.

Grâce au puissant traitement HTTP de NGINX Plus, nous pouvons utiliser des keepalives pour maintenir des connexions avec état aux microservices, réduisant ainsi la latence et améliorant les performances. Il s’agit d’une fonctionnalité particulièrement utile lors de l’utilisation de SSL/TLS pour sécuriser le trafic entre les microservices.

Enfin, nous utilisons les contrôles de santé actifs de NGINX Plus pour gérer le trafic vers les instances saines et, essentiellement, nous intégrons gratuitement le modèle de disjoncteur .

Éditeur – Pour une exploration approfondie de ce modèle, voir MRA, Partie 4 – Le modèle Fabric .

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

Le MRA inclut un exemple d'application en guise de démonstration : l'application de partage de photos Ingenious. Ingenious est implémenté dans chacun des trois modèles : Proxy, Router Mesh et Fabric. L'application de démonstration Ingenious sera rendue publique plus tard cette année.

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

• Il est facile pour les utilisateurs et les développeurs de comprendre ce qu’il fait.
• Il y a plusieurs dimensions de données à gérer.
• Il est facile d’intégrer un beau design dans l’application.
• Il fournit des exigences de calcul asymétriques (un mélange de traitement à haute et à faible intensité) qui permettent des tests réalistes des fonctionnalités de basculement, de mise à l'échelle et de surveillance sur différents types de fonctionnalités.

Conclusion

L'architecture de référence des microservices NGINX est un développement passionnant 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 le décrivant en détail, et nous le rendrons disponible plus tard cette année. Nous en discuterons également en détail lors de la conférence nginx.conf 2016 , du 7 au 9 septembre à Austin, au Texas. N'hésitez pas à nous faire part de vos commentaires, nous avons hâte de vous rencontrer.

En attendant, essayez vous-même le MRA avec NGINX Plus – démarrez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation .