切换到软件负载平衡的 5 个理由

本文改编自 NGINX, Inc. 的 Floyd Smith 和 Faisal Memon 举办的网络研讨会。 我们关于该主题的新电子书可供下载。

目录

0:00 简介

弗洛伊德·史密斯: 您好，欢迎参加我们的演讲。 我们现在在 NGINX，今天我们将讨论我的电子书《切换到负载平衡软件的 5 个理由》 。

今天有两位嘉宾在场。 我是 Floyd Smith，NGINX 的技术营销作家。我曾是 Apple 的高级技术作家，并且撰写过多本有关技术不同方面的书籍。

费萨尔·梅蒙: 大家好，我是 Faisal Memon，在 NGINX 负责产品营销。我在这里工作大约一年了。 在加入 NGINX 之前，我曾在 Riverbed 和思科担任技术营销工程师。 我的职业生涯开始于用 C 语言进行开发。我曾在思科担任软件工程师，从事该职位大约八年。

1:38 你是谁？

弗洛伊德：我们在举办网络研讨会之前就会收到报名信息，我们可以看到每个人提交的职位、组织和参加原因。

看看与会人员的头衔真的很有趣。 我们有解决方案架构师——几种不同类型的架构师。 Linux 管理员、工程主管、首席执行官、高级敏捷交付经理、数名具有 DevOps 头衔的人员、全栈软件开发人员、工程师、科学家、开发人员、营销运营经理。

我们拥有一批非常优秀的技术人才。 我的感觉是，参加本次网络研讨会的人确实对技术非常熟悉，并且将直接面对我们今天在此讨论的问题。

我们还有非常优秀的、广泛的组织代表。 你们中的一些人可能正在关注这个问题，以便能够指导你们的客户做出明智的决定，但你们中的大多数人似乎是在直接在公司内部处理这个问题。

3:53 从硬件到软件

根据财务报告，硬件 ADC 市场正在衰退，因此，尽管客户群正在减少，但销售硬件 ADC 的人仍在努力增加每个客户的收入。 许多硬件 ADC 客户开始发现，他们不想成为那些为硬件 ADC 提供的服务支付越来越多费用的人数不断减少的群体之一。 他们开始意识到他们实际上可以在软件上做得更好，并获得更多的启动灵活性。 那些头衔中带有 DevOps 的人可能知道我的意思。

在 NGINX，我们经常看到的情况是，人们的硬件 ADC 合同续签日期已到，或者他们的流量突然增加，费用也突然上涨，然后他们就急于摆脱合同。 然后他们必须尽力快速完成任务。 他们通常都会成功，但压力很大，没有计划，也没有预算。 在本演示文稿的帮助下，您可以启动更多有计划的流程。

预算问题并不那么重要，因为通过转向软件可以节省很多钱，但操作麻烦却很大。 只要早点开始，就能大大减少这些问题。

NGINX 是硬件 ADC 的一个非常可靠的替代方案。它最初是为了解决C10K 问题而创建的。 也就是说，一台计算机上运行着一个 Web 服务器，可同时服务 10,000 个或更多个连接。 在 NGINX 之前这是不可能的。 人们会建立一个网站，它会变得流行，然后它就会崩溃。 阻止这种情况发生非常非常困难，但有了 NGINX，事情就变得容易多了。

我们的第一个开源版本于 2004 年在俄罗斯发布，NGINX [该软件]最初就是在那里创建[编者-弗洛伊德在这里说的是“创立”；NGINX, Inc. 成立于 2011 年] 。 带有支持的商业版本 NGINX Plus 于 2013 年发布。

NGINX 公司位于硅谷（旧金山），我们的开发办公室在莫斯科。 我们在英国也有办事处。 该公司获得了行业领袖的风险投资支持。 我们有 800 多家客户，前几天我们的员工人数刚刚达到 100 人。

6:33 为全球最繁忙的网站提供领先的 Web 服务器

共有 1.6 亿个网站在 NGINX 上运行。

它有两种不同的使用模式。 一些网站将 NGINX 作为Web 服务器运行，这也是其最初的用途。 但许多网站将 NGINX 作为反向代理服务器运行。 这就是您将 NGINX 放在当前架构前面的地方，使用 NGINX 来处理流量并将流量路由到您的应用服务器。 一旦你这样做了，你就开始了负载均衡，这也是我们今天要讨论的内容。

