Équilibrage de charge ———> via un proxy inverse pour atteindre
Proxy à sept couches et proxy à quatre couches du proxy inverse nginx
Sept couches de proxy :
La méthode de proxy inverse la plus couramment utilisée pour le proxy à sept couches ne peut être configurée que dans le module http du fichier de configuration nginx, et le nom de la méthode doit être défini comme module « en amont ». Notez qu'il ne peut pas être écrit dans le module serveur. ou dans le module Dans la localisation ;
En même temps, le module amont est un module indépendant dans le module http
Proxy à sept couches : le proxy est une requête et une réponse http
Le principe de fonctionnement du proxy à sept couches :
Client -> requête http -> proxy à sept couches (sur le serveur proxy) -> le serveur proxy transmet http, en demandant à un ensemble de serveurs internes (cluster Web) -> le client ne sait pas si le serveur est encore à l'ère de la requête du serveur interne, et l'adresse IP du serveur interne est cachée via le serveur proxy.
En fait, on accède au serveur proxy, la requête est envoyée au proxy, et le proxy la transmet au serveur Web, et le serveur Web répond———————en fait, le serveur Web répond
Proxy de couche 4
Le proxy à quatre couches est basé sur le protocole TCP/IP, et la méthode de transfert proxy de la couche de protocole peut réaliser un transfert avec équilibrage de charge basé sur l'adresse IP et le numéro de port ; le proxy à quatre couches ne peut pas obtenir les informations URL dans le requête http, mais ne peut traiter que le paquet de données tcp/udp Pour le transfert, le transfert de trafic, le nom de la méthode de configuration : flux ; le flux ne peut pas être configuré dans le module http, il est configuré dans le module global et appartient à un module indépendant
La différence entre un proxy à quatre niveaux et un proxy à sept niveaux (c'est nous qui soulignons !!)
1. Le proxy à sept couches utilise des requêtes http, tandis que le proxy à quatre couches utilise des paquets TCP/UDP et transfère le trafic.
Proxy à sept couches : requête http, qui permet d'analyser et de traiter la requête en profondeur. Tels que : contrôle de flux, filtrage de contenu ;
Proxy à quatre couches : pas de contrôle de flux et pas de filtrage de contenu ;
Le proxy à quatre couches convient généralement aux scénarios qui nécessitent de gérer un grand nombre de demandes de connexion.
Le proxy à sept couches convient généralement pour : la scène de traitement précis et de contrôle des demandes
Dans le travail réel, le proxy à quatre niveaux et le proxy à sept niveaux peuvent être utilisés ensemble
2. La vitesse de l'agent à quatre niveaux est plus rapide que celle de l'agent à sept niveaux ;
raison:
(1) : Le proxy à quatre couches est destiné au transfert du trafic et ne peut pas analyser et contrôler la demande, il doit donc être rapide
(2) : L'agent à quatre couches utilise le noyau et le noyau transfère le trafic, ce qui est rapide
Le proxy de couche 7 est relativement lent
raison:
(1) : Le proxy à sept couches traite et analyse la demande, ce qui est lent
(2) : Le proxy à sept couches est en mode utilisateur, contrôle d'accès et traitement du trafic ; il est donc lent
Le proxy à sept couches peut fournir un service supérieur et une expérience utilisateur supérieure
Proxy direct et proxy inverse
Proxy direct :
Le module proxy_pass configure l'adresse d'accès du serveur proxy, ce module ne peut être écrit que dans le module de localisation
proxy inverse :
Le client accède au serveur proxy et le serveur proxy transmet les requêtes ou le trafic au serveur principal. Il y aura plusieurs serveurs Web principaux, mais l'utilisateur ne sait pas à quel serveur il accède finalement.
Le rôle du proxy inverse : équilibrage de charge, haute disponibilité, évolutivité et maintenabilité améliorée.
Comment faire du reverse proxy au travail ?
Proxy inverse -> équilibrage de charge
en amont : équilibrage de charge basé sur http, proxy inverse
Caractéristiques:
1. La méthode d'équilibrage de charge des requêtes http
2. Pas de cache
3. Algorithme d'équilibrage de charge :
(1) Algorithme par défaut : interrogation (rr ); les requêtes sont affectées tour à tour au serveur principal. L'algorithme d'interrogation est utilisé lorsque plusieurs serveurs Web ont des capacités de traitement similaires. L'algorithme par défaut peut être omis.
(2) Algorithme de pondération : sur la base de l'algorithme d'interrogation, en pondérant différents serveurs Web, les serveurs dotés de capacités de traitement plus élevées peuvent allouer plus de requêtes ; (Remarque : bien que le poids soit configuré, le résultat de la chute peut ne pas toujours être précis)
(3) ip_hash : calcule une valeur de hachage basée sur l'adresse IP. Après avoir utilisé l'algorithme ip_hash, la demande du même client sera ibei allouée au même serveur backend pour assurer la stabilité de la session ; lorsque le nombre de serveurs backend changements, la valeur de hachage sera recalculée et le serveur demandé peut également changer
(4) Le nombre minimum de connexions : less_conn ; interrogera, fonctionnalités : enverra la requête au serveur Web principal avec le moins de connexions actuelles, ce qui convient aux situations où le serveur principal prend un temps différent pour traiter les tâches et évite toutes les requêtes étant concentrées dans Sur les serveurs back-end dotés de capacités de traitement plus fortes, l'algorithme less_conn sera utilisé en combinaison avec l'algorithme round-robin pondéré
(5) url_hash : calculez la valeur de hachage en fonction de l'adresse URI. Lors de l'utilisation de l'algorithme url_hash, l'URI de la même requête sera attribué au même serveur backend
Scénarios d'utilisation des algorithmes d'équilibrage de charge :
Scénarios à petite échelle : le degré de concurrence est faible et l'algorithme par défaut peut répondre aux conditions applicables
La capacité de traitement du serveur Web principal peut être utilisée en conjonction avec la différence, le round robin pondéré et le nombre minimum de connexions.
Concurrence à grande échelle : ip_hash, url_hash ; après la première requête, un cache local sera généré et, grâce à l'algorithme de hachage, le serveur Web back-end demandé ne changera pas, ce qui peut améliorer la vitesse d'accès et le cache local. est accessible. Réduire la capacité de requêtes du serveur backend
point important:
ip_hash : lorsque le nombre de serveurs backend change, le serveur demandé peut changer
uri_hash : lorsque l'adresse demandée change, le serveur demandé peut également changer