Rumah  >  Artikel  >  Operasi dan penyelenggaraan  >  Apakah senario aplikasi utama Nginx?

Apakah senario aplikasi utama Nginx?

王林
王林ke hadapan
2023-05-12 09:07:111959semak imbas

Apakah senario aplikasi utama Nginx?

Apa yang boleh dilakukan oleh Nginx

1. Proksi terbalik

2. Pengimbangan beban

3.Pelayan HTTP ( Termasuk pemisahan dinamik dan statik)

4 Proksi hadapan Di atas ialah apa yang saya tahu bahawa Nginx boleh mengendalikan tanpa bergantung pada modul pihak ketiga Berikut ialah penerangan terperinci tentang cara melakukan setiap fungsi

Proksi Songsang

Proksi songsang sepatutnya menjadi perkara yang paling biasa dilakukan oleh Nginx Apakah proksi terbalik Berikut adalah apa yang dikatakan oleh Ensiklopedia Baidu: Kaedah proksi terbalik (Reverse Proxy) merujuk kepada menggunakan pelayan proksi untuk Menerima sambungan. permintaan daripada Internet, kemudian memajukan permintaan kepada pelayan pada rangkaian dalaman, dan mengembalikan hasil yang diperoleh daripada pelayan kepada pelanggan yang meminta sambungan di Internet Pada masa ini, pelayan proksi berkelakuan sebagai pelayan proksi terbalik kepada dunia luar. Secara ringkasnya, pelayan sebenar tidak boleh diakses terus oleh rangkaian luaran, jadi pelayan proksi diperlukan oleh rangkaian luaran dan berada dalam persekitaran rangkaian yang sama dengan pelayan sebenar mungkin juga pelayan dan port yang sama. Tampal di bawah kod mudah untuk melaksanakan proksi terbalik

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

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

Simpan fail konfigurasi dan mulakan Nginx, supaya apabila kita mengakses localhost, ia sama dengan mengakses localhost:8080

Pengimbangan beban

Pengimbangan beban juga merupakan fungsi Nginx yang biasa digunakan untuk memperuntukkan pelaksanaan kepada berbilang unit pengendalian, seperti pelayan Web, pelayan FTP, pelayan aplikasi utama perusahaan dan pelayan kritikal misi lain, dsb. bersama-sama Menyelesaikan tugas kerja. Ringkasnya, apabila terdapat dua atau lebih pelayan, permintaan diedarkan secara rawak kepada pelayan yang ditetapkan untuk diproses mengikut peraturan Konfigurasi pengimbangan beban secara amnya memerlukan konfigurasi proksi terbalik pada masa yang sama, dan melompat ke pengimbangan beban melalui sebaliknya. proksi. Nginx kini menyokong 3 strategi pengimbangan beban terbina dalam, serta 2 strategi pihak ketiga yang biasa digunakan.

1. RR (lalai)

Setiap permintaan diberikan kepada pelayan bahagian belakang yang berbeza satu demi satu dalam susunan kronologi Jika pelayan bahagian belakang turun, ia boleh dihapuskan secara automatik.

Konfigurasi mudah

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;
       }
   }

Kod teras pengimbangan beban ialah

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

Di sini saya mengkonfigurasi 2 pelayan Sudah tentu, ia sebenarnya satu pelayan, tetapi portnya berbeza. Pelayan 8081 tidak wujud, bermakna ia tidak boleh diakses Namun, apabila kita mengakses http://localhost, ia akan melompat ke http://localhost:8080 secara lalai Secara automatik Tentukan status pelayan Jika pelayan tidak boleh diakses (pelayan sedang turun), ia tidak akan melompat ke pelayan ini, jadi ia juga mengelakkan situasi di mana pelayan tidak berfungsi dan menjejaskan penggunaannya dasar, kami tidak Lebih banyak tetapan diperlukan.

2. Berat

Menentukan kebarangkalian pengundian adalah berkadar dengan nisbah akses dan digunakan apabila prestasi pelayan bahagian belakang tidak sekata. Contohnya

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

maka secara amnya hanya 1 kali daripada 10 kali akan diakses ke 8081, dan 9 kali akan diakses ke 8080

3, ip_hash

2 di atas kaedah Terdapat masalah, iaitu, apabila permintaan seterusnya datang, permintaan mungkin diedarkan ke pelayan lain Apabila program kami tidak stateless (sesi digunakan untuk menyimpan data), maka terdapat masalah besar, jika maklumat log masuk disimpan dalam sesi, maka anda perlu log masuk semula apabila melompat ke pelayan lain. Jadi banyak kali kami memerlukan pelanggan untuk hanya mengakses satu pelayan, maka kami perlu menggunakan ip_hash setiap permintaan ip_hash menekan Hasil hash IP capaian diperuntukkan supaya setiap pelawat mempunyai akses tetap kepada pelayan bahagian belakang, yang boleh menyelesaikan masalah sesi.

upstream test {
       ip_hash;
       server localhost:8080;
       server localhost:8081;
   }
4. adil (pihak ketiga)

Permintaan diperuntukkan mengikut masa respons pelayan bahagian belakang, dan mereka yang mempunyai masa respons yang singkat diperuntukkan dahulu.

upstream backend {
       fair;
       server localhost:8080;
       server localhost:8081;
   }
5. url_hash (pihak ketiga)

Edarkan permintaan mengikut hasil cincangan URL yang diakses, supaya setiap URL dihalakan ke pelayan hujung belakang yang sama apabila pelayan bahagian belakang dicache . Tambahkan pernyataan cincang pada huluan Parameter lain seperti berat tidak boleh ditulis dalam pernyataan pelayan Hash_method ialah algoritma cincang yang digunakan

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

5 jenis pengimbangan beban di atas sesuai digunakan dalam situasi yang berbeza. anda boleh memilih mengikut situasi sebenar yang mana mod strategi untuk digunakan, tetapi adil dan url_hash perlu memasang modul pihak ketiga sebelum ia boleh digunakan Memandangkan artikel ini terutamanya memperkenalkan perkara yang boleh dilakukan oleh Nginx, pemasangan Nginx modul pihak ketiga akan tidak akan diperkenalkan dalam artikel ini

Pelayan HTTP

Nginx sendiri juga merupakan pelayan sumber statik Apabila hanya terdapat sumber statik, anda boleh menggunakan Nginx sebagai pelayan kini juga sangat popular untuk memisahkan sumber statik daripada sumber statik, yang boleh dicapai melalui Nginx Pertama, mari kita lihat Nginx sebagai pelayan sumber statik

  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

Atas ialah kandungan terperinci Apakah senario aplikasi utama Nginx?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Kenyataan:
Artikel ini dikembalikan pada:yisu.com. Jika ada pelanggaran, sila hubungi admin@php.cn Padam