现代网络负载均衡和代理简介

最近引起我注意的是，很少有关于现代网络负载均衡和代理的介绍性教育资料。我心想：这怎么可能？

负载均衡是构建可靠分布式系统的核心概念之一。难道不该有高质量的信息么？我搜索并发现这些摘录确实很少。关于负载均衡和代理服务器的维基百科文章中仅包含一些概念的概述，但对各个主题的处理都不多，特别是因为它涉及到现代微服务架构。谷歌搜索到的关于负载均衡的都是一些只有时髦术语无实际内容的页面。

在这篇文章中，我试图通过提供对现代网络负载均衡和代理的介绍来补足缺乏的信息。坦率地说，这个大型主题可以写一部书。为了保持博客的篇幅，我尝试将一组复杂的主题提炼成一个简单的概述; 根据兴趣和反馈，我将考虑在稍后更详细的写关于个别主题的后续帖子。

这就是我写这篇文章的一些背景因素 - 开始吧！

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

Wikipedia 将负载均衡定义为：

“

在计算中，负载均衡改善了跨多个计算资源（例如计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器）的工作负载分布。负载均衡旨在优化资源使用，最大化吞吐量，最小化响应时间，并避免任何单个资源的过载。使用具有负载均衡而不是单个组件的多个组件可以通过冗余提高可靠性和可用性。负载均衡通常涉及专用软件或硬件，例如多层交换机或域名系统服务器进程。

”

以上定义适用于计算的所有方面，而不仅仅是网络。操作系统使用负载均衡来跨物理处理器调度任务，容器编排（如Kubernetes）使用负载均衡来跨计算集群调度任务，网络负载均衡使用负载均衡来跨可用后端调度网络任务。本文的其余部分仅涵盖网络负载均衡。

图1：网络负载均衡概述

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

服务发现：系统中有哪些后端可用？它们的地址是什么（即负载均衡器应该如何与这些后端通信）？健康检查：目前哪些后端健康且可以接受请求？负载均衡：应该使用什么算法来均衡健康后端的各个请求？

在分布式系统中正确使用负载均衡可带来以下好处：

命名抽象：不用每个客户端都需要知道每个后端地址（服务发现），客户端可以通过预定义的机制决定负载均衡，然后可以将域名解析行为委托给负载均衡器。预定义机制包括内置库和众所周知的DNS/IP/端口位置，并将在下面更详细地讨论。容错：通过运行状况检查和各种算法，负载均衡器可以有效地绕过坏的或过载的后端。这意味着操作员通常可以在休闲时修复坏后端，而不总是紧急修复。成本和性能优势：分布式系统网络很少是同质的。该系统可能跨越多个网络区域和区域。在区域内，网络通常以相对_undersubscription_的方式构建。在区域之间，超额认购成为常态。（在此上下文中，undersubscription指的是通过NIC消耗的带宽量占路由器之间可用带宽的百分比）。智能负载均衡可以尽可能地保持均衡区域内的请求流量，从而提高性能（减少延迟）并降低整体系统成本（区域之间所需的带宽和光纤更少）。

负载均衡器与代理

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

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

L4（连接/会话）负载均衡

在讨论当今整个行业的负载均衡时，解决方案通常分为两类：L4和L7。这些类别涉及OSI模型的第4层和第7层。我认为我们使用的这些术语是不幸的，在下面讨论L7时就清楚了。OSI模型与复杂的负载均衡并不具备很好的相似性，其中传统的第4层协议（例如TCP和UDP），通常最终被包括在各种不同OSI的上层协议层中。即，如果L4 TCP负载均衡也支持TLS终端，它现在是L7负载均衡吗？

图2：TCP L4终端负载均衡

图 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相对于处理客户端B的请求量要小3000倍左右！这是一个大问题，并且这已经破坏了负载均衡的初衷。另请注意，任何多路复用，持久连接（keep-alive）的协议都会出现此问题。（多路复用意味着通过单个L4连接并发发送请求，持久连接意味着在没有请求时先不关闭连接）。由于效率原因，所有现代协议都在发展为多路复用和持久（因为创建连接通常很昂贵，特别是当使用TLS加密连接时），因此L4负载均衡器阻抗不匹配会随着时间的推移变得更加明显。此问题可以在L7负载均衡得以修复。

图3：HTTP/2 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协议（请求头，正文数据和报文尾(trailers))。消息传递协议（gRPC，REST等）。

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

