nginx负载均衡-ag真人游戏

ngnix-负载均衡

• 在多台服务器之间有效地分配客户端请求或网络负载
• 通过仅向正常服务器发送请求确保高可用性和可靠性
• 业务不中断地情况下，按需弹性分配服务器资源
  

基本配置

http {
  
    upstream myproject {
  
    ##后端目标服务器
        server 10.10.10.1:8080;
        server 10.10.10.2:8080;
        server 10.10.10.3:8080;
        server 10.10.10.4:8080;
    }
    server {
  
    ##前端接受流量入口
        listen 80;
        server_name www.domain.com;
        location / {
   
            proxy_pass http://myproject;
        }
    }
}
##selinux配置
*setsebool -p httpd_can_network_connect 1

报文头修改行为

• 删除所有的空值报文头，空值时没有意义的，不需要转发到后台服务器
• 包含下划线“_”的报文头将会被静默丢弃，如需要开启可以使用指令underscores_in_headers on 这样做是为了避免在将header射到cgi变量时混淆，因为在此过程中，破折号和下划线都映射到了下划线
• host报文头会被重写为$proxy_host变量值，该变量值为proxy_pass指令中所包含的域名或ip地址
• connection报文头将会被修改为close，http1.1将会被修改为http1.0，该行为会使得收到服务器端的响应后即刻关闭，服务器侧的连接不会保持，http1.1变量可以用proxy_http_version指定

#代理请求request报文头修改指令
syntax：
proxy_set_header field values;
default:proxy_set_header host $proxy_host;proxy_set_header connection close;
context:http,server,location

host报文头对应的变量

服务器获取真实客户端ip

location /match/here {
  
    proxy_set_header host $host;
    proxy_set_header x-forwaeded_proto $scheme;
    proxy_set_header x-real_ip $remote_addr;
    proxy_set_header x-forwarded-for $proxy_add_x_forwarded_for;
    proxy_pass http://example.com;
}

proxy_add_header 可以在http上下文，server上下文，location上下文添加，以统一代理转发

proxy中的buffer行为

代理到另一台服务器是，两个不同连接的速度将影响客户端的体验

• 客户端到nginx的连接（通过互联网，带宽100mbps/30ms延迟）
• nginx代理到后端服务器的连接(内网环境，带宽万兆/1ms延迟)

默认nignx会开启缓冲机制，启用缓冲后，nginx会尽快从代理服务器收到响应，并将其保存到proxy_buffer_size和proxy_buffers指令设置的缓冲区。如果整个响应都无法容纳到内存中，则可以将一部分响应保存到磁盘上的临时文件中。写入临时文件由proxy_max_temp_file_size和proxy_temp_file_write_size指令控制。

禁用缓冲后，响应一收到就立即同步传递到客户端。nginx不会尝试从代理服务器读取整个响应。nginx一次可以从服务器节接受的最大数据大小由proxy_buffer_size指令设置。也可以通过在x-accel-buffering响应头字段中传递“yes”或“no”来启用或禁用缓冲。可以使用proxy_ignore_headers指令禁用此功能。

请注意在整体buffer行为中，还包含操作系统的tcp协议buffer

proxy buffer相关参数

question

如果nginx收到完整的response，但是客户端此时异常中断，在服务器上会不会标示这笔response对应的业务时完整的，但是客户端并没有收到。

proxy_ignore_client_abort
#default value: off

其他比较重要的参数

proxy cache行为

在有proxy cache的配置的情况下，客户端请求不会被转发到后端服务器，而是直接做在nginx上使用本地cache返回

该行为取决于

• nginx是否配proxy_cache，默认情况下proxy_pass不会做cache
• 默认后端服务器response有cahce-control的情况下会cache

在配置了cache，但是在下列情况下时不会做cache的

• 没有cache-control
• cache-control 为private，no-cache，no-store
• 响应请求中有set cookie
• 非get/head请求

追踪cache： add_header x-cache-status $upstream_cache_status;

proxy_cache指令

proxy_cache_path /path/to/cache keys_zone=my_cache:10m levels=1:2 max_size=10g inactive= 60m
use_temp_path=off;
server {
  
    listen 80;
    location / {
  
        proxy_cache my_cache;
        proxy_pass http://my_upstream;
     }
}

