随着个人计算机在 20 世纪 90 年代初变得无处不在，人们对应用程序的需求也越来越大。当时，开发一款应用程序从最初的构思到部署到生产中平均需要三年时间。这种情况发生了巨大变化 – 亚马逊每 11.7 秒部署一个新的或更新的应用程序，而拥有 120 年历史的美国奢侈品零售商 Nordstrom 已将其部署频率从每年两次增加到每月一次。
更快地将应用推向市场使企业能够在竞争中保持领先地位，快速实现规模化，并通过数字渠道增加收入。开发人员在这个新世界中占据中心地位，但他们面临着以惊人的速度开发和部署新应用程序的压力。这反过来又给基础设施和运营 (I&O) 团队带来了压力，要求他们提供灵活的多语言环境来支持开发人员的工作效率。
NGINX 在交付 blazingl 方面发挥着至关重要的作用快速的应用程序。 NGINX Open Source 和 NGINX Plus 作为众所周知的 Web 服务器、反向代理、软件负载均衡器、API 网关和内容缓存，在应用程序开发人员和 DevOps 团队中拥有普遍的足迹和广泛采用。 NGINX 应用程序平台的最新成员是 NGINX Unit，它是一个动态应用程序服务器（为简洁起见，我们将其简称为应用程序服务器）。
您可能想知道：我们还没有足够的应用服务器吗？为什么要引入另一个？
应用服务器 – 为您的应用保持正常运转
首先，我们来看看什么是应用服务器。应用程序服务器的基本工作是为客户端提供对通常所谓的业务逻辑的访问，即动态生成对客户端请求的响应的代码，转换数据以提供业务、服务或应用程序提供的专用功能。应用程序服务器位于客户端和后端层之间来处理事务处理、资源/连接池、负载平衡和冗余。它们使应用程序开发人员能够专注于业务逻辑。
应用程序服务器提供创建和运行应用程序的框架。正如负载均衡器对于 I&O 和 DevOps 团队的关键一样，应用程序服务器对于开发人员来说也是关键。
频繁更改应用服务器配置会导致停机和高昂的运营成本
开发人员经常需要更改应用服务器的配置以扩展或支持新的应用功能。应用服务器必须与后端的各种组件和方面进行交互，例如数据库、网络功能以及用不同语言或同一语言的不同版本编写的应用程序。例如，可能需要支持应用程序的多个版本，因为应用程序本身使用不同版本的 PHP 或 Python。应用服务器还必须支持多种部署环境，例如虚拟机和容器。
考虑到应用服务器提供的功能及其运行的生态系统的复杂性，对其配置的更改通常需要重新启动。这意味着应用程序停机，必须仔细计划或通过复杂的网络来避免，从而导致服务中断和操作复杂性！当配置更改仅针对应用程序服务器运行的多个应用程序之一，但重新启动会影响所有应用程序时，重新启动尤其痛苦。这足以让你对更新犹豫不决。您的功能速度受到打击，开发人员的士气也受到打击。您的应用程序服务器成为创新和快速上市时间的瓶颈。
针对不同语言的不同应用服务器会导致基础设施复杂性爆炸
随着企业采用更加敏捷、灵活的方法进行应用开发，开发人员通常有权选择最适合其应用程序功能需求的语言。这增强了他们的生产力和士气。根据开源平台即服务项目 Cloud Foundry Foundation 的一份报告，“多语言策略提高了业务速度；实现灵活性、可移植性和互操作性；并吸引最优秀的开发商”。
虽然您确实希望为开发人员提供选择的自由，但支持多种语言会带来运营负担。 Cloud Foundry 基金会报告列出了企业开发中使用的 20 多种语言，其中 6 种语言占主导地位：Java、JavaScript、C++、C#、Python 和 PHP。传统的应用程序服务器仅支持一种语言（甚至一种语言的单一版本），因此您使用的每种语言都意味着您的 I&O 团队需要安装、配置和维护另一台应用程序服务器，更不用说处理其运行时的特性了。生产。这可能会导致资源的大量消耗。您还必须为企业中使用的每种语言维护单独的主机。se – 对资本支出和运营支出的直接打击。
传统应用服务器并非专为基于微服务的现代应用而设计
软件架构的微服务方法从多个小组件构建一个大型、复杂的应用程序，每个组件执行单一功能，例如身份验证或通知。通过这种方法，应用程序可以轻松扩展，因为每个微服务都具有弹性和弹性 – 如果一个微服务实例发生故障，其他微服务实例将继续运行。基于微服务的应用程序轻量、灵活、可移植，通常部署在容器上。
企业越来越多地使用微服务对其应用进行现代化改造。根据为微服务提供应用程序性能管理的初创公司 LightStep 发布的《全球微服务趋势》报告，86% 的企业预计微服务将在 5 年内成为其默认架构。微服务本身很轻八、灵活且便携——它们通常部署在容器上。
传统的应用服务器是为三层整体应用程序设计的，包括表示层、数据层和包含业务逻辑的应用程序层。与它们所服务的应用程序一样，遗留应用程序服务器占用空间很大，这使得它们不适合微服务环境，而轻量级和可移植性是微服务环境的关键。使用传统的应用程序服务器，很难在容器上或跨多个云快速启动新实例。由于配置更改而重新启动通常需要很长时间 – 在某些情况下比微服务的操作持续时间（运行时）还要长 – 这违背了微服务的目的。
NGINX 部门如何应对这些挑战？
我们开发了 NGINX Unit 来解决传统应用服务器与现代应用程序环境之间的不匹配问题。 NGINX Unit 是一个操作源动态应用程序服务器，适用于独立应用程序和分布式微服务应用程序架构。
用于一致、零停机配置的动态 API
NGINX Unit 提供 RESTful API 接口来简化配置。该接口提供了一致的机制，用于将配置更改应用于用不同语言编写的不同类型的应用程序。所有更新均以无缝方式进行，不会造成任何停机。 I&O 团队无需计划任何停机时间，从而节省时间和精力，并且您的客户也无需遭受任何服务中断。使用 API 执行配置更新还有一个额外的好处，即允许 DevOps 使用配置管理工具自动执行此过程，并轻松与现有 CI/CD 管道集成。
多语言支持以降低操作复杂性
NGINX Unit 极大地减轻了管理多个应用程序服务器。它目前支持七种语言——Go、Node.js、Perl、PHP、Python、Ruby 和 Java Servlet 容器（最后一个作为实验模块）。您可以在同一服务器上运行用不同语言编写的应用程序。此外，用不同版本的语言（PHP 5 和 PHP 7、Python 2.7 和 Python 3）编写的应用程序版本在同一服务器上并行运行。没错 – 您不必为不同的语言和版本维护不同的应用服务器，或在单独的主机上运行它们。您可以节省硬件成本，以及管理、维护和保护所有这些服务器的相关成本。您的 I&O 团队现在有时间专注于创造价值的 IT 计划，而不是平凡的日常运营。
轻量级、灵活的架构，可优化微服务支持
NGINX Unit 是一个可以部署在任何地方的软件包短跑;裸机、虚拟机、容器、公共云和私有云。 NGINX Unit 由创建 NGINX Open Source 和 NGINX Plus 的同一团队开发，也具有与 NGINX 相同的“核心价值观”。 NGINX 单元是轻量级的：大小不到 1 MB。内存和CPU利用率非常低。这些特性使 NGINX Unit 成为基于微服务的现代应用程序的理想选择（微服务本身是轻量级的，通常在容器上运行），但对于在传统环境中运行的整体应用程序同样有益。
NGINX 单元是从代码到客户的平台中的关键组件
NGINX 在满足开发者社区的应用交付需求方面拥有丰富的历史 – 无论是部署为负载均衡器、用于 API 管理，还是部署在基于微服务的架构中。 NGINX 解决方案灵活、轻量且便携。 NGINX 无缝集成到您的应用程序堆栈中，从而高性能和可靠性。秉承与应用程序代码密切相关的传统，我们开发了另一个中央基础设施组件——应用服务器——它通常是开发人员的第一个基础设施接触点。 NGINX Unit 满足现代应用程序的应用程序服务器要求。
NGINX Unit 是我们更广泛愿景的一部分，其中 NGINX 和 F5 提供端到端应用基础设施（涵盖从代码到客户的基础设施），以便跨多云环境交付应用。要了解更多信息，请注册我们的网络研讨会系列，该系列详细介绍了 NGINX 和 F5 如何解决您的应用程序交付挑战。
发表回复