实现高性能负载均衡的进阶实操指南

经典书籍《NGINX 完全指南》中文版全新再版

这本由 O'Reilly 出版的电子书涵盖了最新的 NGINX 操作指南和使用技巧，是 NGINX 学习及实操的必备指南。新版不仅扩充更新了已有章节，还添加了不少前沿的热门话题。

本书是由中文官方网站推荐，免费下载的电子书籍，大家有兴趣的可以到官方地址下载获取，或者私信我获取。

中文官方网站：https://www.nginx-cn.net/

NGINX 是当今使用最广泛的 Web 服务器之一，部分原因在于它可以用作 HTTP 和其他网络协议的负载均衡器和反向代理服务器。本修订版完全指南通过一些简单易懂的例子解析了应用交付中真实存在的问题。实用的实操指南可帮助您设置开源或商业产品，并利用它们解决各种用例中的问题。

对于了解现代 Web 架构（例如 n 层或微服务设计以及 TCP和 HTTP 等常见 Web 协议）的专业人士来说，本书的这些实操指南为安全和软件负载均衡以及 NGINX 应用交付平台的监控和维护提供了经过验证的解决方案。您还将了解到免费的 NGINX 开源版以及许可授权版 NGINX Plus 的高级功能。

您将获取以下方面的实操指南：

? HTTP、TCP 和 UDP 高性能负载均衡

? 通过加密流量、安全链接、HTTP 身份验证子请求等保护访问

? 将 NGINX 部署到 Google、亚马逊云科技（AWS）和Azure 云服务

? 将 NGINX Plus 配置为 SAML 环境中的服务提供商

? HTTP/3（QUIC）、OpenTelemetry 和 njs 模块

关于作者

Derek DeJonghe 对技术充满热情。他在 Web 开发、系统管理和网络方面拥有扎实的专业背景和丰富的行业经验，对现代 Web 架构有着全面的了解。Derek 领导了一支站点可靠性和云解决方案工程师团队，在一家专业咨询集团工作了十年，创建了可自我修复的自动扩展基础架构。

他目前正专注于筹建一个专用孵化器，以帮助初创企业启用云环境和开发工具。Derek利用自己在云技术和开发方面的丰富领导经验，帮助初创企业制定上市战略，并助力其团队成员研发未来技术。Derek 在弹性云架构方面成绩卓著，革新了云部署安全性和可维护性，可充分满足客户需求。

本指南涵盖15个章节，内容如下图所示

第1章 基础知识

无论是 NGINX 开源版还是 NGINX Plus，您都要先在系统上安装它们并学习一些基础知识。在本章中，您将学习如何安装 NGINX、主要配置文件位于何处以及管理命令是什么，还将了解如何验证您的安装并向默认服务器发出请求。

第2章 高性能负载均衡

如今的互联网用户体验离不开出色的性能和正常运行时间。为此，企业需要运行多个相同的副本，并将负载分散在整个系统集群上。随着负载的增加，集群内会引入新的副本。这种架构技术称为“水平扩展”。基于软件的基础架构因其灵活性而愈发受欢迎，并创造了更多的可能性。无论是仅有两个系统副本组成的高可用性方案，还是全球范围内成千上万个系统构成的大型集群，它们都需要一款像基础架构一样动态的负载均衡解决方案。NGINX 能够以多种方式满足这一需求，例如 HTTP、传输控制协议（TCP）和用户数据报协议（UDP）负载均衡，本章将会对这些内容进行详细介绍。

在实施负载均衡时，必须要保证对客户体验产生完全正向的影响。许多现代 Web 架构采用无状态应用层，将状态存储在共享内存或数据库中。但是并非所有架构都是如此。会话状态不仅蕴含着重大价值，而且在交互式应用中得以广泛使用。出于多种原因 ——例如在需要处理大量数据的应用中，为了避免性能方面的高昂网络开销，这个状态可能就会存储到本地的应用服务器上。在这种情况下，后续的请求会被继续交付到同一台服务器，这对保障用户体验极其重要。与此同时，在会话完成之前，服务器不会得到释放。大规模使用有状态应用需要智能负载均衡器。NGINX 提供了多种跟踪 cookie 或路由的办法来解决这一问题。本章介绍了会话保持，因为它与 NGINX 的负载均衡有关。

