NGINX配置基于Node.js服务的负载均衡服务器

本部署指南说明了如何使用NGINX开源和NGINX Plus在Node.js应用程序服务器池之间平衡HTTP和HTTPS通信。本指南中的详细说明适用于Node.js的基于云的部署和本地部署。

  • 关于NGINX和NGINX Plus
  • 关于Node.js
  • 先决条件和系统要求
  • 为客户端流量配置SSL / TLS证书
  • 创建和修改配置文件
  • 使用NGINX或NGINX Plus配置基本负载平衡
    • 为HTTP和HTTPS流量配置虚拟服务器
    • 配置基本负载平衡
    • 配置基本会话持久性
    • 配置WebSocket流量的负载平衡
    • 配置内容缓存
    • 配置HTTP / 2支持
    • 基本负载平衡的完整配置
  • 使用NGINX Plus配置增强的负载平衡
    • 配置高级会话持久性
    • 配置应用程序运行状况检查
    • 启用实时活动监控
    • 启用上游组的动态重新配置
    • 完整配置以增强负载平衡
  • 资源资源

关于NGINX开源和NGINX Plus

NGINX开源是一种开源Web服务器和反向代理,由于其可伸缩性,出色的性能和较小的占用空间,近年来已越来越受欢迎。NGINX开源最初创建是为了解决C10K问题(在一台Web服务器上同时服务10,000个连接)。NGINX开源软件的功能和性能使其成为高性能网站的重要组成部分-它是全球100,000个最繁忙的网站中排名第一的Web服务器。

NGINX Plus是NGINX开源的商业支持版本。NGINX Plus是一个完整的应用程序交付平台,它通过一系列企业就绪功能扩展了NGINX Open Source的功能,这些功能可增强Node.js部署并有助于大规模构建Web应用程序:

  • 功能齐全的HTTP,TCP和UDP负载平衡
  • 智能会话持久性
  • 高性能反向代理
  • 缓存和卸载动态和静态内容
  • 自适应流传输,可将音频和视频传输到任何设备
  • 应用感知健康检查和高可用性
  • 可通过仪表板或API进行高级活动监控
  • 使用DevOps友好的工具进行管理和实时配置更改

关于Node.js

Node.js是基于V8 JavaScript引擎构建的JavaScript运行时。Node.js使用事件驱动的非阻塞I / O模型,从而使其轻巧高效。Node.js的软件包生态系统npm是世界上最大的开源库生态系统。

要下载Node.js软件并获取安装说明,请访问Node.js网站。

本部署指南中的信息同样适用于开源Node.js软件和商业支持的Node.js框架。

先决条件和系统要求

  • 在物理或虚拟系统上安装和配置的Node.js应用程序服务器。
  • 托管NGINX开源或NGINX Plus的Linux系统。为了避免与其他应用程序发生潜在冲突,我们建议您在全新的物理或虚拟系统上安装NGINX Plus。有关NGINX Plus支持的Linux发行版列表,请参见NGINX Plus技术规范。
  • 物理或虚拟系统上安装的NGINX Open Source或NGINX Plus。某些功能仅在NGINX Plus上可用,包括复杂的会话持久性,应用程序运行状况检查,实时活动监视以及对上游组的动态重新配置。有关这两种产品的安装说明,请参见《NGINX Plus管理指南》。

这些说明假定您具有基本的Linux系统管理技能,包括以下内容。没有为这些任务提供完整的说明。

  • 配置和部署Node.js应用程序
  • 从供应商提供的软件包安装Linux软件
  • 编辑配置文件
  • 在中央管理系统和Linux服务器之间复制文件
  • 运行基本命令以启动和停止服务
  • 读取日志文件

关于样本值和文本复制

  • example.com用作示例域名(在键名和配置块中)。将其替换为您的组织名称。
  • 本指南中的许多NGINX开源和NGINX Plus配置块列出了两个IP地址为192.168.33.11和192.168.33.12的示例Node.js应用服务器。将这些地址替换为Node.js服务器的IP地址。如果您有两个以上,则在每个服务器的配置块中包含一行。
  • 出于可读性原因,某些命令显示在多行上。如果要将它们复制并粘贴到终端窗口中,建议您首先将它们复制到文本编辑器中,在其中可以替换适合于部署的对象名称,并删除浏览器可能插入的任何多余的格式字符。
  • 我们建议您不要将本指南中的配置片段中的文本复制到配置文件中。有关创建配置文件的推荐方法,请参阅《创建和修改配置文件》。

为客户端流量配置SSL / TLS证书

如果计划启用NGINX Open Source或NGINX Plus与Node.js应用程序的客户端之间的通信的SSL / TLS加密,则需要为NGINX Open Source或NGINX Plus配置服务器证书。

  • 默认情况下,NGINX提供的所有NGINX Plus软件包和NGINX Open Source二进制文件均启用SSL / TLS支持。
  • 如果要从源代码编译NGINX开源程序,请包含--with-http_ssl_module参数以启用对HTTP流量的SSL / TLS支持(TCP / UDP的对应参数为--with-stream_ssl_module,电子邮件的对应参数为--with-;mail_ssl_module,但本指南不涵盖那些协议类型)。
  • 如果使用来自其他提供程序的二进制文件,请查阅提供程序文档以确定它们是否支持SSL / TLS。

