Quels sont les principaux scénarios d'application de Nginx ?

Que peut faire Nginx ? Les éléments que les modules tiers peuvent gérer, voici une description détaillée de la façon d'exécuter chaque fonction

Proxy inversé

Le proxy inverse devrait être la chose la plus courante que fait Nginx. provient de l'Encyclopédie Baidu Argument : La méthode du proxy inverse consiste à utiliser un serveur proxy pour accepter les demandes de connexion sur Internet, puis à transmettre les demandes au serveur sur le réseau interne et à renvoyer les résultats obtenus du serveur au client demandant une connexion. sur Internet, le serveur proxy apparaît actuellement comme un serveur proxy inverse pour le monde extérieur. Pour faire simple, le serveur réel n'est pas directement accessible par le réseau externe, un serveur proxy est donc nécessaire. Le serveur proxy est accessible par le réseau externe et se trouve dans le même environnement réseau que le serveur réel. peut également être le même serveur et le même port. Collez ci-dessous un code simple pour implémenter le proxy inverse

server {
       listen       80;                                                        
       server_name  localhost;                                              
       client_max_body_size 1024M;

       location / {
           proxy_pass http://localhost:8080;
           proxy_set_header Host $host:$server_port;
       }
   }

Enregistrez le fichier de configuration et démarrez Nginx, de sorte que lorsque nous accédons à localhost, cela équivaut à accéder à localhost :8080

Équilibrage de charge

L'équilibrage de charge est également couramment utilisé dans Nginx As une fonction, l'équilibrage de charge signifie attribuer l'exécution à plusieurs unités opérationnelles, telles que des serveurs Web, des serveurs FTP, des serveurs d'applications clés d'entreprise et d'autres serveurs critiques, etc., afin d'accomplir conjointement des tâches de travail. Pour faire simple, lorsqu'il y a deux serveurs ou plus, les requêtes sont distribuées de manière aléatoire aux serveurs désignés pour être traitées selon des règles. La configuration de l'équilibrage de charge nécessite généralement la configuration d'un proxy inverse en même temps et passe à l'équilibrage de charge via l'inverse. procuration. Nginx prend actuellement en charge 3 stratégies d'équilibrage de charge intégrées, ainsi que 2 stratégies tierces couramment utilisées.

1. RR (par défaut)

Chaque requête est attribuée à différents serveurs backend un par un par ordre chronologique. Si le serveur backend tombe en panne, il peut être automatiquement éliminé.

Configuration simple

upstream test {
       server localhost:8080;
       server localhost:8081;
   }
   server {
       listen       81;                                                        
       server_name  localhost;                                              
       client_max_body_size 1024M;

       location / {
           proxy_pass http://test;
           proxy_set_header Host $host:$server_port;
       }
   }

Le code de base de l'équilibrage de charge est

upstream test {
       server localhost:8080;
       server localhost:8081;
   }

Ici, j'ai configuré 2 serveurs, bien sûr, c'est en fait un, mais le port est différent, et le serveur 8081 n'existe pas, ce qui signifie que l'accès est non, mais lorsque nous accéderons à http://localhost, il n'y aura aucun problème. Il passera à http://localhost:8080 par défaut, car Nginx déterminera automatiquement l'état du serveur si le serveur est inaccessible. le serveur se bloque), il ne passera pas à ce serveur, ce qui évite également la situation où un serveur se bloque et affecte l'utilisation. Puisque Nginx utilise par défaut la politique RR, nous n'avons besoin d'aucun autre paramètre.

2. Poids

Spécifie 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. Par exemple

upstream test {
       server localhost:8080 weight=9;
       server localhost:8081 weight=1;
   }

Généralement, seulement 1 fois sur 10 accédera à 8081, et 9 fois accédera à 8080

3, ip_hash

Les deux méthodes ci-dessus ont un problème, c'est-à-dire que la prochaine requête arrive A ce moment, la requête peut être distribué sur un autre serveur. Lorsque notre programme n'est pas apatride (en utilisant une session pour enregistrer les données), il y aura un gros problème à ce moment-là, par exemple, si les informations de connexion sont enregistrées dans la session, passez à une autre. serveur, vous devez vous reconnecter, donc souvent nous avons besoin qu'un client accède à un seul serveur, alors nous devons utiliser ip_hash. Chaque requête de ip_hash est allouée en fonction du résultat de hachage de l'adresse IP consultée, de sorte que chaque visiteur soit. corrigé L'accès à un serveur backend peut résoudre les problèmes de session.

upstream test {
       ip_hash;
       server localhost:8080;
       server localhost:8081;
   }