确保 NGINX 所服务的应用的健康状态十分重要。出于多种原因，上游（upstream）请求可能会失败，例如由于网络连接不佳、服务器故障或应用故障等等。代理和负载均衡器必须足够智能，以检测上游服务器（负载均衡器或代理后面的服务器）的故障，并停止向它们传输流量；否则客户端只能等待，最终超时。

当服务器出现故障时，一种避免服务降级的方法是让代理检查上游服务器的健康状况。NGINX 提供了两种不同类型的健康检查方法：被动式（NGINX 开源版提供）和主动式（仅 NGINX Plus 提供）。定期执行的主动健康检查会与上游服务器建立连接或向其发送请求，并且验证响应是否正确。被动健康检查能够在客户端发出请求或建立连接时监控上游服务器的连接或响应。您可能希望使用被动健康检查来减少上游服务器的负载，并使用主动健康检查确定上游服务器的故障，以免引发客户端服务失败。本章最后探讨了如何监控正在实施负载均衡的上游应用服务器的健康状况。

第3章 流量管理

NGINX 也属于 Web 流量控制器。您可以使用 NGINX 智能地路由流量，并根据多个属性控制流量。本章介绍了 NGINX 的多项功能，包括：按比例分配客户端请求；利用客户端的地理位置；通过速率、连接和带宽限制控制流量。阅读时请注意，您可以混合搭配这些功能来解锁更多可能。

第4章 大规模可扩展的内容缓存

缓存能够存储响应结果，以供未来再次使用，进而加速内容的提供。通过从缓存中提供内容，NGINX 可卸载上游（upstream）服务器的高开销、重复性工作，从而减少其负载。缓存可以提高性能并减少负载，这意味着您可以用更少的资源更快地提供服务。缓存还能减少提供资源所需的时间和带宽。

缓存服务器在战略位置上的扩展和分布会对用户体验产生巨大影响。最好将内容托管在靠近消费者的地方，这有助于释放最高性能。您还可以在靠近用户的地方缓存内容，内容交付网络（CDN）就采用了这种模式。NGINX 允许您在放置 NGINX 服务器的任何地方缓存内容，从而有效创建自己的 CDN。借助 NGINX 缓存，您还可以在上游（upstream）发生故障时被动地缓存并提供缓存的响应。缓存功能仅在 http 上下文中可用。本章将介绍 NGINX 的缓存和内容交付功能。

第5章 可编程性和自动化

可编程性是指通过编程进行交互的能力。NGINX Plus 的 API 可以帮助实现这一点，即通过 HTTP 接口与 NGINX Plus 的配置和行为进行交互。该 API 支持通过 HTTP 请求添加或删除上游（upstream）服务器，从而实现对 NGINX Plus 的重新配置。NGINXPlus 中的键值（key-value）存储功能支持其他级别的动态配置 —— 您可以利用 HTTP调用注入 NGINX Plus 动态路由或控制流量所需的信息。本章将探讨 NGINX Plus API以及通过该 API 暴露的键值存储模块。

配置管理工具能够实现服务器的自动化安装和配置，这在云时代是非常宝贵的实用程序。通过使用这些工具，大型 Web 应用的工程师不必再手动配置服务器，只需一次性写好配置和代码，就能够以可重复、可测试和模块化的方式构建出许多具有相同配置的服务器。本章介绍了当前市面上最受欢迎的一些配置管理工具，并讨论了如何使用它们安装 NGINX 以及如何将基本配置模板化。其中有一些很基础的例子，但却很好地演示了如何在每个平台上启用 NGINX 服务器。

第6章 身份验证

NGINX 能够对客户端进行身份验证。使用 NGINX 对客户端请求进行身份验证可以减轻服务器的工作负载，并能够阻止未经身份验证的请求到达应用服务器。NGINX 开源版模块包括基本身份验证和身份验证子请求。NGINX Plus 专有的 JSON Web Token（JWT）验证模块可与使用身份验证标准 OpenID Connect 的第三方身份验证提供商集成。本章介绍了结合使用 NGINX 与身份验证来保护资源的多种方法。

第7章 安全控制

