苏州信用卡wd1234信用卡(苏州银行信用卡)

币圈行情阅读 3 2023-08-24 02:01:12

Bitget下载

注册下载Bitget下载，邀请好友，即有机会赢取 3,000 USDT

Nginx是异步框架的网页服务器，也可以用作反向代理、负载平衡器和HTTP缓存。该软件由伊戈尔·赛索耶夫创建并于2004年首次公开发布。2011年成立同名公司以提供支持。2019年3月11日，Nginx公司被F5 Networks以6.7亿美元收购。

Nginx有以下的特点

由C编写，占用的资源和内存低，性能高。
单进程多线程，当启动nginx服务器，会生成一个master进程，master进程会fork出多个worker进程，由worker线程处理客户端的请求。
支持反向代理，支持7层负载均衡（拓展负载均衡的好处）。
高并发，nginx是异步非阻塞型处理请求，采用的epollandqueue模式
处理静态文件速度快
高度模块化，配置简单。社区活跃，各种高性能模块出品迅速。

主要配置模块

NGINX单元使用三种主要类型的配置对象。所有都是用JSON定义的。应用程序Application对象定义单元正在运行的应用程序的特征，例如语言，过程控件以及文件系统上的位置。侦听器Listener对象定义单元配置，该配置将传入的请求通过已定义的IP地址和端口定向到指定的应用程序。路由对象Router提供路由功能。路由功能包括路由到Unit应用程序，提供静态文件，代理到外部服务以及服务器池上的负载平衡。本章将建立对这些对象的基础理解。

应用程序 Application

{  "applications": {    "my-app": {       "type": "php",        "processes": 2,        "root": "/var/www/app/",         "index": "index.php",         "user": "app_user",        "group": "app_group"     }  } }

部署在NGINX单元上的每个应用程序都由一个应用程序对象定义。用JSON定义的应用程序对象指定了应用程序的属性。每种应用程序类型都有其自己的必需和可选属性。许多不同的应用程序属性控制着单位流程的管理和限制。 type属性是所有应用程序中共有的唯一必需的流程管理属性。它定义了应用程序语言，例如PHP，Python，Golang，Ruby或Perl。其他属性包括应用程序进程数限制；时间限制；用户，组和环境变量；和工作目录。

监听器 Listener

{  "listeners": {    "*:8080": {      "pass": "applications/my-app"    }  }}

为了指示NGINX单元监听传入的请求，必须定义一个监听器对象。侦听器对象定义单元将传入请求定向到的应用程序。侦听器对象是指定给定义IP和端口的键的值。在此示例中，*用于IP地址，因此指示单元监听分配给服务器的所有IP地址。侦听器对象具有两个属性：pass和tls（可选）。 pass属性采用一个字符串值，该值指定将请求定向到的应用程序，应用程序目标，路由或上游。该示例将请求直接发送到名为my-app的应用程序。

路由 Routes

{  "listeners": {    "*:8080": {      "pass": "routes"    }   }, "routes": [     {      "match": {        "host": "blog.example.com"      },       "action": {        "pass": "applications/blog"       }    },     {      "action": {        "pass": "applications/my-app"      }     }  ] }

路由具有两个属性：match和action。这两个属性都有其自己的对象类型，这些对象类型具有许多可配置的属性。

Match支持不同的选项：arguments, cookies, destination, headers, host, method, scheme, source, 和 uri。

Action支持pass, share, fallback, proxy, return, 和 location等。

代理 Proxy

{  "listeners": {    "*:8080": {      "pass": "routes"    }   },  "routes": [     {      "match": {        "uri": "/wiki/*"      },       "action": {        "proxy": "http://172.17.0.1:80" }    },     {      "action": {       "pass": "applications/my-app"     }     }  ] }

代理操作类型会将请求中继到外部HTTP服务。此操作的功能是基本反向代理的功能。可以使用Unix，IPv4和IPv6套接字地址作为目标。该功能将适合许多用例。要获得更多高级功能，可以使用NGINX反向代理和负载平衡器服务器。

