改用软件负载均衡的5个理由

NGINX | 2016年10月13日

本文改编自NGINX, Inc.的Floyd Smith和Faisal Memon主讲的网络研讨会。我们还推出了有关此主题的新电子书，现可下载。

0:00	简介
1:38	您是谁？
3:53	从硬件转向软件
6:33	服务全球繁忙网站的主流Web服务器
8:48	NGINX的定位
9:32	现代Web架构
10:42	DevOps与NGINX高效协同
12:30	NGINX Plus功能
14:41	客户案例研究：WordPress.com
16:42	客户案例研究：Montana Interactive
18:43	客户案例研究：BuyDig.com
20:10	电子书：负载均衡改用软件的5大理由
21:22	理由 #1：大幅降低成本
23:19	NGINX Plus与F5 BIG‑IP对比
24:37	NGINX Plus与Citrix NetScaler对比
26:52	理由 #2：DevOps需要软件应用交付
31:59	理由 #3：使用一个ADC随处部署
35:42	理由 #4：快速适应不断变化的需求
37:08	理由 #5：不受人为性能限制
40:00	资源

0:00 简介

Floyd Smith：大家好，欢迎观看本次演示。我们来自NGINX，今天将介绍我的电子书《改用软件进行负载均衡的5个理由》。

今天由我们两位共同演讲。我是Floyd Smith，担任NGINX技术营销撰稿人。我曾任Apple高级技术撰稿人，并撰写过多本探讨不同技术领域的书籍。

Faisal Memon：大家好，我是Faisal Memon，负责NGINX的产品营销工作。我加入NGINX大约一年了。在此之前，我曾在Riverbed和Cisco担任技术营销工程师。职业生涯初期，我从事C语言开发，后来在Cisco担任了大约八年的软件工程师。

1:38 您是谁？

Floyd：在举办网络研讨会之前，我们会收到报名信息，并能看到各位提交的职位、所属组织和参会原因。

看看参会者的职位很有意思。其中有解决方案架构师，以及其他几类架构师，还有Linux管理员、工程负责人、CEO、高级敏捷交付经理、几位从事DevOps相关工作的人员、全栈软件开发人员、工程师、科学家、开发人员和营销运营经理。

参会者来自不同领域，都具备良好的技术背景。我认为，参加本次网络研讨会的各位都拥有丰富的技术实践经验，也会直接面对我们今天讨论的问题。

参与本次网络研讨会的组织类型也非常广泛。有些人可能希望借此帮助客户做出明智决策，但大多数人似乎正在组织内部直接处理这一问题。

3:53 从硬件到软件

财务报告显示，硬件ADC市场正在萎缩。因此，即使客户群不断缩小，硬件ADC供应商仍试图提高从每位客户获得的收入。许多硬件ADC客户开始意识到，他们不愿继续留在这个日益缩小的客户群体中，为硬件ADC提供的服务支付越来越高的费用。他们逐渐发现，使用软件不仅可以更好地实现相同功能，还能获得更大的灵活性。职位名称中带有DevOps的人可能明白我的意思。

在NGINX，我们经常看到这样的情况：硬件ADC合同到了续约日期，或者流量突然激增、费用随之大幅上涨，客户才开始匆忙设法退出合同。之后，他们不得不赶在很短的时间内完成相关工作。虽然通常能够成功，但整个过程压力很大，既没有事先规划，也没有纳入预算。借助本演示文稿，可以更有计划地启动这一流程。

预算问题并没有那么紧迫，因为迁移到软件可以节省大量成本，但运营方面会遇到很多麻烦。只要尽早开始，就能大幅减少这些麻烦。

NGINX是硬件ADC非常可靠的替代方案。它最初是为了解决C10K问题，即让一台计算机上的一个Web服务器同时处理10,000个或更多连接。在NGINX出现之前，这是不可能实现的。网站上线后，一旦访问量激增，就会崩溃。要避免这种情况极其困难，但有了NGINX，问题就容易解决多了。

我们的首个开源版本于2004年在俄罗斯发布，NGINX［软件］最初也是在那里开发的［编辑注：Floyd在此处使用了“创立”一词；NGINX, Inc.成立于2011年］。提供支持服务的商业版本NGINX Plus于2013年发布。

NGINX公司总部位于硅谷（旧金山），研发办公室设在莫斯科。我们还在英国设有办事处。公司获得了行业领军企业的风险投资支持。我们的客户已超过800家，员工人数最近也刚刚达到100人。