全球最繁忙的 10,000 个网站中，有 51% 已迁移至 NGINX。这是为什么呢？ 为什么最繁忙的网站的使用率比网站整体的使用率还要高？

原因是 NGINX 是真正繁忙的网站的最佳解决方案。 拯救一个繁忙但有问题的网站的一个快速方法是将 NGINX 作为反向代理服务器，然后在其上运行负载均衡。

随着时间的推移，您可以将现有的应用程序转换到 NGINX，或者如果您开发新的应用程序，您也可以将 NGINX 作为这些应用程序的 Web 服务器运行。 这就是我们如何在这些非常忙碌的人群中实现这种使用，他们不会随心所欲地更改网络服务器。 他们有使用其他 Web 服务器的经验，并且知道如何使用它们，但由于 NGINX 为他们所做的一切，他们做出了这一改变。

亚马逊网络服务上 36% 的网站都使用 NGINX。它正在成为一种标准工具。 现在，人们通常从 NGINX 开始，并在整个项目中坚持使用它。

以下是一些使用我们的网站。 当然，有 1.6 亿个网站使用 NGINX，我们无法将它们全部放在一张幻灯片中，但我们的一些合作伙伴和朋友是 Netflix、Airbnb、Uber、以及我提到的 Amazon Web Services、Box、Pinterest、WordPress。

所有以网络交付为生的公司都已转向使用 NGINX。

8:48 NGINX 的适用范围

让我们看看 NGINX 适合哪里。

在右侧，您可以看到 NGINX 作为 Web 服务器运行。 作为一个 Web 服务器，它使用应用网关来允许不同类型的应用服务器与其一起运行。 NGINX 作为一个 Web 服务器，可以处理 10,000 个 同时连接，具体数量取决于您正在执行的操作。

但 NGINX 也可用作反向代理服务器，您可以从中获得缓存、负载均衡和许多其他功能。

9:32 现代网络架构

NGINX 还可以帮助您转向现代 Web 架构。 这可能是转向微服务的三层 J2EE 风格架构。 它可能是复杂的 HTML 和 SOAP 协议，转变为更轻量的协议，如 REST 和消息传递，这是微服务的重要组成部分。 或者从持久部署转变为运行容器或虚拟机的可变部署。

您通常拥有自己拥有的服务，而不是固定的、静态的基础设施。 我们有 SDN、NFV 和云之类的东西，尤其是云。 您无需每隔几个月进行大规模发布，而是每隔几个小时进行持续交付。 您不再拥有孤立的团队（即开发组、测试组和运营组通过各自的经理开展工作），而是拥有一种共同承担责任的 DevOps 文化，每个人都撸起袖子，处理每个问题的一些方面。

10:42 DevOps 与 NGINX 完美结合

DevOps 方法、云部署和自动化服务发现” size-full wp-image-46723″ style=”border:2px solid #666666; padding:2px; margin:2px;” />

DevOps 的故事与 NGINX 紧密相连。许多 DevOps 人员都拥有 NGINX，当他们遇到部署问题时，他们就会使用 NGINX。

在某些部署中，您甚至根本不必更改应用程序设置。 你在它前面放置 NGINX，你就可以以应用服务器可以处理的方式将流量传送到应用服务器。 您没有更改代码，并且在急于解决性能问题时也没有冒着核心功能的风险。

我们将讨论 DevOps 和 NGINX 能够很好地协同工作的其中一个方面是软件负载均衡。 它在云部署中运行得很好，而且在您自己的服务器上也运行得很好。 它具有多种负载均衡方法。 这里 NGINX 和 NGINX Plus 之间存在差异，我稍后会讲解。

NGINX 的动态重新配置功能支持服务发现和正常运行时间。 服务发现对于微服务和自动化至关重要，并且通过动态重新配置，您不必将人们踢出服务器即可进行配置，这对于让您的客户保持在线是一个巨大的优势。

