(翻译)现代网络负载平衡和代理简介（一）

最近注意到，关于现代网络负载均衡和代理可用的介绍性教育材料很少。心想：怎么会这样呢？负载均衡可是关于构造可靠的分布式系统所需核心概念之一啊，有高质量的信息么？我搜索了相关信息确实很少。维基百科关于负载均衡和代理服务的文章包含一些概念但不包含对主题的流利处理，尤其是它涉及到现代微服务架构，打开谷歌搜索负载均衡，主要都是那些对流行语很重视的供应商页面。

在这篇文章中，希望通过对现代网络负载平衡和代理的简单介绍来拨正缺乏信息情况。坦白说，关于这个负载均衡和代理可以写一本书来说，不过由于博客不能太长，我尽可能的将复杂的主题压缩成简单的来说，根据兴趣和反馈，后期我会考虑写一些更详细关于个别主题的后续帖子。

什么是网络负载均衡和代理？

维基百科是这样定义负载均衡的：

负载平衡（Load balancing）是一种计算机技术，用来在多个计算机（计算机集群）、网络连接、CPU、磁盘驱动器或其他资源中分配负载，以达到最优化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。 使用带有负载平衡的多个服务器组件，取代单一的组件，可以通过冗余提高可靠性。负载平衡服务通常是由专用软件和硬件来完成。 主要作用是将大量作业合理地分摊到多个操作单元上进行执行,用于解决互联网架构中的高并发和高可用的问题。

上面的定义适用于计算机的各个方面，不仅仅是网络。操作系统使用负载均衡通过物理处理器来安排任务，容器协调器（如Kubernetes）使用负载平衡来计划跨计算群集的任务，网络负载均衡使用负载均衡来跨可用的后端调度网络任务，本文的其余部分仅包含网络负载均衡

图一显示了网络负载平衡的高级概述。一些客户端正在从一些后端请求资源。负载均衡器位于客户端和后端之间，并且在高层次上执行几项关键任务：

服务发现：在系统中哪些后端可用？他们的地址是什么（也就是负载均衡器该如何和他们通信）？

健康检查：（？我觉得叫安全检查吧？）：哪些后端目前是安全的并且可以接受请求？

负载均衡：应该使用什么算法来平衡后端的各个请求。

在分布式系统中正确使用负载均衡能够提供以下几点好处：

命名抽象：客户端可以通过预定义的机制寻找负载均衡器，而不是每个客户端都需要挨个了解后端（服务发现），可以将名称解析行为委托给负载均衡器。预定义机制包括内置库和众所周知的DNS / IP /端口位置，并将在下面更详细地讨论。

容错：通过运行状况检查和各种算法技术，负载均衡器可以有效地跳过坏的或过载的后端。这意味着操作员通常可以在休闲时修复坏后端，而不是紧急情况。

成本和性能优势：分布式系统网络很少是同质的。该系统可能跨越多个网络区域。在区域内，网络通常以相对不足的方式构建。在区域之间，超额认购成为常态。 （在此上下文中，over / underubscription指的是通过NIC消耗的带宽量占路由器之间可用带宽的百分比）。智能负载平衡可以尽可能地保持区域内的请求流量，从而提高性能（减少延迟）并降低整体系统成本（区域之间所需的带宽和光纤更少）。

负载均衡和代理

在谈论网络负载平衡器时，术语负载平衡器和代理在业内大致可互换使用。这篇文章也会将这些条款视为一般等同的。 （注意并非所有代理都是负载均衡器，但绝大多数代理都将负载均衡作为主要功能）。

有些人可能会争论，当负载均衡作为嵌入式客户端库的一部分完成时，负载均衡器实际上并不是代理。但是，我认为这种区分会给已经令人困惑的话题带来不必要的复杂性。负载平衡器拓扑的类型将在后面详细讨论，但是这篇文章将嵌入式负载均衡器拓扑视为代理的特殊情况;应用程序通过嵌入式库进行代理，该库提供与应用程序进程之外的负载均衡器相同的抽象概念。

L4（传输层）负载均衡

在讨论当今整个行业的负载平衡时，解决方案通常分为两类：L4和L7。这些类别涉及OSI模型的第4层和第7层。由于在讨论L7负载平衡时会变得明显，我认为使用这些术语是很糟糕的。 OSI模型是负载平衡解决方案复杂性的非常差的近似，其包括传统的第4层协议（例如TCP和UDP），但通常最终包括在各种不同OSI层的位和协议。即，如果L4 TCP负载均衡器也支持TLS终端，它现在是L7负载均衡器吗？

图2显示了传统的L4 TCP负载均衡器。在这种情况下，客户端与负载均衡器建立TCP连接。负载均衡器终止连接（即直接响应SYN），选择后端，并与后端建立新的TCP连接（即发送新的SYN）。该图的细节并不重要，将在下面专门讨论L4负载平衡的部分中详细讨论。

