nginx 集群环境搭建

1 ) 概述

nginx 本身就应该选择性能强劲的机器同时为了满足更多流量的需求, 多台nginx 机器做集群来满足强大的需求故而，我们需要一个负载均衡器，以及多台nginx的机器

这里负载均衡器应该有主从和热备，目前先使用一台来描述 这里，我们先用docker来搭建单机版，后续可以选择用docker swarm 或 k8s 来部署到不同的机器上

2 ) 目录结构配置

<code>nginx-cluster-project

├── docker-compose.yml # yml 配置文件

├── balancer # 负载均衡器

│ ├── load-balancer.conf

│ ├── conf.d

│ │ ├── common.conf

│ │ ├── servers.conf

│ │ └── upstreams.conf

│ └── logs

│ ├── access.log

│ └── error.log

├── deploy # 单项nginx服务

│ ├── nginx.conf

│ ├── conf.d

│ │ ├── common

│ │ │ ├── common.conf

│ │ │ ├── gzip.conf

│ │ │ ├── header.cors.conf

│ │ │ ├── header.options.conf

│ │ │ ├── header.proxy.conf

│ │ │ └── log.conf

│ │ ├── servers

│ │ └── upstreams

│ ├── logs

│ │ ├── ng1

│ │ │ ├── error.log

│ │ │ ├── 80

│ │ │ │ ├── access.log

│ │ │ │ └── error.log

│ │ │ ├── 8500

│ │ │ │ ├── access.log

│ │ │ │ └── error.log

│ │ ├── ng2

│ │ │ ├── error.log

│ │ │ ├── 80

│ │ │ │ ├── access.log

│ │ │ │ └── error.log

│ │ │ ├── 8500

│ │ │ │ ├── access.log

│ │ │ │ └── error.log

│ │ └── ng3

│ │ │ ├── error.log

│ │ │ ├── 80

│ │ │ │ ├── access.log

│ │ │ │ └── error.log

│ │ │ ├── 8500

│ │ │ │ ├── access.log

│ │ │ │ └── error.log

│ └── static

│ └── default # 某一个项目的部署目录

├── ssl # 证书配置目录,（集中管理）

│ ├── certificate.crt

│ └── private.key;

从上面可以看到，docker-compose.yml 用于管理docker容器balancer 是负载均衡器服务(本质上也是一项nginx服务)

这里面的 load-balancer.conf 是用于监听和转发到其他nginx服务器上并且监听了所有服务的日志（访问日志和错误日志） deploy 是单项nginx服务的配置目录

从中可以看到, 配置文件是通用的，日志是分开管理的这里为 ng1, ng2, ng3 配置了不同的日志这里集群了多少台nginx服务器，就创建几份目录这里是现成的，也可以在docker-compose.yml中用命令创建 ssl 是用于集中管理证书的目录

关于 docker-compose.yml

version: '3'

services:

load-balancer:

image: nginx:latest

ports:

- "80:80"

- "8500:8500"

volumes:

- ./balancer/load-balancer.conf:/etc/nginx/nginx.conf:ro

- ./balancer/conf.d:/etc/nginx/conf.d:ro

- ./balancer/logs:/var/log/nginx

- ./ssl:/etc/nginx/ssl:ro

depends_on:

- ng-1

- ng-2

- ng-3

networks:

- light_network

ng-1:

image: nginx:latest

volumes:

- ./deploy/nginx.conf:/etc/nginx/nginx.conf

- ./deploy/conf.d:/etc/nginx/conf.d

- ./deploy/logs/ng1:/var/log/nginx

- ./deploy/static:/usr/share/nginx/html

- ./ssl:/etc/nginx/ssl

networks:

- light_network

ng-2:

image: nginx:latest

volumes:

- ./deploy/nginx.conf:/etc/nginx/nginx.conf

- ./deploy/conf.d:/etc/nginx/conf.d

- ./deploy/logs/ng2:/var/log/nginx

- ./deploy/static:/usr/share/nginx/html

- ./ssl:/etc/nginx/ssl

networks:

- light_network

ng-3:

image: nginx:latest

volumes:

- ./deploy/nginx.conf:/etc/nginx/nginx.conf

- ./deploy/conf.d:/etc/nginx/conf.d

- ./deploy/logs/ng3:/var/log/nginx

