Nginx服务器的安装部署和框架简介

2023-05-16

Nginx服务器的安装部署

1. 如何获取Nginx服务器安装文件

Nginx服务器的软件版本包括 Windows版和 Linux版俩种。官网下载地址为http://nginx.org/en/download.html。网页上提供了Nginx服务器的三种版本的下载，分别是开发版本(Development version)、稳定版本(Stable version)和过期版本(Legacy versions)。下面分别介绍页面上下载部分各链接的含义：

"CHANGES-x.x"链接，记录的是对应版本的功能变更日志。包括新增功能、功能的优化和功能缺陷的修复等。

紧接着"CHANGES-x.x"后的"nginx-x.x.x"链接，是Nginx服务器Linux版本下的下载链接，得到的后缀名为.tar.gz。

"pgp"链接，记录的是提供下载的版本使用PGP加密自由软件GnuPG计算后的签名。PGP可以解释为Pretty Good Privacy，是PGP公司的加密或签名工具的套件。点击链接进入相关页面，可以查看GnuPG针对本下载版本的签名，以及执行本次计算的GunPG软件版本号。

"nginx/Windows-x.x.x"链接，是Nginx服务器的Windows版本下载链接，文件后缀名为.zip。

2.安装Nginx服务器和基本配置

2.1 Windows版本的安装

Windows版本的Nginx服务器的安装方法与一般的Windows安装程序不同，直接将所下载好的nginx-x.x.x.zip压缩文件解压到指定盘符中即可。如图2.1所示的文件资源，这就是nginx服务器运行的全部资源。

图2.1 Windows版本Nginx的安装文件资源

2.2 Linux版本的安装

Linux版本的Nginx服务器的安装比Windows版本要麻烦一些，需要先对 Nginx源代码进行编译。在正式开始操作之前，我们先检查 Nginx 编译和安装需要的条件是否满足。至于Linux系统就不再这里赘述了。

为了方便管理和使用，我们在文件系统的根目录"/"下新建Nginx_123目录，最后会把编译好的Nginx 安装到次目录中。同时，在此目录中新建 Nginx_123_Compile，用来编译Nginx 软件：

#mkdir /Nginx_123/

将从官网获取的Linux 版本 nginx-x.x.x.tar.gz复制到相应的目录：

#cp nginx-x.x.x.tar.gz /Nginx_123/

解压Nginx归档，得到Nginx软件安装包的所有资源 :

#tar xf nginx-x.x.x.tar.gz                //解压归档文件

         同样，为了方便后续的学习，我们有必要对解压出来的部分文件和目录做个简单介绍。
    ■ src 目录中存放了Nginx 软件的所有源代码。
    ■ man 目录中存放了 Nginx 软件的帮助文档，Nginx 安装完成之后，在 Fedora的命令行中使用man的命令可以查看：

#man nginx

    ■ html 目录和conf目录中存放的内容和Windows 版本的同名目录相同。
    ■ auto 目录中存放了大量脚本文件，和configure脚本程序有关。
    ■ configure 文件是 Nginx 软件的自动脚本程序。运行 configure 自动脚本一般会完成俩项工作：一是检查环境，根据环境检查结果生成C代码；二是生成编译代码需要的Makefile 文件。
    得到了Nginx软件的 Makefile文件后，我们就可以进行编译源代码了。保持当前的工作路径，使用make命令进行编译：

#make

编译顺利完成以后，使用make的install命令安装Nginx软件：

#make install

命令运行完成后，将当前工作目录定位到/nginx下，可以对Nginx服务器安装后的全部资源进行查看：

#cd /Nginx;

如果在编译过程中出现了源代码的编译错误，进行一下操作：
#rm -rf /Nginx/*
#cd /Nginx_123/Nginx_123_Compile/nginx-1.2.3/; make clean
之后再使用以下命令进行编译和安装：
#make；make install