应用健康检查可以提前预警应用交付问题，以便您可以妥善关闭有问题的服务器，而不是让它卡住并让人们无法使用。 然后还有强大的可定制监控。 再次，这会让你在问题出现时及时了解情况，这样你就可以在问题影响客户之前解决它们。

12:30 NGINX Plus 功能

NGINX Plus 里面有什么？

因此，开源 NGINX 是原始产品，而 NGINX Plus 是在它之上的商业产品。 在 NGINX 我们至少花了 70% 的时间在开源方面，但这也是 NGINX Plus 中高级功能的基础。

该开源产品包括请求路由，这是 Web 服务器的核心功能；压缩，因为这将最大限度地减少 Web 服务器上的负载，并且还可以最大限度地减少网络上的流量，这非常有价值。 它支持 SSL 以确保安全。 我们还有一种嵌入式脚本语言，实际上有两种。 一个是我们自己的，NGINX JavaScript模块（以前称为nginScript），一个是Lua。

NGINX 有几个部分开源的功能，但在 NGINX Plus 中得到了增强。 您可以使用开源 NGINX 很好地实现负载均衡，但使用 NGINX Plus，您可以获得一些更高级的功能。 类似地，您可以使用开源 NGINX 作为边缘缓存和媒体流，并且在 NGINX Plus 中效果会更好。

NGINX Plus 还具有其自身的一些功能。 有应用健康监控、用于监控、监控和分析的 GUI 可视化、RESTful 配置 API 以及一些更高级的负载平衡技术。

通过 NGINX Plus，您可以联系 NGINX 工程师来为您的工作提供支持。 如果您目前正在使用 F5、Citrix 或类似系统，您可能已经习惯了这种支持。 对于规模较大、较为繁忙的网站来说，即使是很短的停机时间也会让你损失很多钱，因此这一点至关重要——而且只要你每年避免一次哪怕是短暂的停机，就可以轻松收回成本。

14:41 客户案例研究 – WordPress.com

让我们来看一些进行转换的客户的案例研究。

WordPress.com 原本使用 F5 的 BIG-IP，后来他们改用 NGINX，因为他们需要对每台服务器每秒超过 10,000 个请求进行负载均衡——这就是我们所说的 C10k 问题，NGINX 十多年来一直在解决这个问题。 当时，每台服务器每秒的请求数限制为 1,000 个。 你可以想象与 10,000 或更多相比，这是一个多么沉重的负担。

Wordpress.com 拥有多个 F5 BIG-IP 系统，并且即将扩展到十个数据中心。 为了支持高可用性，基本上为每个数据中心提供实时备份，他们正在考虑十对 BIG‑IP 服务器。 非常昂贵。 他们还需要进行动态重新配置，以确保在更改配置时不会将用户踢出。

他们开始转向 NGINX，并在 Gravatar（一款为用户提供头像的应用程序）上进行测试。 这让他们熟悉了 NGINX。然后，他们从 F5 服务器迁移到 NGINX，这让他们的内存占用和 CPU 占用都变得很小且可预测。

现在他们在 36 台 NGINX 服务器上每秒处理超过 70,000 个请求和每秒 15 千兆位 [Gbps]。 每台服务器每秒的峰值请求数可达 20,000 个。 而且他们可以随时重新配置和更新。

如果您看到报价，他们只是在谈论小型实施之间的费用差异，其中 NGINX 将为您节省大量资金。 但当你使用十对服务器时，就会发现差别非常大。

16:42 客户案例研究——蒙大拿互动

Montana Interactive 选择 NGINX Plus 实现高可用性负载均衡。 事实上，很多政府服务通过网上提供会更加容易、便宜、更好。 如果您已经在机动车部门或类似部门预约了，您就会明白我的意思。 这些网站可以支持投票、纳税等。

这些基本政府服务数量庞大，而蒙大拿州面积很大，人口却相对较少，且分散在各地。 因此，与让居民开车六到八个小时去政府办公室相比，提供在线服务非常重要。

蒙大拿州最初非常积极地转向在线服务，但随着业务的增长，他们开始遭受会话中断的困扰。 由于税务支付应用程序的庞大需求，他们的季度交易流量出现了大幅增长。 在填写一张大表格的过程中，突然有人掉队了，他们所有的工作都会丢失。 如果您正在纳税或进行任何其他复杂的流程，那会非常紧张。

