Faculté Ordinateurs, Informatique et

Microélectronique
Université Technique de Moldova

Programmation des Applications Distribuées

Travail de laboratoire nr.#2

Thème: Proxy Web - services HTTP

distribués de manière transparente

Effectué par: maître assistant:

Lupei Nicolae Alexandr Gavrișco

Chisinau 2020
 Tables des metiers

1. Le but du laboratoire ......................................................................................................... 3

2. Les objectifs du laboratoire ............................................................................................... 3
3. La mise en oeuvre du systeme ........................................................................................... 3
3.1. Tâches ........................................................................................................................... 3
3.2. L’analyse du travail de laboratoire ............................................................................... 3
Conclusions ................................................................................................................................ 9
Travail de laboratoire nr.\#2

1. Le but du laboratoire
Etude du protocole HTTP dans le cadre de la distribution de données. Utilisation de
méthodes HTTP pour implémenter l'interaction entre le client et un serveur d'applications.
Etude des méthodes de mise en cache et d'équilibrage de charge appliquées pour créer un
service proxy.

2. Les objectifs du laboratoire

 Implémenter un service (ou plusieurs services) qui exposent une API via HTTP;
 Implémentez un service "smart-proxy" qui agit comme une passerelle API,
remplaçant la mise en cache et l'équilibrage de charge;

3. La mise en œuvre du système

3.1. Tâches
 Mandatory - Implement a single horizontally scalable service
 Implement a smart proxy
 Implement sharding
 Implement adapter layer

3.2. L’analyse du travail de laboratoire

Lien de notre repository: https://gitlab.com/nicolae.lupei.1996/padlabs

Le diagramme montre que le système aura quatre couches:

 Base de données - Ici, nous stockons des données et rien de plus, aucune logique.
 DAL - Pour accéder aux données, nous utilisons le modèle Unité de travail et, dans
l'implémentation, nous utilisons ORM EF Core avec le code d'abord et les modèles
de migration.
 Logique métier - pour encapsuler la logique métier, nous utilisons des processeurs
de requêtes, seule cette couche traite la logique métier. L'exception est la
validation la plus simple telle que les champs obligatoires, qui seront exécutés au
moyen de filtres dans l'API.
 API REST - L'interface réelle à travers laquelle les clients peuvent travailler avec
notre API sera implémentée via ASP.NET Core. Les configurations d'itinéraire
sont déterminées par des attributs.

En plus des couches décrites, nous avons plusieurs concepts importants. Le premier est la
séparation des modèles de données. Le modèle de données client est principalement utilisé
dans la couche API REST. Il convertit les requêtes en modèles de domaine et vice versa
d'un modèle de domaine en modèle de données client, mais les modèles de requête
peuvent également être utilisés dans les processeurs de requêtes. La conversion est
effectuée à l'aide d'AutoMapper.

Dans la première tâche, nous avons dû implémenter une mise à l'échelle horizontale. Cela
signifierait, au lieu d'agrandir les composants existants, d'autres composants sont ajoutés
en parallèle. En termes de calcul, cela signifierait ajouter un serveur supplémentaire avec
sa propre mémoire dédiée et son espace disque pour servir une instance supplémentaire
d'une application.

Fig.1. L'échelle horizontale

Lors de la mise à l'échelle, une machine ou une application Web ne peut gérer que cette
quantité limitée de ressources supplémentaires. Le système d'exploitation pourrait par
exemple seulement une certaine quantité de mémoire ou d'espace disque. Ou toute la
puissance du processeur est déjà utilisée et ne peut pas être étendue.
À ce moment, la mise à l'échelle sera inévitable. Avec la mise à l'échelle, de nouveaux
problèmes sont introduits car plusieurs instances seront chargées de gérer les demandes
simultanées.
 Fig.2. L'échelle horizontale pour CustomerApi

Fig.3. Swagger pour deux instances

Un serveur proxy est un serveur intermédiaire ou intermédiaire qui transfère les demandes
de contenu de plusieurs clients vers différents serveurs sur Internet. Un serveur proxy inverse est
un type de serveur proxy qui se trouve généralement derrière le pare-feu dans un réseau privé et
dirige les demandes des clients vers le serveur principal approprié. Un proxy inverse fournit un
niveau supplémentaire d'abstraction et de contrôle pour assurer la fluidité du trafic réseau entre
les clients et les serveurs.

Common uses for a reverse proxy server include:

 Load balancing
 Web acceleration
 Sécurité et anonymat
 NGINX Plus et NGINX sont les meilleures solutions d'équilibrage de charge utilisées par
les sites Web à fort trafic. Plus de 400 millions de sites Web dans le monde font confiance à
NGINX Plus et NGINX pour diffuser leur contenu rapidement, de manière fiable et en toute
sécurité.