到此为止，我们就安装好了一个基本的Nginx服务器。Nginx服务器的安装目录主要包括了 conf、html、logs和sbin等4个目录。
其中，conf目录中存放了Nginx的所有配置文件。其中，nginx.conf文件是Nginx服务器的主要配置文件，其他配置文件是用来配置Nginx的相关功能的，比如，配置 fastcgi 使用的 fastcgi.conf 和 fastcgi_params 俩个文件。

2.3 Nginx服务的启停控制

2.3.1 Nginx 服务的信号控制

Nginx 服务在运行时，会保持一个主进程和一个或多个worker process工作进程。我们通过给Nginx服务的主进程发送信号就可以控制服务的启停了。首先我们要知道主进程的PID。

2.3.2 Nginx 服务的启动

在Linux平台下，启动Nginx 服务器直接运行安装目录下sbin目录中的二进制文件即可。在Windows平台下，可以直接Duang双击nginx.exe即可。

2.3.3 Nginx 服务的启动

停止Nginx服务有俩种方法：一种是快速停止；另一种是平缓停止。快速停止时指立即停止当前Nginx服务正在处理的所有网络请求，马上丢弃链接，停止工作；平缓停止时指允许Nginx服务将当前正在处理的网络请求处理完成，但不再接受新的请求，之后关闭链接，停止工作。

# ./sbin/Nginx -g TERM | INT | QUIT

其中，TERM 和 INT 信用用于快速停止，QUIT 用于平缓停止。

2.3.4 Nginx 服务的重启

更改Nginx服务器的配置和加入新的模块后，如果希望当前的Nginx服务应用新的配置或新模块生效，就需要重启Nginx服务。这里介绍Nginx服务的平滑重启。平滑重启是这样一个过程，Nginx服务进程接收到信号后，首先读取新的Nginx配置文件，如果配置语法正确，则重新启动新的Nginx服务，然后平滑关闭旧的服务进程；如果新的Nginx配置文件有问题，将显示错误，仍然使用旧的Nginx进程提供服务。
使用以下命令实现Nginx服务的平滑重启：

# ./sbin/nginx -g HUP {-c newConfFile}
HUP 信号用于发送平滑重启信号 
newConfFile，可选项，用于指定新配置文件的路径。
或者，使用新的配置文件代替了旧的配置文件后，使用：
# kill HUP /Nginx/logs/nginx.pid
也可以使用平滑。

2.4 Nginx服务器基础配置指令

以下是我准备的 nginx.conf 文件的完整内容，仅供参考：

#### 全局快 开始 ####
#user  nobody;  # 配置允许运行nginx服务器的用户和用户组
worker_processes  7; #配置允许Nginx进程生成的worker process数

error_log  logs/error.log; #配置Nginx服务器运行对错误日志文件存放路径
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

pid        logs/nginx.pid; #配置Nginx服务器运行时的pid文件存放路径和名称。
#### 全局模块 结束 ####

#### events块 开始 ####
events {
    #use epoll; # 配置时间驱动模型
    worker_connections  1024; #配置最大连接数。
}
#### events块 结束 ####

