前言
Nginx 是一个非常轻量级的服务器,他虽轻但是他最大的优点就是可以承载大量的并发,所以说一般的话很少有用 Node 直接去做服务器让用户去访问的,因为 Node 本身就需要做非 常非常多的事情,虽然说简单的可以使用 Node 直接开启,但是对于负载和并发 Node 是弱项,就是反向代理和并发是 Node 整个的弱项,所以我们需要在前面用 Nginx 挡一层,这样的话对于我们整个的系统的运维架构来讲也是一个非常得力的一个助手,还有就是跟其他的比如说我们后层整个架构的设计属于运维的这一块,它也是有一种先天优势的这样的服务器
Nginx概述:「链接」
主要结构
什么是反向代理与负载均衡 反向代理 负载均衡
Nginx 负载均衡的实现
HTTP UPstream 模块 什么是 HTTP Upstream 模块 ip_hash 指令 -- 落到哪个上 server 指令 -- server 的权重 UPstream 指令
其他负载均衡的方法 对于我们前端而言只需要将负载子我们的项目里面配置好就可以了不需要去太深入的学习,只要给人家运维一眼一口,然后知道怎么配合就完了,因为对于运维来讲,他们是不太懂 Node 的什么什么东西的,他们只会配这个 Nginx 的,所以说我们学这个的话只要学的够用就 ok 了
1. 什么是反向代理与负载均衡
反向代理
举例说明:
比如说平时我们上谷歌上不了然后需要,谷歌是我们明确的去要访问的站点,这个时候我们会用一些的工具(代理服务器),这个代理服务器帮我们取回谷歌给我们看,这个就是一个正向的代理
那么反向 代理刚好是相反的:我们不知道去取哪一台机器,然后代理帮我们去取,然后把取到的内容返回给我们
一个是明确的知道,一个是不知道,这就是正向代理和反向代理
上图解释
就是用自己的计算机 A 想访问国外的网站 B ,访问不了,就有一个中间的服务器 C 它去访问国外的网站 B ,其实如果是把这个 C 装到我们自己的电脑上,我们自己的电脑访问 C ,然后 C 再去访问 B ,这个时候这个 C 就叫代理服务器,这个时候就是正向代理,他有一个特点,就是我们一定知道要访问哪个网站
还有就是当我们有一个服务器集群,而且服务器集群中的每台服务器的内容都是一样的时候,同样我们从个人的电脑访问到比如说 现在我们有四台 Node 的机器 ,但是我们无法访问,这个时候有第三方的服务器是可以访问到 那四个 Node 的机器的 ,这个时候我们就可以借助这个第三方的服务器去访问, 但是我们并不知道它最后会落到四台中的哪一台机器上,这个就是反向代理
负载均衡
跟上面的反向代理有一个息息相关的东西就是负载均衡 就是上面的四台机器,你不知道最终要找的是谁,但是 Nginx 知道,它会帮你找到压力最小的那个服务器然后返回给你,就这样的可以分担你的压力
上图需要注意的点
在建立很多很多个服务器的时候,要确保每台服务器上的东西得是一样的
上图中所说的中间服务器,在本章中指的就是 Nginx
内容包括C/C++,Linux,Nginx,ZeroMQ,MySQL,Redis,MongoDB,ZK,流媒体,P2P,K8S,Docker,TCP/IP,协程,DPDK多个高级知识点。
关注VX公众号更多精彩视频分享:Linux C后台服务器开发
2. Nginx 负载均衡的实现
3. HTTP UPstream 模块
什么是 HTTP UPstream 模块
ip_hash 指令
这个是比如用户落在这样一台服务器上了,然后下次用户一刷新又落到别的上面了,这个就不太对了,所以 ip_hash 是为了保证用户再次刷新的时候还能落到他之前落到的那台服务器上,这样就 ok 了
server 指令
这个是:你可以指定这台服务器的权重,就是说如果你知道了这台机器要比别的优秀,那么你可以给它的权重给标的高一点,那么更多的请求就会落到这个你认为优秀的机器上面,默认是 1:1:1 的,这个 1:1:1 可以举成 2:1:1 的例子来说明:就是现在有三台机器,第一台的权重被设置为了 2 后面两台都是 1 ,这样的话落到第一台的几率就是 2 / 3,后面两台的都是 1 / 3
UPstream 指令
4. 其他负载均衡的方法
上面的主要是理论下面是实战操作
macOS 部署 Nginx
第一步的网址是 MAC 系统下的一个神器,它是一个 macOS 缺失的软件包管理器 https://brew.sh/index_zh-cn.html
接着就是打开命令行终端依次输入命令
//安装 Homebrew
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
//查看是否有 nginx 的包
brew search nginx
命令行输出如下:打了一个对勾就证明是有的,接下来就可以安装了
//安装 nginx
brew install nginx
//装过之后可以查看 nginx 对应的一些版本的信息
brew info nginx
//查看 nginx 版本信息
nginx -v
//启动 nginx ,这个默认的端口号是 8080
nginx
//可以暂停 nginx
nginx -s stop
//再次启动 nginx
nginx
这个是时候在浏览器中输入 localhost:8080 就可以打开 nginx 首页了
这个时候你会发现页面 title 的 icon 是 Jenkins 的头像,这个原因是因为如果你装过 Jenkins 的话,它是非常顽固的会不停的去折腾、重启你的 8080 端口,你如果是 kill 是杀不掉的,你需要用下面的命令就可以把它给停掉了
//停掉 jenkins
sudo launchctl unload/Library/LaunchDaemons/org.jenkins-ci.plist
//停掉之后如果想启动 jenkins
systemctl start jenkins
想要进行上面的 反向代理和负载均衡 还需要对 nginx 进行配置
//停止 nginx 服务
nginx -s stop
//重新加载 nginx 配置文件
nginx -s reload
打开 nginx 具体安装目录 查看配置文件
/usr/local/etc/nginx/ 这个是 macOS 下 nginx 的安装目录,其他系统的可能会不大一样
//先进入 nginx 目录的上一级目录
cd /usr/local/etc/
//查看该目录下的所有文件,可以在下图看到 nginx 目录
ls
//再进入 nginx 目录
cd nginx
//查看该目录下的所有文件,可以在下图看到 nginx 目录下的所有文件
ls
可以看到里面有个 nginx.conf 的文件,这个就是 nginx 的配置文件,上面的 nginx2.conf 是之前做的备份可以忽略掉
//查看配置文件的内容,下图是内容的一部分,这个里面的内容就是 nginx 默认的配置内容
cat nginx.conf
对上图的一些解释
#user 指的是哪个用户能用,可以将后面的 nobody 修改成你指定谁用的那个用户的用户名
worker_processes 这个是你的一个工作的进程,其实实际上指的就是 CPU 的核数,如果你是 4 核的话,这个值就是 4,你需要看到自己的电脑是几核的处理器,然后你可以在这里面做相应的设置,最多就是 2 倍,一般就是标准的几核就是几个 或者 2 倍,这个不能乱设
#error_log 这个就是整个产生错误的日志
nginx 的日志跟我们 Node 的日志比一点都不逊色,它们的区别是:nginx 可以完全的记录所有的请求的日志,因为它是一个向外去扩散的一个去做负载均衡的口子,你的那个 Node 是你的项目里的一些 log ,两个人都各自有分工
这个 log 是会非常庞大的,所以像有的一些大公司会有专门去存 log 的服务器,那些数据挖掘的人或者是运维会每天去查这个日志,从这些日志里其实可以拿到很多很多的东西,所以这个日志是至关重要的,对于大公司来讲这个是比命还重要的东西,所以 nginx 的日志是万万不能丢的,任何语言里的日志它们都会分成 level(级别)
上面的第一行就是 出错的日志 ,第二行是警告的,第三行是基本信息
#pid 这个是 nginx 非常重要的一个配置文件,这个就别动就好了
events -> worker_connections 这个就是整个的连接数,就是说你一下子往你的这个上面压多少
http 模块 在这个里面可以去指定一下所谓的我们平时的 gzip 、Etag 等等都是从这里去开启的
#gzip 把前面的 # 号去掉,然后这个 gzip 就开启了,在我们去做性能优化的时候在这里面把 Etag 一开就很简单,还包括那个 express 过期时间都在这里
server
listen 这里是监听 8080 端口
#charset koi8-r 这个是它输出的语言 access_log 这个是它的日志
location 这个非常重要,里面的 root 不是指的同户名,而是当前的 html 文件夹,它会从下面的顺序依次开始找,直到找到对应的一个文件然后去给你吐
error_page 这个是 Node 控制出错的,有时你会发现百度、腾讯或者是其他的一些公司的 404 是一样的,原因就是在这的,所有的请求都固定到这,然后他把一些出错都控制好 是这样的一个原因
下面还有一些 500 502 503 504 ,他都把这些出错导到 50x 去了,所以这些不是真正的内部的系统去做的。而是一些做负载均衡的服务器去做的
location ~ \.php$ 这些就是用正则去匹配一些更复杂的,就是你真正的路由都可以在这里面去写
接下来就是我们要给运维做什么
我们要给运维做的东西相对来说比较简单,不用去搞那些杂七杂八的,注意:修改文件的时候要记得把注释删掉
//这个就是我们前端需要给运维做的东西,这个是从复杂的 nginx 里去抽出来的
worker_processes 4;//这个是你的一个工作的进程,其实实际上指的就是 CPU 的核数
events{
worker_connections 1024;//这个就是整个的连接数,就是说你一下子往你的这个上面压多少
}
//上面两个其实你不给运维的话也是可以的,他都不要,你写了也没用,关键的就是下面的 http
http{
//这个是负载均衡的所有的 server ,这里的 IP 地址需要写成你需要用到的真实有效的才行
upstream firsttest{
server 192.168.230.128;
server 192.168.230.129;
}
server{
//通过 server 监听的是 8080
listen 8080;
//当你访问 / 这个路由地址的时候 通过下面的 proxy_pass 代理去访问 firsttest 然后就可以了
location / {
proxy_pass http://firsttest;
}
}
}
无注释版本
worker_processes 4;
events{
worker_connections 1024;
}
http{
upstream firsttest{
server 192.168.230.128;
server 192.168.230.129;
}
server{
listen 8080;
location / {
proxy_pass http://firsttest;
}
}
}
接着是对照上面的设置修改你的 nginx.conf 文件
先要对之前的 nginx.conf 文件进行备份
//先进入到系统安装的 nginx 目录下
cd /usr/local/etc/nginx
//备份配置文件
cp nginx.conf nginx.conf.back
//备份之后再查看是否已成功生成文件
ls
修改 nginx.conf 文件,将下面的代码片段里面的设置相应的复制按照规则复制进这个文件中,之后保存即可
worker_processes 4;
events{
worker_connections 1024;
}
http{
upstream firsttest{
server 192.168.230.128;
server 192.168.230.129;
}
server{
listen 8080;
location / {
proxy_pass http://firsttest;
}
}
}
修改并保存之后,在浏览器中打开你设置的两个服务器 ip 地址进行查看,打不开的原因也会出现,比如:防火墙未关闭导致的
为了显示区别 我将两台服务器上的文字稍作了修改,修改之后,还需要重载 nginx 才会生效哦
//先暂停
nginx -s stop
//进入 html 目录修改 index.html
cd /usr/share/nginx/html
vi html
//修改之后保存并退出
ESC 键
:
wq
//重载
nginx -s reload
//启动
nginx
现在刷新浏览器,会发现 128 和 129 两台服务器分别能落到的几率为 50%
这里我发现了一个问题,因为我的两台服务器一个是 Centos 一个是 Ubuntu 128,Centos 129 的里面的 index.html 文件修改成功了多了 192.168.230.129 端口号,但是 Ubuntu 那个没有
解决上面 Ubuntu 的问题
//先查看 nginx 配置文件
cat /etc/nginx/nginx.conf
会发现 http 设置里面有这样的默认设置
这里我再次分别进入这两个目录
//发现只有这个目录下有个 default 文件
cd /etc/nginx/sites-enabled
ls
//查看该文件
cat default
发现里面引用的是 root 用户下的 /var/www/html 目录中的 html
这时去修改 /var/www/html 目录下的 html 文件
cd /var/www/html
//查看目录下包含的文件 发现只有 index.nginx-debian.html 文件
ls
//使用下面的命令以图形化的方式打开该目录(适合 Ubuntu 下使用的命令) 再在编辑器中 修改 index.nginx-debian.html 文件 保存并退出
nautilus ./
//先将 nginx 运行暂停
//再重载
//最后启动
systemctl start nginx
//最后查看是否是 running 状态
systemctl status nginx
Ubuntu 下重启期间总是会出现一些莫名奇妙的问题,我的解决方法就是
//先找到在运行中的与 nginx 相关的所有进程
ps -eaf |grep nginx
//然后使用 kill -9 命令将他们一个一个的杀掉
kill -9 1250
//再重新启动 nginx
systemctl start nginx
这个时候再去刷新查看浏览器,会发现已经成功了 129 128 每次落到的几率都是 50%
还可以在修改 nginx.conf 配置文件中的 http 对象,这里我是在 Ubuntu 下里面的文件
//先暂停 nginx
systemctl stop nginx
//进入配置文件目录
cd /etc/nginx
//以图形化的界面打开该目录
nautilus ./
//在编辑器中编辑 nginx.conf 配置文件
//在 firsttest 里面增加一个 ip_hash 属性 一定记得要加 分号
upstream firsttest{
ip_hash;
}
//之后再重载一遍
nginx -s reload
//运行
nginx
再刷新浏览器,会发现访问的是 Ubuntu 这个 128 的增加了 ip_hash 的服务器时,只要你第一个访问成功了,那么它下次就会默认还访问这个上次访问成功了的服务器 ,不会再落到另一台服务器上了,Centos 129 那个服务器就还是之前的 50% 几率的动态落
还可以在里面加一个权重的东西,参照上面的方法,权重是添加到 IP 地址后面的,下图中加了属性 值为 2 这样的话如果是页面刷新三次的话 落到 128 Ubuntu 这台服务器上的几率就是 3 / 2 ,要先把上面加的 ip_hash 删掉,测试才会有效
下面主要是一些 在 Ubuntu 和 Centos 下与上面的 MAC 下的具体操作差异,还有就是操作时遇到的一些坑
装包,Centos 的话需要 先将Centos的yum源更换为国内的阿里云源 参考地址:将Centos的yum源更换为国内的阿里云源 再进行安装
//Centos
yum install nginx
//Ubuntu
sudo apt-get install nginx
在修改完 nginx.conf 文件并保存后 重载时会报错
下面是报错的文本
nginx: [error] invalid PID number "" in "/run/nginx.pid"
需要先执行一行命令,才能再执行重载
// /etc/nginx 是 ubuntu 和 centos 下的安装目录
cd /etc/nginx
nginx -c /etc/nginx/nginx.conf
//然后再进行重载
nginx -s reload
启动和暂停命令使用 systemctl
//启动 nginx
systemctl start nginx
//暂停 nginx
systemctl stop nginx
//重启 nginx
systemctl restart nginx
如果在启动时遇到下面的错误,可移步至 centos7安装nginx
Job for nginx.service failed because the control process exited with error code. See "systemctl status nginx.service" and "journalctl -xe" for details.
Ubuntu 和 Centos nginx 的具体文件位置 nginx 配置文件的目录 /etc/nginx/ nginx 项目资源文件的目录 /usr/share/nginx/
有时在本机打不开的原因:防火墙未关闭、nginx 未启动
在 Ubuntu 下修改文件时先进入目录下再使用 nautilus ./ 命令以图形化的形式打开目录,再在编辑器中进行编辑并保存比较方便
这里我使用的是 Centos 和 Ubuntu 两个虚拟机来模拟的服务器