Équilibrage de charge – quelques questions sur le proxy inverse nginx ?

Question

J'utilise deux serveurs pour configurer un proxy inverse. Le serveur A transmet toutes les demandes au groupe de serveurs de test via la configuration suivante (bien qu'il n'y en ait qu'une dans le groupe) {Code...} Accédez au serveur A via le navigateur et renvoyez le contenu du serveur B. Voici le problème : 1. Serveur B (le serveur étant doté d'un proxy inverse...

怪我咯 · Answer

Point 1 : Pour faire simple, l'objet proxy ne nécessite aucune configuration, mais il est à noter que si vous souhaitez traiter l'IP source de la requête sur B, alors vous devez faire une configuration sur nginx sur A, et modifier l'adresse IP source Mettez-la dans l'en-tête de la requête, par exemple,

Point 2 : Je n'ai jamais utilisé en amont, d'habitude j'utilise proxy_pass

location / {
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $http_host;
      proxy_set_header X-NginX-Proxy true;

      proxy_pass http://127.0.0.1:6101/;
      proxy_redirect off;
      proxy_buffering off;
    }

Point 3 : De manière générale, oui.

高洛峰 · Answer

1 Le serveur proxy B ne nécessite aucun paramètre
2 L'ajout de plusieurs groupes de serveurs en amont est ce qu'on appelle la configuration d'équilibrage de charge. Configurez ensuite proxy_pass
3. Le serveur à charge équilibrée partage théoriquement les données et a la même activité, mais est distribué et déployé sur différentes machines pour réduire la pression du serveur. (L'affiche peut démarrer plusieurs services avec la même activité sur différents ports du même serveur, et configurer l'équilibrage de charge, vérifiez-le faites-le vous-même !)

Il existe actuellement plusieurs méthodes de stratégie d'équilibrage de charge

Polling (par défaut) : chaque requête est attribuée à un serveur backend différent une par une dans l'ordre chronologique. Si le serveur backend tombe en panne, il peut être automatiquement éliminé.
weight : spécifiez la probabilité d'interrogation, le poids est proportionnel au taux d'accès et est utilisé lorsque les performances du serveur back-end sont inégales.
ip_hash : Chaque requête est allouée en fonction du résultat de hachage de l'IP accédée, afin que chaque visiteur ait un accès fixe à un serveur backend, ce qui peut résoudre le problème de session.
équitable (tiers) : Attribuez les requêtes en fonction du temps de réponse du serveur backend, avec une priorité donnée à celles ayant des temps de réponse courts.
url_hash (tiers) : Distribuez les requêtes en fonction du résultat de hachage de l'URL consultée, de sorte que chaque URL soit dirigée vers le même serveur back-end. C'est plus efficace lorsque le serveur back-end est mis en cache.