安全性必须要分层实施，因此您的安全模型必须要有多个层面才能真正得到强化。本章介绍了通过 NGINX 保护 Web 应用安全的许多不同方法。您可以将这些安全防护方法结合使用来增强安全性。

您可能会注意到，本章没有涉及将 NGINX 用作 Web 应用防火墙（WAF）的ModSecurity 3.0 NGINX 模块。如欲了解 WAF 功能的更多信息，请参阅《为 NGINX开源版编译和安装 ModSecurity》。

第8章 HTTP/2 和 HTTP/3（QUIC）

HTTP/2 和 HTTP/3 是 HTTP 协议的主要修订版。这两个修订版旨在解决被称为“队头阻塞”的性能问题，该问题会导致网络数据包因等待排在其前面的数据包完成处理而受阻。HTTP/2 通过在单个 TCP 连接上启用完整的请求和响应多路复用，缓解了应用层中初始 TCP 握手的队头阻塞问题。但 TCP 协议本身仍存在这个问题，因为其丢包恢复机制要求按顺序传输数据包，丢失的数据包必须重传后才能继续进行，故而会造成阻塞。HTTP/3 将 TCP 更换为了基于用户数据报协议（UDP）而构建的 QUIC（与“quick”同音）协议。UDP 不需要连接握手、传输排序或实施丢包恢复，因此 QUIC能够更高效地解决这些传输问题。

HTTP/2 还引入了 HTTP 请求头字段压缩技术，并添加了请求优先级支持。本章详细介绍了在 NGINX 中启用 HTTP/2 和 HTTP/3 的基本配置，以及如何配置 Google opensource Remote Procedure Call（gRPC）。

第9章 复杂的媒体串流

本章涵盖了 MPEG-4（MP4）或 Flash Video（FLV）格式的 NGINX 的流媒体。NGINX 被广泛用于向大众分发和串流内容。NGINX 支持行业标准格式和串流技术，本章将对此展开介绍。NGINX Plus 可通过 HTTP Live Streaming（HLS）模块动态分割内容，及提供已分段媒体的 HTTP Dynamic Streaming（HDS）。NGINX 具有原生的带宽限制功能，并且 NGINX Plus 的高级功能提供了比特率限制，能够以最有效的方式交付内容，同时以最少的服务器资源触及最多用户。

第10章 云部署

云提供商的出现改变了 Web 应用托管的现状。过去，配置新机器等流程通常需要花费数小时到几个月的时间，如今，只需点击或调用 API 就能创建一个流程。这些云提供商通过按使用付费（即用即付）的模式租赁虚拟机（称为基础架构即服务（IaaS））或托管软件解决方案。工程师可以构建整个测试环境，并在不需要时将其拆除。这些云提供商还支持应用根据性能需求即时实现水平扩展。本章介绍了 NGINX 在几个主要云提供商平台上的基本部署。

第11章 容器 / 微服务

容器在应用层提供了一层抽象，将软件包和依赖项的安装从部署流程转移到了构建流程。这点很重要，因为工程师现在发布的代码单元无论在何种环境中都以统一方式运行和部署。作为可运行单元提供的容器可降低环境之间发生依赖项和配置混乱的风险。考虑到这一点，组织都迫切希望将应用部署到容器平台上。在容器平台上运行应用时，通常会尽可能地将堆栈（包括代理或负载均衡器）容器化。NGINX 可以很容易的容器化。它还包含许多有助于容器化应用交付的特性。本章将重点介绍 NGINX 容器镜像的构建，有助于在容器化环境中运行的特性，以及 Kubernetes 和 OpenShift 之上的镜像部署。

在进行容器化时，通常的做法是将服务分解到多个较小的应用中，然后再通过 API 网关将分解的服务连接起来。本章介绍了使用 NGINX 作为 API 网关，对请求进行保护、校验、身份验证并将请求路由到适当服务的常见用例场景。在容器中运行 NGINX 时，应留意几个架构注意事项。当将服务容器化，使用 Docker日志驱动程序时，必须将日志输出到 /dev/stdout 并将错误日志定向到 /dev/stderr。通过这样做，您可以将日志传输到 Docker 日志驱动程序，Docker 驱动程序则能够将日志路由到本地合并日志服务器。