4. équitable (tiers)

Attribuez les demandes en fonction du temps de réponse du serveur backend, et celles avec des temps de réponse courts seront attribuées en premier.

upstream backend {
       fair;
       server localhost:8080;
       server localhost:8081;
   }

5. url_hash (tiers)

Distribuez les requêtes en fonction du résultat de hachage de l'URL consultée, afin 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. . Ajoutez une instruction de hachage en amont. D'autres paramètres tels que le poids ne peuvent pas être écrits dans l'instruction du serveur. hash_method est l'algorithme de hachage utilisé

upstream backend {
       hash $request_uri;
       hash_method crc32;
       server localhost:8080;
       server localhost:8081;
   }

Les cinq méthodes d'équilibrage de charge ci-dessus peuvent être utilisées dans différentes situations, vous pouvez donc choisir quelle stratégie. à utiliser en fonction du mode de situation réel, mais fair et url_hash doivent installer des modules tiers avant de pouvoir être utilisés. Puisque cet article présente principalement ce que Nginx peut faire, l'installation de modules tiers pour Nginx ne sera pas introduite dans. cet article

Serveur HTTP

Nginx lui-même est également un serveur de ressources statiques. Lorsqu'il n'y a que des ressources statiques, vous pouvez utiliser Nginx comme serveur. En même temps, il est également très populaire maintenant de séparer les ressources statiques des ressources statiques. , qui peut être réalisé via Nginx. Tout d'abord, jetons un coup d'œil à Nginx en tant que serveur de ressources statiques

.

  server {
       listen       80;                                                        
       server_name  localhost;                                              
       client_max_body_size 1024M;


       location / {
              root   e:\wwwroot;
              index  index.html;
          }
   }

这样如果访问http://localhost 就会默认访问到E盘wwwroot目录下面的index.html，如果一个网站只是静态页面的话，那么就可以通过这种方式来实现部署。 动静分离 动静分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来，动静资源做好了拆分以后，我们就可以根据静态资源的特点将其做缓存操作，这就是网站静态化处理的核心思路

upstream test{  
      server localhost:8080;  
      server localhost:8081;  
   }  
     
   server {  
       listen       80;  
       server_name  localhost;  
 
       location / {  
           root   e:\wwwroot;  
           index  index.html;  
       }  
         
       # 所有静态请求都由nginx处理，存放目录为html         location ~ \.(gif|jpg|jpeg|png|bmp|swf|css|js)$ {  
           root    e:\wwwroot;  
       }  
         
       # 所有动态请求都转发给tomcat处理         location ~ \.(jsp|do)$ {  
           proxy_pass  http://test;  
       }  
         
       error_page   500 502 503 504  /50x.html;  
       location = /50x.html {  
           root   e:\wwwroot;  
       }  
   }

这样我们就可以吧HTML以及图片和css以及js放到wwwroot目录下，而tomcat只负责处理jsp和请求，例如当我们后缀为gif的时候，Nginx默认会从wwwroot获取到当前请求的动态图文件返回，当然这里的静态文件跟Nginx是同一台服务器，我们也可以在另外一台服务器，然后通过反向代理和负载均衡配置过去就好了，只要搞清楚了最基本的流程，很多配置就很简单了，另外localtion后面其实是一个正则表达式，所以非常灵活

正向代理

正向代理，意思是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端才能使用正向代理。当你需要把你的服务器作为代理服务器的时候，可以用Nginx来实现正向代理，但是目前Nginx有一个问题，那么就是不支持HTTPS，虽然我百度到过配置HTTPS的正向代理，但是到最后发现还是代理不了，当然可能是我配置的不对，所以也希望有知道正确方法的同志们留言说明一下。

resolver 114.114.114.114 8.8.8.8;
   server {
       
       resolver_timeout 5s;

       listen 81;

       access_log  e:\wwwroot\proxy.access.log;
       error_log   e:\wwwroot\proxy.error.log;

       location / {
           proxy_pass http://$host$request_uri;
       }
   }

resolver是配置正向代理的DNS服务器，listen 是正向代理的端口，配置好了就可以在ie上面或者其他代理插件上面使用服务器ip+端口号进行代理了。

最后说两句

Nginx是支持热启动的，也就是说当我们修改配置文件后，不用关闭Nginx，就可以实现让配置生效，当然我并不知道多少人知道这个，反正我一开始并不知道，导致经常杀死了Nginx线程再来启动。。。Nginx从新读取配置的命令是

nginx -s reload

windows下面就是

nginx.exe -s reload

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!