负载平衡的未来取决于数据

云原生应用正在快速构建。 尽管它们目前还没有在应用程序组合中占据主导地位，但它们的数量正在增加。 对容器的兴趣与云原生（基于微服务）架构密切相关，因为其固有依赖于基础设施的通信和扩展。

通常，微服务的扩展是通过水平克隆实现的。 也就是说，如果我们需要给定服务的更多实例，我们只需克隆它并将其添加到负载均衡器选择响应请求的可用池中。 非常简单。 当这些微服务紧密代表功能元素时，该模型效果会更好。

所讨论的负载均衡器通常是容器编排器的一个组件，并默认采用行业标准的基于 TCP 的循环算法。 这意味着一个请求进入，负载均衡器选择“下一个”资源进行响应。

这种方法通常被比作银行或车辆管理局的排队。但这并不完全准确。 在真正的循环场景中，您不会被引导至“下一个可用”资源。 您将被引导至“下一个”资源 — — 即使该资源正忙。 具有讽刺意味的是，车辆管理处和当地银行的分发方法比真正的循环算法更有效。

我知道，对吧？

对于应用来说也是如此。 相同的服务——即使在功能级别——也可能被克隆，因为它们服务于同一组请求。 但由于数据的原因，这些请求在执行方面并不总是平等的。 没错，就是数据。 根据提交或请求的数据，相同的功能请求或 API 调用可能需要更多或更少的时间来执行。 毕竟，检索和序列化单个客户记录比检索和序列化十个或一百个客户记录花费的时间要少。

这就是循环赛出现问题的地方，并且会引入可能影响性能的可变性。 操作公理＃2仍然适用于云原生和基于微服务的架构：随着负载的增加，性能会下降。

循环赛就像蜜獾。 它并不关心资源是否因为带有大量数据集作为响应的请求而超载。 循环赛无论你是否准备好都会说“你是下一个”。 对于那些请求在日益负担沉重的资源队列中排队的用户来说，这可能会导致性能不均衡。

如果您关心性能（您应该关心），那么更好的选择就是任何其他标准算法，例如最少连接或最快响应时间。 基本上，您希望您的算法考虑负载和/或速度，而不是简单地盲目地将请求强加到可能不是最佳选择的资源上。

负载平衡的未来

有些人可能认为，随着我们从 TCP 到 HTTP 再到 HTTP+，这个问题将自行解决。 事实根本不是这样。 无论您基于哪一层，分发方法（负载均衡算法）仍然是相关的。 循环不关心架构，它关心资源并根据可用池做出决策。 无论该池是用于扩展单个 API 调用还是整个整体，对算法来说都没有区别。

因此，如果负载均衡器足够智能，能够在执行之前识别查询何时会产生“超过平均值”的数据，那就太好了。 F5 WAF等 Web应用防火墙能够识别异常结果 - 但这取决于响应，主要是为了实现更好的应用安全性。 我们需要的是让负载均衡器足够智能，能够预测“超大”的合法响应。

如果负载均衡器具有这种辨别能力，它就可以将其纳入决策之中，更均匀地在可用资源之间分配请求。 我们真正想要的是不要被迫指定一个严格的算法来做出决策。 如果负载均衡器可以根据业务阈值和技术特征（例如响应时间、预计执行时间、返回的数据大小以及每个资源当前的负载）做出决策，那就更好了。

归根结底，这种智能只有通过更好的可视性和机器学习才能实现。 如果负载均衡器可以通过经验学习来识别哪些查询比其他查询花费更多时间，那么它就可以应用这些知识来更好地分配请求，从而实现一致、可预测的响应时间。

负载平衡不会消失。 这是我们对从网络到应用的一切扩展的最佳技术响应。 但它确实需要与其他基础设施一起发展，才能变得更加动态、自主和智能。