容器扩展的艺术： 分配

扩展容器不仅仅是在服务前面放置一个代理然后走开。 扩展不仅仅是分布，在快节奏的容器世界中，需要五种不同的功能来确保扩展：重试，断路器，发现，分发和监控。

在这篇有关容器扩展艺术的文章中，我们将深入探讨分布问题。

分配

任何事物扩展的秘诀始终在一定程度上依赖于请求如何在有限的资源集上分布。 甚至云及其看似无限的计算供应也无法改变这一现状。 在收到请求时，可以接受并处理该请求的资源列表是有限的。 时期。

那么，决定将请求发往何处就变得相当重要。 将其发送到错误的资源，性能可能会受到影响。 将其发送给正确的资源，消费者/员工会对结果感到满意。

在规模扩大的早期，这些决策完全基于算法。 循环赛。 最少连接。 最快的响应。 这些坚定的机制今天仍然存在，但已慢慢地成为决策过程中的另一个因素，而不是唯一因素。

这是因为我们不再仅仅依赖基于连接的决策过程（又称“普通的负载均衡”）。 当负载均衡主要用于管理 TCP 连接时，基于连接的分发方案是有意义的。 但现在，规模不仅取决于算法，也取决于架构，并且请求的分发可能是一个复杂的计算，涉及第 4 层协议之上（字面意思）和之外的许多变量。

使分布更加复杂的现实是，当今的架构本身越来越分散。 不仅跨云，还跨容器。 同一应用程序（或 API）的多个版本可能同时投入使用。 负责分发请求的系统必须了解并能够区分它们并确保传递到正确的端点。

如今，决策不仅基于连接容量，而且越来越多地基于第 7 层（HTTP）参数。 主机名。 API 方法（又名 URI）。 API 密钥。 嵌入版本号的自定义 HTTP 标头。 地点。 设备。 用户。 根据请求所处的上下文来评估请求，并在微秒内做出决策。

当今的分发需要分层的架构方法。 对应用程序架构了解得越深，获得的精细度就越低。 当代理在同一微服务的 X 个克隆之间做出负载均衡决策时，它很可能只使用传统的算法驱动方程。 同时，在环境的外部边缘，入口控制器有时会根据 HTTP 层变量做出复杂的决策。

从外部来看，分布是由架构驱动的。 在内部，通过算法。

两者都是扩展容器的关键组件，或许也是最关键的组件。

两者都依赖于有关其可能分发请求的资源的状态（健康状况）的准确、实时信息。 我们将在本系列的接下来几篇文章中讨论监控。