#### http块 开始 ####
http {
    include       mime.types; # 定义 MIME—Type
    default_type  application/octet-stream;

    sendfile on; # 配置允许使用 sendfile 方式传输；
    keepalive_timeout  65; #配置连接超时时间;

    log_format  access.log  
    '$remote_addr - $remote_user [$time_local] "$request" ';

#### server块 开始 ####    
    server {
        listen       8018; # 配置监听端口和主机名称（CrawlLottoCode）
        server_name  192.168.1.108;

        access_log  /CrawlLottoCode/logs/error.log; 
        access_log  /CrawlLottoCode/logs/info.log;
        error_page 404   /404.html; # 配置错误页面

        location / { # 配置处理CrawlLottoCode请求的location
            root   /webappsCrawlLottoCode;
            index  index.html index;
        }
    }

    server {
        listen       8028; # 配置监听端口和主机名称（lottery-payment）
        server_name  192.168.1.108;

        access_log  /lottery-payment/logs/error.log; 
        access_log  /lottery-payment/logs/info.log;
        error_page 404   /404.html; # 配置错误页面

        location / { # 配置处理lottery-payment请求的location
            root   /webappslottery-payment;
            index  index.html index;
        }
    }

    server {
        listen       8038; # 配置监听端口和主机名称（lottery-prize-v6）
        server_name  192.168.1.108;

        access_log  /lottery-prize-v6/logs/error.log;
        access_log  /lottery-prize-v6/logs/info.log;
        error_page 404   /404.html; # 配置错误页面

        location / { # 配置处理lottery-prize-v6请求的location
            root   /webappslottery-prize-v6;
            index  index.html index;
        }
    }

    server {
        listen       8048; # 配置监听端口和主机名称（lottery-server-backend-v5.1）
        server_name  192.168.1.108;

        access_log  /lottery-server-backend-v5.1/logs/error.log;
        access_log  /lottery-server-backend-v5.1/logs/info.log;
        error_page 404 500   /404.html; # 配置错误页面

        location / { # 配置处理lottery-server-backend-v5.1请求的location
            root   /webappslottery-server-backend-v5.1;
            index  index.html index;
        }
    }

    server {
        listen       8058; # 配置监听端口和主机名称（lottery-server-frontend-v5.1）
        server_name  192.168.1.108;

        access_log  /lottery-server-frontend-v5.1/logs/error.log;
        access_log  /lottery-server-frontend-v5.1/logs/info.log;
        error_page 404 500   /404.html; # 配置错误页面

        location / { # 配置处理lottery-server-frontend-v5.1请求的location
            root   /webappslottery-server-frontend-v5.1;
            index  index.html index;
        }
    }

    server {
        listen       8068; # 配置监听端口和主机名称（LottoCodeService）
        server_name  192.168.1.108;

        access_log  /LottoCodeService/logs/error.log;
        access_log  /LottoCodeService/logs/info.log;
        error_page 404 500   /404.html; # 配置错误页面

        location / { # 配置处理LottoCodeService请求的location
            root   /webappsLottoCodeService;
            index  index.html index;
        }
    }

    server {
        listen       8078; # 配置监听端口和主机名称（self-lottery-code）
        server_name  192.168.1.108;

        access_log  /self-lottery-code/logs/error.log;
        access_log  /self-lottery-code/logs/info.log;
        error_page 404 500   /404.html; # 配置错误页面

        location / { # 配置处理self-lottery-code请求的location
            root   /webappsself-lottery-code;
            index  index.html index;
        }
    }
#### server块 结束 ####
   

}
#### http块 结束 ####

Nginx 服务器架构简介

3.1 模块化结构

"模块化设计"：定义为"以功能块为单位进行程序设计，实现其求解算法的方法"。

第一，"功能块"是对模块的描述，一个模块就是一个功能块，应该只负责一个功能，类似于设计模式中的"单一职责原则"。

第二，如果要体现模块化，就免不了将程序进行分解，这也是模块化编程的另一个原则——自顶向下，逐步求精原则。

第三，一个程序被分解为多个模块，那么它们之间一定要存在一定的依赖关系，但是这个依赖不能太强，否则也就不能称之为"模块化"了。于是，又涉及到模块化编程中的一条原则：高内聚，低耦合原则。事实上，在设计模式理论中，也有对应的一条设计原则叫"迪米特原则"。(Law of Demeter)最少知道原则。

模块化设计支持分布式开发，支持团队协同合作，支持应用扩展和升级。

3.2 Nginx 模块化结构

习惯上将 Nginx涉及到的模块分为核心模块、标准HTTP模块、可选HTTP模块、邮件服务模块以及第三方模块等五大类。