在容器化环境中使用 NGINX Plus 时，还需要考虑负载均衡算法。least_time 负载均衡算法专为容器化网络叠加层而设计。NGINX Plus 偏爱较短的响应时间，会将传入请求传递给平均响应时间最短的上游服务器。当所有服务器经过充分的负载均衡，在等量负载下运行后，NGINX Plus 可通过优选最近网络上的服务器，降低网络延迟。

第12章 高可用性部署模式

容错架构将系统分成多个相同的独立堆栈。使用 NGINX 等负载均衡器来分发负载，以优化配置。高可用性的核心理念是在多个活跃节点上进行负载均衡或 active-passive 故障转移。高可用性应用不会出现单点故障；每个组件，包括负载均衡器本身，都必须应用上述其中一种理念。对我们来说，这就意味着对 NGINX 实现高可用。NGINX 经专门设计，可配置为 active-active 或 active-passive 故障转移模式。本章详细介绍了如何运行多台 NGINX 服务器以确保负载均衡层的高可用性。

第13章 高级活动监控

为了确保应用以最佳性能和精度运行，您需要清晰地了解有关其活动的监控指标。NGINX 提供了多种监控选项，例如 stub 状态或高级监控仪表盘以及 NGINX Plus 中的JSON feed。NGINX Plus 活动监控提供有关请求、上游服务器池、高速缓存、健康状态等的洞察。通过使用 OpenTelemetry，还可进一步实现应用集成可观测性。本章详细介绍了使用 NGINX 进行监控的功能及其所带来的可能性。

第14章 利用访问日志、错误日志和请求跟踪进行调试和故障排除

日志记录是了解应用的基础。使用 NGINX 您可有效控制对您和您的应用有意义的日志信息。NGINX 允许您根据不同的上下文将日志以不同的格式拆分到不同的文件中，并更改错误日志的日志级别，以更深入地了解当前状况。NGINX 支持对接 Syslog，天生就具备了将日志以流的形式输出给集中式日志服务器的能力。NGINX 还支持为请求发起全链路跟踪。在本章中，我们将介绍访问和错误日志，基于 Syslog 协议的流式传输，以及利用 NGINX 所生成的请求标识符的实现端到端请求跟踪。

第15章 性能调优

NGINX 调优是一种艺术。无论何种类型的服务器或应用，其性能调优都取决于许多可变项，包括但不限于环境、用例、需求和相关物理组件。瓶颈驱动型性能调优十分常见，意指遇到瓶颈后才进行测试，确定瓶颈，改进限制，并不断重复，直至满足性能需求。在本章中，我们建议在进行系统调优时，使用自动化工具进行测试，并收集和衡量测试结果。本章还介绍了如何通过连接调优保持客户端和上游服务器的长连接，以及如何通过优化操作系统调优满足更多并发连接需求。

书末题署

《NGINX 完全指南》封面上的动物是欧亚猞猁（Lynx lynx），是最大的猞猁物种，分布范围广泛，从西欧延伸到中亚。猞猁的耳尖生有黑色耸立簇毛，两颊毛发浓密而粗糙。皮毛颜色从黄灰色到灰褐色，腹部为白色。这只猞猁通身布满黑斑，与南部地区的亚种相比，北部地区的亚种更灰白，斑点更少。

与其他猞猁物种不同，欧亚猞猁捕食较大的有蹄类动物，例如鹿、麋，甚至是驯养的绵羊。成年猞猁每天消耗两到五磅肉，可长达一周食用单一食物。欧亚猞猁在二十世纪中叶濒临灭绝，后来经过坚持不懈的保护，降级为无危物种。

O'Reilly 封面上的许多动物都濒临灭绝，但对世界意义重大。

封面插画由 Karen Montgomery 参考 Shaw 著作《Zoology（动物学）》中的黑白版画绘制而成。该系列由 Edie Freedman、Ellie Volckhausen 和 Karen Montgomery 共同设计。封面字体为微软雅黑系列字体，Neusa Next Std Bold 和 Arial 粗体。正文字体为微软雅黑和 Arial 字体，标题字体为微软雅黑粗体，Proxima Nova 粗体和 Arial 粗体，代码字体为 Dalton Maag's Ubuntu Mono。