一、nginx升级之路

之前因为业务量并不是很大，所以公司nginx采用的是单机。因为nginx单机性能也很好，所以也没有发生过什么问题。不过后来还是慢慢进行了几次调整。最终换成了多IP地址解析和nginx主从。下面就介绍一下怎么一步步升级的。

1.最初版本：单机nginx

最开始因为很少的用户量而且最主要是服务器资源太少，所以综合考虑下来就部署了一台nginx而且是单机的。具体做法就是将域名解析到nginx服务器，然后由nginx将请求转发到对应的服务。

 2.二次升级版本：解析到多个IP

后面因为有了两台服务器，为了增加nginx的可靠性，在一台nginx宕机时不至于整个业务不能用，所以在域名解析的地方做了指向两个IP地址的解析。

具体如下：

3.三次升级版本：多IP地址解析+nginx主从

其实上面的版本，已经能够保证在一台机器出现问题时候，能够保证系统依然可用。不过这里还是有一个问题：因为我们是在一台服务器里面安装了多台虚拟机，假如只有nginx这台虚拟机挂了，但是我其他的虚拟机都在正常工作，那么部署在这台服务器的应用就全靠另一台服务器上面的nginx来负载了。这样跨服务器的负载显然是会对性能有影响。所以就又进行了一次升级。

 这次升级主要是使用nginx+ keepalived。在这里做一下记录，以便后面有需要的时候直接使用。

二、nginx+ keepalived实现主从

1.准备工作：首先是准备两台虚拟机

两台虚拟机IP： 192.168.2.202 192.168.2.203

VIP：（虚拟IP）192.168.2.230

2.放开两台虚拟机80端口

 分别在两台虚拟机上面执行以下命令

firewall-cmd --zone=public --add-port=80/tcp --permanent

firewall-cmd --reload

3.在两台虚拟机上面安装nginx

安装过程可以参考以前写的一篇博客，这里就不再重复写了。我把链接贴一下。我这个安装了得有十几次了，应该没啥坑。

centos7安装nginx_极速小乌龟的博客-CSDN博客_centos7.9 安装ngxin1.安装依赖yum install -y gcc-c++ pcre pcre-devel zlib zlib-devel openssl openssl-develgcc-c++：安装nginx需要先将官网下载的源码进行编译，编译依赖gcc环境。pcre pcre-devel ：PCRE(Perl Compatible Regular Expressions) 是一个Perl库，包括 perl 兼容的正 则表达式库。nginx 的 http 模块使用 pcre 来解析正则表达式，所以需要在 .https://blog.csdn.net/qq_35771266/article/details/114299110

4.安装keepalived

#安装keepalived
yum install keepalived -y

安装以后检查一下是否安装完成

#安装版本检查
rpm -q -a keepalived

 出现如下版本提示说明安装成功。径默认安装路径: /etc/keepalived

5.新建nginx_check文件

 进入到/etc/keepalived目录下新建nginx_check文件

#新建文件
vi /etc/keepalived/nginx_check.sh

在文件中输入以下内容：

#!/bin/bash
A=`ps -C nginx --no-header |wc -l`
if [ $A -eq 0 ];then
    /usr/local/nginx/sbin/nginx
    sleep 2
    if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then
        killall keepalived
    fi
fi

 6.修改nginx_check文件权限

chmod 777 /etc/keepalived/nginx_check.sh

 7.配置主从keepalived的配置文件

这里有一点需要说明一下，interface ens192 # 绑定虚拟 IP 的网络接口，根据自己的机器填写

这个网卡可以通过 ip addr查看，一定要写成自己的，不然根本不会生效。

! Configuration File for keepalived
global_defs { 
    router_id keep_171  #每台机器需要不一样
}  
vrrp_script chk_nginx {
    script "/etc/keepalived/nginx_check.sh"
    interval 2
}
# 定义虚拟路由，VI_1 为虚拟路由的标示符，自己定义名称
vrrp_instance VI_1 {
    state BACKUP #来决定主从
    interface ens192 # 绑定虚拟 IP 的网络接口，根据自己的机器填写
    virtual_router_id 121 # 虚拟路由的 ID 号， 两个节点设置必须一样
    mcast_src_ip 192.168.2.202 #填写本机ip
    priority 80 # 节点优先级,主要比从节点优先级高
    nopreempt # 优先级高的设置 nopreempt 解决异常恢复后再次抢占的问题
    advert_int 1 # 组播信息发送间隔，两个节点设置必须一样，默认 1s
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    # 将 track_script 块加入 instance 配置块
    track_script {
        chk_nginx #执行 Nginx 监控的服务
    }
 
    virtual_ipaddress {
        192.168.2.230/24 dev ens192
    }
}