他们的解决方案是将运行 Pound 的服务器升级到 NGINX Plus，将 NGINX Plus 放在不同的虚拟机管理程序和数据中心上，并作为动态反向代理运行，实时路由请求，从而更好地管理流量。 转向 NGINX Plus 后，他们看到速度、灵活性和易用性得到了巨大改善。 他们受益于动态重新配置，他们将 SSL 处理卸载到 NGINX 服务器，并使用基于角色的管理来改善运营和安全性。

Montana Interactive 的 James Ridle 对 NGINX 的强大功能感到惊讶。基准测试结果让他震惊不已，他几乎不敢相信使用 NGINX 在同一台服务器上处理数据时能有如此大的差异。

18:43 客户案例研究 – BuyDig.com

这是另一个为客户带来巨大利益的案例研究——BuyDig.com，这是一个通过 NGINX 实现可扩展性和安全性的电子商务网站。

BuyDig.com 有一个较旧的 .NET 应用程序。他们不想更改它，也没有必要。 在遭受大规模DDoS攻击后，他们意识到他们需要一个快速、容错、易于配置且具有更好的性能、安全性和可扩展性的前端。

他们将 NGINX Plus 放置在前端应用层，托管在 Amazon Web Services 上。 他们没有对在.NET 上运行的后端服务进行任何更改。 这太大了——没有变化——不是小变化，不是小麻烦，不是小风险，而是没有。

现在他们获得了出色的性能和安全性。 他们使用 NGINX 的配置语言对其进行了定制。 他们使用 TLS SNI 和可定制的日志来帮助他们保持安全。 他们从未遇到过任何速度减慢或网站停机的情况，他们对性能非常满意。

所以，这些只是 NGINX Plus 功能的一些示例。

20:10 电子书——切换到负载平衡软件的 5 个理由

现在让我深入了解一下电子书。 我会给你一个关于电子书内容的简要概述，然后 Faisal 会带你了解转换的前两个原因，这两个原因更具技术性，之后我会继续讲。 有链接。 我们完成后，您将获得此演示文稿和网络研讨会录音。 我认为，这封电子邮件大约需要一天时间才能发出。

此处的链接将带您到此免费电子书的下载处。 因此，我先提一下原因：它们是为了削减成本；提高 DevOps 适应性；部署到任何地方（您自己的本地服务器、云端、私有云，以及您想做的任何事情）；快速适应的能力，没有奇怪的合同约束，我会详细解释这一点。 但是现在，让我把话题转交给费萨尔来谈谈削减成本的问题。

21:22 原因 1 — 大幅降低成本

费萨尔: 谢谢，弗洛伊德。 五个原因中的第一个原因是，通过迁移到 NGINX Plus 进行软件应用交付，您可以大幅降低成本。

回顾 90 年代中期，扩展网站的唯一方法是购买更大的服务器，但这非常昂贵且不可靠，因为单个服务器也是单点故障。

大约在这个时候，F5 首次发布了 BIG-IP，为网站所有者提供了一种不同的架构；您无需购买更大的服务器，而是可以使用 BIG-IP 对一系列廉价服务器进行负载平衡。 这样就降低了成本，因为购买 BIG-IP 和廉价服务器比购买一台巨型服务器更便宜，而且由于消除了单点故障，您还可以获得一些冗余。

这是一个伟大的建筑——具有革命性，而且在当时确实是城里唯一的建筑——但在过去的 20 年里，很多东西都发生了变化。 一个重大的变化是服务器成本大幅下降。 如今，你可以用不到旧金山湾区一个月租金的钱买到一台相当强大的服务器。

第二个重大变化是现在出现了像 NGINX 这样的开源软件，它提供与 F5 BIG-IP 或 Citrix NetScaler 相同的功能。 在开源的情况下，您可以免费获得与那些大型昂贵设备类似的功能。 Floyd 之前指出，有超过 1.6 亿个网站使用 NGINX。如果你看看排名前 10,000 的网站，你会发现其中超过一半都在使用 NGINX。

