nginx的常用配置

nginx

    Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器，
同时也提供了IMAP/POP3/SMTP服务。Nginx是由伊戈尔·赛索耶夫为俄罗斯访问量第二的Rambler.ru站点（俄文：Рамблер）开发的，第一个公开版本0.1.0发布于2004年10月4日。
    其将源代码以类BSD许可证的形式发布，因它的稳定性、丰富的功
能集、示例配置文件和低系统资源的消耗而闻名。2011年6月1日，nginx 1.0.4发布。
    Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件
（IMAP/POP3）代理服务器，在BSD-like 协议下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。来自百度百科。

nginx安装

    nginx 安装和部署比较简单，前面写过该部分内容，这里简单的
介绍nginx安装的两种方式，第一种使用docker部署（https://hub.docker.com/_/nginx），
第二种方式下载nginx的rpm 包安装。
（http://www.rpmfind.net/linux/rpm2html/search.php?query=nginx）。
在linux本地安装。

nginx 反向代理

正反向代理的区别

    正向代理（forward proxy）：是一个位于客户端和目标服务器之间的服务器(代理服务器)，为了从目标服务器取得内容，客户端向代理服务器发送一个请求并指定目
标，然后代理服务器向目标服务器转交请求并将获得的内容返回给客户端。
用途：突破访问限制、提高访问速度、隐藏客户端真实IP。
    反向代理（reverse proxy）：是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。
用途：隐藏服务器真实IP、负载均衡、提高访问速度。

nginx 的反向代理配置

Nginx 的 location 实现了对请求的细分处理，有些 URI 返回静态内容，有些分发到后端服务器。通过设置nginx default.conf配置文件，配置分发规则。

server {
  listen 80;
  server_name localhost;

  location ~ /edu/ {
    proxy_pass http://localhost:8081;
  }

  location ~ /vod/{
    proxy_pass http://localhost:8082;
  }
}

1、=：用于不含正则表达式uri前，要求字符串与uri严格匹配，如果匹配成功，就停止继续向下搜索并立即处理该请求。
2、~ : 用于表示uri：包含正则表达式，并且区分大小写。
3、~ *: 用于表示uri：包含正则表达式，并且不区分大小写。
4、^~: 表示普通字符匹配，如果该选项匹配，只匹配该选项，不匹配别的选项，一般用来匹配目录。
5、@: "@" 定义一个命名的 location，使用在内部定向时，例如 error_page, try_file。

nginx 负载均衡

    当一台服务器的单位时间内的访问量越大时，服务器压力就越大，大到超过自身承受能力时，服务器就会崩溃。为了避免服务器崩溃，让用户有更好的体验，我们通过负载均衡的方式来分担服务器压力。
    我们可以建立很多很多服务器，组成一个服务器集群，当用户访问网站时，先访问一个中间服务器nginx，再让nginx在服务器集群中选择一个压力较小的服务器，然后将该访问请求引入该服务器。如此一来，用户的每次访问，都会保证服务器集群节点压力趋于平衡，分担了服务器压力，避免了服务器崩溃的情况。
    编辑nginx的 nginx.conf配置文件，在upstream 逐行列出代理的服务地址，设置负载均衡分发规则，nginx 默认采用轮询的负载均衡策略。

http{
......
  upstream myserver {
    ip_hash;
    server 192.168.1.1 weight=1;
    server 192.168.1.2 weight=1;
    fair
  }
......
  server {
    location / {
      ......
      proxy_pass http://myserver;
      proxy_connect_timeout 10;
    }
  }
}

Nginx 提供的集中配置策略：

1、轮询（默认）

每一个请求按时间顺序逐一分配不同的后端服务器，如果后端服务器down掉，能自动剔除。

2、weight

weight 代表权重，默认为1，权重越高北分配的客户端越多。用户后端服务器性能不均的情况。

3、ip_hash

每一个请求按按访问ip的hash结果分配，这样每一个访客固定访问一个后端服务器，
可以解决session的问题。

4、fair 第三方
按后端服务器的响应时间来分配请求，响应时间短的优先分配。

nginx 动静分离

    通过nginx将动态请求和静态请求分离，可以减少不必要的请求消耗，
