导读系列
这篇导读是WordPress用HAProxy进行负载均衡系列4篇文章的第一篇
介绍
HAProxy，字面意思是高可靠性代理服务器，它是一款流行的开源的TCP/HTTP负载均衡和代理服务解决方案，可以运行在Linux，Solaris和FreeBSD上。最常见的应用是通过将负载分配到多个服务器上（例如，web， 应用，数据库）来提高服务器环境的性能和可靠性。 它现在被很多有影响的服务所使用，包括：GitHub, Imgur, Instagram和Twitter。
在这篇指引中，我们首先概述一下HAProxy是什么，基本的负载均衡术语，然后是在你的环境中如何提高性能和可靠性的一些例子。
HAProxy术语
在讨论负载均衡和代理时有很多重要的名词和概念。在下面的几节中我们会回顾一下常见的名词。
在我们讨论负载均衡的基本类型之前，先看一下ACLs, backend和frontend。
访问控制列表（ACL）
在负载均衡中，ACL用于检测一些条件并基于检测结果做出动作（例如，选择一台服务器或者阻塞一个请求）。使用ACLs可以基于各种条件，像模式匹配和后台连接数，来实现灵活的网络流量转发，例如
一个ACL示例：
acl url_blog path_beg /blog
如果用户的请求路径以/blog开头，那这个ACL就会被匹配到。比如这能匹配请求
更详尽的ACL用法请参见
HAProxy配置手册。
Backend
后端是接收转发过来请求的一组服务器。后端在HAProxy配置的backend部分被定义。在最基本形式中，后端可以定义为：
- 使用哪种负载均衡算法
- 服务器和端口列表
后端可以包含一台或多台服务器，通常来说，向后端中增加更多的服务器能够通过将负载分摊到多台服务器上来增加载荷的潜能。通过这种方式也能够增强系统可靠性，以防一些后端服务器挂掉。
这里有一个两台后端服务器配置的例子，web-backend和blog-backend，每个上有两台web服务器，监听在80端口：
backend web-backend
balance roundrobin
server web1 web1.yourdomain.com:80 check
server web2 web2.yourdomain.com:80 check
backend blog-backend
balance roundrobin
mode http
server blog1 blog1.yourdomain.com:80 check
server blog1 blog1.yourdomain.com:80 check
balance round robin一行指定了负载均衡算法，在负载均衡算法一节中有详细介绍。
mode http指定使用7层代理，这在负载均衡分类一节中会有解释。
server指令一行最后的check选项指定了后端服务器需要进行健康检查。
Frontend
前端定义了请求如何转发给后端。前端定义在HAProxy配置文件的frontend小节，由下面几部分组成：
- 一组IP地址和端口（例如 10.1.1.7:80, *:443，等等）
- ACLs
- use_backend规则，定义了根据ACL，匹配到了哪个就用哪个后端，以及/或者一个default_backend规则处理所有其它情况。
前端可以被配置为任意类型的网络流量，下一节有说明。
负载均衡的类型
现在我们对负载均衡中用到的基本元素有了一个了解，那就进一步来看看负载均衡的基本类型。
没有负载均衡
一个没有负载均衡的简单的web应用看起来像这样：
在这个例子中，用户直接连接到服务器，yourdomain.com，没有负载均衡。如果你唯一的web服务器挂了的话，用户就不能再访问了。另外，如果很多用户试图同时访问你的服务器，它可能无法处理大量的请求，用户感觉服务器很慢或者根本就连不上。
4层负载均衡
将网络流量负载均衡到不同服务器的最简单的方法是4层（传输层）负载均衡。这种负载均衡基于IP和端口来转发用户流量（如， 如果一个要求访问http://yourdomain.com/anything的请求，流量会被转发到能够处理在yourdomain.com上端口为80的请求的那台服务器上）。如果需要4层的更多详情，请查阅我们的
网络介绍中TCP章节
下面是一个简单的4层负载均衡的例子：
用户访问负载均衡服务器，它将用户请求转发给web-backend组中的服务器。不论哪台后端服务器被选中了，它会直接响应用户的请求。通常来说，web-backend组中的服务器都应该能返回相同的内容 -- 否则，用户会收到不一致的内容。注意两台web服务器连接到同一个数据库服务器。
7层负载均衡
另一种情况，更复杂的方式是在7层（应用层）进行负载均衡。7层负载均衡能够根据请求的内容转发请求到不同的后端服务器。这种方式允许你在相同的域名和端口下运行多个web应用服务器。更多7层的解释，请查看
网络介绍中HTTP章节。
下面是一个简单的7层负载均衡的例子：
在这个例子中，如果用户请求yourdomain.com/blog，它们被转发给blog后端服务器，也就是一组运行blog应用的服务器。其他请求被转发到web-backend，上面运行其他应用。在这个例子中，两种后端使用相同的数据库服务器。
前端配置片段的示例看起来应该是这样：
frontend http
bind *:80
mode http
acl url_blog path_beg /blog
use_backend blog-backend if url_blog
default_backend web-backend
这配置了一个名为http的前端，处理所有在端口80上流入的流量。
acl url_blog path_beg /blog能够匹配上以/blog开头的用户请求
use_backend blog-backend if url_blog允许ACL将流量代理到blog-backend
default_backend web-backend指定所有其他流量转发到web-backend。
负载均衡算法
负载均衡算法用于决定哪台服务器，在后端，被选中用来进行负载均衡。HAProxy提供了好几种算法选项，在此之上，服务器可以被赋予一个weight参数，来控制这个服务器
相对与其他服务器
被选择的频率。
由于HAProxy提供了如此多的负载均衡算法，这里我们只简要介绍其中几种。完整的算法列表请参见HAProxy配置手册。
几种常用算法列举如下：
roundrobin
Round Robin轮流选择服务器。这是默认算法。
leastconn
选择有最少连接数的服务器--推荐用于长会话。同一个后端的不同服务器仍旧用round robin方式循环。
source
基于源IP地址的hash值来选择服务器。这种方法可以保证同一个用户始终连接同一个服务器。
Sticky Sessions（会话粘滞）
有些应用要求一个用户始终连接到相同的后端服务器上。这种情况通过会话粘滞实现，在需要它的后端上用appsession参数。
健康检查
HAProxy用健康检查来决定一个后端服务器是否能用来处理请求。这避免在服务器不可用的时候，需要手工从后端移除。默认的健康检查是尝试建立一个到服务器的TCP连接，比如，检查后端服务器是否监听在配置的IP和端口上。
如果一台服务器未通过健康检查，也就无法提供服务，它会在后端被自动去使能，流量不会被再转发给它，直到它再次健康。如果所有服务器都失败了，整个服务就变为不可得了，直到至少一台后端服务器恢复健康。
对于特定类型的后端，像特定情况下的数据库服务器，默认的健康检查是不足以决定服务器是否健康的。
其他解决方案
如果你认为HAProxy对你的需求来说太复杂了，下面的方案可能更合适：
Linux虚拟服务（LVS） - 简单、快速的4层负载均衡器，包含在很多Linux发行版中
Nginx - 快速可靠的web服务器，可以用于代理和负载均衡。Nginx由于它的缓存和压缩能力而经常与HAProxy结合使用
高可获得性
上面提及的4层和7层的负载均衡环境中都用负载均衡器将流量导向到很多台服务器中的一台上。然而，这些环境中的负载均衡器本身存在单点失败问题；如果它失效或者有海量请求，会导致服务的延迟或者宕机时间的增加。
高可获得性（HA）环境是一套没有单点失效问题的基础设施。它通过向架构中的每一层增加冗余来避免单机失败导致的宕机事件。负载均衡器让后端（web/app服务器）拥有了冗余，但是对于真正的高可获得性环境，负载均衡本身也需要冗余。
下图是一个基本的高可获得性环境：
在这个例子中，在一个静态IP地址后面，你拥有了多台负载均衡器（一台活动及多台备份的），这个IP地址可以从一台服务器重新配置到另一台。当一个用户访问你的网站时，请求通过外部IP进入活动的负载均衡器。如果这台负载均衡器失效，倒换机制能够感知并自动将IP地址配置到另外一台备份服务器上。有很多种方式实现主备HA，更多请阅读
如何使用浮动IP的这一个部分。
结论
现在你对负载均衡有了一个基本的理解，直到HAProxy能够让你拥有负载均衡能力的几种方式，你有了扎实的基础来开始提高自己服务器环境的性能和可靠性。
下面的导读提供了详细的HAProxy配置样例：
原文链接：
185
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