因此，我们现在拥有的这个开源软件不仅具有与 F5 相比所需的所有功能，而且还具有与任何其他商业产品一样的可扩展性和可靠性。

23:19 NGINX Plus 与 F5 BIG‑IP

我今年早些时候做了一些基准测试和成本分析，以下是其中的摘录。 这是对在现成的商品硬件上运行的 NGINX Plus 软件的比较。 在这种情况下，它由戴尔提供，并且我们将其与 F5 BIG-IP 的不同型号进行比较。

这个特定的例子是 2000S，它是入门级 F5 BIG-IP。 我将它与戴尔服务器上两种不同大小的 NGINX Plus 进行了比较。 其中一个性能略低于 F5 BIG-IP（您可以在底部看到性能指标），另一个性能几乎翻了一番。

仅看右边一栏，NGINX Plus 的性能是 2000S 的两倍，第一年您就可以节省 78%，包括硬件成本和一年的维护支持费用。 这些成本节省将一直延续到第五年。 即使五年后，采用戴尔服务器的 NGINX Plus 的总拥有成本也比 F5 便宜 58%。

24:37 NGINX Plus 与 Citrix NetScaler

我对 Citrix NetScaler 进行了同样的成本比较。 在这里，我们比较入门级 NetScaler、MPX-5550 企业版。

Citrix 具有许可证，如果您想要缓存和内容压缩等基本功能，则必须将许可证升级为企业版许可证。 使用 NGINX，内容缓存和压缩均包含在开源和 NGINX Plus 中，无需支付额外费用。 因此，我们在这里比较的是 Citrix NetScaler 的企业版，因为它提供的功能与 NGINX Plus 中提供的功能更相似，并且当您用 NGINX Plus 替换 Citrix NetScaler 时，我们看到与 F5 相同的成本节省。

您可以获得所期望的所有相同功能和性能，但第一年的费用减少 89%。 即使到第 5 年，您仍然可以节省 75% 的硬件成本（在本例中为商品戴尔服务器）和 NGINX Plus 软件订阅成本。

一个关键指标，也是硬件供应商经常谈论的指标，是每秒 SSL 交易数，或者每秒可以建立的新 SSL 连接数。 在这些平台中，该数字通常通过硬件加速，因此 NetScaler 和 F5 BIG-IP 具有专门的硬件来加速 SSL 交易，这增加了这些平台的成本。

我们看到的是，即使采用软件解决方案——没有硬件加速，仅使用 CPU 的处理能力——我们也可以跟上定制硬件的步伐。 我们可为您大幅节省成本，同时还能提供硬件加速解决方案所带来的性能。

所以，这就是原因 1：通过迁移到 NGINX Plus，您可以节省很多钱。 但这不仅仅与金钱有关。

26:52 原因 #2 – DevOps 需要软件application交付

使用基于软件的解决方案，您还可以获得很大的灵活性，而切换到基于软件的负载均衡器的第二个原因是，如果您要转向 DevOps，您确实需要用于应用交付的软件。

对于 F5 和 NetScaler 来说，这些设备通常以聚合点的形式部署在大型企业内。 因此，大量不相关的流量会通过它。 同一个 F5 BIG-IP 可以对网络防火墙进行负载均衡，可以对企业电子邮件服务器进行负载均衡，可以对多个不同的后端企业应用进行负载均衡，也可以对前端企业应用进行负载均衡。 它可以是微服务架构中的负载均衡 API。 所以，它可以对很多事物进行负载均衡。

从表面上看，这似乎是一个很好的架构，因为它非常简单；您只需通过 F5 运行所有内容。 长期以来，这种方法确实有效，特别是 21 世纪初期，当时一切都围绕私有数据中心展开，我们在本地数据中心运行所有应用，以及企业所依赖的一切。 但在过去几年里情况发生了变化，现在大多数东西都被转移到了云端。

当我说云时，我不仅仅是在谈论在亚马逊内部托管前端 Web应用，还指使用 Salesforce 和 Office 365 之类的东西，而不是内部部署 CRM 系统和内部部署电子邮件服务器。 因此，拥有一个可以完成所有这些事情的设备对于人们现在实际使用的功能来说可能有些过度了。

