NGINX Sprint 2.0：清晰的愿景、新出炉的代码、全新的开源承诺

我们每年都会在 NGINX Sprint 大会上分享我们最出色的新技术，这是一年中最令人兴奋的时刻！我们发布我们创建的新代码和产品版本，努力让我们的社区和客户的日常生活变得更加美好。虽然今年稍有不同，但依然会有新的项目和产品亮相。具体内容我将在后面进行介绍。我必须在这里阐述一下引领我们前行的愿景，最重要的是，这一愿景如何激励我们对社区做出一系列承诺。

F5 的愿景是打造感知可控、随需而变的应用。什么是“感知可控、随需而变的应用”？我们将应用想象成一个生物体，它们能够自主扩展、缩小、自我修复和防御，帮助减少对持续人工干预的需求。

我强调“自主”一词是有原因的。随着新一代数字服务的诞生，底层应用必须摆脱人工操作的速度限制。它们必须足够智能才能根据上下文和条件适应环境。它们必须自己做出改变，就像生物体一样。

我们正在探索如何让机器学习支持自适应智能。但罗马不是一日建成的，我们还要付出很多努力。以下是我们对感知可控、随需而变的应用发展道路的设想，以及通过技术发布和产品路线图来实现愿景的思路。

我们认为现代应用交付领域将经历三次浪潮。第一次浪潮主要是实现大规模并发和扩展。NGINX 便问世于这次浪潮中，为 Web 级应用的兴起而生。

第二次浪潮（也就是我们正在经历的浪潮）是应用解耦为微服务并通过 API 进行连接，以加深分布式程度和提高弹性。Kubernetes 和容器化是这次浪潮的主要推动力量，最初随着云计算的增长而崭露头角。这波浪潮还极大地推动了自动化技术的发展，第一代感知可控、随需而变的应用应运而生。自适应行为既可以像自动扩展一样简单，也可以像策略引擎一样复杂，其中策略引擎通过观察 API 和应用的执行方式进行自我纠正。

第二次浪潮为第三次波浪潮奠定了基础。第三次浪潮将赋予应用更高级的智能性和机器学习能力，让它们能够感知环境，并真正实现无人工干预的自适应。

随着第二次浪潮的推进，我们在 NGINX 用户和已在 Kubernetes 集群中成功部署现代应用的客户中看到了一种通用模式。我们将这种模式称为 Cluster Out，它共分为三个阶段，如下图所示。

第一阶段：构建坚实的 Kubernetes 基础

许多企业仍在紧锣密鼓地部署 Kubernetes 和容器。其实，一个好的生产级 Kubernetes 平台，需要进行深思熟虑的定制和调整。尽管 Kubernetes 是一款强大的多用例通用平台，但开箱即用的特性还是导致它缺乏部署、管理和保护生产应用所需的应用交付和应用安全功能。

最重要的是，如果 Kubernetes 生产环境不稳定，开发人员就不愿意在这里部署代码。为了增强开发人员的信心，您必须为 Kubernetes 生产环境添加七层网络、可观察性和安全性。您可以通过 Ingress 控制器、WAF 和服务网格，并结合其他云原生项目（例如 Prometheus）来解决这一挑战。

第二阶段：安全地管理集群内外的 API

只要您拥有优秀的生产级 Kubernetes 环境，开发人员就愿意在这里部署更多代码。这就是我们常说的“栽下梧桐树，引得凤凰来”。您会发现，微服务和应用的数量正在快速增长，它们与集群内的其他服务、集群外的客户端和应用进行通信所用的 API 数量也是如此。内部（服务到服务）API 调用次数通常是外部（应用到客户端）调用的 10 倍或更多倍。

随着应用环境的扩张，一系列让 Kubernetes 平台无法应对的新挑战不断涌现，包括要求更复杂的 API 身份验证、授权、路由/整形和生命周期管理等。复杂的环境可能有成百上千个 API，因此拥有可帮助您对 API 进行保护、管理、版本控制和弃用的工具至关重要。在 Cluster Out 的这个阶段，您需要 API 网关、API 管理和 API 安全工具等技术，它们能够随着开发人员做出的调整持续扩展服务，并进一步增强应用功能。