静态文件

{  "listeners": {    "*:8080": {      "pass": "routes"    }   },  "routes": [     {      "action": {        "share": "/var/www/static/",         "fallback": {          "share": "/var/app/static"         }      }     }  ] }

share操作类型将提供本地目录中的静态内容。它可以与fallback操作结合使用，该fallback操作将告诉Unit如果找不到所请求的文件或Unit权限不足以访问该文件，则如何指示该请求。fallback操作可以将请求路由到pass，proxy或share操作。当回退将请求定向到另一个share操作时，可以嵌套fallback操作。

上游服务 Upstreams

{  "listeners": {    "*:8080": {      "pass": "upstreams/pool-0"    }   },  "upstreams": {     "pool-0": {      "servers": {         "10.0.0.2:8080": { },         "10.0.1.2:8080": {          "weight": 2.0         }      }     }  } }

单元配置的上游upstreams属性定义了许多命名的上游upstreams对象。每个上游upstreams对象都定义一个服务器servers对象。服务器servers对象使用键来定义目标，并使用该值来指定可选的权重。上游upstreams使用加权循环负载均衡算法。权重最大值为1000000，最小值为0（此类服务器未收到任何请求），默认值为1。

目标 Targets

{   "listeners":{      "*:8080":{         "pass":"routes"      }   },   "routes":[      {         "match":{            "host":"admin.example.com"         },         "action":{            "pass":"applications/my-app/admin"         }      },      {         "action":{            "pass":"applications/my-app/website"         }      }   ],   "applications":{      "my-app":{         "type":"php",         "targets":{            "admin":{               "index":"admin.php",               "root":"/var/www/admin"            },            "website":{               "script":"index.php",               "root":"/var/www/"            }         }      }   }}

路由Routes和应用程序Applications配置的结合。应用程序配置具有一个目标targets属性，该属性定义了应用程序上下文的另一层。 PHP应用程序必须具有在应用程序级别或目标级别定义的root和script或index属性。在该示例中，管理目标targets的根目录与网站目标的根目录不同。 admin目标还允许调用目录结构中的所有PHP文件，其中admin.php为索引。网站目标包含管理根目录；但是，它仅允许调用index.php脚本。一个应用程序最多可以配置254个目标。只需将目标名称附加到应用程序名称空间，即可路由到目标。

了解了主要对象配置后，下面我们就看看Nginx提供的一些主要的功能和相应的配置对象。

负载均衡

当今的互联网用户体验都要求性能和正常运行时间。为此，运行同一系统的多个副本，并将负载分布在它们上。随着负载的增加，可以使系统的另一个副本联机。这种架构技术称为水平缩放。基于软件的基础架构因其灵活性而越来越受欢迎，从而开辟了无限的可能性。无论哪种用例，都需要一种与基础架构一样动态的负载平衡解决方案。 NGINX通过HTTP，TCP和UDP负载平衡方式满足了这一需求。

HTTP 模式