有几种获取服务器证书的方法,包括以下几种。为了您的方便,第二和第三选项提供了分步说明。

  • 如果您已经在另一个UNIX或Linux系统(包括运行Apache HTTP Server的系统)上安装了NGINX Open Source或NGINX Plus的SSL证书,请将其复制到NGINX Open Source或NGINX Plus服务器上的/ etc / nginx / ssl目录中。 。
  • 如下面的生成自签名证书中所述,生成自签名证书。这足以测试场景,但是生产部署的客户端通常需要由证书颁发机构(CA)签名的证书。
  • 向CA或您组织的安全组请求新证书,如下面的生成证书请求中所述。

有关SSL / TLS终止的更多详细信息,请参见《NGINX Plus管理指南》。

生成自签名证书

生成公私钥对和基于它们的PEM格式的自签名服务器证书。

  1. 以root用户身份登录到已openssl安装软件的计算机上。

  2. 生成PEM格式的密钥对(默认)。要加密私钥,请包含-des3参数。(其他可用的加密算法可用,在genrsa命令的手册页上列出。)提示您输入用作加密基础的口令。

    root# openssl genrsa -des3 -out ~/private-key.pem 2048
    Generating RSA private key ...
    Enter pass phrase for private-key.pem:

  3. 在安全位置创建密钥文件的备份。如果丢失密钥,则证书将无法使用。

    root# cp ~/private-key.pem secure-dir/private-key.pem.backup

  4. 生成证书。包括-new-x509参数以创建新的自签名证书。(可选)包括-days参数,以将密钥的有效期从默认的30天(10950天约为30年)更改为默认值。使用适合您的测试部署的值来响应提示。

    root# openssl req -new -x509 -key ~/private-key.pem -out ~/self-cert.pem \-days 10950

  5. 将证书文件和关联的密钥文件复制或移动到NGINX Open Source或NGINX Plus服务器上的/ etc / nginx / ssl目录。

生成证书申请

  1. 以root用户身份登录到已openssl安装软件的计算机上。

  2. 创建要打包在证书中的私钥。

    root# openssl genrsa -out ~/example.com.key 2048

  3. 在安全位置创建密钥文件的备份。如果丢失密钥,则证书将无法使用。

    root# cp ~/example.com.key <SECURE-DIR>/example.com.key.backup

  4. 创建一个证书签名请求(CSR)文件。

    root# openssl req -new -sha256 -key ~/example.com.key -out ~/example.com.csr

  5. 向CA或您的内部安全组请求证书,并提供CSR文件(example.com.csr)。提醒一下,切勿直接与第三方共享私钥(.key文件)。

    证书必须是PEM格式,而不是Windows兼容的PFX格式。如果您是自己从CA网站请求证书的,请在系统提示您选择要为其生成证书的服务器平台时,选择NGINX或Apache(如果可用)。

  6. 将证书文件和关联的密钥文件复制或移动到NGINX Plus服务器上的/ etc / nginx / ssl目录。

创建和修改配置文件

为了减少错误,本指南让您将NGINX提供的文件中的指令复制到配置文件中,而不是使用文本编辑器自己键入指令。然后,您将遍历本指南中的各节(从配置虚拟服务器以进行HTTP和HTTPS流量入手)以了解如何根据部署要求修改指令。

如所提供的,有一个文件用于基本负载平衡(使用NGINX Open Source或NGINX Plus)和一个文件用于增强负载平衡(使用NGINX Plus)。如果要在新的Linux系统上安装和配置NGINX开源或NGINX Plus,并且仅使用它来负载均衡Node.js流量,则可以使用提供的文件作为主要配置文件,按照惯例,该文件称为/ etc / nginx /nginx.conf

但是,我们建议您使用一个在安装NGINX Plus软件包时自动设置的方案,而不是单个配置文件,尤其是如果您已经具有现有的NGINX Open Source或NGINX Plus部署或计划扩大对以下文件的使用时NGINX开源或NGINX Plus将来会用于其他目的。在传统方案中,主配置文件仍称为/etc/nginx/nginx.conf,但是您没有在其中包含所有指令,而是为不同的功能创建了单独的配置文件,并将文件存储在/ etc / nginx / conf中。 .d目录。然后,您可以在include主文件的适当上下文中使用指令,以读取特定于功能的文件的内容。

如果您刚刚安装了NGINX开源或NGINX Plus,则在/etc/nginx/conf.d目录中有一个默认配置文件default.conf。定义的配置不适用于本指南中描述的部署,但是您希望在目录中保留该名称的文件,以便下次升级NGINX Open Source或NGINX Plus时不会将其替换为新版本。要保存副本以供将来参考,您可以将其复制为不带.conf扩展名的新名称。

要下载完整的配置文件以进行基本的负载平衡:

root# cd /etc/nginx/conf.d
root# curl https://www.nginx.com/resource/conf/nodejs-basic.conf > nodejs-basic.conf

要下载完整的配置文件以增强负载平衡:

root# cd /etc/nginx/conf.d
root# curl https://www.nginx.com/resource/conf/nodejs-enhanced.conf > nodejs-enhanced.conf

(您也可以在浏览器中访问URL,然后将文本复制到指定的文件中。)

注意:如果您下载两个文件,则仅将它们之一放在/etc/nginx/conf.d目录中。

要设置常规配置方案,请http在主nginx.conf文件中添加一个配置块(如果尚不存在)。(标准放置在所有全局指令下方。)将此include指令添加适当的文件名:

http {include conf.d/nodejs-(basic|enhanced).conf;
}

指令文档: include