6:33 为全球高流量网站提供支持的主流Web服务器

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

NGINX有两种不同的使用模式。一些网站将NGINX用作Web服务器，这也是它最初的用途。但许多网站将NGINX用作反向代理服务器。也就是说，将NGINX部署在现有架构前端，由NGINX处理流量并将其路由到应用服务器。采用这种方式后，就可以进一步实现负载均衡，这也是我们今天要讨论的内容。

在访问量排名前10,000的网站中，已有51%转向NGINX。为什么会这样？为什么NGINX在这些高访问量网站中的使用率甚至高于其在所有网站中的整体使用率？

这是因为NGINX非常适合流量繁忙的网站。要快速解决繁忙网站遇到的问题，可以将NGINX部署为反向代理服务器，然后在其上运行负载均衡。

随着时间的推移，您可以将现有应用迁移到NGINX；如果开发新应用，也可以使用NGINX作为这些应用的Web服务器。正因如此，NGINX才在这些业务繁忙、不会轻易更换Web服务器的用户中得到广泛采用。他们熟悉其他Web服务器，也知道如何使用，但仍选择改用NGINX，因为NGINX能为他们提供诸多帮助。

Amazon Web Services上的所有网站中，有36%使用NGINX。NGINX正逐渐成为一种标准工具。如今，人们通常从项目之初就使用NGINX，并在整个项目期间持续使用。

以下是部分使用NGINX的网站。当然，使用NGINX的网站多达1.6亿个，不可能全部放在一张幻灯片上。我们的合作伙伴和朋友包括Netflix、Airbnb、Uber、刚才提到的Amazon Web Services，以及Box、Pinterest和WordPress。

这些以Web内容交付为核心业务、必须确保服务正常运行的公司，都已迁移到NGINX。

8:48 NGINX 的适用场景

来看看NGINX适用于哪些场景。

右侧显示的是作为Web服务器运行的NGINX。作为Web服务器，它使用应用网关，以便与不同类型的应用服务器配合运行。NGINX作为Web服务器可处理约10,000个并发连接，具体数量取决于实际用途。

但NGINX也可用作反向代理服务器，从而提供缓存、负载均衡及其他多种功能。

9:32 现代Web架构

NGINX还可帮助您迁移到现代Web架构，例如将J2EE风格的三层架构迁移到微服务；将HTML和SOAP等复杂协议迁移到REST和消息传递等更轻量的协议，而这正是微服务的重要组成部分；或从持久部署转向运行容器或VM的可变部署。

不再采用固定、静态的基础设施，而是通常使用自行掌控的服务。现在有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系统，并计划扩展到10个数据中心。为支持高可用性，也就是为每个数据中心配备实时备份，他们考虑部署10对BIG‑IP服务器，成本非常高。此外，他们还需要即时重新配置功能，以免更改配置时导致用户掉线。

他们先在Gravatar上测试NGINX，开始向NGINX迁移。Gravatar是一款为用户显示头像的应用。通过测试，他们熟悉了NGINX。随后，他们从F5服务器迁移到NGINX，从而获得了较小且可预测的内存占用和CPU占用。

现在，他们使用36台NGINX服务器，每秒可处理超过70,000个请求和15吉比特的数据［Gbps］。每台服务器的峰值处理能力可达每秒20,000个请求，并且可以动态重新配置和更新。

从报价中可以看出，他们谈的只是小规模部署的成本差异。在这种情况下，NGINX可以帮助您大幅节省成本。但当规模扩大到10对服务器时，成本差异就会非常悬殊。

16:42 客户案例研究：Montana Interactive

Montana Interactive选择NGINX Plus实现高可用性负载均衡。事实上，许多政府服务通过在线方式提供会更便捷、更经济，体验也更好。如果您曾在机动车管理部门或类似机构在线预约，就会明白我的意思。这些网站可以支持投票、纳税等服务。

这类基本政府服务数量众多，而蒙大拿州地域辽阔、人口相对较少，且居民分布十分分散。因此，提供在线服务非常重要，可以避免居民驱车6至8小时才能前往政府办事机构。

蒙大拿州起初大力推进在线服务，但随着服务规模扩大，开始出现会话中断问题。由于一款大型税款缴纳应用，其交易流量每季度都会大幅激增。用户填写大型表单时，可能会突然断开连接，之前填写的内容也会全部丢失。无论是报税还是办理其他复杂业务，这都会让人倍感压力。

