作者 | Tina

现如今，全球超过一半（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 认为的，从传统应用领域向现代应用领域产业发展桑利县会经过的四次大潮：第一次大潮同时实现了应用领域的小规模mammalian和扩充，而现如今正在经历的第二次大潮，其特征是同时实现应用领域解耦为微服务并通过 API 连接。这波大潮将极大地促进智能化控制技术的产业发展，可视化受控、随需而变的应用领域也将不断涌现。也就是说，在不远的将来，全世界会迎来以可视化受控、无芒翁的自适应应用领域为标志的第二次大潮。

NGINX 的问世

NGINX 于 2004 年面世。在早期的网络黄金时代，随着 Web 2.0 的兴起，用户数呈阶乘增长，网络不再是单纯的下载 Web 网页，逐渐已经开始展开可视化，应用领域程序的逻辑也变的更复杂，从简单的配置文件提交，到即刻通信和新浪网动态可视化。这种用户规模的上升和可视化允诺的增加，也给伺服器带来了压力。

NGINX 的问世也是为了同时实现小规模的mammalian和扩充，相当多的企业看到了 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

如果说网络的崛起导致应用领域的小规模mammalian和扩充，是我们经历的第一次大潮，那么微服务和容器化的兴起，也可以算作是我们正在经历的第二次大潮。

在第二波大潮下，企业更关注于 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 (

然而，开放源码版和 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/