核心模块是指 Nginx 服务器正常运行必不可少的模块,它们提供了 Nginx 最基本最核心的服务,如进程管理、权限控制、错误日志记录等；标准HTTP模块是通过快速编译Nginx后包含的模块，其支持 Nginx 服务器的标准HTTP功能；可选HTTP模块主要用于扩展标准的HTTP功能，使其能够处理一些特殊的HTTP请求；邮件服务模块主要用于支持 Nginx 的邮件服务；第三方模块是为了扩展 Nginx 服务器的应用，完成第三方机构或者个人编写的可编译到 Nginx中的模块。

简要说明一下 Nginx 中模块的命名习惯。一般以 ngx_作为前缀，_module 作为后缀，中间使用一个或多个英文单词描述模块的功能。比如 ngx_core_module，中间的core表明该模块提供了Nginx程序的核心功能；再如 ngx_events_module，中间的events 表明该模块提供了解析配置文件中 events块的功能；再如ngx_http_core_module，中间的http_core表明该模块提供了 Nginx程序http 服务的核心功能，等等。

3.3 Nginx 服务器的Web请求处理机制

Web服务器和客户端是一对多的关系，Web服务器必须有能力同时为多个客户端提供服务。一般来说，完成并行处理请求工作有三种工作方式：多进程方式、多线程方式和异步方式。

多进程方式是指，服务器每当接收到一个客户端时，就由服务器主进程生成一个子进程出来和该客户端建立连接进行交互，直到连接断开，该子进程就结束了。多进程方式的优点在于，设计和实现相对简单，各个子进程之间相互独立，处理客户端请求的过程彼此不受到干扰，并且当一个子进程产生问题时，不容易将影响漫延到其他进程中，这保证了提供服务的稳定性。当子进程退出时，其占用资源会被操作系统回收，也不会留下任何垃圾。而其缺点也是很明显的。操作系统中生成一个子进程需要进行内存复制等操作，在资源和时间上会产生一定的额外开销，因此，如果Web服务器接收大量并发请求，就会对资源造成压力，导致系统性能下降。

多线程方式和多进程方式相似。它是指，服务器每当接收到一个客户端时，会由服务器主进程派生一个线程出来和该客户端交互。由于操作系统产生一个线程的开销远远小于产生一个进程的开销，所以多线程方式在很大程度上减轻了Web服务器对系统资源的要求。该方式使用线程进行任务调度，开发方面可以遵循一定的标准，这相对来说比较规范和有利于协作。但在线程的管理方面，该方式有一定的不足。多个线程位于同一个进程内，可以访问同样的内存空间，彼此之间相互影响；同时，在开发过程中不可避免的要由开发者自己对内存进行管理，其增加了出错的风险。服务器系统需要长时间连续不停地运转，错误的逐渐积累可能最终对整个服务器产生重大影响。

异步方式是和多进程方式及多线程方式完全不同的一种处理客户端请求的方式。网络通信中的同步机制和异步机制是描述进程处理调用的方式，在网络通信中，主要指网络套接字Scoket的阻塞和非阻塞方式，而Socket的实质也就是I/O 操作。Socket的阻塞调用方式为，调用结果返回之前，当前线程从运行状态被挂起，一直等到调用结果返回之后，才进入就绪状态，获取CPU后继续执行；Scoket的非阻塞调用方式和阻塞调用方式正好相反，在非阻塞方式中，如果调用结果不能马上返回，当前线程也不会被挂起，而是立即执行下一个调用。

3.4 Nginx服务器架构

Nginx服务器启动后，产生一个主进程(master process),主进程执行一系列工作后产生一个或者多个工作进程(worker process)。主进程主要进行Nginx配置文件解析、数据结构初始化、模块配置和注册、信号处理、网络监听生成、工作进程生成和管理等工作；工作进程主要进行进程初始化、模块调用和请求处理等工作，是Nginx服务器提供服务的主主体。

我们可以将Nginx服务器的结构大致分为主进程、工作进程、后端服务器和缓存等部分。

1.主进程（Master Process）

Nginx服务器启动时运行的主要进程。它的主要功能是与外界通信和对内部其他进程进行管理，具体来说有以下几点：

■ 读取Nginx配置文件并验证其有效性和正确性。

