云原生时代，18 岁的 NGINX 过时了吗？

如今，全球半数以上（55%） 的网站都基于 NGINX 运行，差不多相同比例 (53.7%) 的中国网站在 NGINX 开源版上运行。作为最受欢迎的网络服务器，NGINX 自发布到现在已经有 18 年了，它现在有什么样的发展规划呢？

近日，NGINX Sprint China 2022 大会于线上举行，F5 NGINX 讲解了 NGINX 在云原生下的产品路线图，宣布推出 NGINX Kubernetes Gateway 以及 MARA 参考架构 1.0 版本，并且 HTTP3 和 QUIC 也将合并到下一个版本中。“如果有人说原先的 NGINX 产品系列已经过时，那我只能说你并没有密切关注我们的动向”，F5 NGINX 总经理 Rob Whiteley 在主题演讲中这样说道。

NGINX 的进化

在数字化技术的推动下，应用现代化正成为产业发展的趋势与共识。F5 中国区软件事业部总经理章澍分享了 NGINX 认为的，从传统应用向现代化应用发展过程中将会历经的三次浪潮：第一次浪潮实现了应用的大规模并发和扩展，而如今正在经历的第二次浪潮，其特征是实现应用解耦为微服务并通过 API 连接。这波浪潮将极大地推动自动化技术的发展，感知可控、随需而变的应用也将应运而生。也就是说，在不远的将来，全世界会迎来以感知可控、无人工干预的自适应应用为标志的第三次浪潮。

NGINX 的诞生

NGINX 于 2004 年推出。在早期的互联网时代，随着 Web 2.0 的兴起，用户数量呈几何级数增长，互联网不再是单纯的浏览 Web 页面，逐渐开始进行交互，应用程序的逻辑也变的更复杂，从简单的表单提交，到即时通信和在线实时互动。这种用户体量的上升以及互动请求的增加，也给服务器带来了压力。

NGINX 的诞生也是为了实现大规模的并发和扩展，相当多的企业看到了 NGINX 的性能优势并开始使用它。 Igor Sysoev 于 2011 年辞去了在 Rambler 的工作，并创立了 NGINX, Inc.。几年后，NGINX Plus 发布了，这是一个带有一些附加功能的版本，并且在商业上取得了巨大的成功。2019 年， NGINX, Inc. 被 F5 Networks 以 6.7 亿美元收购。

NGINX 采用异步模式，且轻量级，采用 C 进行编写，在性能上的出色表现是击败 Apache 网络服务器的关键。但 NGINX 取得成功，却不仅仅是因为 NGINX 是一个网络服务器，它还具备负载均衡器、反向代理、邮件代理和 HTTP 缓存等功能，提供了构建安全、可靠的 Web 应用程序所需的几乎所有方面的能力。

比如，在 2000 年代早期，一台硬件负载均衡服务器动辄从十几万到几十万不等，因此当服务规模不大时，直接采购硬件负载均衡服务器对于很多中小公司并不划算，而通过 Web 服务器的反向代理的方式却是当时比较经济的方式。一般 Web 服务器都有反向代理功能，NGINX 则是其中典型代表。

在此基础上，NGINX 和 NGINX Plus 平台又由多个分散的同类最佳工具组成，当它们串联使用时，可以以各种“风格”进行部署，以满足企业的多种需求，从而成为了市场占有率第一的网络服务器。

云原生时代的 NGINX

如果说互联网的崛起导致应用的大规模并发和扩展，是我们经历的第一次浪潮，那么微服务和容器化的兴起，也可以算作是我们正在经历的第二次浪潮。

在第二波浪潮下，企业更关注于 Kubernetes 和容器的部署，但 Kubernetes 缺乏生产环境中的应用所需的应用交付、可观察性以及安全防护功能，因此一个好的生产级 Kubernetes 平台需要进行深思熟虑的定制和调整。

NGINX 2021 年的社区调查显示，2/3 的人都已经或打算在生产环境中使用 Kubernetes，但是都有着对于自身知识技能以及对于 Kubernetes 的复杂性、安全防护和扩展性的担忧。为了构建坚实的 Kubernetes 基础，NGINX 通过添加 Ingress controller、WAF、服务网格以及一些其他云原生项目，提供了云原生的、Kubernetes 友好的开源和商业解决方案，来提升应用程序的扩展性、可见性、安全性......