第三阶段：提高集群弹性

实施 Cluster Out 模式的第三个阶段是考虑如何将 Kubernetes 环境与其他环境连接起来，无论这些环境是其他集群还是虚拟机或裸机上的应用部署。毕竟，我们现在设计的是分布式、松散耦合和富有弹性的云原生应用。

现代应用必须至少能够跨多个 Kubernetes 集群进行通信，从而实现更高级别的弹性并实施更智能的策略（例如成本控制策略）。而从广泛意义上来说，现代应用很少是孤岛。它们更有可能被融合到一个由外部服务、存储桶和合作伙伴 API（可能位于其他环境）组成的网络中。即使在内部，复杂的应用也可能需要与不同集群、可用区或数据中心的其他内部应用进行通信。

在这个阶段，开箱即用的 Kubernetes 仍然未能解决其所面临的挑战。您需要将 Kubernetes 边界（即 Ingress Controller）自动连接到外部技术，例如四层负载均衡器、应用交付控制器和 DNS 服务从而路由流量和处理故障转移。

实际上，Cluster Out 模式只是我们从 Kubernetes 早期采用者身上看到的一个成功秘诀。作为一个优先级框架，Cluster Out 是在企业环境中大规模运行容器的逻辑和方法，能够帮助您更有效地采用 Kubernetes 和现代应用。

这种方法的强大之处在于，它为平台团队提供了一种系统方法，支持 Kubernetes 在生产环境中的使用。但 Kubernetes 部署并不是从这里开始发挥作用，而是从开发人员构建由开源工具组成的应用堆栈开始。我们深知这一点。15 年来，开源一直是 NGINX 工作的核心，未来也将继续是激励 NGINX 前行的不竭动力。在接下来的一年里，我们将采取重要措施，投资社区参与、促进开源创新和坚持开源最佳实践，加大对开源的支持力度。

以下是我们在未来一年对开源社区的承诺。

承诺一：更多的开源投入、更多的社区互动

开源的力量有多么强大，我们就是活生生的例子。NGINX 为4 亿多个站点和互联网上的作用比任何服务器都要大 —— 做开源，我们是认真的。我们希望加快步伐，增加我们开发的项目数量，以创建支持七层网络、安全性和可观察性的新一代开源解决方案。

随着工作的推进，我们希望扩大社区参与。因此，我们承诺将 GitHub 用作我们所有新项目的存储库。我们承诺，不仅会开展更多的开源工作，而且会以最透明的方式进行，包括发布高质量的文档、问题跟踪信息和软件发行说明。我们还鼓励社区为我们的项目贡献一臂之力，与我们共同塑造未来。

承诺二：继续创新数据平面及其他技术

我听到很多用户说“代理是一种商品”，这意味着您可以将 NGINX、Envoy、HAProxy 等任何代理换成其他代理。但我们不认可这种说法。有关数据平面的创新仍在不断涌现。仅去年一年，便出现了服务发现、加密、身份验证、安全及跟踪等各种新功能。

NGINX 认为，智能代理是交付现代应用的基石。我们致力于在数据平面层提供更多的开源功能。我们的目标是超越当前的技术水平，并且绝不会仅停留在代理和数据平面上。我们致力于在现代应用技术堆栈的所有层面（包括控制平面和管理平面）进行创新。为此，我们计划开源更多控制平面技术，并开创新的管理平面技术，从而提供更复杂、更凝练的工作流功能。

承诺三：清晰定义开源和商业化的边界

在增加开源解决方案数量的过程中，我们需要一个明确定义的商业版软件的构建模型。因此，我们致力于构建一个透明、一致的模型，以便让每个团队都能够轻松了解不同类型的 NGINX 产品，并充分利用最能满足他们需求的产品。

详细来说：

