负载均衡方案

在单机情况下无法满足用户请求时，就需要对服务器进行升级，从一台服务器扩容到几天、几十台、上百台甚至于上千台。

在用户访问某一个网站的时候，首先是通过 DNS 解析，将域名换成 IP，所以在第一步可以通过 DNS 解析的方式，进行第一次负载。

DNS 负载均衡

在用户请求服务的时候，根据出口 IP 将距离用户最近的机房的 IP 返回给用户。

大型云厂商都会提供这种智能解析的服务，比如阿里云 (opens new window)

但是，由于 DNS 会存在缓存的问题，距离用户最近的机房出现了问题，就麻爪了，用户的请求就会出现失败。

引入负载均衡

我们能够通过硬件或者软件的负载均衡，对失败的机房进行检测，只代理成功可用的机房。

而负载均衡根据 OSI 的参考模型可以划分为好几种：

• 二层负载均衡（mac）
• 三层负载均衡（ip）
• 四层负载均衡（tcp）
• 七层负载均衡（http）

转发的数据量，从二层到七层逐层减少，因为越往上层走要处理的数据会越多，相应的性能也会减少。

二层和三层的，基本都是搞网络的兄弟在玩，程序开发最常见的是四层和七层的负载均衡。

四层负载均衡

四层负载均衡工作在 OSI 模型的传输层，负责 TCP/UDP 协议。这两种协议包含了源 IP+ 端口及目标 IP+ 端口。四层负载均衡服务器在接收到客户端的请求之后，通过修改数据包的地址（IP+ 端口号）将流量转发到应用服务器。

能够实现四层负载均衡的软件有:

1. F5：硬件负载均衡器，功能很好，但是成本很高。
2. lvs：重量级的四层负载软件
3. nginx：轻量级的四层负载软件，带缓存功能，正则表达式较灵活
4. haproxy：模拟四层转发，较灵活

这一层一般是由专门的系统工程师来进行维护，软件层面我经常接触到的是用 HaProxy 负载 K8S 集群。

七层负载均衡

七层负载均衡是基于虚拟的 URL 或者主机 IP 的负载均衡，在四层负载均衡上再考虑应用层的特征，比如同一个 Web 服务器的负载均衡，除了根据 80 端口还能够根据 Http 中的报文头，URL 路径等，再决定是否需要进行负载均衡。

实现七层负载均衡的软件有：

1. haproxy：天生负载均衡技能，全面支持七层代理，会话保持，标记，路径转移；
2. nginx：只在 http 协议和 mail 协议上功能比较好，性能与 haproxy 差不多；
3. apache：功能较差
4. Mysql proxy：功能尚可

总的来说，一般是 lvs 做 4 层负载；nginx 做 7 层负载(也能做 4 层负载, 通过 stream 模块)；haproxy 比较灵活，4 层和 7 层负载均衡都能做

负载均衡使用

接下来以 Nginx 举例（比较最常用）

对于负载均衡我们要关心的几个方面如下。

• 上游服务器配置： 使用 upstream server 配置上游服务器。

• 负载均衡算法：配置多个上游服务器时的负载均衡机制;

  1. 轮询
  2. ip_hash
  3. 自定义 hash_key
  4. 一致性 Hash
  5. 最少连接、最少响应等检测后端服务器状态的算法

• 失败重试机制：配置当超时或上游服务器不存活时，是否需要重试其他上游服务器。

  通过配置上游服务器的 nax fails 和 fail timeout,来指定每个上游服务器，当 fail timeout 时间内失败了 max fails 次请求，则认为该上游服务器不可用/不存活，然后将摘掉该上游服务器，fail timeout 时间后会再次将该服务器加入到存活上游服务器列表进行重试。

• 服务器心跳检查：上游服务器的健康检查/心跳检查。

  1. TCP 心跳
  2. Http 心跳

Nginx 提供的负载均衡可以实现上游服务器的负载均衡、故障转移、失败重试、容错、健康检查等，当某些上游服务器出现问题时可以将请求转到其他上游服务器以保障高可用。

Nginx 负载均衡器本身也是一台反向代理服务器，将用户请求通过 Nginx 代理到内网中的某台上游服务器处理，反向代理服务器可以对响应结果进行缓存、压缩等处理以提升性能。Nginx 作为负载均衡器/反向代理服务器如下图所示。

​

总结

最终这些组件组装起来，大概是这样。

就是将这些请求不断的分解、一个不够就两个，一层不够就两层。

只要保证最后，请求打到执行业务逻辑的服务器上的流量足够小，或者刚好能够达到服务器的负载即可。

​