同时能减少请求的延时。对于更高要求的应用，nginx支持缓存，加快响应速度。autoindex 配置
项可以打开服务器文件夹的目录浏览功能，该功能可用作文件下载、服务器日志下载等。

upstream myserver {
    server 192.168.1.110:10083 weight=1;
    server 192.168.1.110:10081 weight=1;
}
server {
    listen       80;
    listen  [::]:80;
    server_name  127.0.0.1;

    #charset koi8-r;
    #access_log  /var/log/nginx/host.access.log  main;

    location /www/ {
      root /data/:
      index index.html index.htm
    }

    location /image/ {
      root /data/;
      autoindex on;           //
      autoindex_exact_size off;
      autoindex_localtime on;
    }

    location ~.(html|js|css|png|woff|ttf|ico) {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    location / {
        proxy_pass http://myserver;
    }

    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

}

配置说明：

1、autoindex on:打开目录浏览功能，可用作文件服务器。

2、autoindex_exact_size:默认为on，显示出文件的确切大小，单位是bytes,改为off后，
显示出文件的大概大小，单位是kB或者MB或者GB。

3、autoindex_localtime:默认为off，显示的文件时间为GMT时间,
改为on后，显示的文件时间为文件的服务器时间。

nginx rewrite规则

    rewrite的功能就是使用nginx提供的全局变量或自己设置的变量，
结合正则表达式或标志位实现url重写以及重定向。rewrite只能放到server{}，location{}，
if{}中。并且值对UIR起作用。
    rewrite 和location的区别在于rewrite是在同一域名内更改获取
资源的路径，而location是对一类路径做控制访问或反向代理，可以proxy_pass 到其它机器。
很多情况下，rewrite会写在location里，它的执行顺序是：

1. 执行server块的rewrite指令
2. 执行location 匹配
3. 执行选定的location中的rewrite指令
   
   如果其中某步URI被重写，则重新循环执行1-3，直到找到真实的文件。循环超过10次，则返回
   500 Internal Server Error。

rewrite语法格式及参数语法

rewrite是实现URL重写的关键指令，根据regex (正则表达式)部分内容，
重定向到replacement，结尾是flag标记。
rewrite            [flag];
关键字      正则        替代内容         flag标记

关键字：其中关键字error_log不能改变
正则：perl兼容正则表达式语句进行规则匹配
替代内容：将正则匹配的内容替换成replacement
flag标记：rewrite支持的flag标记
rewrite参数的标签段位置：
server,location,if

flag标记说明：
last  #本条规则匹配完成后，继续向下匹配新的location URI规则
break  #本条规则匹配完成即终止，不再匹配后面的任何规则
redirect  #返回302临时重定向，浏览器地址会显示跳转后的URL地址
permanent  #返回301永久重定向，浏览器地址栏会显示跳转后的URL地址

if指令

    该指令用来支持条件判断的，并且根据条件判断结果来选择不同的
nginx的配置，我们可以在server块或location块中配置该指令，
if(condition){...}.

• 当表达式是一个变量时，如果值为空或任何以0开头的字符串都会当作false
• 直接比较变量和内容时，~* 不区分大小写的匹配，~区分大小写
• '!~ ' 如果 '~' 匹配失败时，那么该条件就为true
• '!~ * ' 如果 '~*' 匹配失败时，那么该条件就为true

if ($http_user_agent ~ MSIE) {
  // 代码的含义：$http_user_agent值中是否含有 MSIE 字符串，如果包含为true，否则为false
}

判断请求的文件是否存在,

• '-f' 如果请求的文件存在，那么该条件为true
• '!-f' 如果该文件的目录存在，该文件不存在，那么返回true。如果该文件和目录都不存在，则为false

if (-f $request_filename) {
  // 判断请求的文件是否存在
}
if (!-f $request_filename) {
  // 判断请求的文件是否不存在
}

• 判断请求的目录是否存在使用 '-d' 和 '!-d'
• 使用 '-d'，如果请求的目录存在，则返回true。否则返回false
• 使用 '!-d', 如果请求的目录不存在，但是该请求的上级目录存在，则返回true。如果该上级目录不存在，则返回false
• -e 和 !-e 用来判断是否存在文件和目录
• -x 和 !-x 用来判断文件是否可执行

全部变量

下面是可以用if判断的全局变量

$args: # 找个变量等同于请求中的参数，同$query_string
$content_length: 请求头中的Content-length 字段
$content_type: 请求头当中的content-type字段
$document_root:当前请求在root指令中指定的值
$host: 请求主机头字段，是否为服务器名称
$http_user_agent: 客户端agent信息
$http_cookie: 客户端cookie信息
$limit_rate: 这个变量可以限制链接速率
$request_method: 客户端请求的动作，通常为GET或post
$remote_addr: 客户端的IP地址
$remote_port: 客户端的端口
$remote_user: 已经经过auth basic module验证的用户名
$request_filename: 当前请求的文件路径，由root或alias指令与uri请求生成
$scheme: http 方法（http,https）
$server_protocol: 请求使用的协议，通常是HTTP/1.0或HTTP/1.1
$server_addr: 服务器地址，在完成一次系统调用后可以确定这个值
$server_name: 服务器名称
$server_port: 请求到达服务器的端口号
$request_uri: 包含请求参数的原始URI，不包含主机名，如：/foo/bar.php?arg=baz
$uri: 不带请求参数的当前URI，$uri不包含主机名，如：/foo/bar.php
$document_uri: 与$uri相同

示例

if($http_user_agent ~ MSIE){
  rewrite ^(.*)$ /msid/$1 break;
} //如果UA包含 msie,rewrite 请求到/msid/ 目录下

if($http_cookie ~* "id=([^;]+)(?:;|$)"){
  set $id $1
} //如果cookie匹配正则，设置变量$id等于正则引用部分

if($request_method = post){
  return 405
} //如果提交方法为post，则返回状态405（Method not allowed）

if($slow){
  limit_rate 10k;
} //限速，$slow 可以通过set指令设置

if(!-f $request_filename){
  break;
  proxy_pass http://127.0.0.1;
} //如果请求文件不存在，则反向代理到localhost.这里的break也是停止rewrite检查

if($rags ~ post=140)){
  rewrite ^ http://example.com/ permanent;
} //如果query string 中包含“post=140”，永久定向到example.com

