在大多数情况下，扩展应用和API的方式基本相同。两者都需要某种形式的负载均衡器（通常是代理），以便将请求分发到资源池中的各个资源。
但在将这些请求分配到各项资源的方式上，两者存在相当显著的差异。采用算法时，实际上是在分配负载；采用架构时，则是在引导负载。这种区分或许显得过于拘泥细节，更适合留给学术界讨论。但事实上，选择算法还是架构，会对扩展能力和性能产生深远影响。由于这两点正是使用负载均衡的主要原因，因此这种区分十分重要。
传统负载均衡
基于算法的负载均衡可以简称为负载均衡，或者用我喜欢的说法，称为传统负载均衡。早在本世纪之交以前，我们就一直使用这种扩展方法。它历史悠久，但这并不意味着应该弃用；恰恰相反。在许多情况下，传统负载均衡是兼顾扩展能力与性能的理想选择。
传统的算法负载均衡，顾名思义，会在决策过程中使用算法。也就是说，它会使用轮询、最少连接、最快响应及其相应的加权分配算法，为每个请求选择响应资源。
这是一个简单直接的决策。算法就像蜜獾一样，不关心其他任何事情，只会根据可用数据执行。如果有5个可用资源，算法就会从中选择一个。仅此而已。
基于算法的负载均衡速度相当快，这一点不难想象。凭借如今的处理能力，执行适当的算法并做出决策并不需要太长时间。除轮询算法和某些加权分配算法外，其他算法都具有状态。这意味着它们必须跟踪一些变量，例如“资源A、B和C目前各有多少个连接？”或“哪个资源对上一次请求的响应速度最快？”负载均衡器必须持续跟踪这些信息。在扩展需要多个长连接的传统单体应用时，这些信息可能会变得非常庞大，需要更多资源来管理。
传统负载均衡尤其适合扩展微服务。这是因为每个微服务只承担一项功能（在理想架构中也应如此）。由于这些服务的容量和性能通常相当，采用基本算法（通常是轮询算法）即可轻松扩展。微服务架构可能需要多次调用服务才能完成单个用户请求，因此必须快速做出决策。基于基本算法的负载均衡因而非常适合此类环境。
基本原则是：如果要扩展功能有限的简单服务，并且这些服务的性能大致相当，那么传统的负载均衡就足够了。这正是容器环境内部的常见情况，也是许多原生扩展功能采用简单算法的原因。
对于其他应用和场景，则需要采用基于架构的负载均衡。
HTTP负载均衡
基于架构的负载均衡是一门艺术（没错，是艺术而非科学）：使用负载均衡器，按照与所扩展应用架构相匹配的方式对请求进行细分和处理。与其说基于架构的负载均衡是在分配流量，不如说是在引导流量。这是因为它利用第7层（通常为HTTP）的信息来确定特定请求应发送到何处。因此，我们通常称之为HTTP负载均衡（此外还有一些更晦涩、更侧重网络的术语）。
在这个通过API开放、基于微服务构建的世界中，请求定向能力日益重要。这是因为需要能够根据版本定向API请求，使用主机名或URI路径将请求分派到特定微服务，或按功能拆分应用。
大多数组织都希望提供一致且易用的API。无论是鼓励公民开发者创建使用该API的新应用，还是让合作伙伴能够轻松连接和集成，一致、简单的API都是确保其得到采用的关键。
但在实际环境中，API往往错综复杂。它们由多个服务（通常是微服务）提供支持，并且可能分布在不同位置，很少局限于单一服务。更复杂的是，与前几代应用相比，API更新更频繁，而且无法保证向后兼容。此外，移动应用可能会同时使用新旧资源，例如与Web应用共享图像，并使用与其他应用相同的API。
要扩展这些“应用”和API，需要从架构层面设计负载均衡。在分配流量之前，需要先对流量进行定向。这意味着要使用支持第7层（HTTP）的负载均衡器，实现URL分派、数据分区和功能分解等架构模式。这些模式本质上都属于架构设计，与传统应用相比，需要更紧密地结合应用或API设计。
在扩展应用、兼顾效率与敏捷性并支持API的过程中，HTTP负载均衡日益重要。
可扩展性需要二者兼顾
在现实环境中，很少会只采用一种扩展方式。这是因为，组织交付的应用组合日益丰富，横跨数十年的开发历程，涉及多种应用架构、平台和技术。几乎没有组织能够声称自己只需支持“现代”应用（除非“现代”是指所有不在大型机上运行的应用）。
因此，在扩展各种应用时，您很可能会接触并使用基于算法和基于架构的负载均衡。了解两者的区别非常重要，因为如果本应使用其中一种方式却采用了另一种，可能会导致性能不佳和／或服务中断，对用户、业务乃至您本人都没有好处。
您会越来越多地看到这两种方法结合使用，以扩展现代应用。有时，两者实际上会整合为一项服务，旨在同时扩展逻辑层（API）和物理层（API背后的实际服务）。应用交付控制器（ADC）通常是实施这种组合方法的平台，因为它们能够同样高效地处理这两方面的扩展。
有时，这两项任务由两个不同的系统执行。例如，在容器化环境中，入口控制器负责架构负载均衡，而内部原生服务通常负责通过算法负载均衡实现扩展。
无论具体如何实施和部署，基于算法和基于架构的负载均衡方法都能在应用和API扩展中发挥作用。要充分发挥两者的优势，关键是让负载均衡方式与应用架构相匹配。
持续扩展。
关于作者
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服务。