本节的关键点是L4负载均衡器通常仅在L4 TCP / UDP连接/会话级别运行。因此，负载均衡器大致来回抽取字节，并确保来自同一会话的字节在同一后端结束。 L4负载均衡器不知道它正在抽取字节的任何应用程序细节。字节可以是HTTP，Redis，MongoDB或任何其他应用程序协议。

L7（应用层）负载均衡

L4负载平衡很简单，仍然可以广泛使用。 L4负载平衡有哪些缺点需要投资L7（应用程序）负载平衡？以下面的L4特定案例为例：

• 两个gRPC / HTTP2客户端想要与后端通信，因此它们通过L4负载均衡器连接。
• L4负载均衡器为每个传入的TCP连接建立单个传出TCP连接，从而产生两个传入和两个传出连接。
• 但是，客户端A通过其连接每分钟发送1个请求（RPM），而客户端B通过其连接发送每秒50个请求（RPS）。

在前面的场景中，选择处理客户端A的后端将处理大约3000倍的负载，然后选择后端来处理客户端B！这是一个大问题，并且通常首先会破坏负载平衡的目的。另外注意，任何多路复用，保持活动协议都会出现此问题。 （多路复用意味着通过单个L4连接发送并发应用程序请求，并且保持活动意味着在没有活动请求时不关闭连接）。由于效率原因，所有现代协议都在发展为多路复用和保持活动（创建连接通常很昂贵，特别是当使用TLS加密连接时），因此L4负载平衡器阻抗不匹配随着时间的推移变得更加明显。此问题由L7负载平衡器修复。

图3显示了L7 HTTP / 2负载均衡器。在这种情况下，客户端与负载均衡器建立单个HTTP / 2 TCP连接。然后负载平衡器继续进行两个后端连接。当客户端向负载均衡器发送两个HTTP / 2流时，流1被发送到后端1，而流2被发送到后端2.因此，即使多路复用具有截然不同的请求负载的客户端也将在后端有效地平衡。这就是L7负载平衡对现代协议如此重要的原因。 （L7负载平衡由于能够检查应用程序流量而产生巨大的额外优势，但将在下面详细介绍）。

L7负载均衡和OSI模型

正如我在上面关于L4负载平衡的部分所述，使用OSI模型来描述负载平衡功能是有问题的。原因是L7，至少如OSI模型所描述的那样，本身包含多个离散的负载平衡抽象层。例如，对于HTTP流量，请考虑以下子层：

可选的传输层安全性（TLS）。请注意，大家争论TLS属于哪个OSI层。为了便于讨论，我们将考虑TLS L7。

• 物理HTTP协议（HTTP / 1或HTTP / 2）。
• 逻辑HTTP协议（标头，正文数据和预告片）。
• 消息传递协议（gRPC，REST等）。
• 复杂的L7负载平衡器可以提供与上述每个子层相关的特征。

另一个L7负载均衡器可能只有一小部分功能将其置于L7类别中。简而言之，从功能比较的角度来看，L7负载均衡器的格局要比L4类别复杂得多。 （当然，本节刚刚介绍了HTTP; Redis，Kafka，MongoDB等都是受益于L7负载平衡的L7应用程序协议的例子）。

负载均衡器功能

在本节中，我将简要总结负载平衡器提供的高级功能。并非所有负载平衡器都提供所有功能。

服务发现

服务发现是负载均衡器确定可用后端集的过程。方法多种多样，一些例子包括：

• 静态配置文件
• DNS
• Zookeeper,Etcd,Consul......
• Envoy’s universal data plane API.

健康检查

运行状况检查是负载均衡器确定后端是否可用于提供流量的过程。健康检查通常分为两类：

• 活动：负载均衡器定期发送ping（例如，对/ healthcheck端点的HTTP请求）到后端，并使用它来衡量运行状况。
• 被动：负载均衡器从主数据流中检测健康状态。例如，如果一行中存在三个连接错误，则L4负载均衡器可能会判定后端是不健康的。如果一行中有三个HTTP 503响应代码，则L7负载均衡器可能会判断后端是否运行状况不佳。

负载均衡

是的，负载平衡器必须实际平衡负载！给定一组健康的后端，如何选择后端来提供连接或请求？负载均衡算法是一个活跃的研究领域，范围从简单的算法，如随机选择和循环，到考虑可变延迟和后端负载的更复杂的算法。考虑到其性能和简单性，最受欢迎的负载平衡算法之一被称为2个最小请求负载平衡的功能。

会话保持有时候又叫做粘滞会话