负载均衡器特性

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

服务发现

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

静态配置文件。DNS。Zookeeper，Etcd，Consul等Envoy的通用数据平面API。

健康检查

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

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

负载均衡

是的，负载均衡必须真正的能均衡负载！给定一组健康的后端，如何选择合适的后端来提供连接或请求？负载均衡算法是一个活跃的研究领域，范围从简单的算法，如随机选择和循环，到考虑可变延迟和后端负载的更复杂的算法。鉴于其性能和简单性，最流行的负载均衡算法之一被称“两个随机选择的力量”。

粘性会话

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

TLS边界

TLS的主题及其在边缘服务和保护”服务到服务”通信中的作用可以单独发表一篇。话虽如此，许多L7负载均衡器进行了大量的TLS处理，包括终止边界，证书验证和固定，使用SNI的证书服务等。

可观察性

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

安全和DoS缓解

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

配置和控制平面

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

还有更多

本节刚刚介绍了负载均衡器提供的功能类型一些表面。更多有关L7负载均衡器的部分，请参见下面的讨论。

负载均衡拓扑的类型

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

中间代理

图4：中间代理负载均衡拓扑

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

边缘代理

图5：边缘代理负载均衡拓扑

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

嵌入式客户端库

图6：通过嵌入式客户端库进行负载均衡

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

尽管如此，上述的一些库已经成功地让那些能够限制编程语言扩散并克服库升级难度的公司所取得了成功。

边车(sidecar)代理

图7：通过sidecar代理进行负载均衡

嵌入式客户端库负载均衡拓扑的另一种变体是图 7中所示的边车代理拓扑。近年来，这种拓扑结构已经被推广为“服务网格”。边车代理背后的理念是，以牺牲轻微的延迟为代价，通过iptables跳转到不同的进程，来提供对编程语言无侵入式改造的目的。在撰写本文时，最受欢迎的边车代理负载均衡有Envoy，NGINX，HAProxy和Linkerd等。有关边车代理方法的更详细的处理，请参阅我的博客文章介绍Envoy以及我的在服务网格数据平面与控制平面的博客。

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

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

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

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

L4负载均衡器是否仍然有效？

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

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

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

TCP/UDP 终端负载均衡器

图8：L4终端负载均衡器

仍在使用的第一种L4负载均衡器是终端负载均衡器，如图 8所示。这与我们在上面的L4负载均衡介绍中看到的负载均衡器相同。在这种类型的负载均衡器中，使用两个离散的TCP连接：一个在客户端和负载均衡器之间，一个在负载均衡器和后端之间。

L4终端负载均衡器仍然使用有两个原因：

它们实施起来相对简单。对客户端的近距离（低延迟）连接终端具有重大的性能影响。具体地，如果终端负载均衡器可以靠近使用有损网络（例如，蜂窝网络）的客户端放置，则在数据被移动到可靠光纤传输到其最终位置之前，重传可以变得。换句话说，这种类型的负载均衡器可以在用于原始TCP连接终止的存在点（POP）场景中使用。

TCP/UDP 直通负载均衡器

图9：L4直通负载均衡器

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

连接跟踪（connection tracing）：是追踪所有活跃TCP连接状态的过程。这包括诸如握手是否已完成，是否已收到FIN，连接已空闲多长时间，已为连接选择了哪个后端等数据。网络地址转换（NAT）：NAT是使用连接跟踪数据在数据包穿过负载均衡器时更改数据包的IP/端口信息的过程。

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

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

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

直接服务器返回（DSR）

图10：L4直接服务器返回（DSR）

直接服务器返回（DSR）负载均衡器如图10所示。DSR建立在上一节中描述的直通负载均衡器之上。DSR是一种优化，其中只有入口/请求数据包经过负载均衡器。出口/响应数据包在负载均衡器直接返回客户端。执行DSR有趣的主要原因是，在许多工作负载中，响应流量比请求流量大很多（例如，典型的HTTP请求/响应模式）。假设10％的流量是请求流量，90％的流量是响应流量，如果是DSR，那么使用1/10的负载均衡器容量就可以满足系统的需要。由于历史上负载均衡器非常昂贵，因此这种类型的优化会对系统成本和可靠性产生重大影响（少即是好：less is always better）。DSR负载均衡器扩展了直通负载均衡器的概念，具体如下：