■ 建立、绑定和关闭Socket。

■ 按照配置生成、管理和结束工作进程。

■ 接收外界指令，比如重启、升级及退出服务器等指令。

■ 不中断服务，实现平滑启动，应用新配置。

■ 不中断服务，实现平滑升级，升级失败进行回滚处理。

■ 开启日志文件，获取文件描述符。

■ 编译和处理Perl脚本。

2.工作进程（Worker Process）

由主进程生成，生成数量可以通过Nginx配置文件指定，正常情况下生存与主进程的整个生命周期。该进程的主要工作有以下几项：

■ 接收客户端请求。

■ 将请求依次送入各个功能模块进行过滤处理。

■ I/O调用，获取响应数据。

■ 与后端服务器通信，接收后端服务器处理结果。

■ 数据缓存，访问缓存索引、查询和调用缓存数据。

■ 发送请求结果，响应客户端请求。

■ 接收主程序指令，比如重启、升级和退出等指令。

3.缓存索引重建及管理进程（Cache Loader & Cache Manager）

Cache模块，主要由缓存索引重建（Cache Loader）和缓存索引管理（Cache Manager）俩类进程完成工作。缓存索引重建进程是在Nginx服务启动一段时间之后（默认是1分钟）由主进程生成，在缓存元数据重建完成后就自动退出；缓存索引管理管理进程一般存在于主进程的整个生命周期，负责对缓存索引进行管理。

缓存索引重建进程完成的主要工作是，根据本地磁盘上的缓存文件在内存中建立索引元数据库。该进程启动后，对本地磁盘上存放缓存文件的目录结构进行扫描，检查内存中已有的缓存元数据是否正确，并更新索引元数据库。

缓存索引管理进程主要负责在索引元数据更新完成后，对元数据是否过期做出判断。

这俩个进程维护的内存索引元数据库，为工作进程对缓存数据的快速查询提供了便利。

3.5 进程交互

Nginx服务器在使用Master-Worker模型时，会涉及主进程与工作进程之间的交互和工作进程之间的交互。这俩类交互都依赖于管道（channel）机制，交互的准备工作都是在工作进程生成时完成的。

1.Master-Worker交互

工作进程是由主进程生成的。Nginx服务器启动以后，主进程根据配置文件决定生成的工作进程的数量，然后建立一张全局的工作进程表用于存放当前未退出的所有工作进程。在主进程生成工作进程后，将新生成的工作进程加入到工作进程表中，并建立一个单项管道，包含了主进程向工作进程发出的指令、工作进程ID、工作进程在工作进程表中的索引和必要的文件描述符等信息。

主进程与外界通过信号机制进行通信，当接收到需要处理的信号时，它通过管道向相关的工作进程发送正确的指令。每个工作进程都有能力捕获管道中可读事件，当管道中有可读事件时，工作进程从管道读取并解析指令，然后采取相应的措施。这样就完成了Master-Worker的交互。

2.Worker-Worker交互

Worker-Worker交互在实现原理上和Master_worker交互基本是一样的。只要工作进程之间能够得到彼此的信息，建立管道就可通信。由于工作进程之间是相互隔离的，因此一个进程要想知道另一个进程的信息，只能通过主进程来进行设置。

为了达到工作进程之间交互的目的，主进程在生成工作进程后，在工作进程表中进行遍历，将该新进程的ID以及针对该进程建立的管道句柄传递给工作进程表中的其他进程，为工作进程之间的交互做准备。每个工作进程捕获管道中可读事件，根据指令采取相应措施。

当工作进程w1需要向w2发送指令时，首先在主进程给它的其他工作进程信息中找到w2的进程ID,然后将正确的指令写入指向w2的通道。工作进程w2捕获到管道中的事件后，解析指令并采取相应措施。这样就完成了Worker-Worker交互。

--参考《Nginx高性能Web服务器详解》

后期我会介绍Nginx服务器的高级配置篇，尽情期待。

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)

Nginx

服务器的安装部署和框架简介