Proxy inverse – l'épine dorsale de l'architecture des microservices

L'architecture de microservices impliquait de décomposer une application complexe en petites applications autonomes afin que chacune d'entre elles puisse être mise à l'échelle et maintenue indépendamment . Avec la pléthore d'avantages liés à l'architecture des microservices, il n'est pas étonnant que tout le monde dans le secteur informatique s'oriente vers cette nouvelle architecture !

Au cœur de l’architecture des microservices se trouve le concept de proxy inverse. Un proxy inverse joue un rôle central dans la direction du trafic entre différents microservices, ainsi que dans la répartition de la charge de travail entre plusieurs instances d'un microservice. Sans le proxy inverse, le réseau complexe d’interactions et de répartition de charge au sein de l’architecture des microservices tel que nous le comprenons aujourd’hui ne serait tout simplement pas réalisable !

Plongeons en profondeur dans le rôle d'un proxy inverse dans un environnement de microservices !

Qu'est-ce qu'un proxy ?

Un proxy est un serveur situé entre l'ordinateur d'un client et Internet. Tout trafic sortant de la machine du client passe par le serveur proxy. Pour le reste d’Internet, il semble que le serveur proxy initie les requêtes.

Il existe plusieurs raisons pour lesquelles on utiliserait un serveur proxy. Certains d'entre eux sont les suivants -

• Masquage d'identité : grâce au proxy, la véritable identité d'un client n'est pas révélée sur Internet. Il peut être utilisé pour accéder à du contenu qui aurait autrement été bloqué/restreint pour le client.
• Mise en place de restrictions : Grâce à certaines configurations, les serveurs proxy peuvent être utilisés pour restreindre l'accès à certains contenus pour le client.
• Cela améliore également la sécurité

Qu'est-ce qu'un proxy inverse ?

Un proxy inverse est un serveur situé entre Internet et les serveurs backend. Tout trafic destiné aux serveurs doit passer par le proxy inverse. Pour le reste d’Internet, il semble que le proxy inverse traite les requêtes.

L’utilisation des proxys inverses présente plusieurs avantages en général. Vous en trouverez peut-être quelques-uns répertoriés ici .

Le concept de proxy inverse donne vie à l'architecture des microservices, permettant au client de naviguer dans l'environnement dynamique des microservices en déterminant à quels serveurs accéder. Sans ce composant vital, le client se retrouverait sans les moyens de naviguer efficacement dans le paysage complexe de l’architecture des microservices.

Découverte des services 🌍

Les services dans une architecture de microservices évoluent en fonction de la charge. Cela signifie que les répliques d'un service peuvent aller et venir à tout moment pendant la durée de vie d'une application. Le proxy inverse détecte les serveurs d'un service et dirige efficacement le trafic du client vers ceux-ci.

Équilibrage de charge ⚖️

Puisqu'un service peut avoir plusieurs répliques en cours d'exécution, il devient important que les requêtes du client soient correctement réparties sur les serveurs disponibles. L'équilibrage de charge n'est qu'une autre fonctionnalité de Revere Proxy qui est utilisée ici. Le proxy inverse répartit intelligemment la charge entre les répliques disponibles d'un service.

Surveillance 🖥️

Étant donné que toute demande entrant dans notre application passe par le proxy inverse, c'est un bon endroit pour surveiller les demandes et effectuer la journalisation. Cela aide à obtenir des informations cruciales sur le nombre de services présents dans le système.

Trafic interne 🚦

Dans un environnement de microservices, un proxy inverse est également utilisé pour acheminer le trafic interne du cluster. Ceci est particulièrement utile dans le cas d’une communication de service à service.

Mise en cache 💰

La mise en cache est un avantage général lié à l’utilisation du proxy inverse. Le serveur proxy peut renvoyer des résultats mis en cache pour des requêtes similaires, améliorant ainsi le temps de réponse du client.

Agrégation ⛙

La demande d'un seul client peut nécessiter l'agrégation des réponses de plusieurs services au niveau du backend. Une telle agrégation peut être effectuée par le proxy inverse, laissant au client un point de terminaison propre à utiliser !

Proxy entre couches

Un proxy inverse peut être utilisé dans différentes configurations. Ces configurations dictent généralement la couche OSI au niveau de laquelle la décision de routage est prise. Il existe généralement deux proxys célèbres : (1) le proxy au niveau de la couche 4 et (2) le proxy au niveau de la couche 7. À mesure que nous remontons les couches, nous décodons davantage d'informations à partir des paquets Internet qui peuvent être utilisées pour la décision de routage.

Proxy de couche 4

La couche 4 du modèle OSI est la couche de transport. Du point de vue d'un développeur d'applications, les éléments disponibles au niveau de la couche 4 pour la décision de routage sont :

• IP et port du client qui envoie la requête
• IP et port du serveur qui reçoit la requête

Ainsi, un proxy de couche 4 ne peut prendre des décisions de routage qu'en fonction de l'IP et du port du serveur et du client. Il ne peut pas examiner le contenu des requêtes et peut donc prendre des décisions de routage limitées.

Il existe plusieurs raisons pour lesquelles on utiliserait un proxy de couche 4 :

• Lorsque seul un équilibrage de charge au niveau des paquets est requis.
• On ne veut pas que le proxy inverse déchiffre la demande pour des raisons de sécurité.
• L'efficacité est requise car le proxy au niveau de la couche 4 est rapide.

Le proxy de couche 4 présente également plusieurs inconvénients :

• Puisque nous sommes au niveau 4, l’équilibrage de charge intelligent n’est pas possible
• Il ne peut pas effectuer un véritable équilibrage de charge des microservices.

Proxy de couche 7

La couche 7 du modèle OSI est la couche application. Du point de vue d'un développeur d'applications, les éléments disponibles au niveau de la couche 7 pour la décision de routage sont :

• Tout ce qui était disponible au niveau 4
• L'intégralité du contenu de la demande, y compris les en-têtes

Étant donné que beaucoup plus de contenu pour la prise de décision est disponible au niveau de la couche 7, un routage plus intelligent peut être effectué.

Voici quelques raisons pour lesquelles on utiliserait un proxy de couche 7 :

• Vous devez prendre des décisions de routage intelligentes dans votre proxy inverse
• Vous souhaitez utiliser la mise en cache

Voici quelques inconvénients liés à l'utilisation d'un proxy de couche 7 :

• Le proxy de couche 7 est généralement plus lent que la couche 4 car il déchiffre la requête et examine son contenu pour les décisions de routage.
• Étant donné que le proxy inverse examine le contenu des requêtes, l'utilisation d'un proxy de couche 7 pose également un problème de sécurité.

Le proxy inverse est sans aucun doute l’un des éléments importants d’une architecture de microservices. Sans cela, les véritables avantages de l’architecture des microservices ne pourront jamais être pleinement exploités.

Nous arrivons ainsi à la fin de ce blog ! J'espère que vous avez appris quelque chose de nouveau aujourd'hui.