HAProxy 和负载均衡概念：基础知识

简介

高可用代理 (HAProxy)，是一个流行的开源代理和 TCP/HTTP 负载均衡器 解决方案，能够运行在 Solaris, FreeBSD、以及 Linux。它最常用于通过在多个服务器之间平衡分配工作负载，来增强服务器环境的可靠性和性能。这类工具被用于许多知名环境，如 Instagram、GitHub、Twitter 和 Imgur。

本指南将向您介绍 HAProxy，使您熟悉负载均衡术语，并提供如何利用它来增强服务器环境性能和可靠性的示例。

HAProxy 核心术语

在深入探讨 负载均衡 和 代理 的细节之前，有一些重要的术语和概念需要熟悉。我们将在接下来的章节中首先回顾这些概念。

ACL (访问控制列表)

在负载均衡中，ACL 用于测试特定条件并根据结果执行操作。这提供了根据后端连接、模式匹配以及许多其他因素来优化转发流量的能力。以下是使用 ACL 的示例：

在这种情况下，如果用户请求的路径以 /blog 开头，则 ACL 匹配。例如，此匹配请求将指向 http://yourdomain.com/blog/blog-entry-1。 HAProxy 配置手册 包含有关 ACL 使用的详细指南。

后端

转发的请求由一组被称为后端的服务器接收。这些请求在 HAProxy 配置的 backend 部分中定义。最简单来说，后端可以通过要使用的负载均衡算法以及端口 and 服务器列表来定义。一个后端可以由单个服务器或多个服务器组成。随着向后端添加更多服务器，潜在的负载能力会增加，处理工作会分散到多个服务器上。如果某些后端服务器下线，其他服务器将作为备份来处理请求。

让我们看一个配置两个后端的示例。在这种情况下，它们是一个 blog-backend 和一个 web-backend。每个后端都有两个 Web 服务器，监听端口 80：

balance roundrobin 这行旨在指定负载均衡算法。详细信息可以在接下来的 负载均衡算法 章节中找到，而 mode http 则设置了第 7 层代理的使用。我们将在 负载均衡类型 章节中对此进行解释。此外，服务器指令后的 check 选项表示将在这些特定的后端服务器上触发健康检查。

前端

关于如何将请求转发到后端的定义被称为前端。这些请求在 HAProxy 配置的 frontend 部分中定义。它们由 ACL、端口、一组 IP 地址以及一个根据满足哪些 ACL 条件来定义使用哪些后端的规则（称为 use_backend 规则）组成。此外，还存在一个 default_backend 规则以应对任何其他情况。下一节将解释如何针对各种网络流量类型配置前端。

负载均衡类型

确立了用于负载均衡的基础组件后，我们现在可以继续了解负载均衡的基本类型。

无负载均衡

在最基本的形式中，缺乏负载均衡的情况可以如下图所示：

在这种情况下，用户直接连接到位于 yourdomain.com 的 Web 服务器。这里没有负载均衡。由于只有一台数据库服务器，如果它下线，对其中信息的访问就会完全中断。如果许多用户同时尝试连接到单个 Web 服务器，而该服务器无法承受所施加的负载，则所有连接都会变慢或完全无法连接。

负载均衡（第 4 层）

将网络流量均衡分配到多台服务器的最简单、最实用的方法之一是使用传输层或第 4 层均衡方法。这种负载均衡方式根据连接用户 IP 地址所属的 IP 范围和端口来引导用户。换句话说，如果 http://yourdomain.com/anything 是请求的来源，那么定义用于处理这些请求的后端将是最终处理它们的后端。它将把针对 yourdomain.com 的请求转发到端口 80。

第 4 层负载均衡的基本结构如下所示：

当用户访问负载均衡器时，他们的请求会被转发到 Web 后端服务器组。配置的后端服务器将直接响应用户的请求。为了避免用户遇到不一致的数据，所有 Web 后端服务器都应该提供相同的内容。如上图所示，两台 Web 服务器最终都连接回同一个数据库服务器。

负载均衡（第 7 层）

还有另一种更复杂的网络流量负载均衡方法。那就是使用第 7 层（即应用层）负载均衡。这种方法允许根据用户请求的内容将用户请求转发到不同的后端服务器。此方法允许通过相同的端口和域名在多个 Web 应用服务器之间进行负载均衡。有关该层的更多详细信息，请参阅我们的 网络的核心细节：了解术语、接口和协议 教程。