这种聚合带来的第二个问题是，它导致这些设备被牢牢锁定。 您变得非常不愿意对其进行更改，因为如果您搞乱了 F5 配置，可能会导致整个公司网络瘫痪。 它可以平衡电子邮件服务器、网络防火墙的负载。 因此，配置变得有风险，并且更改需要受到严格限制和锁定。

任何想要对其进行更改的人通常都需要提交 IT 票，这可能需要数小时、数天或数周的时间，具体取决于组织以及组织对请求的更改的优先级。

由于硬件极其封闭，转向 DevOps 变得十分困难。 当你进行 DevOps 并走向自动化时，你就会走向持续集成，你就会走向更频繁地发布代码。 如果每次想要进行更改时都必须提交 IT 凭单，那么这会抑制并扼杀该主动性。

我们在很多组织中看到的情况是，负责应用并希望转向 DevOps 和敏捷开发的人员无法每次都提交工单，因为这会妨碍 DevOps 和敏捷计划。 因此，他们有时会部署开源 NGINX，并让 F5 BIG‑IP 指向它，而该 NGINX 实例将由 DevOps 或应用团队管理，这使他们能够实现自动化并轻松进行更改。 这是一种绕过公司 IT 政策的方法。 然后我们看到很多客户，当然，一旦他们尝试了，就开始转向 NGINX Plus 以获得更高级的功能以及支持。

NGINX 支持一系列灵活的不同部署模型，包括可以保留当前 F5 的模型。 您可以使用 NGINX Plus 来补充和卸载前端 Web应用、API 和微服务的负载均衡和交付，同时保留 F5 来执行企业电子邮件服务器的网络负载均衡。 如果您不需要网络服务和网络负载均衡，那么您显然也可以用 NGINX Plus 替换 F5，并获得单一解决方案。

我们支持一系列不同的部署模型，帮助组织走向 DevOps、持续交付和自动化。

对于原因＃3，我将把它交还给弗洛伊德。

31:59 原因 3 — 使用一个 ADC 随处部署

弗洛伊德：谢谢你，费萨尔。

使用 NGINX，您可以使用一个 ADC 解决方案在任何地方进行部署。 “到处” 是什么意思？ 这意味着您的本地服务器、公共云、私有云或混合云都可以在一个解决方案上工作。 这不仅有实用性，也有建筑方面的意义。

首先，如果您使用的是内部服务器而不是云，那么我们所说的一切都非常适用。 许多人为了获得更好的灵活性、更多的功能并节省资金而转向 NGINX 和 NGINX Plus，他们就处于这种情况：他们正在部署到内部服务器。

如果您正在使用云或想要考虑使用云，那么 NGINX 和硬件 ADC 之间根本就没有可比性。您无法将硬件 ADC 移至亚马逊的数据中心。 硬件 ADC 对此不会提供帮助。

现在，硬件 ADC 开发人员确实有一些基于软件的解决方案，但在某些情况下，他们只建议您使用这些解决方案进行开发。 它不是硬件 ADC 的替代品。您可能看到过简单性方面的优势，或者“如果没有坏就不要修”，但当您想要迁移到云时，这些优势就会土崩瓦解。

使用 NGINX 和 NGINX Plus，应用架构独立于交付平台。 某些云提供商开始添加越来越多的您可以通过 API 绑定的服务。 在开发过程中，这确实是一件很棒的事情，因为您不必担心如何做某事；您只需使用它们的 API 来处理负载均衡、缓存或其他功能。 但是当你扩大规模时，你只需为每笔交易支付少量费用。

好吧，突然之间，当你进行数千、数万、数十万笔交易时，这些数字开始累积起来。 计费非常混乱且难以预测，特别是因为它基于总是在变化的流量。

如果您使用基于 NGINX 或 NGINX Plus 的方法，那么您基本上在任何平台上都执行相同的操作，并且当您转移到其他云提供商或回到公司内部时，差别很小。

事实上，我们有客户在其内部服务器和云端之间进行负载均衡。 那么，它看起来像什么？ 他们拥有足够的内部服务器来满足 80% 或 90% 的时间的需求。 这样，当他们需要扩大规模时，他们不必购买甚至插入新服务器；他们只需扩展到云端。