在某些应用程序中，同一会话的请求到达相同的后端非常重要。这可能与缓存，临时复杂构造状态等有关。会话的定义各不相同，可能包括HTTP cookie，客户端连接的属性或某些其他属性。许多L7负载均衡器都支持粘性会话。顺便说一句，注意到会话粘性本质上是脆弱的（托管会话的后端可能会die），因此在设计依赖它们的系统时要小心。

TLS终止

TLS的主题及其在边缘服务和保护服务到服务通信中的作用值得自己发表。据说，许多L7负载均衡器进行大量的TLS处理，包括终止，证书验证和固定，使用SNI的证书服务等。

观测

正如在会谈中所说的那样：“可观察性，可观察性，可观察性。”网络本质上是不可靠的，负载均衡器通常负责导出统计数据，跟踪和日志，帮助运营商找出问题所在，以便他们能够解决问题。负载平衡器的可观察性输出差异很大。最先进的负载平衡器提供丰富的输出，包括数字统计，分布式跟踪和可自定义的日志记录。我要指出，增强的可观察性不是免费的;负载均衡器必须做额外的工作来生产它。但是，数据的好处大大超过了相对较小的性能影响。

安全和DoS缓解

特别是在边缘部署拓扑中（见下文），负载平衡器通常实现各种安全功能，包括速率限制，身份验证和DoS缓解（例如，IP地址标记和识别，缓送等）。

配置和控制平面

需要配置负载平衡器。在大型部署中，这可能成为一项重大任务。通常，配置负载平衡器的系统称为“控制平面”，并且在其实现中变化很大。有关此主题的更多信息，请参阅我在服务网格数据平面与控制平面上的帖子。

其他

本节刚刚介绍了负载均衡器提供的功能类型。有关L7负载平衡器的部分，请参见其他讨论。

负载均衡器拓扑类型

现在我已经介绍了负载均衡器的概况，L4和L7负载均衡器之间的差异，以及负载均衡器功能的摘要，将继续介绍部署负载均衡器的各种分布式系统拓扑。 （以下每种拓扑适用于L4和L7负载平衡器）。

图4中所示的中间代理拓扑可能是获得大多数读者负载平衡的最常用方法。此类别包括Cisco，Juniper，F5等硬件设备;亚马逊的ALB和NLB以及谷歌的云负载均衡器等云软件解决方案;和纯软件自托管解决方案，如HAProxy，NGINX和Envoy。中间代理解决方案的专家是用户简单性。通常，用户通过DNS连接到负载均衡器，无需担心其他任何问题。中间代理解决方案的缺点是代理（即使是群集）是单点故障以及扩展瓶颈。中间代理通常也是黑盒子，使操作变得困难。是客户端观察到的问题吗？在物理网络？在中间代理？在后端？这很难说。

图5中所示的边缘代理拓扑实际上只是中间代理拓扑的变体，其中负载均衡器可通过Internet访问。在这种情况下，负载均衡器通常必须提供额外的“API网关”功能，例如TLS终止，速率限制，身份验证和复杂的流量路由。边缘代理的优缺点与中间代理相同。需要注意的是，在面向Internet的大型分布式系统中部署专用边缘代理通常是不可避免的。客户端通常需要使用服务所有者无法控制的任意网络库通过DNS访问系统（使以下部分中描述的嵌入式客户端库或sidecar代理拓扑不能直接在客户端上运行）。另外，出于安全原因，希望具有单个网关，通过该网关，所有面向因特网的流量进入系统。

为了避免中间代理拓扑中固有的单点故障和扩展问题，更复杂的基础架构已经转向将负载均衡器通过库直接嵌入到服务中，如图6所示。库支持的功能差别很大，但有些这类中最知名且功能最丰富的是Finagle，Eureka / Ribbon / Hystrix和gRPC（松散地基于称为Stubby的内部Google系统）。基于库的解决方案的主要优势在于它将负载均衡器的所有功能完全分配给每个客户端，从而消除了之前描述的单点故障和扩展问题。基于库的解决方案的主要内容是，库必须以组织使用的每种语言实现。分布式架构正变得越来越“多语言”（多语言）。在这种环境下，以多种不同语言重新实现极其复杂的网络库的成本可能会变得令人望而却步。

最后，在大型服务架构中部署库升级可能会非常痛苦，因此很有可能许多不同版本的库将在生产中同时运行，从而增加了操作认知负载。 综上所述，上述图书馆已经成功地为那些能够限制编程语言扩散并克服库升级难度的公司提供了帮助。

嵌入式客户端库负载平衡器拓扑的一种变体是图7中所示的边车代理拓扑。近年来，这种拓扑已经被普及为“服务网格”。边车代理背后的想法是以轻微为代价通过跳跃到不同进程的延迟惩罚，可以在没有任何编程语言锁定的情况下获得嵌入式库方法的所有好处。在撰写本文时，最受欢迎的边车代理负载均衡器是Envoy，NGINX，HAProxy和Linkerd。有关边车代理方法的更详细的处理，请参阅我的博客文章介绍Envoy以及我在服务网格数据平面与控制平面上的帖子。