另一方面，微服务和应用的数量在快速增长，微服务之间以及集群内外之间的 API 数量也不断增加。一般来说，微服务之间的内部 API 调用次数通常是应用到客户端之间的外部 API 调用次数的 10 倍或者更多。随着应用环境的扩张，复杂的环境可能有成百上千个 API，更复杂的 API 身份验证、授权、路由、整形和生命周期管理等问题就会随之而来，所以在云原生时代，网关功能更为重要。

NGINX 提供了 API Gateway、Ingress Controller、Service Mesh多种选择。其中，作为被普遍使用的反向代理工具，基于 NGINX 实现的 NGINX Ingress 也成为了 Kubernetes 集群中最广泛使用的 Ingress 网关。目前 NGINX Ingress 主要有两个版本，其中一个是 Kubernetes 社区所开发和维护的 NGINX Ingress Controller (kubernetes/ingress-NGINX)。而 F5 NGINX 也开发和维护了 NGINX Ingress Controller (NGINXinc/kubernetes-ingress)，在数据平面上添加一些高级功能或商业支持。

然而，开源版本和 NGINX 维护的版本之间存在一定差异，这也让用户感到困惑。为了消除这种困惑，NGINX 基于 Kubernetes API Gateway SIG 参考架构，于今年早些时候推出了 NGINX Kubernetes Gateway。NGINX Kubernetes Gateway 由 Ingress controller 发展而来，是一种基于 Gateway API 规范内测版的新兴技术。Gateway API 终将取代 Kubernetes 架构中的 Ingress Controller，为了与云原生趋势保持一致，NGINX 表示已决定将之前仅在开源版本中提供的 NGINX Kubernetes Gateway 作为下阶段的 Kubernetes 网络开发重点。

现代应用参考架构 MARA

云原生基础设施和基于微服务的设计，能够高容错、松耦合，使得开发可快速迭代，让企业可以用敏捷的方式支持数字化转型。然而利用云原生构建现代化应用并不容易，“部署 Kubernetes 有很多不同的方法——网络、安全、身份验证，甚至像 API 网关这样的东西。对于大多数刚起步的企业来说，这还是比较复杂。” F5 NGINX 总经理Rob Whiteley在接受媒体采访时曾说。“如果没有很好地理解，很容易陷入错误的配置状态。”

“我们意识到，我们可以制作一个模版作为企业参考架构：给出真正的操作代码，而不是纸上的概念。”Whiteley 说。因此，MARA 诞生了。这种思路类似于构建一个“黄金镜像”，让用户从列表中自动拉取、组装和预集成所有脚本，然后通过一个命令进行部署。并且 F5 希望开发人员只需单击几下就能够在几分钟内配置和部署好一个 Kubernetes 环境，形成一个完整并稳定可靠的开发环境。

总之，MARA 是一个悉心设计的“稳定可靠、经过测试且可以部署到在 Kubernetes 环境中运行的实时生产应用”解决方案。该模块化架构集成了创建生产级云原生环境所需的一切——安全性、日志记录、网络、应用服务器、配置和 YAML 管理等。

即使平台能够集成所有这些功能，但要完全满足生产环境要求还需要更多的工作。经过不断实验并探索如何帮助核心开发人员更高效、更轻松地部署现代应用，NGINX 在去年的 Sprint 大会上宣布推出了 MARA参考架构，一个现代应用的开源架构和部署模型。在今年的 NGINX Sprint 上，Rob Whiteley 也在主题演讲中宣布了即将推出 MARA 1.0版本。

在发布时，MARA 预配置了多种选择，使用Elastic进行日志管理，使用Prometheus和Grafana进行监控和仪表板，使用Amazon Web Services的Elastic Kubernetes Service (EKS) 作为部署目标，使用Spinnaker进行持续交付，以及 TLS的证书管理器，以及中间层的许多 NGINX 产品。

另外，微服务相对单体服务，其故障定位难度完全不是一个等级，因此要使微服务监控和可观察性更上一层楼，就需要引入优秀的 APM 系统。CNCF 管理的 OpenTelemetry 项目 （由 OpenTracing 和 OpenCensus 合并而成），它以一种综合的方式生成追踪、日志和指标，也成为了目前服务监控可观察性统一方案。MARA 1.0 版本也选择了集成OpenTelemetry，实现日分布式跟踪、指标收集等功能，这也是1.0版本中的一个重要变化。