DSR负载均衡器通常仍执行部分连接跟踪。由于响应数据包不会经过负载均衡器，因此负载均衡器将不会知道完整的TCP连接状态。但是，负载均衡器可以通过查看客户端数据包和使用各种类型的空闲超时来很好的推断链接状态。DSR负载均衡器通常使用通用路由封装（GRE）来封装从负载均衡器发送到后端的IP数据包，而不是NAT 。因此，当后端接收到封装的数据包时，它可以对其进行解封装并知道客户端的原始IP地址和TCP端口。这允许后端直接响应客户端，而响应数据包不会流经负载均衡器。DSR负载均衡器的一个重要部分是，后端需要参与负载均衡。后端需要具有正确配置的GRE隧道，并且根据网络设置的底层细节可能需要其自己的连接跟踪，NAT等。

请注意，在直通负载均衡器和DSR负载均衡器设计中，都有大量的途径设置连接跟踪，NAT，GRE等。不幸的是，该主题也超出了本文的范围。

通过“高可用性对儿（high avalibility pairs）”实现容错

图11：通过HA对和连接跟踪的L4容错

到目前为止，我们一直在考虑独立设计的L4负载均衡器。直通和DSR负载均衡器都需要在负载均衡器本身中进行一定量的连接跟踪和状态。如果负载均衡器死了怎么办？如果负载均衡器的单个实例死亡，则将切断经过负载均衡器的所有连接。根据应用的不同，这可能会对应用程序性能产生重大影响。

从历史上看，L4负载均衡器曾经是从典型供应商（Cisco，Juniper，F5等）购买的硬件设备。这些设备非常昂贵并且处理大量流量。为了避免单个负载均衡器故障切断所有连接并导致严重的应用程序中断，负载均衡器通常部署在“高可用性对儿”中，如图 11所示。典型的HA负载均衡器设置具有以下设计：

一对HA边缘路由器服务于一定数量的虚拟IP（VIP）。这些边缘路由器使用边界网关协议（BGP）宣告VIP 。主边缘路由器的BGP权重高于备份，因此在稳定状态下，它为所有流量提供服务。（BGP是一个极其复杂的协议;出于本文的目的，只考虑BGP一种机制，通过该机制，网络设备宣布它们可用于从其他网络设备获取流量，并且每个链路可以具有优先考虑链路流量的权重）。类似地，主L4负载均衡器向具有比备份更高的BGP权重的边缘路由器宣告自己，因此在稳定状态下它正在为所有流量服务。主负载均衡器交叉连接到备份负载，并共享其所有连接跟踪状态。因此，如果主模块死亡，则备份可以接管处理所有活动连接。两个边缘路由器和两个负载均衡器都是交叉连接的。这意味着如果其中一个边缘路由器或其中一个负载均衡器死亡，或者由于某些其他原因而撤销其BGP通知，则备份可以接管所有流量。

上面的设置是今天仍然有很多高流量的互联网应用在使用。但是，上述方法存在很大的缺点：

考虑到容量使用情况，必须在“HA负载均衡器对儿”之间正确分片VIP。如果单个VIP增长超过单个“HA对儿”的容量，则VIP需要拆分成多个VIP。系统的资源使用率很低。50％的容量处于闲置状态。鉴于历史上硬件负载均衡器非常昂贵，这会导致大量成本闲置。现代分布式系统设计提供比主/备份更好的容错能力。例如，更优的情况，系统应该能够遭受多个同时发生的故障并且继续运行。如果主备/负载均衡器同时死亡，则“HA负载均衡器对儿”容易发生完全故障。供应商提供的专有大型硬件设备非常昂贵，导致供应商锁定。通常会希望用使用通用商用计算服务器构建水平可扩展软件的解决方案来替换这些硬件设备。

通过具有分布式一致性散列的集群进行容错和扩展

图12：通过集群负载均衡器和一致性散列的L4容错和扩展

上一节介绍了通过HA对的L4负载均衡器容错以及该设计中固有的问题。从2000年代早期到中期，大型互联网基础设施开始设计和部署新的大规模并行L4负载均衡系统，如图12所示。这些系统的目标是：

减轻上一节中描述的“HA对儿”设计的所有缺点。从专有硬件负载均衡器供应商转向使用标准计算服务器和NIC构建的商品软件解决方案。

此L4负载均衡器设计被称为容错和通过群集和分布式一致性散列进行扩展。它的工作原理如下：