upstream backend { server 10.10.12.45:80 weight=1;   server app.example.com:80 weight=2;} server {  location / {    proxy_pass http://backend;  } }

TCP模式

stream { upstream mysql_read {    server read1.example.com:3306 weight=5;    server read2.example.com:3306;     server 10.10.12.34:3306 backup;  }  server {    listen 3306;    proxy_pass mysql_read;   }}

UDP 模式

stream {  upstream ntp {    server ntp1.example.com:123 weight=2;    server ntp2.example.com:123;   }  server {    listen 123 udp;    proxy_pass ntp;   }}

负载均衡方法

Round robin 基于权重，按统计顺序分配流量
Least connections 把流量分配到连接最少的上游服务上去
Generic hash 通过管理员定义的基于文本，变量的哈希值来分配流量，常用于服务和请求内容匹配的场景
Random 基于权重，随机分配流量
IP hash，仅对HTTP生效，使用IP地址的前三个字节生成哈希值，并相应地分配流量

被动健康检查

upstream backend { server backend1.example.com:1234 max_fails=3 fail_timeout=3s;   server backend2.example.com:1234 max_fails=3 fail_timeout=3s;}

利用健康检查，确保流量只会路由到健康的服务上去

慢启动

upstream {  zone backend 64k;  server server1.example.com slow_start=20s;  server server2.example.com slow_start=15s; }

慢启动给服务时间热身，在上述的例子中，服务1会等待20秒接受新的请求，已给出足够的时间来初始化，准备缓存等。

TCP健康检查

stream {  server {    listen 3306;    proxy_pass read_backend;    health_check interval=10 passes=2 fails=3;  } }

在上述的例子中，如果上游服务器无法响应NGINX发起的三个或更多TCP连接，则将被视为不正常。 NGINX每10秒执行一次检查。仅在通过两次运行状况检查后，服务器才被视为运行状况良好。

流量管理

NGINX也被归类为Web流量控制器。可以使用NGINX根据许多属性智能的路由流量和控制流。NGINX能够基于百分比拆分客户端请求，利用客户端的地理位置以及以速率，连接和带宽限制的形式控制流量的能力。

A/B测试

upstream backend { server 10.10.12.45:80 weight=1;   server app.example.com:80 weight=2;} server {  location / {    proxy_pass http://backend;  } }

当测试电子商务网站上转换率的不同类型的营销和前端功能时，这种类型的A / B测试很有用。应用程序通常使用一种称为canary release的部署类型。在这种类型的部署中，流量会缓慢切换到新版本。在推出新版本的代码时，在不同版本的应用程序之间拆分客户端可能很有用，以限制发生错误时的爆炸半径。无论在两个不同的应用程序集之间拆分客户端的原因是什么，NGINX都通过使用split_clients模块使此操作变得简单。

限制连接数目

http {  limit_conn_zone $binary_remote_addr zone=limitbyaddr:10m;   limit_conn_status 429;  ...  server {    ...    limit_conn limitbyaddr 40;    ...  } }

上述配置限制到Server的连接数为40，返回429错误。

限制速率

http {  limit_req_zone $binary_remote_addr     zone=limitbyaddr:10m rate=1r/s;   limit_req_status 429;  ...  server {    ...    limit_req zone=limitbyaddr burst=10 nodelay;    ...  } }

限速模块功能强大，可防止滥用快速请求，同时仍为所有人提供优质服务。限制请求速率的原因有很多，其中之一就是安全性。您可以通过在登录页面上设置非常严格的限制来拒绝暴力攻击。您可以对所有请求设置合理的限制，从而禁用可能试图拒绝为您的应用程序提供服务或浪费资源的恶意用户的计划。

限制带宽

location /download/ {   limit_rate_after 10m;   limit_rate 1m;}

通过限制特定连接的带宽，NGINX可以以指定的方式在所有客户端之间共享其上传带宽。这两个指令可以完成所有操作：limit_rate_after和limit_rate。 limit_rate指令默认指定给定上下文的速率限制，以每秒字节数为单位。但是，可以为兆字节指定m或为千兆字节指定g。两个指令的默认值均为0。值0表示完全不限制下载速率。此模块允许以编程方式更改客户端的速率限制。

大规模内容缓存

缓存通过存储将来要再次提供的请求响应来加速内容服务。内容缓存减少了上游服务器的负载，缓存了完整的响应，而不需要运行计算并再次查询同一请求。缓存可提高性能并减少负载，这意味着可以用更少的资源更快地服务。在战略位置扩展和分发缓存服务器可能会对用户体验产生巨大影响。最好将内容托管在消费者附近，以获得最佳性能。可以将内容缓存在用户附近。这就是内容交付网络或CDN的模式。借助NGINX，可以在可以放置NGINX服务器的任何地方缓存内容，从而有效地创建自己的CDN。借助NGINX缓存，还可以在上游发生故障时被动缓存并提供缓存的响应。

缓存区域

proxy_cache_path /var/nginx/cache  keys_zone=CACHE:60m  levels=1:2  inactive=3h   max_size=20g;proxy_cache CACHE;

使用proxy_cache_path定义缓存区域和响应的路径。

缓存忽略

proxy_cache_bypass $http_cache_bypass;

如果HTTP请求标头cache_bypass设置为任何非0的值，该配置将告诉NGINX绕过缓存。

缓存性能

location ~* \.(css|js)$ {  expires 1y;  add_header Cache-Control "public";}

此location块指定客户端可以缓存CSS和JavaScript文件的内容。 expires指令指示客户端一年后其缓存资源将不再有效。 add_header指令将HTTP响应标头Cache-Control添加到响应中，其值为public，这允许沿途的任何缓存服务器缓存资源。如果我们指定专用，则仅允许客户端缓存该值。

缓存性能有很多因素，磁盘速度最为重要。 NGINX配置中可以执行许多操作来帮助提高缓存性能。一种选择是以这样一种方式设置响应的标题，即客户端实际上缓存了响应，根本不向NGINX发出请求，而只是从其自己的缓存中提供服务

认证

NGINX能够验证客户端。使用NGINX对客户端请求进行身份验证可减轻工作量，并能够阻止未经批准的请求到达应用服务器。 NGINX开源可用的模块包括基本身份验证和子请求身份验证。

基本认证

生成一个密码文件，如下例：

# comment    name1:password1    name2:password2:comment    name3:password3

使用openssl对该文件加密

$ openssl passwd MyPassword1234

使用auth_basic和auth_basic_user_file来配置认证

location / {  auth_basic "Private site";   auth_basic_user_file conf.d/passwd;}

和第三方认证服务集成

location /private/ {  auth_request /auth;  auth_request_set $auth_status $upstream_status;}location = /auth { internal; proxy_pass http://auth-server;    proxy_pass_request_body off;  proxy_set_header Content-Length "";   proxy_set_header X-Original-URI $request_uri;}

安全控制

安全性是分层完成的，安全模型必须有多层才能真正得到加强。NGINX提供不同的功能来支持安全能力。

基于IP地址的安全控制

location /admin/ {   deny 10.0.0.1;  allow 10.0.0.0/20;   allow 2001:0db8::/32;   deny all;}

allow和deny指令在HTTP，Server和Location上下文中有效。顺序检查规则，直到找到与远程地址匹配的为止。

跨域资源共享

map $request_method $cors_method {   OPTIONS 11;  GET 1;  POST 1;  default 0; }server {   ...  location / {    if ($cors_method ~ '1') {      add_header 'Access-Control-Allow-Methods'         'GET,POST,OPTIONS';      add_header 'Access-Control-Allow-Origin'         '*.example.com';      add_header 'Access-Control-Allow-Headers'         'DNT,        Keep-Alive,         User-Agent,         X-Requested-With,         If-Modified-Since,        Cache-Control,         Content-Type';    }    if ($cors_method = '11') {      add_header 'Access-Control-Max-Age' 1728000;       add_header 'Content-Type' 'text/plain; charset=UTF-8';       add_header 'Content-Length' 0;      return 204;    }  }}

此示例通过使用map将GET和POST方法分组在一起进行了精简。 OPTIONS请求方法向客户端返回有关此服务器的CORS规则的预检请求。 CORS允许使用OPTIONS，GET和POST方法。设置Access-Control-Allow-Origin标头可以使从该服务器提供的内容也可以在与该标头匹配的原始页面上使用。预检请求可以在客户端上缓存1,728,000秒或20天。

当诸如JavaScript之类的资源所请求的资源不是其自己的域时，它会构成跨域访问CORS。当请求被视为跨源请求时，浏览器必须遵守CORS规则。如果浏览器没有专门允许其使用的标头，则它将不使用该资源。为了使我们的资源可以被其他子域使用，我们必须设置CORS标头，这可以通过add_header指令完成。如果请求是具有标准内容类型的GET，HEAD或POST，并且该请求没有特殊的标头，则浏览器将发出请求，并且仅检查源。其他请求方法将使浏览器发出前请求，以检查该资源将服从的服务器条款。如果没有适当地设置这些标头，则浏览器在尝试利用该资源时将给出错误消息。

客户端加密

http {   # All directives used below are also valid in stream server {    listen 8433 ssl;    ssl_protocols TLSv1.2 TLSv1.3;    ssl_ciphers HIGH:!aNULL:!MD5;    ssl_certificate /etc/nginx/ssl/example.pem;     ssl_certificate_key /etc/nginx/ssl/example.key;     ssl_certificate /etc/nginx/ssl/example.ecdsa.crt;     ssl_certificate_key /etc/nginx/ssl/example.ecdsa.key;     ssl_session_cache shared:SSL:10m;     ssl_session_timeout 10m;  } }

该例子配置SSL来加密http服务。

控制特定资源的访问

location /resources {  secure_link_secret mySecret;  if ($secure_link = "") {     return 403;   }  rewrite ^ /secured/$secure_link; }location /secured/ {  internal;  root /var/www;}

此配置创建一个内部且面向公众的位置块。面向公众的位置块/ resources将返回403 Forbidden，除非请求URI包含一个md5哈希字符串，可以使用提供给secure_link_secret指令的密码进行验证。除非已验证URI中的哈希，否则$ secure_link变量为空字符串。

用Secret保护资源是确保文件受到保护的好方法。该Secret与URI结合使用。然后，此字符串将被md5散列，并且该md5散列的十六进制摘要在URI中使用。哈希将放入链接中，并由NGINX评估。 NGINX知道哈希之后的URI中所请求文件的路径。 NGINX还通过secure_link_secret指令提供了Secret信息。 NGINX能够快速验证md5哈希并将URI存储在$ secure_link变量中。如果无法验证哈希，则将变量设置为空字符串。请务必注意，传递给secure_link_secret的参数必须是静态字符串；它不能是变量。

通过过期时间控制资源

location /resources {  root /var/www;  secure_link $arg_md5,$arg_expires;  secure_link_md5 "$secure_link_expires$uri$remote_addr mySecret";  if ($secure_link = "") { return 403; }  if ($secure_link = "0") { return 410; } }

secure_link指令采用两个参数，并以逗号分隔。第一个参数是保存md5哈希值的变量。本示例使用HTTP参数md5。第二个参数是一个变量，它以Unix纪元时间格式保存链接到期的时间。 secure_link_md5指令采用单个参数，该参数声明用于构造md5哈希值的字符串的格式。与其他配置一样，如果哈希未通过验证，则$secure_link变量将设置为空字符串。但是，在这种用法下，如果哈希匹配但时间已到期，则$secure_link变量将设置为0。

HTTP重定向

server {  listen 80 default_server;  listen [::]:80 default_server; server_name _;  return 301 https://$host$request_uri;}

此配置在端口80上监听IPv4和IPv6以及任何主机名的默认服务器。 return语句将301永久重定向返回到同一主机上的HTTPS服务器并请求URI。

务必始终在适当的时候重定向到HTTPS。可能会发现不需要重定向所有请求，而仅重定向那些在客户端和服务器之间传递敏感信息的请求。在这种情况下，可能只想将return语句放在特定的位置，例如/ login。

HTTP/2

HTTP / 2是对HTTP协议的主要修订。这个版本中完成的许多工作都集中在传输层，例如在单个TCP连接上启用完整的请求和响应多路复用。通过对HTTP头字段进行压缩获得了效率，并增加了对请求优先级的支持。该协议的另一个重要补充是服务器能够将消息推送到客户端。

基本配置

server {  listen 443 ssl http2 default_server;  ssl_certificate server.crt;   ssl_certificate_key server.key;  ...}

要打开HTTP / 2，只需要将http2参数添加到listen指令中

gRPC

server {  listen 80 http2;  location / {    grpc_pass grpc://backend.local:50051;  } }

NGINX能够接收，代理，负载均衡，路由和终止gRPC调用。使用gRPC模块，NGINX可以设置，更改或删除gRPC调用标头，设置请求超时以及设置上游SSL / TLS规范。当gRPC通过HTTP / 2协议进行通信时，可以将NGINX配置为在同一端点上接受gRPC和非gRPC Web通信。

HTTP/2服务端推送

server {  listen 443 ssl http2 default_server;    ssl_certificate server.crt;   ssl_certificate_key server.key;   root /usr/share/nginx/html;    location = /demo.html {    http2_push /style.css;    http2_push /image1.jpg; }}

要使用HTTP / 2服务器推送，必须配置为HTTP / 2配置服务器。可以指示NGINX使用http2_push指令推送特定文件。该指令采用一个参数，即要推送到客户端的文件的完整URI路径。

容器和微服务

容器在应用程序层提供了一个抽象层，从而将软件包的安装和相关性从部署转移到了构建过程。这很重要，因为工程师可以以统一方式运行和部署的代码单元，而不管环境如何。将容器提升为可运行单元可减少依赖环境和环境之间的配置麻烦的风险。鉴于此，组织将其应用程序部署在容器平台上方面有很大的动力。在容器平台上运行应用程序时，通常要对尽可能多的堆栈进行容器化，包括代理或负载平衡器。 NGINX可以轻松地进行容器化和部署。它们还包括许多使交付容器化应用程序的功能。

官方镜像

$ docker run --name my-nginx -p 80:80 \  -v /path/to/content:/usr/share/nginx/html:ro -d nginx

NGINX已通过Docker Hub提供了正式的Docker镜像。这个官方的Docker镜像可以使用自己喜欢的应用程序交付平台NGINX轻松地在Docker中快速启动和运行。能够使用一个命令在容器中启动NGINX并运行它！这些官方镜像的Dockerfile和源可在GitHub上获得。以通过构建自己的Dockerfile并在FROM命令中指定官方镜像来扩展官方镜像。

创建自己的Docker镜像

通过以下的Dockerfile可以创建自己的Nginx镜像。

FROM centos:7    # Install epel repo to get nginx and install nginxRUN yum -y install epel-release && \ yum -y install nginx    # add local configuration files into the imageADD /nginx-conf /etc/nginxEXPOSE 80 443CMD ["nginx"]

├── Dockerfile └── nginx-conf  ├── conf.d │ └── default.conf  ├── fastcgi.conf ├── fastcgi_params  ├── koi-utf ├── koi-win ├── mime.types  ├── nginx.conf  ├── scgi_params  ├── uwsgi_params  └── win-utf

使用环境变量

daemon off; env APP_DNS;include /usr/share/nginx/modules/*.conf; ...http { perl_set $upstream_app 'sub { return $ENV{"APP_DNS"}; }';   server {  ...   location / {    proxy_pass https://$upstream_app;   }  }}

要使用perl_set，必须安装ngx_http_perl_module。可以通过动态或静态（从源代码构建）加载模块来实现。默认情况下，NGINX从其环境中删除所有的环境变量；需要使用env指令声明不想删除的任何变量。 perl_set指令采用两个参数：要设置的变量名称和呈现结果的perl字符串。

Kubernetes Ingress Controller

Kubernetes是容器编排和管理的领先平台。入口控制器Ingress Controller是将流量路由到应用程序其余部分的边缘容器。 NGINX非常适合担任此角色，并使其易于配置。 NGINX-Ingress项目通过DockerHub映像提供了NGINX开放源代码入口控制器。使用NGINX入口控制器启用Kubernetes集群可提供NGINX的所有相同功能，但具有Kubernetes网络和DNS的附加功能来路由流量。

Nginx作为常见的Web服务被广泛地用于部署应用服务，了解和用好Nginx是软件架构师的必修课。