大厂技术坚持周更精选好文
简介
nginx 是一个高性能的 HTTP 服务器，也可以当作电子邮件代理服务器；其特点是占有内存少，并发能力强且非常稳定，并且有着丰富的模块库，配置灵活简单；因为上述特点，现在 Nginx 几乎已经是互联网系统中不可或缺的一部分；
性能天花板
Nginx 作为一个 web 服务器，差不多可以称为 “性能天花板” 了，在做一些优化之后，Nginx 甚至能做到 “单机百万 QPS” 的表现；因为这逆天的性能表现，国内的互联网大厂基本都会使用 Nginx 作为自己的网关，直接承载所有的线上流量；那 Nginx 为什么能拥有这么 :ox::beer: 的性能呢？
架构设计
因为散热的原因， CPU 的频率已经十多年没有增长了（下图绿色部分），而 CPU 的频率就决定了它的指令执行速度；
CPU 厂商对这一问题的解决方案是横向的往多核方向发展，这就意味着所有的单进程、单线程的软件性能都将无法从 CPU 升级上获得提升，想提升服务器的 QPS，就必须充分使用 CPU 的多个核，那应该如何有效利用 CPU 多核的特性呢？
线程 是 CPU 调度的最小单位，支持多线程的软件就可以同时使用 CPU 多个核的算力，进程是比线程更大的粒度，所以支持多进程也可以，Nginx 就采用了多进程的架构；Nginx 中主要包含下面几种进程：
- master 进程：负责读取配置、绑定端口、创建子进程；
- worker 进程：负责大多数的逻辑，比如，处理网络请求、读写磁盘、和其他服务通信等；
- cache manager、cache loader：缓存相关逻辑；
Nginx 服务器启动后，会生成一个 master 进程，master 线程在完成自己的工作后就开始创建 worker 进程，随后进入 sleep 的状态，不占用过多的计算资源；
worker 进程是实际处理用户请求的进程，又因为 Nginx 采用事件驱动的非阻塞 I/O 架构设计，并发数高的时候 worker 进程将会一直保持 running 的状态，理论上一个 worker 就能吃掉一整个 CPU 核心的算力，所以默认情况下 nginx 会根据系统的 CPU 核心数来创建 worker 进程，有几个核就创建几个 worker 进程；
那多个 worker 进程是怎么监听同一个端口的？大家本地启动开发服务器的时候应该遇到过端口被占用的报错；master 进程监听了 80、443 端口，worker 进程属于 master 的子进程，在 linux 中子进程将默认继承父进程监听的端口；
使用 master/worker 除了能充分利用 CPU 多核的算力之外，还带来了一些其他诸如 “热升级” 的好处；
榨干 CPU 算力
虽然说架构设计很重要，但光架构设计还不足以让 Nginx 有这么强大的性能；Nginx 还通过其他各种手段榨干 CPU 的算力，抢占服务器上其他应用的计算资源；比如：
上面说的高并发时 Nginx 的 worker 进程会一直保持 running 的状态，抢占 CPU 的算力，但 Linux 作为分时操作系统，会将 CPU 的执行时间分为许多碎片，交由所有进程轮番执行。这些时间片有长有短，从5毫秒到800毫秒不等，内核分配其长短时，会依据进程的静态优先级来分配。没错，Nginx 为了让 worker 进程能分到更长的时间片，会增加 worker 进程的静态优先级，让它能够抢占到更多的 CPU 计算时间；
想做到高性能，必须同时拥有 “好架构” :heavy_plus_sign: “好的细节处理”；
使用入门
Nginx 的配置系统由一个主配置文件和其他一些辅助的配置文件构成。这些配置文件均是纯文本文件，全部位于 Nginx 安装目录下的 conf 目录下。
配置文件中以 # 开始的行，或者是前面有若干空格或者 TAB ，然后再跟 # 的行，都被认为是注释；
配置文件中可以包含若干配置项，每个配置项由 “配置指令” 和 “指令参数” 2个部分构成，并以 ; 结尾，指令参数也就是配置指令对应的配置值。举个例子：
# 这一行是注释，下一行中的 error_page 为 “配置指令”，其后跟着的是对应的 “指令参数”error_page 500 502 503 504 /50x.html; 配置指令
配置指令分为两种：
- 简单配置指令：指令的参数全部由简单字符串构成，不包含复合配置块，上述的 “error_page” 即为简单配置项；
- 复杂配置指令：包含复合配置块，复合配置块是由 {} 括起来的一堆指令，其中可能包含一个或多个简单配置指令和复杂配置指令，例如：
- events {
worker_connections 1024 ;
}
指令参数
指令的参数使用一个或者多个空格或者 TAB 字符与指令分开，由一个或者多个 TOKEN 字符串组成，TOKEN 字符串之间由空格或者TAB键分隔开来；
指令上下文
复杂配置指令中的 http 、 location 、 server 、 mail 会产生指令上下文，指令上下文存在嵌套关系，比如：
# main 上下文user nginx;worker_processes 1;error_log logs/error.log info;events { worker_connections 1024;}http { server { listen 80; server_name www.example.com; location / { index index.html; } }}mail { auth_http 127.0.0.1 :80/auth.php; pop3 _capabilities "TOP" "USER"; imap_capabilities "IMAP4rev1" "UIDPLUS"; server { listen 110; protocol pop3; proxy on; }} main 上下文主要用来配置与具体的业务（http 或者邮件）无关的逻辑，比如例子中的：
- error_log 配置错误日志路径；
- worker_processes worker 进程数；
- user 指定可以运行 Nginx 服务的用户和用户组；
- events 配置 Nginx 服务器与用户的网络连接，比如上述 worker_connections 用来配置 worker 进程可以同时支持的最大连接数；
main 上下文中还包含了 http 指令，http 是 Nginx 服务器配置中最重要的部分，代理、缓存等绝大多数功能和第三方模块的配置都可以放到这个模块中来；mail 可用来定义电子邮件代理服务器相关的配置；
常见指令
include
从其他文件引入配置，可用来对复杂的 Nginx 配置做拆分；
# main 上下文user nginx;worker_processes 1;error_log logs/error.log info;events { worker_connections 1024;}http { server { listen 80; server_name www.example.com; location / { index index.html; } } include /etc/nginx/conf.d/*.conf;} server
server 块用来配置 “虚拟服务器” ，每一个 server 块都相当于一台 “虚拟服务器”，“虚拟服务器” 是一个与实体服务器相对应的概念，将一台实体服务器进行划分，对外表现为多个服务器，可以充分利用服务器的硬件资源，并且可以不用为每一个要运行的网站提供单独的 Nginx 服务器；
server { listen 80; server_name a.com; location / { proxy_pass }}server { listen 80; server_name b.com; location / { proxy_pass }} server 中最重要的两条指令为 listen 和 server_name ，这两条指令共同决定了一个请求究竟会打到哪一个 “虚拟服务器中”；
listen
用来配置 “虚拟服务器” 监听的 ip 和 port ，只能配置在 server 块中，具体语法：
# 只监听来自 127.0.0.1 这个 IP，请求 8000 端口的请求listen 127.0.0.1:8000;# 只监听来自 127.0.0.1 这个IP，请求 80端 口的请求（不指定端口，默认80）listen 127.0.0.1;# 监听来自所有 IP，请求 8000 端口的请求listen 8000;# 监听 80 端口的请求，且如果没有其他 server_name 能匹配上的话将会默认匹配该 serverlisten 80 default_server; server_name
用来配置 “虚拟服务器” 的网址，只能配置在 server 块中，具体语法：
server_name myserver.com www.myserver.com;# 还可以使用通配符 *server_name myserver.* *.myserver.com;# 还可以使用正则server_name ~^(?<www>.+).example.org$; 存在 通配符 以及正则的话，则存在多个 server_name 被同时匹配上的可能，当有多个匹配上的话，会按照下面的优先级来决定请求打到哪一个 “虚拟服务器”：
- 准确匹配的 server_name；
- 通配符在开始时匹配的 server_name；
- 通配符在结尾时匹配的 server_name；
- 正则表达式匹配的 server_name；
- locatioin
server 中使用 listen 和 server_name 来区分 “虚拟服务器”，location 指令则让 server 可以非常灵活的处理请求；
location 的语法结构：
location [ = | ~ | ~* | ^~ ] uri { ...} location 有五种匹配方式：
空 | location 后没有参数直接跟着 标准 URI ，表示前缀匹配，代表跟请求中的 URI 从头开始匹配； |
= | 用于 标准 URI 前，要求请求 字符串 与其精准匹配，成功则立即处理，nginx停止搜索其他匹配。 |
^~ | 用于 标准 URI 前，并要求一旦匹配到就会立即处理，不再去匹配其他的那些个正则 URI，一般用来匹配目录 |
~ | 用于 正则 URI 前，表示 URI 包含正则表达式，区分大小写 |
~ * | 用于 正则 URI 前，表示 URI 包含正则表达式，不区分大小写 |
Nginx 中不会直接按照 location 出现的先后顺序进行匹配，而是按照下面的规则进行匹配：
- 先精准匹配 = ，精准匹配成功则会立即停止其他类型匹配；
- 没有精准匹配成功时，进行前缀匹配。先查找带有 ^~ 的前缀匹配，带有 ^~ 的前缀匹配成功则立即停止其他类型匹配，普通前缀匹配（不带参数 ^~ ）成功则会暂存，继续查找正则匹配；
- = 和 ^~ 均未匹配成功前提下，查找正则匹配 ~ 和 ~* 。当同时有多个正则匹配时，按其在配置文件中出现的先后顺序优先匹配，命中则立即停止其他类型匹配；
- 所有正则匹配均未成功时，返回步骤 2 中暂存的普通前缀匹配（不带参数 ^~ ）结果；
- 所有匹配都不命中时，默认进入 / ；
- rewrite 和 proxy_pass
rewrite 可以出现在 server、location、if 块中，用来改写请求地址，具体的语法如下：
rewrite regex replacement [last|break|redirect|permanent]; proxy_pass 只能出现在 location、if 块中，用来将请求转发至对应的服务，具体语法如下：
proxy_pass uri; 举个例子：
server { rewrite /a.html /b.html break; return 200 'ok'; location /a.html { return 200 'a.html'; } location /b.html { return 200 'b.html'; } location /c.html { proxy_pass }} 使用场景
域名 -> 域名
将某一个域名的请求在本地拦截之后，转发到 nginx 中，nginx 将请求转发到其他域名；
server { listen 80; server_name www.baidu.com; location / { proxy_pass }} 域名 -> 本地 ip
将某一个域名的请求拦截之后，转到到 nginx 中，nginx 将对应的请求打到本地的其他 ip；
server { listen 80; server_name www.baidu.com; location / { proxy_pass }} 路径 -> 域名
根据不同路径将请求转发至不同的域名；
server { listen 80; server_name www.baidu.com; location ^~ /to_google { proxy_http_version 1.1; rewrite .* /; proxy_pass }} 接口跨域
解决前端本地 开发环境 调用线上接口时跨域的问题；
server { listen 80; location ^~ /api { proxy_pass add_ header Access-Control-Allow-Methods *; add_header Access-Control-Max-Age 3600; add_header Access-Control-Allow-Credentials true; add_header Access-Control-Allow-Origin $http_origin; if ($ request _method = OPTIONS){ return 200; } }} 小结
- Nginx 因为其优秀的架构设计和极致的细节处理，才拥有了现在这么强悍的性能，两者缺一不可；
- Nginx 有一套自己设计的指令式配置语法，跟传统的 编程语言 不同，学习成本不高，感兴趣的同学可以学习一下；
- 还是别用 Nginx 作为你的开发代理工具了；
:heart:谢谢支持
以 上 便 是 本 次 分 享 的 全 部 内 容 ， 希 望 对 你 有 所 帮 助 ^ _ ^
喜 欢 的 话 别 忘 了 转 发、 点 赞 、 关 注 三 连 哦 ~ 。
原文：微信公众号 E L a b 团 队