cache行为tips
在cache路径下会很多cache对象条目，条目内容包含实际的返回内容，条目
名称默认的生成模式为:md5($scheme$proxy_host$request_uri)
可以用指令：

proxy_cache_key $proxy_host$request_uri$cookie_jessionid;

重新定义生成cache key,配合 proxy_cache_mtheods,可以cache动态结果

request tracing

经过nginx负载均衡后，如何把前后请求关联起来，nginx plus r10和nginx 1.11.0引入了变量 $request_id变量，该变量是随机生成的32个十六进制字符的字符串，该字符串会在每个http请求到达是自动跟配给它，通过配置nginx plus和所有后端服务以传递$request_id值，可以端对端跟踪每个请求
用法

• proxy_add_header:服务器侧请求跟踪
• add_heaer:在客户端侧做测试
• log format：做前后端请求关联，排障

log_format trace '$remote_addr:$remote_port - $remote_user [$time_local]' '"$request" $status $body_byte_sent "$https_referer"' '"$http_user_agent" "$http_x_forwarded_for" $request_id';

tracing config sample

log_format trace '$remote_addr:$remote_port $upstream_addr- $remote_user [$time_local]' '"$request" $status $body_byte_sent "$https_referer"' '"$http_user_agent" "$http_x_forwarded_for" $request_id';
sever {
  
    access_log /var/log/nginx/access.log trace;
    listen 80;
    proxy_set_header host $host;
    proxy_set_header x-forwarded-proto $scheme;
    proxy_set_header x-real-ip $remete_addr;
    #add_header x-request-id $request_id;
    proxy_set_header x-forwarded-for $proxy_add_x_forwarded_for;
    proxy_set_header x-request-id $request_id;
    location / {
  
        proxy_buffering on;
        proxy_pass http://myupstream;
    }
}

如果后端也是nginx，直接使用$request_id是本机生成id，可以用$http_x_request_id获取上级id

#upstream.example
upstream myproject {
  
    ip_hash;
    server 127.0.0.1:8080 max_fail=10 fail_timeout=30s max_conns=300;
    server 127.0.0.1:8081 max_fail=10 fail_timeout=30s slow_start;
    server 127.0.0.1:8082 max_fail=10 fail_timeout=30s backup;
    server 127.0.0.1:8083 max_fail=10 fail_timeout=30s down;
}
proxy_pass http://myproject

分发参数

获取后端服务器监控信息

proxy_next_upstream指定什么样的response被认为是不成功的：

• error：与服务器建立连接，向服务器传递请求或读取响应头时发生错误
• timeout：与服务器建立连接，向服务器传递请求或读取响应header时发生超时

一些其他行为控制

tips：

• slow start在只有一个upstream的时候该参数忽略，同时该server也不会mark down
  max conn需要注意zone的配置，否则整体限制数量为worker数量乘该值
  如果server达到max conn，可以使用queue指令设定队列（nginx plus）

连接限制 limit_req

访问速率限制有助于防范ddos攻击以及业务秒杀活动的薅羊毛行为，nginx中可以应用 limit_rate实现，在nginx中使用leak bucket算法实现，需要配置

• key - 用于区分一个客户端与另一个客户的参数，通常时一个变量
• shared memory zone -保持这些ley状态的区域的名称和大小(“leak bucket”)
• rate - 以每秒请求数(r/s)或每分钟请求数(r/m)指定的请求速率限制。每分钟请求数用于指定小于每秒一个请求的速率

#example
http {
   #...
    limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
    server {
   #...
        location /search/ {
  
            limit_req zone=one;
        }
    }
}

超过速率的客户端请求nginx将响应503服务不可用错误，错误返回可以通过limit_req_staus指定

根据客户端ip地址分流

在使用nginx做负载均衡的过程中，可能会出现根据ip地址段进行分流的需求，某些网段客户端取服务器组a，某些网段取服务器组b，此时需要使用geo指令，该指令包含在：

• ngx_http_geo_module
• ngx_stream_geo_module
  上述两个模块，可以在http/tcp/udp协议负载均衡中根据ip地址进行分流。用法类似map、

#example
http {
  
    geo $remote $geo {
  
        default 0;
        10.128.4.214/32 1;
        10.128.4.217/32 2;
    }
    ......
    server {
  
        if ( $geo = 1 ) {
  
        return 200 "this is for 214";
        }
        if ( $geo =2 ) {
  
        return 200 "this is for 217";
        }
    }
}