NGINX 的开源演进：兼顾稳定和高性能

NGINX 作为纯 C 实现的软件，源码质量很高。创始人Igor Sysoev最开始也只专注于解决 C10K 问题，并一个人写了几乎所有的代码，独自管理到 2011 年。

2017 年，当时的 NGINX 首席执行官接受媒体采访时介绍说，这个轻量级软件，核心代码一直少于 200,000 行。同时，开源版本依赖很少，仅有非常少的库，如 Openssl、glib。这也是它高性能的原因之一。“性能为王”是它击败 Apache 网络服务器的原因，其模块化机制也始终可以让 NGINX 关注于可以为工程师提供“灵活度”，这也是让它在 Web 网关服务器领域中一直领先地位的原因。

但云原生的到来正在改变 API 网关的角色，也给 NGINX 带来了新的挑战。很多其他 API 网关解决方案都是基于 NGINX 搭建的，比如开源和商用的 Kong API 网关以及开源的 OpenResty 等，这些软件在敏捷开发行业很火。

虽然这进一步验证了 NGINX 核心技术在这个领域的可用性，但也让人们思考 NGINX 在云原生技术下的优势。但相对来讲，NGINX 使用 C 语言，代码空间封闭；而新兴的一些软件使用 Lua，虽然可以随时编写功能插件，但通过解析 String 并立即返回调用函数，这样导致其代码空间是完全开放的。所以从这一点来说，NGINX 的设计更加安全稳定。而传统行业也比一些敏捷行业更注重安全稳定的性能，所以 NGINX 仍然是传统行业的首选。就像 Rob Whiteley 在主题演讲中提到的那样，“开源安全性是开发人员的首要考虑事项”。

他表示，“数以千计的企业正在生产环境中运行 NGINX 开源软件——这是一件好事，因为这充分表明了公司们对我们开源版本的高度信任，我们将带着这份信任再接再厉。对于核心 NGINX 开源版软件，我们一直在不断添加新特性和功能，并支持更多操作系统平台。在即将发布的下个版本中，我们将通过 HTTP3 和 QUIC 这两大功能来保障 Web 应用以及流量的安全性和可扩展性。”

在 NGINX 的设计中，后端服务以静态配置文件的形式记录，里面使用了一些优化过的静态哈希表设计，因此性能也非常好。但在微服务时代，后端服务的 IP 发生变化的时候，都需更改配置文件，静态配置的方式也给网关实现“连接复用”增加了难度，而基于 UDP 的 HTTP3 和 QUIC 协议则可以实现跨 IP 迁移。各种网络技术实际上早已经成熟，但 NGINX 更多考虑的是稳定性，因此在 QUIC 第一份规范草案提交给 IETF 的五年之后，NGINX 才选择合并 QUIC 到当前版本中。

这同时说明 NGINX 也一直在跟进网络世界的重大变化。例如，NGINX 于 2015 年 9 月开始支持 HTTP/2，距协议修订标准化仅几个月。HTTP/2 服务器推送支持也于 2018 年推出，现在 HTTP /3 和 QUIC 也终于要实现到 NGINX 中。

在开源崛起和迈向成功的过程中，NGINX 在这一二十年里发挥了至关重要的作用。现在，通过 NGINX 在云原生领域的重大发布，我们也可以看出 NGINX 一直在努力提升自身的竞争力，用 Rob Whiteley 的话来说，就是“NGINX 要想十年后还能广受欢迎，就需要不断做出改进......对自己的开源工作反躬自省，跟上开源运动的持续发展。”

参考链接：

https://www.NGINX-cn.net/blog/future-of-NGINX-getting-back-to-open-source-roots/

https://www.NGINX-cn.net/blog/5-things-to-know-about-NGINX-kubernetes-gateway/

https://www.bilibili.com/video/BV1wh41187De/

https://thenewstack.io/NGINXs-reference-architecture-for-kubernetes-microservices/

https://mp.weixin.qq.com/s/UPaA6uRTVn2Nu2qJKA9soQ

https://www.NGINX.com/blog/our-roadmap-quic-http-3-support-NGINX/