location ~* \.(gif|jpg|png|swf|flv)$ {
  valid_referers none blocked www.demo.com www.1122.com;
  if($invalid_referer){
    return 404;
  } //防盗链
}

防盗链

防盗链的实现原理：客户端向服务器端请求资源时，为了减少网络带宽，提高响应时间，
服务器一般不会一次将所有资源完整地传回客户端。比如请求一个网页时，首先会传回该网页
的文本内容，当客户端浏览器在解析文本的过程中发现有图片存在时，会再次向服务器发起对该
图片资源的请求，服务器将存储的图片资源再发送给客户端。但是如果这个图片是链接到其他站点
的服务器上去了呢，比如在我项目中，我引用了的是淘宝中的一张图片的话，那么当我们网站重新
加载的时候，就会请求淘宝的服务器，那么这就很有可能造成淘宝服务器负担。因此这个就是盗链行
为。因此我们要实现防盗链。

实现防盗链：使用http协议中请求头部的Referer头域来判断当前访问的网页或文件的源地址。
通过该头域的值，我们可以检测访问目标资源的源地址。如果目标源地址不是我们自己站内的URL
的话，那么这种情况下，我们采取阻止措施，实现防盗链。但是注意的是：Referer头域中的值
是可以被更改的。因此该方法也不能完全安全阻止防盗链。

1.根据请求文件类型实现防盗链配置实列如下：
server {
  listen 8080;
  server_name xxx.abc.com
  location ~* ^.+\.(gif|jpg|png|swf|flv|rar|zip)$ {
    valid_referers none blocked www.xxx.com www.yyy.com *.baidu.com  *.tabobao.com;
    if ($invalid_referer) {
      rewrite ^/ http://www.xxx.com/images/forbidden.png;
    }
  }
}
2.根据请求目录实现防盗链的配置实列如下：
server {
  listen 8080;
  server_name xxx.abc.com
  location /file/ {
    root /server/file/;
    valid_referers none blocked www.xxx.com www.yyy.com *.baidu.com  *.tabobao.com;
    if ($invalid_referer) {
      rewrite ^/ http://www.xxx.com/images/forbidden.png;
    }
  }
}

参考地址
https://segmentfault.com/a/1190000002797606
https://www.jianshu.com/p/a8261a1a64f8
https://www.cnblogs.com/tugenhua0707/p/10798762.html

