Nginx基础详解，内涵案例分析-优快云博客

本文链接：https://blog.youkuaiyun.com/weixin_38303684/article/details/78417010

这是我看的思路比较清晰的有关Nginx基本功能讲解的文章，先转给大家一起看，顺便自己收藏一手！！！

以下是转载的文章内容：

1、静态HTTP服务器

首先，Nginx是一个HTTP服务器，可以将服务器上的静态文件（如HTML、图片）通过HTTP协议展现给客户端。

配置：

[html]view plain copy 
   
 server {  
     listen80; # 端口号  
     location / {  
         root /usr/share/nginx/html; # 静态文件路径  
     }  
 }  

2、反向代理服务器

什么是反向代理？

客户端本来可以直接通过HTTP协议访问某网站应用服务器，网站管理员可以在中间加上一个Nginx，客户端请求Nginx，Nginx请求应用服务器，然后将结果返回给客户端，此时Nginx就是反向代理服务器。

配置：

[html]view plain copy 
     
 server {  
     listen80;  
     location / {  
         proxy_pass http://192.168.20.1:8080; # 应用服务器HTTP地址  
     }  
 }  

既然服务器可以直接HTTP访问，为什么要在中间加上一个反向代理，不是多此一举吗？反向代理有什么作用？继续往下看，下面的负载均衡、虚拟主机等，都基于反向代理实现，当然反向代理的功能也不仅仅是这些。

3、负载均衡

当网站访问量非常大，网站站长开心赚钱的同时，也摊上事儿了。因为网站越来越慢，一台服务器已经不够用了。于是将同一个应用部署在多台服务器上，将大量用户的请求分配给多台机器处理。同时带来的好处是，其中一台服务器万一挂了，只要还有其他服务器正常运行，就不会影响用户使用。

Nginx可以通过反向代理来实现负载均衡。

配置

[html]view plain copy 
   
 upstream myapp {  
     server192.168.20.1:8080; # 应用服务器1  
     server192.168.20.2:8080; # 应用服务器2  
 }  
 server {  
     listen80;  
     location / {  
         proxy_pass http://myapp;  
     }  
 }  

以上配置会将请求轮询分配到应用服务器，也就是一个客户端的多次请求，有可能会由多台不同的服务器处理。可以通过ip-hash的方式，根据客户端ip地址的hash值将请求分配给固定的某一个服务器处理。

配置：

[html]view plain copy 
   
 upstream myapp {  
     ip_hash; # 根据客户端IP地址Hash值将请求分配给固定的一个服务器处理  
     server192.168.20.1:8080;  
     server192.168.20.2:8080;  
 }  
 server {  
     listen80;  
     location / {  
         proxy_pass http://myapp;  
     }  
 }  

另外，服务器的硬件配置可能有好有差，想把大部分请求分配给好的服务器，把少量请求分配给差的服务器，可以通过weight来控制。

配置：

[html]view plain copy 
   
 upstream myapp {  
     server192.168.20.1:8080weight=3; # 该服务器处理3/4请求  
     server192.168.20.2:8080; # weight默认为1，该服务器处理1/4请求  
 }  
 server {  
     listen80;  
     location / {  
         proxy_pass http://myapp;  
     }  
 }  

4、虚拟主机

有的网站访问量大，需要负载均衡。然而并不是所有网站都如此出色，有的网站，由于访问量太小，需要节省成本，将多个网站部署在同一台服务器上。

例如将www.aaa.com和www.bbb.com两个网站部署在同一台服务器上，两个域名解析到同一个IP地址，但是用户通过两个域名却可以打开两个完全不同的网站，互相不影响，就像访问两个服务器一样，所以叫两个虚拟主机。

配置：

[html]view plain copy 
   
 server {  
     listen80default_server;  
     server_name _;  
     return444; # 过滤其他域名的请求，返回444状态码  
 }  
 server {  
     listen80;  
     server_name www.aaa.com; # www.aaa.com域名  
     location / {  
         proxy_pass http://localhost:8080; # 对应端口号8080  
     }  
 }  
 server {  
     listen80;  
     server_name www.bbb.com; # www.bbb.com域名  
     location / {  
         proxy_pass http://localhost:8081; # 对应端口号8081  
     }  
 }  