他们采用的解决方案是将运行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；支持在任何环境中部署（自有本地服务器、公有云、私有云，或您希望使用的任何其他环境）；能够快速适应变化；没有不合理的合同限制。稍后我会详细说明。现在有请Faisal介绍如何降低成本。

21:22 理由1：大幅降低成本

Faisal：谢谢你，Floyd。五大理由中的第1个是，改用NGINX Plus进行软件应用交付可以大幅降低成本。

回顾20世纪90年代中期，当时扩展网站的唯一方法是购买更大型的服务器。这不仅成本极高，而且可靠性不足，因为这台服务器也是单点故障。

大约就在这一时期，F5首次发布了BIG‑IP，为网站所有者提供了一种不同的架构：无需购买更大型的服务器，而是可以使用BIG‑IP对一组价格较低的服务器进行负载均衡。这样既能降低成本，因为购买BIG‑IP和这些服务器比购买一台巨型服务器更便宜；又能消除单点故障，获得一定的冗余能力。

这是一种出色的架构，在当时堪称革命性突破，市场上也几乎没有其他选择。但在过去20年里，很多事情都发生了变化。其中一个重大变化是服务器成本大幅下降。如今，购买一台性能相当强劲的服务器，花费甚至低于旧金山湾区一个月的房租。

第二个重大变化是，如今已有NGINX这样的开源软件，可以提供与F5 BIG‑IP或Citrix NetScaler相同的功能。借助开源软件，可以免费获得与这些昂贵的大型设备类似的功能。Floyd此前指出，使用NGINX的网站已超过1.6亿个。在排名前10,000的网站中，超过一半运行在NGINX上。

因此，现在有了这款开源软件。与F5相比，它不仅具备所需的全部功能，而且在可扩展性和可靠性方面也不逊于其他商业产品。

23:19 NGINX Plus 与 F5 BIG‑IP 对比

今年早些时候，我做了一些基准测试和成本分析，以下是其中的节选。这里比较的是运行在现成通用硬件上的NGINX Plus软件。本例中的硬件由Dell提供，[我们]将其与不同型号的F5 BIG‑IP进行比较。

这个具体示例采用2000S，即入门级F5 BIG‑IP。我将其与戴尔服务器上两种不同规格的NGINX Plus进行了比较。其中一种的性能略低于F5 BIG‑IP（可在底部查看性能指标），另一种的性能则接近其两倍。

只看右侧一列，NGINX Plus的性能是2000S的两倍，而第1年即可节省78%的成本，其中包括硬件成本和一年的维护支持费用。这些成本节省可一直延续到第5年。即使在5年后，NGINX Plus与Dell服务器组合的总拥有成本仍比F5低58%。

24:37 NGINX Plus 与 Citrix NetScaler 对比

我对Citrix NetScaler也进行了同样的成本比较。这里比较的是入门级NetScaler，即MPX‑5550 Enterprise Edition。

Citrix的许可模式规定，如果需要缓存和内容压缩等基本功能，则必须将许可证升级为Enterprise Edition许可证。对于NGINX，无论是开源版本还是NGINX Plus，均免费提供内容缓存和压缩功能。因此，此处比较的是Citrix NetScaler Enterprise Edition，因为它与NGINX Plus提供的功能更为对等。将Citrix NetScaler替换为NGINX Plus时，可以实现与替换F5时相同的成本节省。

您可以获得符合预期的同等功能和性能，但第1年的支出可减少89%。即使到第5年，硬件成本（本例中为通用Dell服务器）和NGINX Plus软件订阅成本仍可节省75%。

一个关键指标，也是硬件供应商经常提及的指标，是每秒SSL事务数，即每秒可建立的新SSL连接数。在这些平台中，该指标通常通过硬件加速。因此，NetScaler和F5 BIG‑IP配备了用于加速SSL事务的专用硬件，这也推高了这些平台的成本。

我们发现，即使采用软件解决方案，不使用硬件加速，仅依靠CPU的处理能力，也能达到定制硬件的性能水平。我们在提供与硬件加速解决方案相当性能的同时，还能显著节省成本。

这就是理由1：迁移到NGINX Plus可以大幅节省成本。但这不仅仅是成本问题。

26:52 理由2：DevOps需要软件应用交付

基于软件的解决方案还能提供很大的灵活性。改用软件负载均衡器的第2个理由是：如果正在向DevOps转型，应用交付确实需要软件支持。