- ./deploy/static:/usr/share/nginx/html

- ./ssl:/etc/nginx/ssl

networks:

- light_network

networks:

light_network:

external: true

1 ）网络

这里看到，共用了一个 light_network 网络，而且是外部已存的网络所以，一开始的时候，就要创建它, 参考

https://blog.csdn.net/Tyro_java/article/details/134982223 其他服务要想使用nginx集群，就需要使用同样的网络或连通它

2 ）服务

这里定义了4个服务，分为 1个负载均衡器和3个nginx服务其实就是4个nginx服务，当然，如果需要更多nginx服务也可以继续进行创建在3个nginx服务中，都没有暴露端口，而端口是在负载均衡器中配置的在同一个docker网络中，docker容器都内都可以相互访问

3 ）其他

这里配置缺少了对 cpu, 内存，副本，重启等策略的定义这里为了保持集群的纯粹性，使用极简的配置，更多配置参考下面的链接

关于 deploy 中的服务

1 ）nginx.conf

user nginx;

worker_processes auto;

pid /var/run/nginx.pid;

events {

worker_connections 1024;

}

http {

include /etc/nginx/mime.types; # mime.types 配置

include /etc/nginx/conf.d/common/common.conf; # 通用 common 配置

include /etc/nginx/conf.d/common/gzip.conf; # 通用 gzip 配置

include /etc/nginx/conf.d/common/log.conf; # 通用 log 配置

include /etc/nginx/conf.d/upstreams/*.conf; # 包含 upstream 定义

include /etc/nginx/conf.d/servers/*.conf; # 包含 server 定义

}

这里可以看到，核心文件都拆分到了不同的目录和文件中这样的拆分设计，让后续复杂的业务更加容易管理

2 ) conf.d/upstreams/consul.conf

upstream backend_consul {

server consul-client1-1:8500 weight=1;

server consul-client2-1:8500 weight=1;

}

这里看到，consul-client1-1 是 consul 的服务名也就是在docker网络中，可以通过服务名来访问，而非动态的ip这里的意图，就是把2台consul客户端做一个负载均衡的处理一般设计consul集群的时候，会有2台客户端和3~5台服务端这里的consul的2台客户端，通过nginx的负载均衡处理，就保证高可用

3 ）conf.d/servers/*.conf

3.1 index_80.conf

server {

listen 80;

server_name _;

index index.html index.htm;

root /usr/share/nginx/html/default;

access_log /var/log/nginx/80/access.log main; # main 是 log 的格式

error_log /var/log/nginx/80/error.log notice; # notice 是 错误的级别 debug、info、notice、warn、error、crit、alert或emerg

include /etc/nginx/conf.d/common/header.cors.conf; # 包含 cors 的处理

include /etc/nginx/conf.d/common/header.proxy.conf; # 包含 proxy 的处理

# 定义 首页

location / {

try_files $uri $uri/ =404;

include /etc/nginx/conf.d/common/header.options.conf; # 包含 options 的处理

}

}

3.2 consul_8500.conf

server {

listen 8500;

server_name _;

access_log /var/log/nginx/8500/access.log main; # main 是 log 的格式

error_log /var/log/nginx/8500/error.log notice; # notice 是 错误的级别 debug、info、notice、warn、error、crit、alert或emerg

include /etc/nginx/conf.d/common/header.cors.conf; # 包含 cors 的处理

include /etc/nginx/conf.d/common/header.proxy.conf; # 包含 proxy 的处理

# 定义 首页

location / {

proxy_pass http://backend_consul$request_uri;

proxy_connect_timeout 1s; # 代理超时，请求一台超过1s就会转发到其他ip

include /etc/nginx/conf.d/common/header.options.conf; # 包含 options 的处理

}

}

… 其他可以继续配置

从这里可以看到，每个端口都可以自行配置管理

集群注意事项

在构建和管理NGINX集群时，有许多关键的注意事项，如下

1 ） 集群规模与业务需求：

根据业务需求和系统负载情况，合理配置集群中服务器的数量过多的服务器可能导致资源浪费，而过少的服务器则可能无法应对高并发请求在评估集群规模时，需要考虑业务的增长趋势和未来的扩展需求。

2 ）负载均衡策略

选择合适的负载均衡策略对于集群的性能至关重要常见的策略包括轮询、最少连接数、IP哈希等根据业务场景的特点（如请求的分布、服务器的性能等）来选择合适的策略，以确保请求能够均匀、高效地分发到各个服务器上

3 ）网络带宽与延迟

确保集群中服务器之间的网络带宽足够，以保证请求分发的效率网络带宽不足可能导致请求处理速度下降，影响用户体验同时，要注意降低网络延迟，确保请求能够快速到达目标服务器并得到响应

4 ）服务器的硬件与配置

服务器的硬件配置对于集群的性能有着重要影响需要确保服务器具有足够的CPU、内存和存储空间来应对高并发请求同时，合理配置NGINX的参数（如worker_processes、worker_connections等）也是提升集群性能的关键

5 ）安全性考虑

NGINX集群作为网络服务的核心组件，其安全性至关重要需要采取一系列安全措施来防范潜在的安全威胁，如使用HTTPS协议、限制访问权限、定期更新和修补安全漏洞等

6 ）日志与监控

启用并配置好NGINX的日志功能，以便收集和分析集群的运行状态通过查看访问日志和错误日志，可以及时发现和解决潜在的问题同时，建立有效的监控机制，对集群的性能指标进行实时监控和报警，确保集群的稳定运行

7 ）高可用性设计

在构建NGINX集群时，需要考虑高可用性设计例如，可以采用主从配置或热备方案来确保服务的连续性和可用性还需要制定故障转移和恢复策略，以便在服务器出现故障时能够迅速恢复服务

8 ）维护与升级

定期对NGINX集群进行维护和升级是必要的这包括更新软件版本、清理日志文件、优化配置参数等在进行升级或维护操作时，需要确保操作的安全性和稳定性，避免对集群的正常运行造成影响综上所述，构建和管理NGINX集群需要考虑多个方面的因素只有在充分考虑并处理好这些注意事项的基础上，才能确保集群的稳定性和性能达到最佳状态

关于 多台负载均衡器

之前提到的集群配置中，如果仅有一台负载均衡器而没有相应的备份或冗余机制那么当这台负载均衡器出现故障时，整个集群将会受到影响，这并不能算作真正的高可用设计要实现高可用性的负载均衡，我们需要考虑以下几点：

1 ）负载均衡器的冗余设计：

部署多台负载均衡器，并通过某种机制（如VRRP、Keepalived等）实现它们之间的主备切换或负载均衡。这样，当主负载均衡器出现故障时，备用负载均衡器可以迅速接管工作，确保服务的连续性。

2 ）健康检查与故障转移

负载均衡器需要能够定期检查后端服务器的健康状态，一旦发现服务器出现故障或响应缓慢，应将其从负载均衡池中移除，并将请求转发到其他健康的服务器上。同时，负载均衡器之间也需要进行健康检查，以确保主备切换的顺利进行。

3 ）数据同步与一致性

如果负载均衡器涉及到会话保持或数据缓存等功能，需要确保在主备切换或负载均衡过程中，数据的同步和一致性得到保障，避免因为数据不一致导致的问题。

4 ）网络设计与隔离：

在网络层面，需要考虑负载均衡器与后端服务器之间的网络隔离和冗余设计例如，可以使用多个网络交换机或路由器来确保网络的稳定性和可靠性。

5 ）监控与报警：

建立完善的监控和报警机制，对负载均衡器和后端服务器的运行状态进行实时监控。一旦出现故障或异常情况，应能够及时发出报警通知，以便管理员迅速介入处理。

6 ）综上所述

要实现真正的高可用负载均衡设计，我们需要从多个方面进行考虑和规划确保在任何情况下都能保持服务的连续性和稳定性这不仅仅涉及到负载均衡器本身的设计，还需要考虑到整个集群的架构和配置

说明

我们目前搭建的是一套极简的nginx集群，这里可以参考以上注意事项来对集群进行优化和扩展关于多机器部署，可以使用docker swarm 或 k8s 等进行多机器部署关于 docker swarm 部署服务参考

https://blog.csdn.net/Tyro_java/article/details/135002423https://blog.csdn.net/Tyro_java/article/details/135004351https://blog.csdn.net/Tyro_java/article/details/135023723

源码地址

https://github.com/cluster-deploy/cluster-nginx