负载均衡。人们普遍认为，我们需要并依赖负载均衡，每天都用它来扩展应用（也希望能缩减应用规模）。负载均衡已成为关键基础设施，不仅负责扩展应用以满足需求，还要确保企业赖以提高生产力和实现盈利的应用及服务持续可用。
因此，我们需要重新审视负载均衡。如今，运维人员往往需要负责预置、配置和部署这些神奇的服务，也越来越倾向于将负载均衡视为一种战术性工具，但负载均衡不应仅限于此。从战略角度看，负载均衡可以提升性能、降低风险，并帮助更高效地利用交付应用所需的资源。它远比人们常说的“管道”更智能。了解几个要点，有助于运维人员进一步思考如何利用负载均衡来支持应用。
下面直接介绍运维人员确实需要了解的3个负载均衡要点。
1. 算法是相对的
首先要说的是，轮询应该是最不值得一提的算法，不过这一点您早就知道了，对吧？所以我们略过它，来讨论更智能的算法，例如最少连接和最快响应时间。在制定策略以平衡性能与资源的高效利用时，这些算法当然是更好的选择。每种算法都会考虑应用特征（或至少是交付应用的平台特征），而这些特征对于决定由哪个应用实例（或者容器）接收下一个请求至关重要。最少连接算法认为，连接数较少的实例拥有更多容量，因此更有能力立即处理当前请求。它优先考虑容量利用效率，而非性能。
最快响应时间算法则处于另一端，它根据性能来决定将请求定向到哪个实例。实例响应越快，被选中的频率就越高。根据运维中的基本规律（负载越高，性能越低），负载较轻的服务器最终会响应得更快，因而被选中。虽然这也在一定程度上兼顾了容量利用效率，但该算法始终优先考虑性能，而非容量。
但请注意这些算法的名称：最少和最快。假设两只乌龟在人行道上赛跑，其中一只会更快，尽管它们的速度在我们看来都很“慢”。最少连接算法也是如此。在99和100之间选择时，99显然是两者中较少的一个。
为何重要
负载均衡管理请求的方式会直接影响性能和可用性。这两项关键特性最终会影响客户互动和员工生产力。优化包含负载均衡的架构，有助于企业提高生产力并实现利润目标。
深入了解：
2. “即时故障转移”（往往）只是一个误区
随着云和软件定义数据中心的兴起，弹性伸缩已成为扩展应用的常用方式。弹性伸缩要求能够按需扩容和缩容，从而优化资源及预算的使用。既然可以按需扩容，何必过度配置？同样，依赖冗余原则的高可用性（HA）架构也几乎已显得过时。主应用实例发生故障的可能性并不高，何必让闲置资源随时待命？这简直是在浪费资本和运营预算！让这恼人的备用资源退场吧！
虽然按需故障转移和扩展在理论上很理想，但实践起来并没有那么简单。事实上，即使是虚拟服务器（或云服务器，或您习惯使用的其他称谓），启动也需要时间。如果等到主服务器发生故障或容量已满后，您（或自动化系统）才启动另一台服务器，就已经太迟了。云环境中的容量规划不能沿用传统环境中的计算方法。现在，容量阈值的计算需要同时考虑资源消耗速率和另一台服务器的启动时间，才能随需求无缝扩展。
故障转移也是如此。如果主服务器发生故障，启动替代服务器需要一定时间。在此期间，用户会遇到连接中断或超时，可能转而选择竞争对手，甚至去看最新的猫咪视频。闲置的备用服务器看似浪费资源，就像保险一样，但真正需要时，您会庆幸它随时可用。尤其是当该应用负责客户互动或创造收入时，即使只有几分钟的停机，也可能带来风险和后续成本；相比之下，维持备用服务器随时待命的成本或许是值得的。
值得注意的是，容器凭借极快的启动速度，似乎有望解决这些问题。如果可用性、性能和成本同等重要，不妨开始探索容器在平衡这三者方面能够带来的价值。
为何重要
停机会造成高昂成本。与其追究停机原因，不如从一开始就避免停机。为应对故障，必须部署适当的架构和故障转移方案，确保持续可用性，为业务成功提供关键保障。
深入了解：
3. 客户端IP并非真实的客户端IP。
在应用从开发环境迁移到生产环境时出现的各种问题中，这可能是最常见、也最容易避免的问题。事实上，大多数负载均衡服务（至少可靠的服务都是如此）都属于代理。这意味着客户端连接到代理，再由代理连接到应用。两段连接都使用TCP传输HTTP流量，因此必须遵循网络通信规则。源IP（也就是您以为的客户端IP）实际上是代理的IP地址。如果基于IP地址执行安全控制、身份验证或计量，就会造成严重问题。从HTTP标头中提取的值并不是所需的值。
业界基本已形成惯例，利用HTTP自定义标头来解决这一问题。X-Forwarded-For标头可能正是您真正需要的。代理转发请求时，会将真实的客户端IP地址写入此标头。遗憾的是，它并非正式标准，而更像是业界约定俗成的事实标准，因此需要进行验证。
关键在于，您要查找的客户端IP地址并不是您以为的那个。因此，开发人员需要在依赖该信息的应用迁移到生产环境之前考虑到这一点，以免应用突然停止工作。
为何对业务至关重要
与开发或测试环境相比，在生产环境中排查问题的成本要高得多。查找和修复问题所需的时间都会对项目进度产生负面影响，并延缓产品上市，而在应用驱动的世界中，上市速度对保持竞争优势和实现业务成功至关重要。及早发现这一常见问题并在开发或测试阶段加以解决，可确保更快、更顺畅地部署到生产环境并推向市场。
深入了解：
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。