Fig.4. Reverse proxy avec Nginx

En tant que proxy inverse basé sur logiciel, NGINX Plus est non seulement moins coûteux que
les solutions matérielles dotées de capacités similaires, mais il peut être déployé dans le cloud
public ainsi que dans des centres de données privés, alors que les fournisseurs d’infrastructures
cloud ne permettent généralement pas aux clients ou proxys inverses matériels propriétaires dans
leurs centres de données.

API Gateway (ou proxy intelligent) est un composant intermédiaire souvent utilisé pour
exposer de manière transparente les API publiques de plusieurs services. Cette approche permet
de changer la façon dont le trafic entrant est géré, sans changer les services derrière la passerelle
API, elle offre également un point d'entrée unique et transparent du système. Quelques raisons
d'utiliser une passerelle API / un proxy intelligent.
 Fig.5. API Gateway

Smart Proxy est composé de projets FOSS modifiés et de configurations système

nécessaires qui permettent au trafic souhaité, et uniquement au trafic souhaité, d'être acheminé
hors d'un nœud de sortie de réseau affecté vers un proxy géolocalisé à charge équilibrée. Si
Smart Proxy est déployé en tant que produit autonome, l'utilisateur peut l'activer en mettant
simplement à jour l'adresse du serveur DNS sur les appareils souhaités. Lorsqu'il est déployé en
tant qu'extension d'une infrastructure réseau existante, l'utilisateur final n'est pas du tout obligé
d'apporter des modifications. Le système peut être logiquement divisé en trois parties: serveur
DNS, Load-Balancer et Proxy.

Fig.6. Smart proxy et load balancer

 Fig.7. Load on services

Une solution plus viable pour résoudre les problèmes consiste à mettre en œuvre un
stockage centralisé au niveau de l'application. De cette manière, les données sont rendues
accessibles de manière centralisée.
Comme l'implémentation diffère selon la technologie, chaque sujet (sessions et cookies) sera
traité un par un.
Redis a été choisi pour cet exemple. Avec Redis est un cache clé-valeur centralisé en
mémoire et prend en charge des structures de données telles que des listes, des ensembles triés et
des chaînes.
Commençons par démarrer une instance Redis. Le moyen le plus simple est d'utiliser l'image
officielle Redis Docker. Une autre option serait d'utiliser un Redis Helm Chart pour déployer
Redis directement dans un cluster Kubernetes.

Points forts des performances, de l'évolutivité et de la disponibilité avec REDIS:

 Augmente le débit des demandes et les temps de réponse
 Aucun risque de perte de performance
 Le cache est partagé entre tous les serveurs d'applications et le sous-ensemble de
données le plus chaud est conservé localement
 Le cache est disponible sous la pression du tas JVM
 Permet au système d'évoluer avec une taille de segment JVM gérable
 Cache plus grand et stockage de débordement plus rapide
 Sérialisation rapide et efficace des graphiques d'objets
 Put et mises à jour asynchrones via une stratégie d'écriture différée
 Augmente les opportunités de mise en cache hors tas
 Réduit la surcharge d'invalidation de cluster sur le tas
 Caches qui survivent aux redémarrages et aux plantages d'applications
 Fonctions de surveillance riches pour la maintenance préventive et le dépannage

Au niveau du proxy intelligent qui agrège les données des deux services, je mets en
œuvre une API GraphQL.
GraphQL est l'un des moyens les plus modernes de créer et d'interroger des API. GraphQL est
une syntaxe qui décrit comment demander des données, et est généralement utilisée pour charger
des données d'un serveur vers un client. GraphQL a trois caractéristiques principales:
 Il permet au client de spécifier exactement les données dont il a besoin.
 Cela facilite l'agrégation des données provenant de plusieurs sources.
  Il utilise un système de types pour décrire les données.
 Avec GraphQL, l'utilisateur est capable de faire un seul appel pour récupérer les
informations requises plutôt que de construire plusieurs requêtes REST pour les
récupérer.

Ainsi, une requête GraphQL est une chaîne qui est envoyée à un serveur pour être interprétée et
remplie, qui renvoie ensuite JSON au client.

Fig.8. GraphQL API

Conclusions

Comme toutes les autres technologies Internet, les serveurs proxy semblent souvent
incroyablement compliqués et difficiles à comprendre. Nous ne pouvons pas dire qu'ils sont aussi
simples que quelque chose de basique - mais avec juste assez de persévérance, vous pouvez les
maîtriser et utiliser les avantages qu'ils offrent pour rendre votre environnement en ligne plus sûr.
Les serveurs proxy Web sur de grands réseaux contribuent à améliorer la fiabilité en
bloquant les données malveillantes, et ils vous permettent de mettre en cache votre contenu Web
et de le renvoyer rapidement sur les demandes suivantes.