共计 7390 个字符,预计需要花费 19 分钟才能阅读完成。
有的时候博客内容会有变动,首发博客是最新的,其余博客地址可能会未同步, 认准
https://blog.zysicyj.top
首发博客地址
文章更新打算
系列文章地址
Nginx 的三个次要利用场景
动态资源服务通过本地文件系统提供服务
动态资源服务是指通过本地文件系统提供动态文件(如 HTML、CSS、JavaScript、图片等)的服务。这种服务通常由 Web 服务器来提供,比方 Nginx、Apache 等。
动态资源服务的实现原理很简略,当客户端申请动态资源时,服务器会依据申请的 URL 门路找到对应的文件,并将文件内容返回给客户端。这个过程不须要进行动静解决,因而能够进步服务的性能和响应速度。
在 Nginx 中配置动态资源服务非常简单,只须要在配置文件中指定动态资源的根目录即可。例如,以下是一个简略的 Nginx 配置示例:
server {
listen 80;
server_name example.com;
root /path/to/static/files;
location / {try_files $uri $uri/ =404;}
}
上述配置中,root
指定了动态资源的根目录,location /
示意所有申请都会被该配置块解决。try_files
指令用于尝试查找申请的文件,如果找到则返回文件内容,否则返回 404 谬误。
反向代理服务
反向代理是一种服务器架构模式,它将客户端的申请转发给后端的多个服务器进行解决,并将处理结果返回给客户端。与正向代理不同,反向代理是对服务器端的资源进行代理,客户端并不知道申请的资源实际上是由哪个服务器提供的。
反向代理的次要作用是负载平衡和进步零碎的可靠性和安全性。通过将申请分发给多个后端服务器,能够平衡服务器的负载,进步零碎的并发解决能力。同时,反向代理还能够暗藏后端服务器的实在 IP 地址,减少零碎的安全性。
Nginx 是一款罕用的反向代理服务器,它具备高性能、高并发解决能力和灵便的配置选项。在 Nginx 中配置反向代理非常简单,只须要在配置文件中指定后端服务器的地址即可。以下是一个简略的 Nginx 反向代理配置示例:
server {
listen 80;
server_name example.com;
location / {proxy_pass http://backend_server;}
}
上述配置中,proxy_pass
指令用于指定后端服务器的地址,能够是 IP 地址或域名。当客户端发送申请时,Nginx 会将申请转发给后端服务器,并将后端服务器的响应返回给客户端。
缓存
Nginx 具备弱小的性能缓存性能,能够无效进步网站的访问速度和性能。Nginx 的性能缓存次要包含两个方面:动态文件缓存和反向代理缓存。
动态文件缓存是指将动态文件(如 HTML、CSS、JavaScript、图片等)缓存到内存中,当客户端申请这些文件时,间接从缓存中返回,而不须要再次读取文件。这样能够大大减少文件的读取工夫,进步网站的响应速度。
反向代理缓存是指将后端服务器的响应后果缓存到内存中,当客户端发送雷同的申请时,间接从缓存中返回响应后果,而不须要再次申请后端服务器。这样能够缩小对后端服务器的拜访压力,进步零碎的并发解决能力。
Nginx 的缓存配置非常灵活,能够依据须要进行配置。能够设置缓存的有效期、缓存的大小、缓存的存储地位等。以下是一个简略的 Nginx 缓存配置示例:
http {
proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m;
server {
listen 80;
server_name example.com;
location / {
proxy_cache my_cache;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_bypass $http_cache_control;
proxy_no_cache $http_pragma $http_authorization;
proxy_pass http://backend_server;
}
}
}
上述配置中,proxy_cache_path
指令用于指定缓存的存储地位和大小。proxy_cache
指令用于启用缓存,proxy_cache_valid
指令用于设置缓存的有效期。proxy_cache_use_stale
指令用于指定在后端服务器不可用时是否应用过期的缓存。proxy_cache_bypass
和 proxy_no_cache
指令用于管制缓存的应用条件。
负载平衡
负载平衡是指将客户端的申请分发给多个服务器进行解决,以达到平衡服务器负载、进步零碎性能和可靠性的目标。负载平衡能够通过多种形式实现,包含硬件负载均衡器、软件负载均衡器和 DNS 负载平衡等。
Nginx 是一款罕用的软件负载均衡器,它具备高性能、高并发解决能力和灵便的配置选项。在 Nginx 中配置负载平衡非常简单,只须要在配置文件中指定后端服务器的地址即可。以下是一个简略的 Nginx 负载平衡配置示例:
http {
upstream backend_servers {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
server {
listen 80;
server_name example.com;
location / {proxy_pass http://backend_servers;}
}
}
上述配置中,upstream
指令用于定义后端服务器的地址,能够是 IP 地址或域名。proxy_pass
指令用于将申请转发给后端服务器。当客户端发送申请时,Nginx 会依据肯定的负载平衡算法抉择一个后端服务器进行解决。
Nginx 反对多种负载平衡算法,包含轮询、IP 哈希、起码连接数等。能够依据理论需要抉择适合的负载平衡算法。
API 服务
API(Application Programming Interface)服务是指通过接口提供的一组性能和服务,用于与其余软件系统进行交互和通信。API 服务通常用于实现不同零碎之间的数据传输和性能调用。
API 服务能够通过多种形式实现,包含 RESTful API、SOAP API、GraphQL 等。其中,RESTful
API 是一种罕用的 API 设计格调,它应用 HTTP 协定进行通信,通过 URL 和 HTTP 办法来示意资源和操作。
在实现 API 服务时,须要思考以下几个方面:
- 接口设计:定义 API 的资源和操作,包含 URL 门路、HTTP 办法、申请参数、响应格局等。
- 受权认证:爱护 API 的安全性,限度只有受权用户能力拜访 API。
- 数据传输:API 服务通常须要与数据库或其余零碎进行数据交互,须要思考数据传输的形式和格局。
- 错误处理:解决 API 申请过程中可能呈现的谬误,返回适合的错误码和错误信息。
在理论开发中,能够应用框架来简化 API 服务的实现。例如,应用 Spring Boot 能够疾速搭建 RESTful API 服务,应用 Express 能够疾速搭建 Node.js
API 服务。
OpenResty
OpenResty 是一个基于 Nginx 的高性能 Web 应用服务器,它将 Nginx 与 Lua 脚本语言集成在一起,提供了弱小的扩大能力和灵便的配置选项。
OpenResty 的次要特点包含:
- 高性能:OpenResty 基于 Nginx,具备高性能和高并发解决能力。
- 扩大能力:OpenResty 应用 Lua 脚本语言作为扩大语言,能够通过编写 Lua 脚本来实现自定义的性能和逻辑。
- 灵便配置:OpenResty 的配置文件采纳 Nginx 的配置语法,能够灵便配置各种性能和选项。
- 动静模块:OpenResty 反对动静加载模块,能够依据须要加载和卸载模块,进步零碎的灵活性和可维护性。
应用 OpenResty 能够实现各种性能,包含反向代理、负载平衡、API 服务、动态资源服务等。通过编写 Lua 脚本,能够实现自定义的性能和逻辑,如访问控制、申请转发、数据处理等。
OpenResty 的装置和配置绝对简略,能够依据官网文档进行操作。在理论开发中,能够依据需要抉择适合的性能和配置选项,编写 Lua 脚本来实现自定义的性能。
Nginx 呈现的历史背景
Nginx 之所以呈现,是因为互联网的数据量快速增长以及互联网的疾速遍及、全球化和物联网的倒退。这些因素导致了对网络服务器的性能和效率要求越来越高。
在过来,Apache 是最罕用的 Web 服务器软件之一。然而,Apache 的架构是基于每个连贯对应一个过程的模型,这种模型在面对大量并发连贯时效率较低。因为摩尔定律的存在,硬件性能一直晋升,但 Apache 的架构并没有跟上硬件性能的倒退。
Nginx 的呈现正是为了解决 Apache 的性能问题。Nginx 采纳了事件驱动的异步非阻塞架构,能够解决大量并发连贯而不会耗费过多的系统资源。它应用大量的线程来解决多个连贯,而不是为每个连贯创立一个过程。这种架构使得 Nginx 在高并发场景下表现出色,可能更好地应答互联网数据量的快速增长。
此外,Nginx 还具备高度可扩展性和灵活性,能够作为反向代理服务器、负载均衡器和动态文件服务器等多种用处。它还反对动静模块的扩大,能够依据理论需要进行性能扩大和定制。
总结来说,Nginx 之所以呈现,是为了满足互联网数据量快速增长和高并发连贯的需要,以及解决 Apache 在解决大量并发连贯时的性能问题。它的异步非阻塞架构和高度可扩展性使得它成为了互联网畛域中十分重要的服务器软件之一。
为什么用 Nginx?
- 高并发,高性能
:Nginx 采纳了事件驱动的异步非阻塞架构,可能解决大量并发连贯,而且在高负载状况下依然可能放弃较低的资源耗费。它的事件驱动模型使得它可能更好地解决并发申请,提供更高的吞吐量和更低的提早。支流的 32 外围 64G 内存的服务器,能够轻松达到数千万并发申请连贯,解决动态资源能够达到一千万的 RPS。 - 可扩展性好:Nginx 的设计使得它非常适合构建可扩大的零碎。它能够作为负载均衡器,将申请散发到多个后端服务器上,从而实现程度扩大。此外,Nginx 还反对动静模块加载,能够依据须要增加或删除模块,不便扩大性能。
- 高可靠性
:Nginx 具备杰出的稳定性和可靠性。它采纳了多过程或多线程的工作模式,每个过程或线程都是独立的,一个过程或线程的解体不会影响其余过程或线程的失常工作。此外,Nginx 还具备主动故障复原和主动重启性能,能够在呈现故障时放弃服务的可用性。 - 热部署:Nginx 反对热部署,即在不进行服务的状况下更新配置文件或模块。这意味着能够在不影响用户拜访的状况下进行系统配置的更改或降级。
- BSD 许可证:Nginx 采纳 BSD 许可证,这意味着它能够收费应用,并且能够自在批改和散发。BSD 许可证还容许将 Nginx 用于商业目标,而无需公开源代码。
综上所述,Nginx 具备高并发、高性能、可扩展性好、高可靠性和热部署等长处,使得它成为构建高性能、牢靠的 Web 应用程序和服务的现实抉择。
Nginx 的组成
- Nginx 二进制可执行文件:这是 Nginx 的外围组件,它是一个独立的可执行文件,负责接管和解决客户端的申请,并将申请转发给后端的服务器。Nginx 的二进制可执行文件通常位于操作系统的可执行文件门路中,比方
/usr/sbin/nginx
。 - Nginx.conf 配置文件:这是 Nginx 的次要配置文件,用于配置 Nginx 服务器的各种参数和行为。Nginx.conf 文件蕴含了全局配置、http 模块配置、server 模块配置等多个局部,能够通过编辑该文件来定制 Nginx 服务器的行为。
- access.log 拜访日志:Nginx 会将每个客户端的申请记录到 access.log 文件中,该文件记录了客户端的 IP 地址、拜访工夫、申请的 URL、HTTP 状态码等信息。通过查看 access.log 文件,能够理解到 Nginx 服务器的拜访状况,对于排查问题和剖析性能十分有帮忙。
- error.log 谬误日志:Nginx 会将服务器的错误信息记录到 error.log 文件中,该文件记录了 Nginx 服务器在解决申请过程中呈现的谬误,比方申请超时、后端服务器连贯失败等。通过查看 error.log 文件,能够及时发现和解决服务器的问题。
除了以上几个组成部分,Nginx 还能够通过加载各种模块来扩大其性能,比方 HTTP 模块、SSL 模块、缓存模块等。这些模块能够通过在 Nginx.conf 配置文件中进行配置和加载。
Nginx 版本
- Nginx 0.1.0:这是 Nginx 的第一个版本,公布于 2004 年 10 月 4 日。这个版本只反对根本的 HTTP 性能。
- Nginx 0.2.0:公布于 2004 年 10 月 10 日,这个版本减少了对 FastCGI 的反对。
- Nginx 0.3.0:公布于 2004 年 10 月 26 日,这个版本减少了对代理服务器的反对。
- Nginx 0.4.0:公布于 2004 年 11 月 9 日,这个版本减少了对 SSL 的反对。
- Nginx 0.5.0:公布于 2005 年 1 月 4 日,这个版本减少了对虚拟主机的反对。
- Nginx 0.6.0:公布于 2006 年 4 月 4 日,这个版本减少了对缓存的反对。
- Nginx 0.7.0:公布于 2008 年 5 月 6 日,这个版本减少了对 HTTP 流的反对。
- Nginx 0.8.0:公布于 2010 年 6 月 8 日,这个版本减少了对异步文件 IO 的反对。
- Nginx 1.0.0:公布于 2011 年 4 月 12 日,这个版本是 Nginx 的第一个稳固版本。
- Nginx 1.2.0:公布于 2012 年 4 月 24 日,这个版本减少了对 IPv6 的反对。
- Nginx 1.4.0:公布于 2013 年 4 月 24 日,这个版本减少了对 SPDY 的反对。
- Nginx 1.6.0:公布于 2014 年 4 月 24 日,这个版本减少了对 HTTP/1.1 的反对。
- Nginx 1.8.0:公布于 2015 年 4 月 21 日,这个版本减少了对 HTTP/ 2 的反对。
- Nginx 1.10.0:公布于 2016 年 4 月 26 日,这个版本减少了对 TLS SNI 的反对。
- Nginx 1.12.0:公布于 2017 年 4 月 12 日,这个版本减少了对 TLS 1.3 的反对。
- Nginx 1.14.0:公布于 2018 年 4 月 17 日,这个版本减少了对动静模块的反对。
- Nginx 1.16.0:公布于 2019 年 4 月 23 日,这个版本减少了对 gRPC 的反对。
- Nginx 1.18.0:公布于 2020 年 4 月 21 日,这个版本减少了对 HTTP/ 3 的反对。
- Nginx 1.19.1:公布于 2020 年 7 月 7 日。
- Nginx 1.20.0:公布于 2021 年 4 月 20 日。
- Nginx 1.21.0:公布于 2021 年 7 月 12 日。
- Nginx 1.22.1:公布于 2022 年 5 月 24 日。
Nginx 的版本号由三个数字组成,格局为 主版本号. 次版本号. 订正版本号
。例如,1.18.0 是一个典型的 Nginx 版本号。
- 主版本号:当 Nginx 的次要性能产生重大变动或者有不兼容的改变时,主版本号会减少。这意味着新版本可能须要用户进行一些批改或者配置调整能力失常应用。
- 次版本号:当 Nginx 的性能有较大的加强或者有一些新个性增加时,次版本号会减少。这些新个性通常不会毁坏现有的配置和应用形式。
- 订正版本号:当 Nginx 进行一些谬误修复、性能优化或者其余小的改变时,订正版本号会减少。这些改变通常不会引入新的性能或者毁坏现有的配置。
通常状况下,咱们能够通过查看 Nginx 的版本号来理解其性能和改变状况。比方,如果版本号的主版本号产生了变动,那么可能须要留神一些不兼容的改变;如果版本号的次版本号减少了,那么可能有一些新的性能或者个性能够应用;如果版本号的订正版本号减少了,那么可能有一些谬误修复或者性能优化。
如何抉择 Nginx 版本
-
开源免费版 Nginx:
- 这是最常见的 Nginx 版本,也是最宽泛应用的版本。
- 它是一个高性能的 HTTP 和反向代理服务器,能够用于负载平衡、动态资源缓存、反向代理等场景。
- 开源免费版 Nginx 具备稳定性高、性能优越、配置简略等特点。
- 它提供了丰盛的模块和插件,能够满足大部分的需要。
- 如果你只须要根本的 HTTP 和反向代理性能,并且对商业反对没有特地的需要,那么开源免费版 Nginx 是一个不错的抉择。
-
商业版 Nginx Plus:
- 商业版 Nginx Plus 是由 Nginx 官网提供的增强版 Nginx。
- 它在开源版本的根底上减少了一些高级性能和工具,如负载平衡算法、健康检查、实时监控、高级缓存等。
- 商业版 Nginx Plus 还提供了商业反对和服务,包含技术支持、紧急修复、性能优化等。
- 如果你须要更高级的性能和更牢靠的商业反对,能够思考应用商业版 Nginx Plus。
-
阿里巴巴 Tengine:
- Tengine 是由阿里巴巴团体开发的 Nginx 衍生版本。
- 它在官网骨干版本的根底上进行了一些批改和优化,以适应阿里巴巴的特定需要。
- Tengine 在性能和稳定性方面与官网版本相当,但可能会有一些额定的性能和个性。
- 如果你是阿里巴巴的用户,或者对 Tengine 的特定性能有需要,能够思考应用阿里巴巴 Tengine。
-
OpenResty:
- OpenResty 是一个基于 Nginx 和 Lua 的 Web 应用服务器。
- 它将 Nginx 作为外围,通过 Lua 脚本扩大了 Nginx 的性能,使其能够解决动静申请和业务逻辑。
- OpenResty 实用于须要在 Nginx 上编写简单的业务逻辑的场景,如 API 网关、微服务架构等。
- 如果你须要在 Nginx 上编写简单的业务逻辑,能够思考应用 OpenResty。
综上所述,抉择哪个版本的 Nginx 取决于你的具体需要和应用场景。如果你只须要根本的 HTTP 和反向代理性能,开源免费版 Nginx 是一个不错的抉择。如果你须要更高级的性能和商业反对,能够思考商业版 Nginx
Plus。如果你是阿里巴巴的用户或对 Tengine 的特定性能有需要,能够思考应用阿里巴巴 Tengine。如果你须要在 Nginx 上编写简单的业务逻辑,能够思考应用 OpenResty。
<!– md tj.md –>
本文由 mdnice 多平台公布