在大型企业中，F5和NetScaler设备通常部署为流量汇聚点，因此会承载大量彼此无关的流量。同一台F5 BIG‑IP既可以为网络防火墙、企业电子邮件服务器和多个不同的后端企业应用提供负载均衡，也可以为面向外部的企业应用提供负载均衡。它还可以为微服务架构中的API提供负载均衡。因此，它可以为多种对象提供负载均衡。

表面上看，这似乎是一种不错的架构，因为它非常简单，只需让所有流量都经过F5即可。这种方式长期以来确实有效，尤其是在21世纪初，当时私有数据中心占据主导地位，所有应用以及企业依赖的一切都在本地数据中心运行。但过去几年情况发生了变化，如今大多数应用和资源都在迁移到云端。

我所说的云，不仅是指在Amazon中托管面向用户的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 个理由，下面交回给 Floyd。

31:59 理由3：使用一个ADC随处部署

Floyd：谢谢你，Faisal。

借助NGINX，只需一种ADC解决方案，即可在各种环境中部署。“各种环境”是指什么？这意味着本地服务器、公有云、私有云或混合云均可使用同一种解决方案。这既涉及实际应用，也涉及架构设计。

首先，如果您使用的是本地服务器而非云环境，那么我们前面所述的内容都非常适用。许多用户为了获得更高的灵活性、更多功能并节省成本而迁移到NGINX和NGINX Plus，他们正是这种情况：将其部署在本地服务器上。

如果您正在使用云，或计划今后考虑使用云，那么NGINX与硬件ADC根本不具可比性。您无法将硬件ADC迁移到Amazon的数据中心，硬件ADC在这种情况下也无法提供帮助。

目前，硬件ADC开发商确实提供了一些基于软件的解决方案，但在某些情况下，他们仅建议将这些方案用于开发。这些方案无法取代硬件ADC。它们在简单性方面可能具备一定优势，或者说可以“能用就别改”，但当您希望迁移到云端时，这些优势便不复存在。

借助NGINX和NGINX Plus，应用架构可以独立于交付平台。部分云提供商开始增加越来越多可通过API接入的服务。在开发阶段，这非常方便，因为无需考虑如何实现某项功能，只需使用其API来处理负载均衡、缓存或其他功能。但随着规模扩大，每笔事务都会产生少量费用。

当交易量突然达到数千、数万乃至数十万笔时，这些费用就会迅速累积。计费方式非常复杂，难以预测，尤其是费用取决于不断变化的流量。

如果采用基于NGINX或NGINX Plus的方法，那么在任何平台上的操作基本相同。迁移到其他云提供商或重新部署到本地时，差异也很小。

事实上，我们有些客户会在本地服务器和云端之间进行负载均衡。具体是如何实现的？他们配备足够的本地服务器，以满足80%或90%时间内的需求。需要扩展时，无需购买甚至接入新服务器，只需扩展到云端即可。

云端通常比本地服务器慢。由于所有流量都经过负载均衡，只有那些在仅使用内部服务器时会被丢弃的会话才会转到云端。这些会话的延迟会略高，但仍能得到处理，不会进入队列或被丢弃。

从成本角度看，这种方式很有优势，因为只有在突发情况下（例如流量突然激增）才需要为云资源付费。流量激增可能源于新闻报道或产品获得好评；也可能是业务持续超出规划，而内部基础设施尚未完成扩容；还可能是节假日期间出现短期需求。对于每年只使用几周的额外容量，部署两倍数量的服务器并不划算，而扩展到云端即可满足需求。借助NGINX，这一切都能灵活实现，甚至可以自动完成。

35:42 理由#4：快速适应不断变化的需求

NGINX可帮助您快速适应应用不断变化的需求。当需要快速添加服务器或增加服务器对以实现高可用性时，您无法等待硬件完成订购、发货、收货和测试，再为其编写iRules或完成所需的其他软件配置。iRules也是专有技术，只有使用F5服务器时才需要。具备这项技能的应届毕业生并不容易招聘。如果负责iRules的人员离职，也很难找到替代人选。

涉及配置变更时，往往无法等待网络运维团队审批。您也不希望自己的变更与紧急程度较低的事项一起排队等候。

使用NGINX，新项目审批所需的额外工作会少得多。对于价格为2,000美元或3,000美元的服务器，使用NGINX和NGINX Plus时，可以在储物间里存放一些备用硬件。但对于价格高达数万美元的硬件ADC，这种做法并不可行。

这种灵活性、冗余能力，以及随时按需完成任务的能力，是NGINX的核心特性，也是NGINX深受用户喜爱的部分原因。