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

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

云原生应用正快速涌现。虽然它们尚未在应用组合中占据主导地位，但数量正在增加。容器受到关注与云原生（基于微服务的）架构密切相关，因为这类架构在通信和扩展方面本身就依赖基础设施。

通常，微服务通过横向复制实现扩展。也就是说，如果需要增加某项服务的实例，只需复制该服务，并将新实例添加到可用池中，由负载均衡器从中选择实例来响应请求。非常简单。当这些微服务与功能组件高度对应时，这种模式的效果会更好。

这里所说的负载均衡器通常是容器编排器的一个组件，默认采用业界标准的基于TCP的轮询算法。这意味着，当请求到达时，负载均衡器会选择“下一个”资源进行响应。

这种方法常被比作在银行或机动车管理部门排队，但这种比喻并不完全准确。在真正的轮询场景中，请求不会被分配给“下一个可用”资源，而是会被分配给“队列中的下一个”资源，即使该资源正忙。颇具讽刺意味的是，机动车管理部门和本地银行的分流方式实际上比真正的轮询算法更高效。

可不是嘛？

应用也是如此。即使在功能层面，同一服务也可能被克隆，因为这些副本处理的是同一组请求。但由于数据不同，这些请求的执行开销并不总是相同。没错，关键就在于数据。同一个功能请求（或API调用）的执行时间可能更长，也可能更短，具体取决于提交或请求的数据。毕竟，与检索并序列化10条或100条客户记录相比，检索并序列化一条客户记录所需的时间更短。

这正是轮询机制的不足之处，它会引入可能影响性能的波动。运维公理2仍然适用于云原生和基于微服务的架构：随着负载增加，性能会下降。

轮询就像蜜獾一样毫不在意。即使某个资源因大量请求而不堪重负，并且这些请求需要返回大量数据，它也不会理会。无论资源是否准备就绪，轮询都会说：“下一个就是你。”因此，如果用户的请求最终在负载日益加重的资源上排队，用户体验到的性能可能会参差不齐。

如果关注性能（确实应该关注），那么几乎任何其他标准算法都是更好的选择，例如最少连接或最快响应时间算法。简而言之，算法应考虑负载和速度等因素，而不是不加判断地将请求分配给可能并非合适选择的资源。

负载均衡的未来

有些人可能认为，随着协议栈从TCP上升到HTTP，再到HTTP+，这个问题会自行解决。但事实并非如此。无论基于哪一层，分配方式（即负载均衡算法）仍然至关重要。轮询算法并不关注架构，而是关注资源，并根据可用资源池做出决策。无论该资源池用于扩展单个API调用还是整个单体应用，对算法而言都没有区别。

因此，如果负载均衡器足够智能，能识别哪些查询会产生“高于平均水平”的数据量，而且是在查询执行之前就识别出来，那就更好了。像F5 WAF这样的Web应用防火墙能够识别异常结果，但这是在响应阶段进行的，主要用于增强应用安全性。我们需要的是让负载均衡器足够智能，能够预测“超大”的合法响应。

如果负载均衡器具备这种判断能力，就可以在决策时将这一因素纳入考量，从而在可用资源之间更均匀地分配请求。我们真正希望的是，不必指定一种僵化的决策算法。更理想的方式是让负载均衡器根据业务阈值和技术特征做出决策，例如响应时间、预计执行时间、返回的数据量，以及每项资源当前的负载。

归根结底，这种智能只能通过提升可见性和运用机器学习来实现。如果负载均衡器能够从经验中学习，识别出哪些查询比其他查询耗时更长，就可以运用这些知识更合理地分配请求，从而实现一致且可预测的响应时间。

负载均衡不会消失。它是我们应对从网络到应用各层面扩展需求的重要技术手段。但它也需要与基础设施的其他部分同步演进，变得更加动态、自主和智能。

关于作者

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章