您还可以使用通配符表示法在适当的上下文块中引用与某种功能或流量类型有关的所有文件。例如,如果您将所有HTTP配置文件的功能都命名为-http.conf,那么这是一个适当的include指令:

http {include conf.d/*-http.conf;
}

作为参考,本文档中还提供了完整的配置文件:

  • 基本负载平衡的完整配置
  • 完整配置以增强负载平衡

但是,我们建议您不要直接从此文档中复制文本。它不一定使用与文本编辑器相同的机制来定位文本(例如,换行符和空白)。在复制到编辑器中的文本中,行可能会同时运行,并且配置块中的子语句缩进可能会丢失或不一致。对于NGINX开源或NGINX Plus而言,没有格式设置不会出现问题,因为(像许多编译器一样)它们在解析期间会忽略空格,仅依靠分号和花括号作为定界符。但是,缺少空格的确使人更难以解释和修改配置而不会犯错误。

关于重新加载更新的配置

我们建议您每次完成对配置的一组更新时,都运行命令以测试配置文件的语法有效性。nginx -t

root# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

要告诉NGINX Open Source或NGINX Plus开始使用新配置,请运行以下命令之一:

root# nginx -s reload

或者

root# service nginx reload

使用NGINX开源或NGINX Plus配置基本负载平衡

本节说明如何在两台Node.js服务器之前将NGINX开源或NGINX Plus设置为负载平衡器。前两节中的说明是强制性的:

  • 为HTTP和HTTPS流量配置虚拟服务器
  • 配置基本负载平衡

其余部分中的说明是可选的,具体取决于应用程序的要求:

  • 配置基本会话持久性
  • 配置WebSocket流量的负载平衡
  • 配置内容缓存
  • 配置HTTP / 2支持

完整的配置文件显示在“基本负载平衡的完整配置”中。

如果您使用的是NGINX Plus,则可以在完成基本负载平衡的配置后配置其他增强功能。请参阅使用NGINX Plus配置增强的负载平衡。

为HTTP和HTTPS流量配置虚拟服务器

这些指令server在顶级http配置块中的单独块中定义用于HTTP和HTTPS通信的虚拟服务器。所有HTTP请求都重定向到HTTPS服务器。

  1. 配置一个server块,侦听在端口443上收到的https://example.com请求。

    ssl_certificatessl_certificate_key指令是必需的; 替换在为客户端流量配置SSL / TLS证书中选择的证书和私钥的名称。

    其他指令是可选的,但建议使用。

    # In the 'http' block
    server {listen 443 ssl;server_name example.com;ssl_certificate           /etc/nginx/ssl/<certificate-name>;ssl_certificate_key       /etc/nginx/ssl/<private-key>;ssl_session_cache         shared:SSL:1m;ssl_prefer_server_ciphers on;}

    指令文件:listenserverserver_namessl_certificatessl_certificate_keyssl_prefer_server_ciphersssl_session_cache

  2. 配置一个server块,该块将在端口80上收到的对http://example.com的请求永久重定向到HTTPS服务器,这在下一步中进行了定义。

    如果您不使用SSL / TLS进行客户端连接,请忽略该location块。当在本指南的其余部分中指示server为HTTPS通信量的块添加指令时,请将其添加到该块中。

    # In the 'http' block
    server {listen 80;server_name example.com;proxy_http_version 1.1;proxy_set_header Host $host;proxy_set_header Connection "";# Redirect all HTTP requests to HTTPSlocation / {return 301 https://$server_name$request_uri;}
    }   

    指令文件:locationproxy_http_versionproxy_set_headerreturn

有关配置SSL / TLS的更多信息,请参阅NGINX Plus管理指南和HTTP SSL / TLS模块的参考文档。

配置基本负载平衡

要配置负载平衡,首先要创建一个名为“上游组”的文件,其中列出了后端服务器。然后,通过在一个或多个proxy_pass指令中引用上游组,将NGINX开源或NGINX Plus设置为反向代理和负载平衡器。

  1. 使用两个在端口8080上侦听的Node.js应用程序服务器配置一个名为nodejs的上游组,一个在IP地址192.168.33.11上,另一个在192.168.33.12上侦听。

    # In the 'http' block
    upstream nodejs {server 192.168.33.11:8080;server 192.168.33.12:8080;
    }

    指令文件:serverupstream

  2. server我们为HTTP和HTTPS配置虚拟服务器中创建的HTTPS通信location块中,包括两个块:

    • 第一个匹配HTTPS请求,其中路径以/ webapp /开头,并将它们代理到我们在上一步中创建的nodejs上游组。
    • 第二个location通过对http://example.com/的所有请求进行临时重定向将所有流量集中到第一个块。
    # In the 'server' block for HTTPS traffic
    location /webapp/ {proxy_pass http://nodejs;
    }location = / {return 302 /webapp/;
    }

    指令文件:locationproxy_passreturn

    请注意,这些块仅处理标准HTTPS流量。如果要负载均衡WebSocket通信,则需要添加另一个location块,如配置WebSocket通信的代理中所述。

默认情况下,NGINX Open Source和NGINX Plus使用Round Robin算法在服务器之间进行负载平衡。负载平衡器按顺序遍历上游组中的服务器列表,将每个新请求转发到下一台服务器。在我们的示例中,第一个请求发送到192.168.33.11,第二个请求发送到192.168.33.12,第三个请求发送到192.168.33.11,依此类推。有关其他可用负载平衡算法的信息,请参见《NGINX Plus管理指南》。

在NGINX Plus中,您还可以使用域名系统(DNS)或API在后端服务器集发生更改时设置上游组的动态重新配置。请参阅启用上游组的动态重新配置。

有关代理和负载平衡的更多信息,请参阅《 NGINX Plus管理指南》中的NGINX反向代理和HTTP负载平衡,以及HTTP 代理和上游模块的参考文档。

配置基本会话持久性

如果您的应用程序需要基本的会话持久性(也称为粘性会话),则可以使用IP哈希负载平衡算法在NGINX开源中实现它。(如配置高级会话持久性中所述,NGINX Plus提供了一种更为复杂的会话持久性形式。)

使用IP哈希算法,NGINX为每个请求基于客户端的IP地址计算哈希,并将该哈希与上游服务器之一相关联。它将带有该哈希值的所有请求发送到该服务器,从而建立会话持久性。

如果客户端具有IPv6地址,则哈希基于整个地址。如果它具有IPv4地址,则哈希仅基于地址的前三个八位位组。旨在针对从子网(/ 24)范围动态分配IP地址的ISP客户端进行优化。但是,在以下情况下无效:

  • 到您站点的大部分流量来自一个转发代理或来自同一/ 24网络上的客户端,因为在这种情况下,IP哈希将所有客户端映射到同一服务器。
  • 客户端的IP地址可以在会话期间更改,例如,当移动客户端从WiFi网络切换到蜂窝网络时。

要在NGINX中配置会话持久性,请将ip_hash指令添加到upstream在配置基本负载平衡中创建的块中:

# In the 'http' block
upstream nodejs {ip_hash;server 192.168.33.11:8080;server 192.168.33.12:8080;
}

指令文档: ip_hash

您还可以使用哈希负载平衡方法来保持会话持久性,其中哈希基于指定的文本和NGINX变量的任意组合。例如,您可以使用以下配置在完整(四字节)的客户端IP地址上进行哈希处理。

# In the 'http' block
upstream nodejs {hash $remote_addr;server 192.168.33.11:8080;server 192.168.33.12:8080;
}

指令文档: hash

配置WebSocket流量的负载平衡

WebSocket协议(在RFC 6455中定义)允许在客户端和服务器之间的单个TCP连接上同时进行双向通信,双方可以独立发送数据。为了启动WebSocket连接,客户端向服务器发送一个握手请求,将请求从标准HTTP升级到WebSocket。如果握手请求通过验证,并且服务器接受请求,则建立连接。创建WebSocket连接后,浏览器客户端可以将数据发送到服务器,同时从该服务器接收数据。

Node.js应用服务器开箱即用地支持WebSocket,因此不需要其他Node.js配置。如果要使用NGINX开源或NGINX Plus将WebSocket通信代理到Node.js应用程序服务器,请添加本节中讨论的指令。

默认情况下,NGINX Open Source和NGINX Plus使用HTTP / 1.0进行上游连接。为了正确地代理,WebSocket连接需要HTTP / 1.1以及一些其他设置HTTP标头的配置指令:

# In the 'http' block
map $http_upgrade $connection_upgrade {default upgrade;''      close;
}# In the 'server' block for HTTPS traffic
location /wstunnel/ {proxy_pass http://nodejs;proxy_http_version 1.1;proxy_set_header Upgrade $http_upgrade;proxy_set_header Connection $connection_upgrade;
}

指令文件:locationmapproxy_http_versionproxy_passproxy_set_header

proxy_set_header需要第一个指令,因为Upgrade请求标头是逐跳的;也就是说,HTTP规范明确禁止代理转发它。该指令将覆盖禁止。

第二个proxy_set_header指令将Connection标头设置为取决于map块中测试的值:如果请求具有Upgrade标头,则Connection标头设置为upgrade; 否则,将其设置为close

有关代理WebSocket通信的更多信息,请参见WebSocket代理和NGINX作为WebSocket代理。

配置内容缓存

从Node.js应用服务器缓存响应不仅可以缩短对客户端的响应时间,而且可以减少服务器上的负载,因为合格的响应会立即从缓存中提供,而不是在服务器上再次生成。有许多有用的指令可用于微调缓存行为。有关详细讨论,请参见《使用NGINX进行缓存的指南》。

要启用来自Node.js应用服务器的响应的基本缓存,请添加以下配置:

  1. 包括该proxy_cache_path指令以创建本地磁盘目录/ tmp / NGINX_cache /用作缓存。该keys_zone参数为称为backcache的区域分配10 MB的共享内存,该区域用于存储缓存密钥和元数据(例如使用计时器)。1 MB的区域可以存储大约8,000个密钥的数据。

    # In the 'http' block
    proxy_cache_path /tmp/NGINX_cache/ keys_zone=backcache:10m;

    指令文档: proxy_cache_path

  2. location与HTTPS请求匹配的块中(路径以/ webapp /开头),包括proxy_cache用于引用上一步中创建的缓存的指令。

    # In the 'server' block for HTTPS traffic
    location /webapp/ {proxy_pass http://nodejs;proxy_cache backcache;
    }

    指令文件:proxy_cacheproxy_pass

有关缓存的更多完整信息,请参阅《NGINX Plus管理指南》和HTTP 代理模块的参考文档。

配置HTTP / 2支持

NGINX 1.9.5和更高版本以及NGINX Plus R7和更高版本完全支持HTTP / 2。与往常一样,我们建议您运行最新版本的软件以利用改进和错误修复。

  • 如果使用NGINX开放源代码,请注意,在1.9.5版和更高版本中,SPDY模块已从代码库中完全删除,并被HTTP / 2模块取代。升级到1.9.5或更高版本后,您将无法再将NGINX开源配置为使用SPDY。如果要继续使用SPDY,则需要从NGINX 1.8.x分支中的源代码编译NGINX Open Source 。

  • 如果使用NGINX Plus,则在R11和更高版本中,nginx-plus软件包默认情况下支持HTTP / 2,而先前版本中可用的nginx-plus-extras软件包已由NGINX创作的单独的动态模块弃用。

    在NGINX Plus R8到R10中,nginx-plusnginx-plus-extras软件包默认支持HTTP / 2。

    在NGINX Plus R8和更高版本中,NGINX Plus默认情况下支持HTTP / 2,并且不支持SPDY。

    如果使用NGINX Plus R7,则必须安装nginx-plus-http2软件包而不是nginx-plusnginx-plus-extras软件包。

要启用HTTP / 2支持,请将http2参数添加到我们在“ 为HTTP和HTTPS通信配置虚拟服务器”中创建的HTTPS通信块中的listen伪指令中,如下所示:server

# In the 'server' block for HTTPS traffic
listen 443 ssl http2;

指令文档: listen

要验证HTTP / 2转换是否正常,您可以使用适用于Google Chrome和Firefox的“ HTTP / 2和SPDY指示器”插件。

基本负载平衡的完整配置

为方便起见,此处显示了基本负载平衡的完整配置。它取决于http上下文。完整文件可从NGINX网站下载。

我们建议您不要直接从本文档中复制文本,而应使用“ 创建和修改配置文件”中描述的方法在配置中包括这些指令–将include指令添加到httpnginx.conf文件的上下文中以在/etc/nginx/conf.d/nodejs-basic.conf的内容。

proxy_cache_path /tmp/NGINX_cache/ keys_zone=backcache:10m;map $http_upgrade $connection_upgrade {  default upgrade;  ' '     close;
}upstream nodejs {  # Use IP Hash for session persistence  ip_hash;# List of Node.js application servers  server 192.168.33.11:8080;  server 192.168.33.12:8080;
}server {  listen 80;  server_name example.com;# Redirect all HTTP requests to HTTPS  location / {  return 301 https://$server_name$request_uri;  }
}server {  listen 443 ssl http2;  server_name example.com;ssl_certificate           /etc/nginx/ssl/certificate-name;  ssl_certificate_key       /etc/nginx/ssl/private-key;  ssl_session_cache         shared:SSL:1m;  ssl_prefer_server_ciphers on;# Return a temporary redirect to '/webapp/' when user requests '/'  location = / {  return 302 /webapp/;  }# Load balance requests for '/webapp/' across Node.js app servers location /webapp/ {  proxy_pass http://nodejs;  proxy_cache backcache;  }# WebSocket configuration  location /wstunnel/ { proxy_pass https://nodejs;  proxy_http_version 1.1;  proxy_set_header Upgrade $http_upgrade;  proxy_set_header Connection $connection_upgrade;  }
}

使用NGINX Plus配置增强的负载平衡

本节说明如何使用NGINX Plus中的某些扩展功能配置增强的负载平衡。

注意:在设置本节中描述的增强功能之前,必须完成以下两个部分中有关基本负载平衡的说明:

  • 为HTTP和HTTPS流量配置虚拟服务器
  • 配置基本负载平衡

除非另有说明,否则所有可选的基本功能(在配置NGINX开源和NGINX Plus的基本负载平衡的其他小节中都有介绍)可以与此处描述的增强功能结合使用。

  • 配置高级会话持久性
  • 配置应用程序运行状况检查
  • 启用实时活动监控
  • 启用上游组的动态重新配置

完整的配置文件显示在“增强负载平衡的完整配置”中。

配置高级会话持久性

NGINX Plus具有比开源NGINX更复杂的会话持久性方法,该方法在sticky指令的三个变体中实现。在以下示例中,我们将该指令添加到在“ 配置基本负载平衡”中创建的上游组中。sticky cookie

  1. 删除或注释掉ip_hash指令,仅保留server指令:

    # In the 'http' block
    upstream nodejs {#ip_hash;server 192.168.33.11:8080;server 192.168.33.12:8080;
    }

    指令文件:serverupstream

  2. 配置使用指令的会话持久性。sticky cookie

    # In the 'http' block
    upstream nodejs {zone nodejs 64k;server 192.168.33.11:8080;server 192.168.33.12:8080;sticky cookie srv_id expires=1h domain=.example.com path=/;
    }

    指令文件:,sticky cookiezone

通过这种方法,NGINX Plus将HTTP会话cookie添加到来自上游组的给定客户端的第一个响应中,从而确定哪个服务器生成了响应(以编码方式)。来自客户端的后续请求包括cookie值,NGINX Plus使用该值将请求路由到同一上游服务器,从而实现会话持久性。

zone指令创建一个共享内存区域,用于存储有关会话的信息。分配的内存量(这里为64 KB)决定了一次可以存储多少个会话(该数量因平台而异)。在nodejs 每个sticky指令中,分配给区域的名称(在这里)必须是唯一的。

在示例中,的第一个参数设置要设置或检查的cookie的名称。该参数告诉浏览器时cookie的有效期,在这里一个小时。该参数定义域和参数定义了该cookie被设置URL路径。sticky cookiesrv_idexpiresdomainpath

有关会话持久性的更多信息,请参见《NGINX Plus管理指南》。

配置应用程序运行状况健康检查

健康检查是按固定间隔发送到服务器的带外HTTP请求。它们用于确定服务器是否响应正常且功能正常,而无需客户端的实际请求。

由于health_check伪指令放置在location块中,因此我们可以为每个应用程序启用不同的运行状况检查。

  1. location与HTTPS请求匹配的块中,该路径的路径以/ webapp /开头(在配置基本负载平衡中创建),添加health_check指令。

    在这里,我们将NGINX Plus配置为每5秒(默认URI和频率)向nodejs上游组中的每台服务器发送对顶级URI /(斜杠)的带外请求。如果服务器没有正确响应,它将被标记为Down并且NGINX Plus将停止向其发送请求,直到通过后续的运行状况检查为止。我们包含该参数,因此我们可以定义一组非默认的运行状况检查测试(在下一步中定义它们)。match

    # In the 'server' block for HTTPS traffic
    location /webapp/ {proxy_pass http://nodejs;proxy_cache backcache;health_check match=health_check;
    }

    指令文档: health_check

  2. http上下文中,请包含一个match指令,以定义服务器必须通过的测试才能被视为正常运行。在此示例中,它必须返回状态码200Content-Type响应标头必须包含text/html,并且响应正文必须与指示的字符串匹配。

    # In the 'http' block
    match health_check {status 200;header Content-Type ~ text/html;body ~ "Hello world";
    }

    指令文档: match

  3. nodejs上游组中,zone根据需要添加以下指令(如果已配置高级会话持久性,则已经添加了它)。它创建一个共享内存区域,该区域存储组的配置和运行时状态,所有工作进程均可访问。

    # In the 'http' block
    upstream nodejs {zone nodejs 64k;server 192.168.33.11:8080;server 192.168.33.12:8080;# ...
    }

    指令文档: zone

NGINX Plus还具有启动缓慢的功能,该功能对于健康检查非常有用。当故障服务器恢复正常或将新服务器添加到上游组时,NGINX Plus会在定义的时间内缓慢增加流量。这使服务器有时间进行“热身”,而不会被启动时无法处理的更多连接所淹没。有关更多信息,请参见《NGINX Plus管理指南》。

例如,要为Node.js应用程序服务器设置30秒的缓慢启动时间,请将slow_start参数包含在它们的server指令中:

# In the 'upstream' block
server 192.168.33.11:8080 slow_start=30s;
server 192.168.33.12:8080 slow_start=30s;

参数文档: slow_start

有关自定义健康检查的信息,请参见《NGINX Plus管理指南》。

启用实时活动监控

NGINX Plus包含一个实时活动监视界面,可实时提供关键的负载和性能指标,包括NGINX Plus R6及更高版本中的TCP指标。通过RESTful JSON接口报告统计信息,从而非常容易将数据提供给自定义或第三方监视工具。还有一个内置仪表板。请按照以下说明进行部署。

有关实时活动监控的更多信息,请参见《NGINX Plus管理指南》。

配置模块和内置NGINX Plus仪表板的最快方法是从NGINX网站下载示例配置文件,并根据需要进行修改。有关更完整的说明,请参阅3个简单步骤中的NGINX Plus实时活动监视。

  1. status.conf文件下载到NGINX Plus服务器:

    # cd /etc/nginx/conf.d
    # curl https://www.nginx.com/resource/conf/status.conf > status.conf

  2. 根据文件中的注释为您的部署自定义文件。特别是,文件中的默认设置允许任何网络上的任何人访问仪表板。强烈建议您使用以下一种或多种方法限制对仪表板的访问:

    • 基于IP地址的访问控制列表(ACL)。在样本配置文件中,取消对allowdeny指令的注释,并用10.0.0.0/8替换管理网络的地址。只有指定网络上的用户才能访问状态页面。

      allow 10.0.0.0/8;
      deny all;

      指令文档:allowdeny

    • HTTP基本身份验证。在样本配置文件中,取消对auth_basicauth_basic_user_file指令的注释,并将用户条目添加到/ etc / nginx / users文件中(例如,通过使用htpasswdgenerator)。如果安装了Apache,则另一个选择是重用现有的htpasswd文件。

      auth_basic on;
      auth_basic_user_file /etc/nginx/users;

      指令文件:auth_basicauth_basic_user_file

    • 客户端证书,它是SSL / TLS完整配置的一部分。有关更多信息,请参阅NGINX Plus管理指南和HTTP SSL / TLS模块的文档。

    • 防火墙。将防火墙配置为禁止外部访问仪表板端口(样本配置文件中为8080)。

  3. nodejs上游组中,zone根据需要包括指令(如果您配置了高级会话持久性或应用程序运行状况检查,则已经添加了它)。它创建一个共享内存区域,该区域存储组的配置和运行时状态,所有工作进程均可访问。

    # In the 'http' block
    upstream nodejs {zone nodejs 64k;server 192.168.33.11:8080;server 192.168.33.12:8080;# ...
    }

    指令文档: zone

  4. server用于HTTPS流量的块(在为HTTP和HTTPS流量配置虚拟服务器中创建)中,添加status_zone伪指令:

    # In the 'server' block for HTTPS traffic
    status_zone nodejs_server;

    指令文档: status_zone

当您重新加载NGINX Plus配置文件时(例如通过运行命令),可以在http:// nginx-plus-server-address:8080上立即使用NGINX Plus仪表板。nginx -s reload

启用上游组的动态重新配置

使用NGINX Plus,您可以使用DNS或NGINX Plus R13中引入的NGINX Plus API动态地重新配置负载均衡的服务器组(HTTP和TCP / UDP)。有关DNS和API方法的详细讨论,请参见NGINX Plus管理指南。

配置API方法

要使用NGINX Plus API对上游的Node.js应用服务器组进行动态重新配置,您需要授予对其的安全访问权限。您可以使用API来添加或删除服务器,动态地改变它们的权重,并设置其地位primarybackupdown

  1. zone指令包括在nodejs上游组中,以创建一个共享内存区域来存储组的配置和运行时状态,从而使该信息可用于所有工作进程。(如果您配置了高级会话持久性,应用程序运行状况检查或实时活动监视,则已经进行了此更改。)

    # In the 'http' block
    upstream nodejs {zone nodejs 64k;server 192.168.33.11:8080;server 192.168.33.12:8080;# ...
    }

    指令文档: zone

  2. server用于HTTPS流量的块(在为HTTP和HTTPS流量配置虚拟服务器中创建)中,location为NGINX Plus API 添加一个新块,该块可实现其他功能的动态重新配置。它包含api指令(api也是该位置的常规名称,如此处所用)。

    (如果通过下载status.conf文件配置了实时活动监视,则它已经包含此块。)

    强烈建议您限制对该位置的访问,以便只有授权的管理员才能访问NGINX Plus API。以下示例中的allowdeny指令仅允许从本地主机地址(127.0.0.1)访问。

    # In the 'server' block for HTTPS traffic
    location /api {api write=on;allow 127.0.0.1;deny all;
    }

    指令文件:allowdenyapi

配置DNS方法

http块中,加resolver指令指向你的DNS服务器,然后添加resolve参数将server在指令中的NodeJS upstream块,指示NGINX Plus来进行周期性的重新解析域名(example.com这里)与DNS:

# In the 'http' block
resolver <IP-address-of-DNS-server>;upstream nodejs {zone nodejs 64k;server example.com resolve;
}

指令和参数文档:resolveresolver

NGINX Plus版本9和更高版本也可以使用DNS SRV记录中的其他信息,例如端口号。将service参数serverresolve参数一起包括在指令中:

# In the 'http' block
resolver <IP-address-of-DNS-server>;upstream nodejs {zone nodejs 64k;server example.com service=http resolve;
}

参数文档: service

完整配置以增强负载平衡

为方便起见,此处显示用于增强负载平衡的完整配置。它取决于http上下文。完整文件可从NGINX网站下载。

我们建议您不要直接从本文档中复制文本,而应使用“ 创建和修改配置文件”中描述的方法在配置中包括这些指令–即,将include指令添加到httpnginx.conf文件的上下文中以进行读取在/etc/nginx/conf.d/nodejs-enhanced.conf的内容中。

注意:所述的api在该结构中总结块和所述可下载 的NodeJS-enhanced.conf文件是API方法动态重新配置的。如果要改用DNS方法,请对该块进行适当的更改。(在这种情况下,您也可以删除或注释掉NGINX Plus API的指令,但是它们与使用DNS方法不冲突,并启用动态重新配置以外的功能。)

proxy_cache_path /tmp/NGINX_cache/ keys_zone=backcache:10m;map $http_upgrade $connection_upgrade {  default upgrade;  ''      close;
}match nodejs_check {  status 200;  header Content-Type ~ "text/html";  body ~ "Hello world";
}upstream nodejs { # Health-monitored upstream groups must have a zone defined  zone nodejs 64k;# List of Node.js application servers  server 192.168.33.11:8080 slow_start=30s;  server 192.168.33.12:8080 slow_start=30s;# Session persistence using sticky cookie  sticky cookie srv_id expires=1h domain=.example.com path=/;
}server {  listen 80;  server_name example.com;# Redirect all HTTP requests to HTTPS  location / {  return 301 https://$server_name$request_uri;  }
}server {  listen 443 ssl http2;  server_name example.com;# Required for NGINX Plus to provide extended status information  status_zone nodejs;ssl_certificate            /etc/nginx/ssl/certificate-name;  ssl_certificate_key        /etc/nginx/ssl/private-key;  ssl_session_cache          shared:SSL:1m;  ssl_prefer_server_ciphers  on;# Return a 302 redirect to '/webapp/' when user requests '/'  location = / {  return 302 /webapp/;  }# Load balance requests for '/webapp/' across Node.js app servers  location /webapp/ {  proxy_pass http://nodejs;  proxy_cache backcache;# Set up active health checks  health_check match=nodejs_check;  }# WebSocket configuration  location /wstunnel/ {  proxy_pass https://nodejs;  proxy_http_version 1.1;  proxy_set_header Upgrade $http_upgrade;  proxy_set_header Connection $connection_upgrade; }# Secured access to the NGINX Plus API  location /api {  api write=on;allow 127.0.0.1; # Permit access from localhost  deny all;        # Deny access from everywhere else  }
}

资源资源

  • NGINX Plus概述
  • NGINX Plus管理指南
  • NGINX维基

N | Solid的开发者NodeSource为该部署指南做出了贡献。

修订记录

  • 版本3(2018年4月)–有关NGINX Plus API的更新信息(NGINX Plus R13,NGINX开源1.13.4)
  • 版本2(2017年5月)–关于HTTP / 2支持的更新(NGINX Plus R11和更高版本)
  • 版本1(2016年12月)–初始版本(NGINX Plus R11,NGINX 1.11.5)

翻译来源:https://docs.nginx.com/nginx/deployment-guides/load-balance-third-party/node-js/

NGINX配置基于Node.js服务的负载均衡服务器相关推荐

  1. Fenix – 基于 Node.js 的桌面静态 Web 服务器

    Fenix 是一个提供给开发人员使用的简单的桌面静态 Web 服务器,基于 Node.js 开发.您可以同时在上面运行任意数量的项目,特别适合前端开发人员使用. 您可以通过免费的 Node.js 控制 ...

  2. fastcgi php 集群 分离,使用nginx配置多个php fastcgi负载均衡--梦飞翔的地方(梦翔天空)...

    配置还是非常简单的,充分体现了nginx的强大与配置的简单,下面是大致的服务器结构图: 应用的最前端是一台nginx服务器,所有静态的内容都由nginx来处理,而将所有php的请求都分摊到下游的若干台 ...

  3. 记录linux下nginx配置html缓存,js,css等不缓存(服务器上的*.html和js,css,jpg等在同一级目录下)

    问题描述: 在linux下的nginx配置拦截html,并设置不缓存,js,css,jpg,png等静态资源缓存30天; 备注: 我们服务器上的*.html和js,css,jpg等在同一级目录下 解决 ...

  4. 基于 Egg.js 框架的 Node.js 服务构建之用户管理设计

    转载需经本人同意且标注本文原始地址:https://zhaomenghuan.github.io/blog/nodejs-eggjs-usersytem.html 前言 近来公司需要构建一套 EMM( ...

  5. Pomelo:网易开源基于 Node.js 的游戏服务端框架

    Pomelo 是基于 Node.js 的高性能.分布式游戏服务器框架.它包括基础的开发框架和相关的扩展组件(库和工具包),可以帮助你省去游戏开发枯燥中的重复劳动和底层逻辑的开发.Pomelo 不但适用 ...

  6. 基于 Node.js + Koa 构建完整的 Web API (配置 ESLint 和使用 Airbnb 编码规范)

    主题内容:基于 Node.js + Koa 构建完整的 Web API (配置 ESLint 和使用 Airbnb 代码规范) 背景描述:上一篇 基于 Node.js + Koa 构建完整的 Web ...

  7. 基于 Egg.js 框架的 Node.js 服务构建之用户管理设计 1

    前言 近来公司需要构建一套 EMM(Enterprise Mobility Management)的管理平台,就这种面向企业的应用管理本身需要考虑的需求是十分复杂的,技术层面管理端和服务端构建是架构核 ...

  8. rds基于什么开发_为什么不学基于TypeScript的Node.js服务端开发?

    为什么不学?学不动了吗?!别躺下啊,我扶你起来! 我们早就知道,如今的JavaScript已经不再是当初那个在浏览器网页中写写简单的表单验证.没事弹个alert框吓吓人的龙套角色了.借助基于v8引擎的 ...

  9. node ajax crud,基于node.js和rethinkdb的CRUD(增删改查)Web服务

    基于node.js和rethinkdb的CRUD(增删改查)Web服务 这是一个简单的REST web服务演示案例源码,使用Node.JS和Express 和RethinkDB,后者持久化JSON数据 ...

最新文章

  1. AI一分钟|美团确认收购摩拜;特斯拉今年第一季度产量创历史新高
  2. 易语言模拟键盘(ctrl+v)_键盘快捷键使用大全
  3. oracle数据库集群日志,Oracle集群数据库中恢复归档日志
  4. ajax多选下拉,模拟select下拉框之多选(数据源采用模拟Ajax数据--原创)(示例代码)...
  5. 华为nova 9系列曝光:全系标配骁龙778G 4G处理器
  6. 5G手机将不用流量可免费看电视,网友:流量免费,内容付费?
  7. mysql日志输出到syslog_在chroot环境下将MySQL日志输出到syslog
  8. Vue.js 入门案例
  9. Java如何获取文件编码格式
  10. 笨方法学Python笔记(5)
  11. 数学建模——蒙特卡罗模型
  12. r5驱动 索尼exmor_SONY的驱动安装顺序(还不知道的赶快进来看看!!)
  13. 正则验证手机号码和邮箱格式
  14. Win10安装Ubuntu20.04双系统
  15. 如何判断Activity是否在前台显示
  16. Emscripten 单词_学会词根词缀,开启高效、快速地记忆英语单词模式
  17. Norms for Vectors and Matrices
  18. android蓝牙设备类型设置 dev class设置
  19. [置顶]Ceph源码解析:PG peering
  20. 蓝桥杯-打印菱形/字符串截断

热门文章

  1. SQLServer2000同步复制技术实现步骤作者
  2. iphone简单实例 (字体,弹出窗口) (实例)
  3. Objective-C 2.0 with Cocoa Foundation --- 2,从Hello,World!开始
  4. php模板技术 实例
  5. 优化 WordPress 后台设置教程
  6. c#.net——c#.net异步实现网页信息爬取
  7. SpringBoot——项目启动时读取配置及初始化资源
  8. 【C++面向对象】类的数据成员:绑定、布局和存取
  9. 音量已经调到100%,如何再调整
  10. ArrayList 相关总结