负载平衡应用和 API： 算法与架构
大多数情况下，扩展应用程序和 API 基本上是同一件事。 两者都需要某种负载均衡器（通常是代理），并且需要在资源池中分配请求。
但这些请求在各个资源之间的分布方式存在相当大的差异。 对于算法来说，我们实际上是在分配负载，而对于架构来说，我们实际上是在引导负载。 现在，这似乎是一个最好留给学术界去处理的迂腐区别。 事实是，算法和架构之间的选择对规模和性能有着深远的影响。 由于两者都是您使用负载均衡的原因，因此区别就变得很重要。
普通的负载平衡
基于算法的负载均衡可以称为负载均衡，或者我喜欢称之为普通旧式负载均衡。 这是我们从本世纪初就一直使用的规模方法。 它的年龄并不意味着应该被抛弃；恰恰相反。 在许多情况下，普通的旧式负载均衡是平衡规模和性能的最佳选择。
正如人们可能猜测到的那样，普通的旧算法负载均衡在其决策过程中使用算法。 这意味着使用循环、最少连接、最快响应及其加权等分布算法来选择资源来响应任何给定的请求。
这是一个直接的决定。 就像蜜獾一样，算法不关心除了根据可用数据执行之外的任何事情。 如果有五种可用资源，则将根据算法从中选择一种。 时期。
正如您所想象的，基于算法的负载均衡非常快。 利用当今的处理能力来执行适当的算法并做出决策并不需要很长时间。 除循环和某些加权分布算法外，其他算法都是有状态的。 这意味着他们必须跟踪诸如“目前与资源 A、B 和 C 有多少个连接？”或“哪个资源对其上一个请求的响应最快？”之类的变量。 负载均衡器必须跟踪此信息。 在需要多个长寿命连接的传统单片应用的扩展环境中，这些信息可能会变得非常庞大，并且需要更多的资源来管理。
普通的旧式负载均衡的优势在于扩展微服务。 这是因为每个微服务都有（或在理想架构中应该有）一个功能。 通过采用基本算法（通常是循环算法）可以轻松扩展这些服务，因为它们的容量和性能通常是相当的。 由于微服务架构的性质，可能需要多个服务调用才能满足单个用户请求，因此必须快速做出决策。 这使得基于基本算法的负载均衡成为此类环境的良好选择。
基本的经验法则是：如果您使用有限的功能集来扩展简单服务，并且这些功能在性能方面通常是等效的，那么普通的负载均衡就足够了。 这就是您在容器环境中看到的，也是为什么如此多的本机扩展功能都基于简单算法的原因。
对于其他应用和情况，您将需要考虑基于架构的负载均衡。
HTTP 负载平衡
基于架构的负载均衡是一门艺术（是的，是艺术而不是科学），即使用负载均衡器以与其正在扩展的应用的架构相匹配的方式对请求进行切分。 基于架构的负载均衡更多的是引导流量而不是分配流量。 这是因为它利用第 7 层（通常是 HTTP）来决定给定请求需要去哪里，也是我们倾向于称之为 HTTP 负载均衡（以及其他更深奥的（和以网络为中心）的术语）的原因。
在由 API 公开并基于微服务的世界中，引导请求的能力变得越来越重要。 这是因为您需要能够根据版本定向 API 请求，使用主机名或 URI 路径将请求分派到特定的微服务，或分解应用的功能。
大多数组织都希望公开一个易于使用的一致 API。 无论是为了鼓励公民开发者创建使用 API 的新应用，还是为了让合作伙伴轻松连接和集成，一致、简单的 API 对于确保采用都是至关重要的。
但现实中的API往往很混乱。 它们由多种服务（通常是微服务）支持，并且可能分布在不同地点。 它们很少局限于单一的服务。 事情很复杂，它们比前几代应用程序更新得更频繁，并且不可靠地向后兼容。 同样，移动应用程序可以同时利用新旧资源——与网络应用程序共享图像并使用与其他应用程序相同的 API。
要扩展这些“应用程序”和 API，需要采用负载均衡的架构方法。 您需要在分配流量之前对其进行引导，这意味着使用支持第 7 层（HTTP）的负载均衡器来实现 URL 调度、数据分区和功能分解等架构模式。 这些模式中的每一种都具有架构性，并且与传统应用程序相比，需要对应用或 API 设计有更大的亲和力。
在扩展应用程序、平衡效率和灵活性以及支持 API 的过程中，HTTP 负载均衡变得越来越重要。
可扩展性需要两者
在现实世界中，你很少会只看到一种类型的尺度。 这是因为组织越来越多地提供跨越数十年开发、应用程序架构、平台和技术的强大应用集。 很少有组织可以宣称只支持“现代”应用（除非现代包括任何不在大型机上运行的应用程序）。
因此，您可能会看到并使用算法和架构负载均衡来扩展各种应用。 这就是为什么理解差异很重要，因为在另一种更合适时使用一种可能会导致性能不佳和/或中断，这对用户、企业或您来说都不是好事。
您将越来越多地看到两种方法结合起来扩展现代应用。 有时，两者实际上会作为单一服务存在，旨在扩展逻辑（API）和物理（API 背后的实际服务）。 应用交付控制器 (ADC) 通常是实施组合方法的平台，因为它们能够以相同的速度执行两种操作。
有时这些是由两个不同的系统执行的。 例如，在容器化环境中，入口控制器负责架构负载均衡，而内部本机服务通常负责使用算法负载均衡进行扩展。
无论实施和部署细节如何，事实是，基于算法和架构的负载均衡方法在扩展应用程序和 API 方面都发挥着作用。 最大限度地发挥它们的优势的关键是将负载均衡与应用架构相匹配。
扩大规模。