! Configuration File for keepalived
global_defs { 
    router_id keep_172
}  
vrrp_script chk_nginx {
    script "/etc/keepalived/nginx_check.sh"
    interval 2
}
# 定义虚拟路由，VI_1 为虚拟路由的标示符，自己定义名称
vrrp_instance VI_1 {
    state MASTER #来决定主从
    interface ens192 # 绑定虚拟 IP 的网络接口，根据自己的机器填写
    virtual_router_id 121 # 虚拟路由的 ID 号， 两个节点设置必须一样
    mcast_src_ip 192.168.2.203 #填写本机ip
    priority 300 # 节点优先级,主要比从节点优先级高
    nopreempt # 优先级高的设置 nopreempt 解决异常恢复后再次抢占的问题
    advert_int 1 # 组播信息发送间隔，两个节点设置必须一样，默认 1s
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    # 将 track_script 块加入 instance 配置块
    track_script {
        chk_nginx #执行 Nginx 监控的服务
    }
 
    virtual_ipaddress {
        192.168.2.230/24 dev ens192
    }
}

 8.启动keepalived

#启动命令
service keepalived start

#重启命令
service keepalived restart

#关闭命令
service keepalived stop

 启动完成以后就可以进行测试了，在浏览器输入虚拟IP进行访问。

 然后停掉主节点nginx,再次访问。可以看到虚拟IP已经自动漂移到了202这个从节点。

 然后再次启动主节点，和主节点的keepalived.再次访问。可以发现当主节点上线以后虚拟IP又自动漂移到了主节点203上面。

注意：这里有一点要特别说明一下，就是重新启动主节点以后，要重新启动keepalived。需要使用重启命令，而不是启动命令。这个我也不知道为什么。如果有明白的可以跟我讲一下。不然虚拟IP无法自动漂移到主节点。

service keepalived start

番外：这里因为搭建完成以后发现主从没有生效，所以开始排查问题。排查过程中发现两台服务器keepalived和nginx都启动成功了，然后虚拟IP也生效了，但是我停掉主节点nginx以后从节点并没有生效，服务直接不能用了。所以怀疑是这个脚本没有生效。于是就对这个命令搜了一下。下面备注一下：

 ps -C nginx --no-header |wc -l  这条命令可以分成几部分来看。

ps -C nginx 在服务器执行一下就很清晰了。其实就是统计了当前nginx的进程.

--no-header 这个看名字也能猜出来一个大概就是不要上面截图中的最上面那个标题头了，也就是红框中的这一行。至于为什么要去掉，其实就是想通过查询结果的行数来确定nginx是不是在运行。

 

|wc -l   其中|就是一个管道命令 ，相当于基于前面的结果进行再次处理。wc我搜索了一下就是统计命令， -l就是统计行数。

这里真的得吐槽一下，网上很多人不知道哪里弄得我感觉都没有测试过，直接粘贴复制的，很多多是 ps -C nginx -no-header  但是这个其实是 --no-header 像我这种不是专业运维的真的是被搞得很无语。希望大家不要走我的老路。

9.能否一主多从

这个我后面在想能不能实现一主多从，于是又搞了一台从机进行测试。

机器IP

201 优先级  200 BACKUP

202 优先级 100 BACKUP

203 优先级 300 MASTER

启动以后发现并不是很理想，这个倒是能实现主节点挂掉漂移到201,201挂掉漂移到202,这倒是相当于多了一次容错机会。不过在主节点挂掉以后，再次启动主节点，如果说当前只有一台存活能够顺利漂移会主节点，如果有两台存活你就会发现它不回来了。。。

三、nginx集群

在上面的主从模式中，我们通过域名解析到多台nginx在我看来其实就是nginx集群了。不过到上面为止我们都是在使用nginx充当流量网关，就是请求拿过来以后进行了转发，并没有做业务处理。但是还有另一种情况，就是假设我们做了多级缓存，拿nginx来充当业务网关，这个时候就需要再部署nginx业务网关集群了。大致意思如下：

 其实用nginx充当业务网关进行部分高并发流量处理的原因很简单，Tomcat的并发能力太低了，跟nginx比起来差的太远。如果我们能够直接通过redis去拿到数据，相比与先请求Tomcat，然后Tomcat再去请求redis拿数据，那并发性能要高很多的，要知道nginx和redis的单机承载量都是万级别以上的。

实现方式比较简单，就跟我们正常的业务负载是一样的，就是在后面多加了一级nginx，通过主从，然后将业务请求转发到多台nginx。不过如果都是作为请求转发而没有做特殊业务处理的话我觉得还不如不做。因为这样增加了一层反而会使性能下降不少。不如直接使用域名解析效果好。

好了这就是我倒目前为止在业务中的使用了。如有问题欢迎交流~