马上注册，，享用更多功能，让你轻松玩转本站。
您需要 登录 才可以下载或查看，没有帐号？立即注册
x
关于现代网络负载均衡和代理（proxy）的介绍性资料很少，这件事引起了我的注意。为什么会这样呢？构建一个可靠的分布式系统时，负载均衡是一个非常核心的概念。但可惜的是，搜索发现关于负载均衡和服务代理的内容很少。维基百科文章只包含了一些概念,没有对该主题的详细介绍，尤其是与现代微服务架构相关的。 本文试图通过对现代网络负载均衡和代理的简单介绍，来弥补这部分信息的缺乏。为了保持文章的长度，尽量将复杂的话题浓缩成简单的概述。 1 什么是网络负载均衡和代理？ 维基百科这样定义负载均衡： 在计算中，负载均衡可以改善在多个计算机资源（如计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器）上的工作负载分布。负载均衡旨在优化资源的使用，最大吞吐量，及最小响应时间，避免任何单一资源的过载。通过使用多个组件而不是单个组件，负载均衡通过冗余来提高可靠性和可用性。负载均衡通常涉及专用软件和硬件，例如多层交换机或域名系统服务器进程。 以上定义适用于计算的各个方面，而不仅仅是网络。操作系统使用负载均衡在物理处理器之间安排任务，诸如Kubernetes之类的容器编排者使用负载均衡来计划跨计算集群的任务，网络负载均衡通过调用可用后端来平衡网络任务。以下内容仅涵盖网络负载均衡。 图 1: 网络负载均衡描述 图1展示了网络负载均衡高层次的概览。一些客户端从后端请求资源。负载均衡器位于客户端和后端之间，在更高层次执行关键任务： 服务发现： 在系统中哪些后端可用？地址是多少？（换句话说，负载均衡器如何与它们通信？） 健康检查： 在系统中目前哪些后端是健康的，可以接受请求？ 负载均衡： 用什么样的算法把独立的个人请求发给健康的后端？
在分布式系统中正确使用负载均衡会带来如下好处： 命名抽象： 客户端可以通过预定义的机制来寻址负载均衡器，而不是每个客户端都需要了解每个后端（服务发现），然后将名称解析的任务委托给负载均衡器。预定义的机制包括内置库和众所周知的DNS/IP/端口地址，后面会有详细的讨论。 容错： 通过健康检查和各种算法技术，负载均衡器的路由方法可以绕过坏的或者超负载的后端。这也意味着运维人员可以随时优先修复后端错误。 低成本和高性能： 分布式系统网络一致性比较差。系统可能会横跨不同的网络区域。在一个区域内，网络之间通常以相对小的带宽建立的。而在不同的区域之间，网络大带宽成为常态（带宽的大小是指通过NIC使用的带宽量占路由器之间可用带宽的百分比）。智能的负载均衡可以尽可能保持区域内的请求流量，从而提高性能（低延迟）并降低整体系统成本（减少区域间的带宽和光纤）。
负载均衡器VS代理 在谈论到网络负载均衡器，Load Balancer 和 Proxy 两个术语在行业内可以互换使用。在本文中也把两者视为一致的表达。（不过，不是所有的代理都是负载均衡器，但绝大多数代理都将负载均衡作为主要功能）。 一些人会争辩说，当负载均衡器作为嵌入式客户端库的一部分实现时，这种负载均衡器并不是真正的代理。这种区分其实添加了不必要的复杂性。本文会详细讨论负载均衡器的拓扑类型，嵌入式负载均衡器是代理的一个特例，应用通过嵌入式库进行代理，嵌入式库与应用进程外的负载均衡器整体抽象是一致的。 L4（连接/会话）负载均衡 业界讨论负载均衡时，解决方式往往分为两类：L4 和 L7。指的是OSI模型的第四层和第七层。OSI模型包括传统的第四层协议（如TCP和UDP），还包含各种不同OSI层的协议。换句话说，如果 L4 TCP负载均衡器也支持 TLS 终止，这不就是 L7负载均衡器么？ 图2：TCP L4 终止负载平衡 图2展示了传统的L4 TCP负载均衡器。在这种情况下，客户端与负载均衡器建立TCP连接，负载均衡器终止连接（即直接响应SYN），选择一个后端，并与后端建立新的TCP连接（即发起新的SYN）。 本节的关键是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）。
在上述场景中，后端选择处理客户端B请求是选择客户端A请求负载的大约3000倍。这是一个很大的问题，打破了负载均衡的目的。需要注意的是这个问题发生在任何复用，保持存活状态的协议。（复用意味着通过单个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本身包含多个离散的负载均衡抽象层。例如，对于HTTP流量，请考虑以下子层： 可选的传输层安全性（TLS）。网络界对于TLS 属于OSI模型哪一层有争论。为了方便，我们考虑将TLS放在 L7。 物理HTTP协议（HTTP / 1或HTTP / 2）。 逻辑HTTP协议 (Header、Body 和 Trailer) 。 消息传递协议（gRPC，REST等）。
一个复杂的L7负载均衡器要提供与上述每个子层有关的功能。另L7负载均衡器可能只有一小部分功能属于OSI模型中L7层。简而言之，L7负载平衡器的功能远比L4类型复杂得多。（HTTP、 Redis、Kafka、MongoDB等都是应用L7 协议的例子，它们受益于L7负载均衡）。 2 负载均衡器功能 在本节中将总结负载均衡器提供的高级功能，并非所有负载均衡器都提供全部功能。 服务发现 服务发现是负载平衡器确定可用后端的过程，实现的方式有很多种，一些例子包括： 静态配置文件。 DNS。 Zookeeper，Etcd，Consul等。 Envoy的通用数据平面API。
健康检查 运行状况检查是负载均衡器确定后端是否可用来为流量提供服务的过程。健康检查一般分为两类： 负载均衡 负载均衡器必须实际平衡负载！当给定一组健康的后端时，选择哪个后端处理请求？负载平衡算法是一个活跃的研究领域，从简单的算法（如随机选择和循环算法）到考虑可变延迟和后端负载的更复杂的算法。考虑到其性能和简单性，最流行的负载均衡算法是二节点最小请求负载均衡（power of 2 least request load balancing）。 粘滞会话 （ Sticky sessions ） 在某些应用中，同一会话的请求到达相同的后端是很重要的。这与缓存，临时复杂状态等有关。会话的定义各不相同，可能包括HTTP Cookie，客户端连接的配置或其他属性。许多L7负载平衡器支持会话粘连。会话粘性本质上是脆弱的（后端保存的会话可能会失效），所以在设计系统的时候减少对它们的依赖。 TLS终止 关于TLS，它在边缘服务和服务间通信方面值得肯定。因此，许多L7负载均衡器会执行大量的TLS处理，包括终止，证书验证和保存，使用SNI的证书服务等。 可观察性 正如谈话中所强调的：“可观察性，可观察性，可观察性”。网络本质上是不可靠的，负载均衡器通常负责导出统计信息，跟踪信息和记录日志，帮助运营人员找出问题所在，从而解决问题。最先进的负载平衡器可观察性输出包括数字统计，分布式跟踪和可定制的日志记录。增强的可观察性不是免费的; 负载平衡器必须做很多附加的工作来完成它。至于，负面影响，相对带来的好处，几乎不值一提。 安全性和 DoS 防范 特别是在边缘部署拓扑（见下文）中，负载均衡器通常实施各种安全功能，包括速率限制，身份验证和DoS防范（例如，IP地址标记和识别，缓送 Tarpitting 等）。 配置和控制面板 负载平衡器需要配置。在大规模部署中，这是一项重要工作。一般来说，配置负载均衡器的系统被称为“控制面板”，并且在其实现中变化很大。 3 负载均衡器拓扑的类型 前面介绍了负载平衡器的概要，L4和L7负载平衡器之间的区别以及负载均衡器特性，接下来将转向部署负载均衡器的各种分布式系统拓扑。（以下每种拓扑均适用于L4和L7负载均衡器）。 中间代理 图4：中间代理负载均衡拓扑 图4所示的中间代理拓扑是大多数读者最熟悉的负载均衡一种方式。这一类包括Cisco，Juniper，F5等硬件设备; 云软件解决方案，如亚马逊的ALB和NLB以及Google的 Cloud Load Balancer ; 以及HAProxy，NGINX和Envoy等纯软件自主托管解决方案。中间代理解决方案使用简单。通常，用户通过DNS连接到负载均衡器，不需要担心其他任何事情。中间代理解决方案的特点是代理（即使是集群）是单一的故障点，也是扩展的瓶颈。中间代理通常是一个让运维变得困难的黑匣子。当问题出现时，是在客户端还是物理网络？在中间代理还是后端？这很难说。 边缘代理 图5：边缘代理负载平衡拓扑 图5所示实际上只是中间代理拓扑的一种变体，负载均衡器通过Internet访问。在这种情况下，负载均衡器通常必须提供附加的“API网关”功能，如TLS终止，速率限制，身份验证和复杂的流量路由。边缘代理的优缺点与中间代理相同。需要注意的是，在面向Internet的大型分布式系统中部署专用边缘代理通常是不可避免的。客户端通常需要使用服务所有者无法控制的任意网络库（后面会讨论嵌入式客户端库或附属代理拓扑结构不能直接在客户端上运行）通过DNS访问系统。另外，由于安全原因，希望具有单个网关，通过该网关，所有面向互联网的流量进入系统。 嵌入式客户端库 图6：通过嵌入式客户端库进行负载平衡 为了避免中间代理拓扑中固有的单点故障和扩展问题，更复杂的基础设施已经开始将负载均衡器直接嵌入到服务库中，如图6所示。支持的功能库有很大的不同，但是这个类别中最知名和最丰富的功能包括Finagle，Eureka / Ribbon / Hystrix和gRPC（松散地基于称为Stubby的内部Google系统）。基于库的解决方案的主要功能是将负载均衡器的所有功能完全分配给每个客户端，从而消除之前描述的单点故障和扩展问题。基于客户端库的解决方案的主要内容是客户端库必须每种语言调用。分布式架构正变得越来越“多语言”（多语言）。在这样的环境下，用许多不同的语言来重新实现一个非常复杂的网络库的成本会变得过高。最后，在大型服务体系结构中部署库升级可能会非常痛苦，这使得很多不同版本的库将在生产中同时运行， 综上所述，上面提到的这些库对于那些能够限制编程语言扩散并克服库升级难题的公司来说是成功的。 Sidecar代理 图7：通过sidecar代理进行负载平衡 嵌入式客户端库负载平衡器拓扑的一个变种是图7中所示的辅助代理拓扑。近年来，这种拓扑已经被普遍推广为“服务网格”（Service Mesh）。Sidecar代理背后的思路是，以跳过一个不同的过程的代价来承担轻微的延迟，嵌入式库的所有好处都可以在没有任何编程语言锁定的情况下获得。在撰写本文时，最受欢迎的sidecar代理负载平衡器是Envoy，NGINX，HAProxy和Linkerd。 负载均衡器拓扑的总结和优缺点 中间代理拓扑是最简单的负载平衡拓扑。缺点是：单点故障，伸缩瓶颈和黑箱操作。 边缘代理拓扑与中间代理类似，但通常无法避免。 嵌入式客户端库拓扑提供了最好的性能和可扩展性，但是需要在每种语言中实现该库，并跨所有服务升级库。 Sidecar代理拓扑性能比嵌入式客户端库拓扑弱，但不受任何限制。
总体而言，sidecar代理拓扑（服务网格）正在逐渐取代所有其他的服务。流量进入服务网格之前，始终需要边缘代理拓扑。 4 L4负载均衡的现状 L4负载均衡器 还有用吗 ？ 本文讨论了L7负载平衡器如何用于现代协议，后面还会讨论L7负载平衡器的特性。这是否意味着L4负载平衡器没用了？没有！尽管在我看来，L7负载均衡器最终将完全取代L4负载均衡器进行服务间通信，但是L4负载均衡器对边缘通信仍然很重要。因为几乎所有现代大型分布式架构都使用两层L4 / L7负载平衡架构处理互联网流量。在L7负载均衡器之前在边缘部署中部署专用L4负载均衡器的好处是： 下面将介绍几种不同的中间/边缘代理L4负载均衡器的设计。这些设计不适用于客户端库和Sidecar拓扑。 TCP / UDP 终端 负载均衡器 图8：L4终端负载均衡器 仍在使用的第一类L4负载均衡器是图8所示的终端负载均衡器。这类负载均衡器，使用两个离散的TCP连接：一个在客户端和负载均衡器之间，另一个在负载均衡器和后端之间。 L4终端负载均衡器仍然有两个原因： TCP / UDP直通负载均衡器 图9：L4直通负载均衡器 第二种类型的L4负载均衡器是图9所示的直通负载均衡器。在这种类型的负载均衡器中，TCP连接不会被负载均衡器终止。而是在连接跟踪和网络地址转换（NAT）发生后，将每个连接的数据包转发到选定的后端。首先，我们来定义一下连接跟踪和NAT： 使用连接跟踪和NAT，负载平衡器可以将大部分原始TCP流量从客户端传递到后端。例如，假设客户正在交谈，1.2.3.4:80而选定的后端位于10.0.0.2:9000。客户端TCP数据包将到达负载均衡器at 1.2.3.4:80。然后负载均衡器将交换数据包的目标IP和端口10.0.0.2:9000。它还会将数据包的源IP与负载均衡器的IP地址进行交换。因此，当后端在TCP连接上响应时，数据包将返回到负载平衡器，在那里进行连接跟踪并且NAT可以在反向再次发生。 为什么会使用这种负载均衡器来代替上一节中描述的终端负载均衡器呢？几个原因： 允许后端执行拥塞控制：TCP拥塞控制是因特网上的端点节制发送数据的机制，从而不会压倒可用带宽和缓冲区。由于直通负载均衡器不会终止TCP连接，因此不参与拥塞控制。这个事实允许后端根据他们的应用使用情况使用不同的拥塞控制算法。它还可以更容易地进行拥塞控制变更的实验（例如，最近的BBR部署）。 形成直接服务器返回（DSR）和群集L4负载平衡的基准： 更高级的L4负载平衡技术（如DSR和使用分布式一致性散列的群集（以下各节中讨论））需要直通负载平衡。
直接服务器返回（ Direct Server Return ， DSR ） 图10：L4直接服务器返回（DSR） 直接服务器返回（DSR）负载平衡器如图10所示。DSR构建在上一节中介绍的直通负载均衡器上。DSR是一种优化，只有入口/请求数据包才能通过负载均衡器。出口/响应数据包在负载平衡器周围直接返回到客户端。执行DSR很有趣的主要原因是，在许多工作负载中，响应流量对请求流量（例如，典型的HTTP请求/响应模式）产生了不满。假设10％的流量是请求流量，90％的流量是响应流量，如果使用DSR的负载均衡器为1/10的容量可以满足系统的需求。由于历史上负载平衡器非常昂贵，因此这种优化可能会对系统成本和可靠性产生重大影响。DSR负载均衡器将直通负载均衡器的概念扩展如下： 负载平衡器通常仍然执行部分连接跟踪。由于响应数据包不会遍历负载均衡器，因此负载均衡器将不会意识到完整的TCP连接状态。但是，负载均衡器可以通过查看客户端数据包并使用各种类型的空闲超时来强烈推断状态。 负载均衡器通常使用通用路由封装（GRE）来封装从负载均衡器发送到后端的IP数据包，而不使用NAT 。因此，当后端收到封装的数据包时，可以对其进行解封装，并知道客户端的原始IP地址和TCP端口。这允许后端直接响应客户端，而无需响应数据包流经负载平衡器。 DSR负载平衡器的一个重要组成部分是后端参与负载均衡。后端需要有一个正确配置的GRE隧道，根据网络设置的低层细节，可能需要自己的连接跟踪，NAT等。
请注意，在直通负载均衡器和DSR负载均衡器设计中，可以通过负载均衡器和后端来设置连接跟踪，NAT，GRE等多种方式。 通过高可用性配对的容错 图11：通过HA对和连接跟踪的L4容错 到目前为止，我们一直在考虑L4负载平衡器的设计。直通和DSR负载平衡器都需要负载均衡器本身的一些连接跟踪和状态。如果负载平衡器死了怎么办？如果负载平衡器的单个实例死亡，则所有通过负载平衡器的连接将被切断。取决于应用程序，这可能会对应用程序性能产生重大影响。 历史上，L4负载均衡器是从典型供应商（Cisco，Juniper，F5等）购买的硬件设备。这些设备非常昂贵，处理大量的流量。为了避免单个负载均衡器发生故障切断所有连接，并导致大量应用程序中断，负载均衡器通常部署在高可用性配对中，如图11所示。典型的HA负载均衡器设置具有以下设计： 一对HA边缘路由器为虚拟IP（VIP）提供服务。这些边缘路由器使用边界网关协议（BGP）宣布虚拟IP 。主边缘路由器具有比备份更高的BGP权重，因此在稳定状态下，它服务所有流量。（BGP是一个非常复杂的协议; 就本文而言，考虑BGP是网络设备宣布可以从其他网络设备获取流量的机制，并且每个链路都可以具有优先考虑链路流量的权重）。 同样，主L4负载均衡器向边缘路由器宣布自己的BGP权重高于备份，因此在稳定状态下，它将服务所有流量。 主负载均衡器交叉连接到备份，并共享其所有连接跟踪状态。因此，如果主负载宕机，备份可以接管处理所有活动的连接。 两台边缘路由器和两台负载均衡器都是交叉连接的。这意味着如果其中一个边缘路由器或负载平衡器中的一个死亡，或者由于某种其他原因撤消BGP通知，备份可以接管所有通信。
上面的设置是目前具有高流量的互联网应用还在使用的方式。但是，上述方法有很大的缺点： 考虑到容量使用情况，虚拟 IP （VIP）必须在HA负载平衡器对之间正确分片。如果单个VIP超出单个HA对的容量，则需要将VIP分成多个VIP。 系统的资源使用情况很差。50％的容量在稳定状态下闲置。鉴于历史上硬件负载平衡器非常昂贵，这导致大量闲置资本。 现代分布式系统设计比主动/备份提供更高的容错能力。例如，最佳地，系统应该能够同时遭受多个故障并继续运行。如果主动和备用负载均衡器同时死亡，则HA负载均衡器对可能会发生完全故障。 来自供应商的专有大型硬件设备非常昂贵，并导致供应商锁定。通常希望用可商购计算服务器构建的可横向扩展的软件解决方案替代这些硬件设备。
通过具有分布式一致散列的集群进行容错和扩展 图12：L4容错和通过集群负载平衡器和一致性哈希的扩展 上一节介绍了通过HA对的L4负载平衡器容错以及该设计中固有的问题。从21世纪初到中期，大型互联网基础设施开始设计和部署新的大规模并行L4负载平衡系统，如图12所示。这些系统的目标是： 这个L4负载均衡器设计最好称为容错和扩展，通过集群和分布式一致的散列。它的工作原理如下： 让我们看看上面的设计是如何缓解HA对方法的所有缺点的： 所有现代化的L4负载均衡系统都在朝着这种设计方向发展（或其他变体）。最著名的两个例子是Google的Maglev和Amazon 的 网络负载均衡器（NLB） 。目前还没有实现这种设计的OSS负载平衡器，但是，我知道有一家公司计划在2018年将其发布到OSS。我对这个版本感到非常兴奋，因为现代L4负载平衡器是一个至关重要的部分在网络空间中缺少OSS。 5 L7负载平衡的现有技术状态 在过去的几年中，L7负载平衡器/代理的发展已经复苏。随着分布式系统中的微服务架构的不断推进，这方面也在不断进步。从根本上说，固有故障的网络在使用更频繁时变得更加难以有效地运行。而且，自动扩展，容器调度等等的出现意味着在静态文件中配置静态IP的日子早已不复存在。系统不仅要利用网络，还要变得更加动态，需要负载平衡器的新功能。本节将简要概述在现代L7负载平衡器的最新发展。 协议支持 现代L7负载平衡器为许多不同的协议增加了明确的支持。负载平衡器对于应用程序流量的知识越多，关于可观察性输出，高级负载平衡和路由等方面可以做的更复杂的事情。例如，在撰写本文时，Envoy明确支持L7协议解析和路由用于HTTP / 1，HTTP2，gRPC，Redis，MongoDB和DynamoDB。未来可能会有更多协议被添加，包括MySQL和Kafka。 动态配置 如上所述，分布式系统越来越具有动态性，需要并行投资来创建动态和反应式控制系统。Istio就是这样一个例子。 高级负载平衡 L7负载均衡器现在通常内置对高级负载平衡功能的支持，如超时，重试，速率限制，断路，屏蔽，缓冲，基于内容的路由等。 可观察性 如上面有关一般负载平衡器功能的部分所述，正在部署的日益动态的系统越来越难以调试。强大的协议特定的可观测性输出是现代L7负载平衡器最重要的特性。任何L7负载平衡解决方案现在都需要输出数字统计信息，分布式跟踪和可自定义日志记录。 可扩展性 现代L7负载平衡器的用户通常希望轻松扩展以添加自定义功能。这可以通过写入加载到负载均衡器的可插入过滤器来完成。许多负载平衡器也支持脚本，通常通过Lua。 容错 L7负载均衡器的容错性如何？一般来说，我们把L7负载平衡器视为可消耗和无状态的。使用商业软件就能够对L7负载平衡器轻松水平扩展。此外，L7负载平衡器执行的处理和状态跟踪比L4复杂得多。试图建立一个L7负载平衡器的HA配对在技术上是可能的，但非常繁杂。 总的来说，在L4和L7负载平衡领域，业界正在从HA配对转向通过一致的哈希聚合横向水平可扩展系统。 更多 L7负载平衡器正在以惊人的速度发展。有关Envoy提供的示例，请参阅Envoy的架构概述。 6 全球负载均衡和集中控制平面 图13：全局负载平衡 负载平衡的未来将越来越多地将单个负载平衡器视为商品设备。我认为，真正的创新和商业机会都在控制层面。图13显示了一个全局负载均衡系统的例子。在这个例子中，几个不同的事情正在发生： 全球负载均衡器越来越能够做复杂的事情。例如： 为了实现全局负载均衡，用作数据平面的负载平衡器必须具有复杂的动态配置能力。 7 从硬件到软件的演变 本文只是简单地提到了硬件和软件，主要是在L4负载平衡器HA对的历史背景下。这方面的业界趋势又是怎样呢？ 历史上的路由器和负载平衡器都是昂贵的专有硬件。 越来越多的专有L3 / L4网络设备正在被商用服务器硬件，商用网卡和基于IPVS，DPDK和fd.io等框架的专业软件解决方案取代。价格低于5K美元的现代数据中心机器可以使用Linux和自定义的基于DPDK的 user-space 应用，轻松饱和具有非常小数据包的80Gbps NIC。与此同时，廉价的路由器/交换机ASIC可以以惊人的总带宽和数据包速率进行ECMP路由选择，正在被打包成商品路由器。 像NGINX，HAProxy和Envoy这样先进的L7软件负载平衡器也在迅速地迭代和侵入之前像F5这样的供应商领域。因此，L7负载平衡器也在积极地向商品软件解决方案迈进。
与此同时，整个行业向主流云提供商推动的IaaS，CaaS和FaaS意味着越来越多的工程师需要了解物理网络是如何工作的 8 结论和负载均衡的未来 这篇文章的主要内容是： 负载平衡器是现代分布式系统中的关键组件。 有两种负载均衡器：L4和L7。 L4和L7负载平衡器都与现代架构中相关。 L4负载均衡器正朝着横向可扩展的分布式一致哈希水平扩展解决方案迈进。 由于动态微服务体系结构的激增，L7负载平衡器最近发展迅速。 全局负载平衡和控制平面与数据平面之间的分离，是负载平衡的未来，存在大量商业机会。 业界正在积极向商用OSS硬件和软件提供网络解决方案。相信像F5这样的传统负载均衡厂商将首先被OSS软件和云供应商所取代。传统的路由器/交换机厂商，如Arista / Cumulus /等。短期会有好的发展，但最终也将被公有云供应商和自研物理网络所取代。
总的来说，现在是计算机网络的一个激动人心的时代！大多数系统开始向OSS和软件方向转变，迭代速度加快。分布式系统向“无服务器”计算发展，必须继续充满活力，底层网络和负载平衡系统的复杂性也将齐头并进。
| 
/3 
发表于 2018-1-20 02:12:53
微信
收藏
转播
分享
淘帖