N个边缘路由器以相同的BGP权重宣布所有Anycast VIP。等价多路径路由（ECMP）用于确保通常来自单个流的所有分组到达相同的边缘路由器。流通常是源IP/端口和目标IP/端口的4元组。（简而言之，ECMP是一种使用一致哈希在一组相同加权的网络链路上分发数据包的方法）。虽然边缘路由器本身并不特别关心哪些分组到达那里，但是通常用于使来自某个单一流的所有分组经过同一组链路，以避免乱序的包导致降低性能。N个L4负载均衡器机器以与边缘路由器相同的BGP权重通告所有VIP。再次使用ECMP，边缘路由器通常会为某个单一流选择相同的负载均衡器机器。每个L4负载均衡器机器通常会执行部分连接跟踪，然后使用一致性散列来选择流的后端。GRE用于封装从负载均衡器发送到后端的数据包。然后，DSR用于通过边缘路由器将数据包直接从后端发送到客户端。L4负载均衡器使用的一致性哈希算法是一个活跃的研究领域。在权衡负载，最小化延迟，最小化后端更改期间的中断以及最小化内存开销方面存在权衡。对该主题的完整讨论超出了本文的范围。

让我们看看上述设计如何减轻“HA对儿”方法的所有缺点：

可根据需要来添加新的边缘路由器和负载均衡器。在添加新计算机时，每层都使用一致的哈希来尽可能减少受影响流的数量。系统的资源使用可以根据需要运行，同时保持足够的突发容限和容错。边缘路由器和负载均衡器现在都可以使用商用硬件构建，而成本只是传统硬件负载均衡器的一小部分（下面将详细介绍）。

通常被问到这个设计的一个问题是“边缘路由器为什么不通过ECMP直接与后端通信？为什么我们需要负载均衡器？“其原因主要是围绕DoS缓解和后端操作简便性。如果没有负载均衡器，每个后端都必须参与BGP，并且执行滚动部署的难度要大得多。

所有现代L4负载均衡系统都在朝着这种设计（或其某些变体）发展。最着名的两个例子是Google的Maglev和亚马逊的网络负载均衡器（NLB）。目前没有任何OSS负载均衡器可以实现这种设计，但是，我知道有一家公司计划在2018年向OSS发布一个。我对这个版本感到非常兴奋，因为现代L4负载均衡器正缺少OSS这一个至关重要的部分。

L7负载均衡的当前技术水平

确实是的。最近几年L7负载均衡器/代理开发出现了复苏。这与分布式系统中对微服务架构的持续推动非常吻合。从根本上说，当更频繁地使用时，固有故障的网络变得更难以有效地操作。此外，自动扩展，容器调度程序等的兴起意味着在静态文件中配置静态IP的日子早已过去。系统不仅更多地利用网络，它们还变得更加动态，也需要负载均衡提供更多新的功能。在本节中，我将简要总结现代L7负载均衡器中开发最多的领域。

协议支持

现代L7负载均衡器正在为许多不同的协议添加明确的支持。负载均衡器对应用流量的了解越多，它在可观察性输出，高级负载均衡和路由等方面就可以做得越精密。例如，在撰写本文时，Envoy明确对HTTP/1，HTTP/2，gRPC，Redis，MongoDB和DynamoDB支持L7协议解析和路由。未来可能会添加更多协议，包括MySQL和Kafka。

动态配置

如上所述，分布式系统的日益动态的性质需要在创建动态和反应控制系统方面进行同时投入。Istio就是这种系统的一个例子。有关此主题的更多信息，请参阅我在服务网格数据平面与控制平面上的帖子。

高级负载均衡

L7负载均衡器现在通常内置支持高级负载均衡功能，如超时，重试，速率限制，熔断，阴影，缓冲，基于内容的路由等。

可观察性

如上面关于一般负载均衡器功能的部分所述，正在部署的越来越动态的系统变得越来越难以调试。用健壮的协议规范可观察性输出可能是现代L7负载均衡器提供的最重要的功能。现在，任何L7负载均衡解决方案几乎都需要输出数字统计，分布式跟踪和可自定义日志记录。

可扩展性

现代L7负载均衡器的用户通常希望轻松扩展它们以添加自定义功能。这可以通过编写加载到负载均衡器中的可插入过滤器来完成。许多负载均衡器也支持脚本，通常是通过Lua脚本。

容错