下图展示了第 7 层负载均衡：

在这种情况下，用户请求 yourdomain.com/blog，其请求会被转发到 blog 后端。这是一个专门分配用于运行博客应用程序的后端服务器集。与此同时，其他请求将被转发到 web 后端。然而，这两个后端最终都会访问同一个数据库服务器。

第 7 层负载均衡的一小段前端配置示例如以下命令所示。它们配置 http 前端以通过端口 80 处理传入流量：

如果用户请求的路径以 /blog 开头，则 acl url_blog path_beg /blog 将匹配该请求。

use_backend blog backend if url_blog 通过利用 ACL 将流量代理到 blog-backend。

defaut_backen web_backend 将所有其他流量转发定向到 web-backend。

负载均衡算法

在进行负载均衡时，是由负载均衡算法来定义选择哪个后端服务器。HAProxy 提供了几种算法选项。此外，还可以为服务器分配权重参数，以控制某个服务器与其他服务器相比被选中的频率。可用的算法实在太多，无法一一描述。因此，本指南将仅关注最常用的算法。您可以参考 HAProxy 文档转换器 以查看完整列表。最常用的算法包括：

• roundrobin：依次选择服务器的默认算法。
• leastconn：自动选择连接数最少的服务器。不过，同一后端内的这些服务器应以轮询方式进行轮换。
• source：该算法根据发起用户请求的源 IP 地址来选择服务器。这是一种确保用户始终连接到同一台服务器的方法。

粘性会话

对于某些应用程序，要求连接的用户必须始终链接到同一台服务器。通过“粘性会话”并使用需要它的后端中的 appsession 参数，即可实现这种持久性。

处理健康检查

HAProxy 需要一种方法来确定后端服务器处理请求的能力。这代替了在服务器离线时将其从后端移除的操作。默认运行的“健康检查”会尝试建立 TCP 连接。它通过监听配置的 IP 地址和端口来实现这一点。

如果服务器的健康检查未通过，则该服务器无法处理发送的请求。此时，该服务器在后端会被自动禁用，不再向其转发流量，直到它重新启动并正常运行（健康）。然而，在某些情况下，通过默认健康检查来确定服务器的健康状况被证明是不够的。

替代解决方案

对于您的特定需求，HAProxy 可能会显得过于复杂。在这种情况下，有几个不错的替代方案可能会更高效：

• Nginx：这是一个可靠且快速的 Web 服务器，可用于负载均衡和代理目的。事实上，Nginx 通常与 HAProxy 配合使用，以利用其压缩和缓存功能。
• Linux 虚拟服务器 (LVS)：这是一个简单的 4 层负载均衡器，包含在许多 Linux 系统中。

高可用性

到目前为止，我们已经讨论了 4 层和 7 层负载均衡。它们都利用负载均衡器来确定许多后端服务器中的哪一个将负责响应用户的请求。但重要的是要记住负载均衡器的局限性。即，它是一个单点故障。这意味着如果它宕机或因用户请求过多而过载，将分别导致停机或请求处理延迟。然而，高可用（HA）设置提供了一种没有任何单点故障的基础架构。通过在系统架构的每个层级引入冗余，这可以防止因服务器故障而导致停机事件。虽然负载均衡器将有助于促进后端的冗余，但负载均衡器本身也需要实现冗余。

下图展示了高可用性设置的基本形式：

该基础设施有多个负载均衡器（一个处于活动状态，其余处于被动状态）绑定到一个静态 IP 地址。如果情况需要，可以将此 IP 地址重新映射到其他服务器。用户请求通过外部 IP 地址发送到当前处于活动状态的负载均衡器。如果此时该负载均衡器处于离线状态，故障转移机制将检测其状态，并将 IP 地址重新分配给被动服务器。

结论

对负载均衡的基本理解，以及对 HAProxy 满足系统负载均衡需求的一些方式的了解，应该能为您在开始优化当前服务器环境的可靠性和性能方面打下坚实的基础。您还可以查看我们的教程 Nginx HTTP 代理、负载均衡、缓冲和缓存：概述 以了解更多关于 Nginx 负载均衡特性的信息。

祝您计算愉快！