云端通常比您的内部服务器慢，并且由于所有内容都是负载平衡的，所以只有在您使用内部服务器时会被丢弃的会话才会转到云端。 它们的延迟稍长，但它们会被处理，而不会被放入队列或被丢弃。

从经济角度来说，这很棒，因为您只需在紧急情况下支付云计算费用，例如流量突然激增。 这可能是因为新闻报道，如果您的产品获得了好评，或者您可能只是在持续超出您的业务计划，而您尚未扩大内部规模来满足它，或者恰巧是假期，而您每年只需要几周就需要两倍数量的服务器，这是不值得的，因为您可以通过扩展到云端来实现这一点。 借助 NGINX，这一切都可以灵活甚至自动完成。

35:42 原因 4 — 快速适应不断变化的需求

NGINX 让您能够快速适应应用不断变化的需求。 当您需要快速添加服务器或添加服务器对以实现高可用性时，您不能等待硬件订购、交付、接收、测试，然后执行 iRules 或您需要为它们执行的任何软件配置。iRules 也是专有的 - 只有在您拥有 F5 服务器时才需要 iRules。 这不是一套你可以轻易从大学毕业后就被聘用的技能。 如果您的 iRules 人员离开，您将很难再找到其他人。

当涉及到配置更改时，通常您不能等待网络操作批准更改。 您确实不希望将您的更改与不太紧急的事情一起放入队列中。

使用 NGINX 后，新项目审批的开销会小得多。 使用 NGINX 和 NGINX Plus，当您谈论花费 2,000 美元或 3,000 美元的服务器时，您可以在机柜中保留一些额外的硬件。 当您谈论硬件 ADC 的数万美元时，您无法做到这一点。

这种灵活性、冗余性、在需要时做需要做的事情的能力是 NGINX 的核心特性，也是用户如此喜爱我们的部分原因。

37:08 原因＃5 - 没有人为的性能限制

最后，NGINX 不会对性能产生任何人工或接触驱动的限制。 对于 NetScaler Enterprise Edition，该服务器的吞吐量合同限制为 0.5 Gbps。 嗯，从企业角度来说，这太荒谬了。 在行业标准硬件上运行的类似 NGINX 设置将支持 20 Gbps。 这是 Citrix 限制的 40 倍。

另一件事是 Citrix 号码是一个合同约束。 如果超出此限额，您的付款期限将突然大幅增加。 我们建议使用 20 Gbps。 所以，这只是意味着当您进入该区域时，您可能会开始注意到您的性能有所下降，并且您可能会认为获取另一台服务器并在其上进行负载平衡是一个好主意。 但您可以灵活地决定。 您的预算不会突然减少。

对于 Citrix 来说，这就像遇到停车标志一样。 在这种情况下，更多的业务可能是一个坏消息。 多一个客户可能会让你损失很多钱，多几个客户也会让你损失很多钱，因为他们会给你设定上限。 当您使用 NGINX 时，拥有更多业务是个好消息，而且随着客户群扩大，收入增加，您的成本也会稳步增长。

我们经常会接到超出这些上限的人打来的紧急电话，而且他们的预算突然就超出了。 如果不做出重大改变，他们就无法回到预算范围内。 然后他们必须努力使用 NGINX 并重新回到良好的状态。 然后，他们通常实际上会超出预算，因为他们在 NGINX 上节省了很多钱。

但谁需要这么头疼呢？ 当您突然遇到这种可怕的预算/绩效冲突时，您还会感到不确定性和恐惧吗？ 尽早切换到 NGINX 意味着您可以完全摆脱这个问题。

40:00 资源

• 案例研究 – WordPress.com/Automattic 上的 NGINX
• 案例研究 - Montana Interactive 使用 NGINX Plus 提高应用程序性能和客户服务
• 案例研究 – Buydig.com 如何在不更改任何代码的情况下扩展和保护其 Microsoft .NET 应用程序
• 电子书——切换到负载平衡软件的 5 个理由
• 博客 – NGINX Plus 与…… F5 BIG-IP： 性价比比较
• 博客 – NGINX Plus 与…… Citrix NetScaler： 性价比比较
• NGINX Plus 免费试用