我写了很多关于L4负载均衡器容错的文章。L7负载均衡器容错怎么样？通常，我们将L7负载均衡器视为可消耗和无状态的。使用商用软件可以轻松地水平缩放L7负载均衡器。此外，L7负载均衡器执行的处理和状态跟踪比L4复杂得多。尝试建立基于L7负载均衡器的“高可用对儿”在技术上是可行的，但这将是一项重大任务。

总的来说，在L4和L7负载均领域中，业界正逐渐从“HA对”转向通过一致散列融合的水平可扩展系统。

更多

L7负载均衡器正在以惊人的速度发展。有关Envoy提供的示例，请参阅Envoy的架构概述。

全局负载均衡和集中控制平面

图13：全局负载均衡

未来负载均衡将越来越多地将各个独立负载均衡器视为商品设备。在我看来，真正的创新和商业机会都在控制平面内。图 13显示了全局负载均衡系统的示例。在这个例子中，发生了一些不同的事情：

每个边车代理与三个不同区域（A，B和C）中的后端通信。如图所示，90％的流量被发送到区域C，而5％的流量被发送到区域A和B.边车代理和后端都向全局负载均衡器报告周期性状态。这允许全局负载均衡器做出考虑延迟，成本，负载，当前故障等的决策。全局负载均衡器周期性地为每个边车代理配置当前路由信息。

全局负载均衡器将越来越能够完成任何单个负载均衡器无法独立完成的复杂事物。例如：

自动检测并绕过区域性故障。应用全局安全和路由策略。使用机器学习和神经网络检测和缓解包括DDoS攻击在内的流量异常。提供集中的UI和可视化，使工程师能够聚合地理解和操作整个分布式系统。

为了实现全局负载均衡，用作数据平面的负载均衡器必须具有复杂的动态配置功能。有关此主题的更多信息，请参阅我在Envoy的通用数据平面API以及服务网格数据平面与控制平面上的帖子。

从硬件到软件的演变

到目前为止，这篇文章仅简要提到了硬件与软件，主要是在历史L4负载均衡器“HA对儿”的上下文中。这个领域的行业趋势是什么？

之前的推文是一种幽默的夸张，但仍然总结了很多趋势，它们是：

从历史上看，路由器和负载均衡器由极其昂贵的专有硬件提供。越来越多的大多数专有L3/L4网络设备正在被商用服务器硬件，商用NIC以及基于IPVS，DPDK和http://fd.io等框架构建的专用软件解决方案所取代。成本低于5千美元的现代数据中心机器可以使用Linux和使用DPDK编写的自定义用户空间应用程序轻松地使用非常小的数据包来让80Gbps网卡达到饱和。与此同时，能够以惊人的总带宽和数据包速率进行ECMP路由的廉价且基本的路由器/交换机ASIC被打包为商品路由器。精密的L7软件负载均衡器，如NGINX，HAProxy和Envoy，也在快速迭代和侵占之前的F5等供应商领域。因此，L7负载均衡器也在积极地转向商用软件解决方案。与此同时，整个行业正在向主要的云提供商来推动IaaS，CaaS和FaaS的方式转变，意味着越来越少的工程师需要了解物理网络的工作方式（这些是“黑魔法“和”我们不再需要蹲下了解“上面的部分”。

结论和负载均衡的未来

总而言之，这篇文章的主要内容是：

负载均衡器是现代分布式系统中的关键组件。有两种通用类型的负载均衡器：L4和L7。L4和L7负载均衡器都与现代架构相关。L4负载均衡器正朝着可水平扩展的分布式一致性散列解决方案发展。由于动态微服务架构的激增，L7负载均衡器最近投入巨资。全局负载均衡以及控制平面和数据平面的分离是负载均衡的未来，并且可以发觉很多未来的创新和商业机会。该行业正在积极地转向用于网络解决方案的商用OSS硬件和软件。我相信像F5这样的传统负载均衡供应商将首先被OSS软件和云供应商所取代。传统路由器/交换机供应商，如Arista/Cumulus/等，我认为在内部部署方面有更大的发展空间，但最终也将被公共云供应商和他们自己开发的物理网络取代。

总的来说，我认为这是计算机网络的一个迷人时刻！大多数系统向OSS和软件的转变，正使得迭代速度提高几个数量级。此外，随着分布式系统通过“无服务器”范例继续向动态化迈进，底层网络和负载均衡系统的复杂性还将相应的增加。

原文链接：https://blog.envoyproxy.io/introduction-to-modern-network-load-balancing-and-proxying-a57f6ff80236