在服务器8080和8081分别开了一个应用，客户端通过不同的域名访问，根据server_name可以反向代理到对应的应用服务器。

虚拟主机的原理是通过HTTP请求头中的Host是否匹配server_name来实现的，有兴趣的同学可以研究一下HTTP协议。

另外，server_name配置还可以过滤有人恶意将某些域名指向你的主机服务器。

5、FastCGI

Nginx本身不支持PHP等语言，但是它可以通过FastCGI来将请求扔给某些语言或框架处理（例如PHP、Python、Perl）。

[html]view plain copy 
   
 server {  
     listen80;  
     location ~ \.php$ {  
         include fastcgi_params;  
         fastcgi_param SCRIPT_FILENAME /PHP文件路径$fastcgi_script_name; # PHP文件路径  
         fastcgi_pass127.0.0.1:9000; # PHP-FPM地址和端口号  
         # 另一种方式：fastcgi_pass unix:/var/run/php5-fpm.sock;  
     }  
 }  

配置中将.php结尾的请求通过FashCGI交给PHP-FPM处理，PHP-FPM是PHP的一个FastCGI管理器。

转自：http://blog.youkuaiyun.com/zhongguozhichuang/article/details/52816887

案例分析：

通俗理解，首先当我们不用Nginx做反向代理时，我们通常是一个服务器在工作，那么当客户访问量很大的时候，我们都知道服务器会变慢或者承受不了，那么加上一个Nginx做反向代理，用于接收和处理客户的请求，然后把这些请求分发给下面一群小弟，也即是服务器，这里就会涉及到集群和分布式的概念，大家可以自行百度一下，这样就能做到优化。

再给大家举个我在网上看到的详细的例子：

首先我们要了解系统的性能瓶颈在哪里，一般来说网络io速度和内存io接近，都远高于磁盘io。假定一个接口请求返回数据100k（一般没有这么大，只是假定一个方便计算的值），10个并发请求就是1M，那么全双工千兆网卡（现在还有万兆网卡，但成本太高，应用还不广），可以支撑并发10000个请求，开双网卡，理论的上限就是20000个并发请求。

假设我们收到请求马上就返回，那么最高并发数就是我们上面计算的结果，但是，问题在于，应用服务器做不到马上返回，因为它有很多业务逻辑需要执行处理，比如给用户发推送发短信发邮件，本地磁盘写日志，请求数据库增删改查，调用微信的登录接口等等等等，都附加了各个层面的io。

所以第一层的优化，我们会尽量优化应用服务自身，把发推送发短信发邮件的活推到队列，让别的服务器去干。这个一般用内存队列，io很高。

开多线程或者协程的方式异步写日志，但再怎么优化，磁盘io的上限突破不了，这个io很低。还有更激进的方案，干脆日志也写内存，或者通过内网网络同步到别的服务器上，可以更优化。

数据库复用连接池，减少连接和断开的时间开销。查询语句尽量优化，减少等待数据库操作的时间。当然，再怎么优化，一样有个上限。

调用微信的登录接口等外部接口，这个就更难办了，受制于人，除了tcp连接池复用能稍微优化一点点，完全是取决于外部条件。

木桶理论取最短板，所有这些条件里，总有最慢最落后的那个。假如拖后腿的这个，最佳状态也只能优化到支持2000个并发，那就尴尬了，本来能支持20000个请求的系统，只能用到1/10性能。

（当然也可以在dns对应不同ip方式分布请求，但是dns层面的分布更复杂更麻烦，因为dns缓存的原因，请求也不能均匀分布，而且ip地址也是越来越稀缺的资源，没有背景没有后台的，搞这么多ip也不容易啊）

单个公网ip算一个节点的话，这个节点本来的潜力是响应20000个并发请求，实际在应用层面只能到2000并发，潜力还未发掘啊。这个时候，就是反向代理起到用武之地的时候了。

首先一个反向代理的服务器抛开所有业务层的东西，只单纯的接下请求再返回，那么可以支持到20000并发了。接下来应用层面谁来处理？找来10个小弟，转发给他们，每人2000正好。这样这个节点系统虽然性价比只有10/11，但是性能潜力好歹挖尽了。

这就是反向代理的作用了。

相关Nginx反向代理提高性能可以看：https://www.zhihu.com/question/19761434