意外后果： 代理负载过大

如今，可扩展性的需求已不再是一个问题。 答案永远是肯定的，你需要它。 业务增长取决于applications的运营增长，毕竟，应用程序是当今商业模式不可或缺的一部分 - 无论在哪个行业。 因此，系统通常会在需要的时候（而不是如果需要的话）部署实现该规模所必需的东西。 这通常意味着代理。 因此，负责扩展的代理（通常是负载均衡器）是任何现代架构中非常关键的组件。

这些代理不仅仅是一种扩展机制；而且它们越来越多地被要求通过自动扩展的奇迹自动地做到这一点。 这个简单的带连字符的单词含义丰富，例如能够以编程方式指示系统不仅启动额外容量，而且还能确保负责可扩展性的代理知道其存在并能够将请求发送给它。

人们认为任何有价值的代理都具有所需的编程接口。 毕竟，API 经济不仅仅涉及应用程序和人之间的共享，还涉及系统之间的共享——本地、外部和云端。 但我们常常没有意识到，向负载平衡代理添加新资源的任务是在管理或控制平面上进行的，而不是在数据平面上。

这很有道理。 我们不想在收集统计数据或操作系统配置时干扰系统的运行。 这是不允许的，特别是在我们试图增加容量的情况下，因为系统正在全力运行，向热切的用户提供应用程序。

但当相反的情况发生时会发生什么呢？ 当系统的运行干扰了管理系统的能力时？

您的自动缩放（或手动缩放）将会失败。 这意味着应用程序容量不会增加，业务将受到影响。

这很糟糕，就好像你需要我告诉你一样。

发生这种情况的原因是许多代理（在构建时并未考虑到这个悖论）共享控制平面和数据平面的系统资源。 它们之间没有隔离。 提供应用程序的同一网络用于管理代理。 分配给交付应用程序的相同 RAM 和计算也被分配给管理代理。 在负载下，这两者中只有一个能够获得资源。 如果您尝试将应用程序资源添加到代理以便扩展，但又无法访问系统来执行此操作，那么您就很麻烦了。

这就是为什么从可管理性的角度来评估代理的选择很重要。 不仅仅是易于管理。 不仅仅是它的 API 和脚本功能，还有其在负载下的可管理性。 专为大规模设计的代理应该有一组单独的资源，指定为“管理”资源，以确保无论数据平面在交付应用程序时负载有多大，它仍然可以被管理和监控。

在网络世界中，我们称之为带外管理，因为它发生在数据路径（主路径、关键路径）之外。

在带外管理负载下的代理的能力对于应用程序以及通过它们扩展业务的整体能力（自动或手动）非常重要。