Nginx 的热部署、热加载、平滑升级！

Nginx 只所以出名，和它内部的精密设计有关。Nginx 采用了高度模块化的设计思路，并且内部的进程主要有两类，master 进程 和 worker 进程。其中 master 进程只有一个，worker 进程可以有多个。

其中 master 进程是用来管理监控控制其下边的 worker 进程的主进程，这个进程由 root 发起。其中原因是 http 这个服务需要启用 80 端口，而只有  root 才有权限启用 80 端口。

worker 进程才是真正 working 的进程，才是真正处理请求的进程。worker 进程全部都是 master 进程的子进程。worker 进程是以普通用户的身份进行运行的，这样就可以极大增加程序的安全性。就算是万一有一个进程被劫持，那也不会有管理员权限。

Worker 进程中，原生的功能只有最基本的 web 服务。但是由于 nginx 是高度模块化的应用程序，所以，在每一个 worker 进程中，有着一个或者多个模块。但是需要注意的是，装载的模块可不是全部一次加载进去的，只有当这个进程真的需要这个模块的时候，才会被这个工作进程加载。

模块化的思想和面向对象的思想，是推动现代整个开发的重要思想。

由于 nginx 这个高度模块化的机制，也成就了其高效轻量的特点。

nginx 作为一个反向代理、负载均衡服务器，必须具备高可用的特点，因此 nginx 支持热部署。

nginx 的热部署和其并发模型有着密不可分的关系。说白了，就是因为 master 进程的关系。当通知 ngnix 重读配置文件的时候，master 进程会进行语法错误的判断。如果存在语法错误的话，返回错误，不进行装载；如果配置文件没有语法错误，那么 ngnix 也不会将新的配置调整到所有 worker 中。而是，先不改变已经建立连接的 worker，等待 worker 将所有请求结束之后，将原先在旧的配置下启动的 worker 杀死，然后使用新的配置创建新的 worker。我在昨天的这篇文章《nginx 的热配置，配置立即生效命令 nginx -s reload 详解》中讲到的 nginx -s reload 其实就是一个热部署。

Nginx 作为一个服务器，我们不可能把服务停了在进行配置升级、软件版本升级吧。所以，Nginx 的热部署就极大的方便了我们对服务器软件的升级维护。

下面我们看一个 Nginx 版本从 1.10.3 平滑升级 Nginx 1.11.10 的升级例子。

首先，我们分别在官网下载这两个版本的 Nginx 源代码，然后使用 make 进行编译，然后只安装 1.10.3 版本的 Nginx，命令为：make install。1.11.10 版本的只编译即可。

然后我们启动 Nginx，启动后，效果类似上图。

然后我们在使用 cp 命令，把正在运行的 1.10.3 版本的 nginx 二进制文件备份一下。

cp nginx nginx.old

然后，我们把编译好的 1.11.10 版本的 Nginx 二进制文件拷贝替换到 nginx 目录中。

cp -r nginx /usr/local/openresty/nginx/sbin/ -f

回车上面命令，然后输入 y。然后我们使用 kill -USR2 命令。

kill -USR2 13195

然后再查看进程信息。

发现有两个 master 进程，其中一个老的 master 进程没有监听 80 端口。这时老进程就不在接受新的请求，新的请求讲转移给新的进程。

这时我们可以对老的进程发生信号，请优雅的关闭老的 worker 进程。

kill -WINCH 13195

然后，我们再次查看进程信息。

我们发现老的 master 进程还在，worker 进程退出了。这时新的请求都已过度到新的 worker 进程了。老的 master 进程并不监听和处理请求，它留下来只是为了方便我们进行版本回退。

当然如果你感觉这样显示不美观，会产生误导，则在升级完成后，可以把老的 master 进程删除掉。如果需要回退，则使用 reload 命令即可重新加载老的 master 进程。

： » Nginx 的热部署、热加载、平滑升级！