nginx 配置高可用集群

    Keepalived是Linux下一个轻量级别的高可用解决方案。

    Keepalived起初是为LVS设计的，专门用来监控集群系统中各个服务
节点的状态，它根据TCP/IP参考模型的第三、第四层、第五层交换机制检测每个服务节点的状态，
如果某个服务器节点出现异常，或者工作出现故障，Keepalived将检测到，并将出现的故障的服
务器节点从集群系统中剔除，这些工作全部是自动完成的，不需要人工干涉，需要人工完成的只是
修复出现故障的服务节点。

    后来Keepalived又加入了VRRP的功能，
VRRP（VritrualRouterRedundancyProtocol,虚拟路由冗余协议)出现的目的是解决静态路
由出现的单点故障问题，通过VRRP可以实现网络不间断稳定运行，因此Keepalvied一方面具有服
务器状态检测和故障隔离功能，另外一方面也有HAcluster功能。

    健康检查和失败切换是keepalived的两大核心功能。
所谓的健康检查，就是采用tcp三次握手，icmp请求，http请求，udp echo请求等方式对负载均
衡器后面的实际的服务器(通常是承载真实业务的服务器)进行保活；而失败切换主要是应用于配置
了主备模式的负载均衡器，利用VRRP维持主备负载均衡器的心跳，当主负载均衡器出现问题时，
由备负载均衡器承载对应的业务，从而在最大限度上减少流量损失，并提供服务的稳定性。

    keepalived的工作原理详情参考
https://blog.csdn.net/qq_24336773/article/details/82143367。

keepalived部署

• 配置高可用的准备工作
  1. 准备两天服务器
  2. 在两台服务器中安装nginx
  3. 在两台服务器中安装keepalive
• keepalived 安装
  1. yum install keepalived -y
  2. 安装完成后在etc目录下生成keepalived目录，有文件keepalived.cnf
• 完成高可用配置（主从配置）

global_defs {
   notification_email { # 指定keep alived在发生切换时需要发送达到的邮件账户
     [email protected]
     [email protected]
     [email protected]
   }
   notification_email_from [email protected] #指定发件人
   smtp_server 192.168.200.1                #指定smtp 服务器地址
   smtp_connect_timeout 30
   router_id LVS_DEVEL
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}
vrrp_instance VI_1 {
    state MASTER   #master 主服务器，BACKUP 从服务器
    interface ens33 #设置示例绑定网卡，ifconfig 命令查看网卡信息
    virtual_router_id 51
    priority 100     # master 权重高于BACKUP
    advert_int 1     # 主从机器之间同步检查的时间间隔
    authentication {  # 设置认证
        auth_type PASS  # 主从服务器验证方式
        auth_pass 1111
    }
    virtual_ipaddress {  # 设置ip,多个虚拟ip
        192.168.200.16
        192.168.200.17
        192.168.200.18
    }
}

• 启动keepalived服务,命令: service keepalived start
• 检测keepalived是否成功，命令: ip add show ens33;

nginx 原理

    nginx的基本原来网上的资料太多了，简单了解一下，这里贴出来其它博客地址。
https://developer.51cto.com/art/201909/602664.htm
https://www.jianshu.com/p/c1c62e1af266

nginx 监控Amplify

    Amplify是一个免费的监控工具，可以用来监控基于nginx的微服务
架构。Amplify由nginx软件背后的公司开发和维护。

    使用Amplify，可以跨容器收集和聚合度量，并呈现关键性能数据的
一致可视化集，例如每秒的活动连接或请求数。它还可以很容易地快速检查任何性能下降、
流量异常，并更深入地了解nginx配置。

    为了使用Amplify，应该在容器内安装一个基于Python的小型代理
软件（Amplify agent）。案例安装地址（https://github.com/nginxinc/docker-nginx-amplify）。
想要了解更多有关Amplify的信息，
请查看的官方文档（https://github.com/nginxinc/nginx-amplify-doc）。

    目前Amplify agent 采集到的数据需要发送到amplify的pass平台，
这个不适应我们的生产条件，本地测试看看效果。

nginx + keepalived高可用配置参考博客如下：
https://blog.csdn.net/java_zyq/article/details/90041267