多worker协同：zone

如果upstream不包含zone指令，则每个工作进程将保留其自己的服务器组配置副本，并维护其自己一组相关计数器。计数器包括与组中每个服务器的当前连接数以及将请求传递给服务器的尝试失败次数，zone对主动监控检查和api动态更新upstream时必须的。另外：

• max_fail
• max_conn
• least_conn
  在没有zone的情况下，都时per worker独立计数，在worker-1发现server-1 down，work-2并不会共享这个信息，而是可能继续发送request，同理，max_conn,least_conn也是per worker独立计数

访问控制/ip acl

基于ip访问控制

location / {
  
    satisfy any;
    allow 192.168.1.0/24;
    deny all;
}

基于报文头用户名密码的访问控制

location / {
  
    auth_basic "adminstrator's area"
    auth_basic_user_file conf/htpasswd;
}

使用apache2-utils(debian，ubuntu)或者httpd-tools(redhat/centos)对用户名密码进行加密

jwt认证

jwt(json web token)是openid connect标准中用于用户信息的数据格式，该标准是oauth 2.0协议之上的标准标识层。api和微服务的部署者也是因为其简单性和灵活性而转向jwt标准。通过jwt身份验证，客户端发送json web令牌到nginx，nginx根据本地密钥文件或远程服务来验证令牌

token包含三个部分：报文头，报文体，签名，签名所用的加密key存放在nginx上或者外部，nginx使用签名加密key验证token的合法性，并根据token报文体中的字段判断如何处理该请求。token明文部分包含本token使用的签名算法，签发token机构，使用本token的机构，超时时间等相关信息

jwt认证：本地key认证

server {
  
    listen 80;
    location /products/ {
  
        proxy_pass        http://api_server;
        auth_jwt          "api" token=$arg_apijwt;
        auth_jwt_key_file conf/key.jwt;
    }
}

• auth_jwt 指定的realm以及获取token的变量头
• auth_jwt_key_file 本地存放key的位置

jwt认证：外部key/cache

proxy_cache_path /cat/cache/nginx/jwk levels=1 keys_zone=jwk:1m max_size=10m;
server {
  
    location / {
  
        auth_jwt "site";
        auth_jwt_key_request /_jeks_uri;
        proxy_pass http://my_backend;
    }
    location = /_jwts_uri {
  
        internal;
        proxy_method get;
        proxy_cache   jwt;  # cache response
        proxy_pass     https://idp.example.com/oauth2/keys;
    }
}

从外部网址获取外部key并cahce，此时一般用非对称加密模式key，获取到的是签名token用的密钥对总的公key

subrequest纯外部认证

nginx和nginx plus可以使用外部服务器或服务验证对网站的每个请求。为了执行身份验证，nginx向外部服务器发出http子请求，如果子请求返回2xx响应代码，则允许访问，如果子请求返回401或者403，则拒绝访问。这种身份验证类型允许实现各种身份验证方案，例如多因子身份验证，或者允许实现ldap或oauth身份验证，在零信任模型下，该模式可以配置为所以应用的统一入口，后端服务器只允许nginx代理请求。不接受其他任何客户端直接请求。

example

• 每个请求包含一个ieauthrization报文头，包含预先申请的token
• nignx作为一个oauth2模型中的资源服务器代理，提取出token，向认证服务器发出token验证请求，请求中包含url和tokeni信息组合
• nginx对每个uri和token的认证结果进行cache，cache时间为5分钟，5分钟内同样的url token组合无需再次发起认证请求

配置细节

location / {
  
    auth_request /auth;
    auth_request_set $auth_status $upstream_status;
    proxy_pass http://myapp;
}
location /auth {
  
    internal;
    proxy_cache_key $http_zuthorization$request_uri;
    proxy_cache_vaild 401 403 2m;
    proxy_cache mycache;
    proxy_pass_request_budy off;
    proxy_set_header content-length "";
    proxy_set_header x-token $http_authorization;
    proxy_set_header x-original-uri $request_uri;
    proxy_pass       http://10.128.4.214/auth;

• 主请求和子请求变量透传
• 用token 实际访问uri做认证
• 认证结果做cache，cache时间由认证服务器控制，超过10分钟不访问会删除
• 负面认证结果cache2分钟