nginx 集群环境搭建
1 ) 概述
- nginx 本身就应该选择性能强劲的机器
- 同时为了满足更多流量的需求, 多台nginx 机器做集群来满足强大的需求
- 故而，我们需要一个负载均衡器，以及多台nginx的机器
- 这里负载均衡器应该有主从和热备，目前先使用一台来描述
- 这里，我们先用docker来搭建单机版，后续可以选择用docker swarm 或 k8s 来部署到不同的机器上
2 ) 目录结构配置
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 网络，而且是外部已存的网络
- 所以，一开始的时候，就要创建它, 参考
- 其他服务要想使用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 部署服务参考