NGINX 开源软件将始终是生产级软件，为构建现代应用提供了可靠基础。它将保持轻量级、快速和易于使用的特性，专为开发人员和各个应用团队而设计。请放心，就像 NGINX 开源软件一样，我们创建的每个开源工具本身都非常有用。我们不会限制使用某些特性，阻止开发人员和应用团队构建出色的应用。
我们的商业 NGINX 产品建立在开源工具之上，提供了额外功能来帮助平台团队和大型企业团队在生产环境中大规模运行和交付现代应用。具体来说，商业工具将提供额外的安全性、治理功能、可观察性及可扩展性。这是所有 NGINX 项目都具有的特点。尽管具体功能会因工具的用途而异，但平台运营团队大可放心，NGINX 商业产品在设计时充分考虑了他们的特定需求。

我们知道，不去兑现的承诺不叫承诺。所谓光说不练假把式，我们已经开始朝着这个承诺努力了，大家敬请期待吧！着眼未来一年，我们就以上的三个承诺发布了三个公告。

公告一：为 Kubernetes 社区提供更多资源

多年来，Kubernetes 社区一直依赖 NGINX 为其 Ingress 资源和控制器提供支持。除了这个社区版本，NGINX 本身还提供了 NGINX Open Source Ingress Controller 和商业版 NGINX Plus Ingress Controller。多年来，我们在 Kubernetes 社区中学到了很多，并希望进一步参与推进 Kubernetes Ingress 项目。今天我们要宣布两件事：

我们将专门委派一名全职员工来帮助管理 Kubernetes 社区的 Ingress 项目。
我们将调派多名员工加入 Kubernetes Gateway API SIG，以帮助推进 Kubernetes 的 Ingress 和 Egress 功能。我们很高兴为 Ingress 及其他 Kubernetes 相关项目注入了许多资源。多年来，Kubernetes 社区一直都很给力，做出了很多重要贡献。我们很荣幸能够增强与 Kubernetes 社区的合作伙伴关系。

公告二：在交付堆栈的每个层面建立新的开源项目

我们一直参与创建开源数据平面技术，即 NGINX Open Source、NGINX JavaScript、NGINX Unit 和 NGINX ModSecurity WAF。但正如我前面所说，我们正在扩展我们的开源技术，努力将它们覆盖到控制和管理平面技术。

具体来说，我们将在未来几个月内发布两个全新的开源项目，一个主攻微服务网络，一个可支持平台运营团队轻松运营和管理企业内的 NGINX 实例。我们还将发布一个独立于平台的开源开发者工具（与核心 NGINX 技术无关），用于开发现代应用。虽然我现在迫不及待地想向大家透露细节，但在开发人员体验完善之前，包括为您提供支持所需的 GitHub 存储库、文档和讨论组等，我们还是保留点新项目的神秘感吧。

这些新工具将帮助开发人员管理大量 NGINX 实例，并无缝连接到 Kubernetes 环境或跨 Kubernetes 环境无缝连接。所有这些都将开源且免费提供，并提供专门为平台运营团队设计的额外商业版本。

公告三：全新开源的现代应用参考架构

现代应用根据工具生态系统而构建，但东拼西凑的工具或项目很让人头疼，并且需要大量的人工配置。今天，我们宣布推出了 NGINX 现代应用参考架构（MARA），现已在 GitHub 上线。

参考架构考虑了现代应用架构的关键特性：可移植性、可扩展性、弹性和敏捷性。NGINX 与其他几家厂商和企业合作，创建了一款完整的、完全可操作的、基于微服务的应用，只需几分钟便可启动和运行，并托管在单个 GitHub 存储库中。MARA 是易于部署、可搬运的生产就绪代码，开发人员、DevOps 和平台运营团队可以使用它在 Kubernetes 环境中构建和部署现代应用。

该架构采用模块化方法，提供了免费和开源的模块化组件，这些组件预先进行配置和集成，让现代应用构建过程更简单、更可靠且更自动。我们将继续推动此参考架构的演进，欢迎社区成员加入我们。您是否拥有特定的代码存储库？或者不同的 CI 或 CD 工具？不妨构建一个新模块，将这些技术集成到参考架构中，并为其贡献代码。我们的目标是帮助那些想要快速可靠地在生产环境中启动和运行 Kubernetes 的公司减少障碍。

有关参考架构的所有详细信息，请参阅我们博文：《全新开源的现代应用参考架构》。