Nginx 优势总结 转载部分

对于企业来说，NGINX 是实现数字转型的有效途径

NGINX 是实现技术突破的必要工具。

随着 2020 年的魔幻开局，国内众多行业都受到了不小的冲击，疫情期间人人自危，企业复工困难，上下游供应链有一端没有恢复就不能真的恢复业务；像疫情这种黑天鹅事件是完全不可预测的。对于企业而言现在正处于一个模糊的、不确定的、快速变化的时代，在这种 VUCA 时代特征下出现这种状况可以说既是意外又不是意外。对于企业的影响一方面取决于该行业的特点，另外一方面企业所做出反应状况的不同也会形成不一样的结果。

随之而来的就是许多线下业务被迫转移线上，然而看起来只是一场非常简单的业务迁移，但在后台架构看来，却是一场对企业自身、以及企业后台面对流量、并发与架构稳定性的挑战。

首先是业务场景的变换。从线下切换至线上，不只是业务呈现形式的变更，其更涉及到企业内部更深处的平台建设、流程规划、人员培训等一系列内容。

其次是现有的技术能力难以支撑。随着线下业务的大量取消，越来越多的用户开始涌入线上平台，这对企业的后端架构能力提出了更高的要求，要在能够稳定承受流量高并发的同时还能兼顾后台性能的稳定性。然而这对众多专注在线下业务的企业来说，要在短时间内把线上平台打造为这样一款高性能的平台，的确有点难为他们。

这也显示出当下的一个痛点，场景的突然转变驱使着企业去选择具备更加高性能、更加高效的处理平台，而对于企业的现实情况来说，线上的高并发表示其急需平台下的高性能 web 服务。

而这，恰好是 NGINX 的长处。为什么这么说？因为相较于传统 ADC，NGINX 具有以下几点优势：

1、采用事件驱动的异步框架

基于异步及非阻塞的事件驱动模型，可以说是 NGINX 得以获得高并发、高性能的关键因素。因为一个 HTTP/HTTPS 请求包括多个阶段，每一个阶段在什么时候发生是不确定的，这就造成了异步性。每一个阶段的发生都会触发事件驱动框架，然后交由事件消费者处理，也就是说一个事件消费者仅仅是处理了一个请求中的一小部分。NGINX 采用事件驱动的设计来减少进程休眠的几率，从而实现提高网络性能、减少请求延时以及支撑高并发的能力。

2、反向代理

有正向代理自然就存在反向代理。正向代理是指以请求端也就是客户端的角度为正向，用户发出请求经过的代理，称为“正向代理”。反向代理则恰恰相反，是由代理选择服务端节点。存在即合理，反向代理的存在也表明其拥有着不可替代优势：

• 首先能够通过隐藏服务节点的 IP 来保护服务安全，此外也可以通过将服务节点置于防火墙之后来确保业务节点服务器不会被直接攻击到。
• 其次反向代理可以让服务节点更加专注于业务，一些 HTTPS、压缩等于业务无关的能力可以交由反向代理服务器去实现，从而避免浪费业务服务节点处理请求的能力。
• 最后反向代理服务器能够提供额外的缓存机制，将一些短时间内不会变化的动态内容储存在缓存中，降低业务服务器的请求量；

正是由于 NGINX 引入了反向代理的特性，让请求和响应都要经过 NGINX，因此也给 NGINX 带来了诸如负载均衡、HTTP 缓存等能力。

3、负载均衡

“准备超越当前 ADC 的功能了吗？”这是在 NGINX 官网负载均衡功能介绍页面非常醒目的一句话，这无疑显示了 NGINX 在这方面的雄厚实力与决心。负载均衡就是将请求“均衡”地分配到多台业务节点服务器上。这里的“均衡”是依据实际场景和业务需要而定的。对于 NGINX 来说，请求到达 NGINX，NGINX 作为反向代理服务器，有绝对的决策权，可以按照规则将请求分配给它知道的节点中的一个，通过这种分配，使得所有节点需要处理的请求量处于相对平均的状态，从而实现负载均衡。

4、HTTP 缓存

浏览器缓存是前端开发中经常遇到的问题，它是提升性能同时减少服务器压力的有效手段之一。NGINX 可以作为静态页面的 web 服务器，同时还支持 CGI 协议的动态语言，比如 perl、PHP 等。

而综合上述总结的几点 NGINX 优势，NGINX 无疑是最合适的那个打造高性能平台的工具。然而虽然它很火，但往往流行程度和开发者的掌握程度是不相等的。尤其是在众多业务转型线上，越来越多的企业认识到 NGINX 对于业务支撑的重要性，作为开发者，掌握 NGINX 开发能力似乎已经成为了“必修课”。

然而开发者在应用 NGINX 的过程中往往会遇到各种问题，国内 NGINX 技术专家陶辉曾经总结过，大多数人使用 NGINX 都停留在这几个级别：

• 第一种：使用 NGINX 配置最简单的反向代理服务或者静态资源服务，当扩展功能时发现新增的指令 NGINX 不支持，但又不懂如何增加 NGINX 模块，如何分析 access 日志。
• 第二种：可以根据源码定制安装 NGINX，对网上流传的大众配置做一些个性化的修改，但遇到修改 proxy_pass 后的 URL 上游服务不正常等问题时就束手无策，不清楚 NGINX 各个目录的意义，也不清楚 NGINX 的进程结构。
• 第三种：能够顺畅地使用 NGINX 的常用功能，但不清楚第三方模块发生冲突时的解决方案、stale 过期缓存的用法、NGINX 诸多变量是如何被赋值的、听说 if 指令是邪恶的却不知道它的设计理念及正确用法等等。
• 第四种：可以正确地使用 NGINX 的功能及第三方模块，并按照网络上常见的优化参数优化性能，但对如何系统化地优化性能没有头绪，对于 NGINX、Linux 提供的内存缓冲区、网络类等诸多指令和参数的优化没有头绪。
• 第五种：可以熟练使用 NGINX，但对各第三方功能模块如何与 NGINX 结合使用以及对 NGINX 性能影响不太清楚，对 NGINX 源码的理解没有达到由点到面的程度。