不同负载均衡器拓扑的总结和优缺点

• 中间代理拓扑通常是最容易使用的负载平衡拓扑。由于单点故障，缩放限制和黑盒操作，它不足。
• 边缘代理拓扑类似于中间代理，但通常无法避免。
• 嵌入式客户端库拓扑提供了最佳性能和可伸缩性，但是需要以每种语言实现库以及需要跨所有服务升级库。 sidecar代理拓扑的性能不如嵌入式客户端库拓扑，但不受任何限制。

总的来说，我认为边车代理拓扑（服务网格）正在逐步取代所有其他拓扑以进行服务到服务通信。在流量进入服务网格之前，始终需要边缘代理拓扑。

L4负载平衡的当前技术水平

L4负载平衡器是否仍然相关？

这篇文章已经讨论了L7负载平衡器对于现代协议的重要性，并将在下面进一步详细介绍L7负载平衡器功能。这是否意味着L4负载平衡器不再相关？没有！虽然在我看来L7负载平衡器最终将完全取代L4负载平衡器以进行服务到服务通信，但L4负载平衡器在边缘仍然非常相关，因为几乎所有现代大型分布式架构都使用双层L4 / L7负载平衡架构用于互联网流量。在边缘部署中在L7负载平衡器之前放置专用L4负载平衡器的好处是：

• 由于L7负载平衡器执行的应用程序流量的分析，转换和路由更加复杂，因此它们可以处理相对较小的原始流量负载（以每秒数据包数和每秒字节数衡量），而不是优化的L4负载均衡器。这一事实通常使L4负载平衡器成为处理某些类型的DoS攻击（例如，SYN泛洪，通用数据包泛洪攻击等）的更好位置。
• L7负载平衡器往往更积极地开发，更频繁地部署，并且比L4负载平衡器具有更多错误。在L7负载均衡器部署期间可以进行健康检查和排放的前置L4负载平衡器比现代L4负载平衡器（通常使用BGP和ECMP）的部署机制要容易得多（下面有更多内容）。最后，因为L7负载平衡器更容易出现错误，纯粹是由于其功能的复杂性，拥有可以绕过故障和异常的L4负载平衡器可以使整个系统更加稳定。

在下面的部分中，我将介绍中/边缘代理L4负载平衡器的几种不同设计。以下设计通常不适用于客户端库和边车代理拓扑。

第二种类型的L4负载均衡器是直通负载均衡器，如图9所示。在这种类型的负载均衡器中，负载均衡器不会终止TCP连接。相反，在发生连接跟踪和网络地址转换（NAT）之后，每个连接的数据包将转发到选定的后端。首先，让我们定义连接跟踪和NAT：

• 连接跟踪：是跟踪所有活动TCP连接状态的过程。这包括诸如握手是否已完成，是否已收到FIN，连接已空闲多长时间，已为连接选择了哪个后端等数据。
• NAT：NAT是使用连接跟踪数据在数据包遍历负载均衡器时更改数据包的IP /端口信息的过程。

使用连接跟踪和NAT，负载均衡器可以通过从客户端到后端的大多数原始TCP流量。例如，假设客户端正在与1.2.3.4:80对话，所选后端位于10.0.0.2:9000。客户端TCP数据包将在1.2.3.4:80到达负载均衡器。然后，负载均衡器将使用10.0.0.2:9000交换数据包的目标IP和端口。它还将交换数据包的源IP和负载均衡器的IP地址。因此，当后端响应TCP连接时，数据包将返回到负载均衡器，在负载均衡器中进行连接跟踪，NAT可以在相反方向再次发生。

为什么会使用这种类型的负载平衡器来代替上一节中描述的终端负载平衡器，因为它更复杂？原因如下：

• 性能和资源使用情况：由于直通负载均衡器不会终止TCP连接，因此它们不需要缓冲任何TCP连接窗口。每个连接存储的状态量非常小，通常通过有效的哈希表查找来访问。因此，直通负载平衡器通常可以处理比终止负载平衡器大得多的活动连接数和每秒数据包数（PPS）。
• 允许后端执行自定义拥塞控制：TCP拥塞控制是Internet上端点限制发送数据以便不会压倒可用带宽和缓冲区的机制。由于直通负载均衡器未终止TCP连接，因此它不参与拥塞控制。这一事实允许后端根据其应用用例使用不同的拥塞控制算法。它还允许更容易地对拥塞控制变化进行实验（例如，最近的BBR推出）。
• 形成直接服务器返回（DSR）和集群L4负载平衡的基线：更高级的L4负载平衡技术（例如DSR和具有分布式一致性散列的集群）需要直通负载平衡（在以下部分中讨论）。