前言
面对大量的访问请求与海量的数据，我们可以通过加大单机的性能来实现服务的稳定，还可以考虑拆分系统来防止单机故障。
负载均衡（Load Balance）是指将负载（例如访问请求，任务等等）进行平衡分摊到多个服务器或组件上执行，以提高性能，作为单点故障的解决方案。
本文将讨论常见的负载均衡分类。
负载均衡分类
从实现方式不同，可以分为软件实现与硬件实现。从实现的节点不同，我们可以分为DNS负载均衡，HTTP负载均衡，IP负载均衡，链路层负载均衡等等。
DNS负载均衡
这是一种利用域名解析来实现的负载均衡技术，在DNS服务器上配置多个A记录，这些A记录对应的是服务器集群，在大型网站中，DNS解析通常作为第一级负载均衡。
优点有：
- 使用简单，全交给DNS服务器来处理，不需要额外配置负载均衡服务器。
- 基于用户的地址，可以解析成距离用户最近的服务器地址，加快访问速度。
缺点有：
- DNS服务是多级服务，在增加或者修改DNS后，需要较长时间才能传递到全网。在这段时间内用户可能会访问失败。
- 维护性差。由于DNS服务不能知道服务器的负载情况，所以支持的算法较少，无法根据服务器当前负载量进行调节。
- DNS的控制器通常来说在域名商手里，导致无法做更多的扩展。
HTTP负载均衡
这是一种利用反代技术来转发HTTP流量的技术，通常使用Nginx作为负载均衡工具，在用户的HTTP请求到达后，由反向代理服务器根据算法，将HTTP请求发送给相应的服务器，服务器完成处理后，再将数据返回给代理服务器，由代理服务器将数据转交给用户。
优点有：
- 没有暴露真实服务器ip。可以有效的隐藏内网信息。
- 支持的算法较多，可以根据需求不同来配置不同负载均衡策略。
- 安装和配置相对简单。
缺点有：
- 对服务器的健康检查只支持端口检测，而不支持url检测。如出现错误，则会转至另一服务器进行重试。
- 适用的范围较小，只支持http，https等协议。
IP负载均衡
在网络层通过修改目的地址来实现负载均衡。用户请求到达负载均衡服务器后，负载均衡服务器从负载均衡算法得到一个真实服务器地址，将ip数据报的目的地址改为改真实服务器的地址。真实服务器处理完成后，将响应数据包返回给负载均衡服务器，负载均衡服务器再将ip数据报的源地址改为自身的ip地址，发送给用户。
其中，真实服务器将数据返回给负载均衡服务器时，存在两种方式，第一种是负载均衡服务器作为真实服务器集群的网关，则不用配置其他东西。第二种方式是负载均衡服务器在修改目的ip地址的同时修改源地址，然后就可从真实服务器收到返回数据，这种方式成为源地址转换(snat)。
链路层负载均衡
工作在数据链路层，通过修改mac地址来进行负载均衡。在用户请求到达时，不修改ip地址，而是修改目的mac地址，配置真实服务器集群与负载均衡服务器的ip一致，达到不修改ip地址来进行数据转发。这种方式也成直接路由模式（DR模式）。
混合型负载均衡
通常作为一个大型架构，不会只使用一种负载均衡方案，而是采用多个负载均衡方案来实现。
这里举个简单方式：
用户进行DNS查询时，由DNS服务器根据负载均衡算法返回不同的反向代理服务器，再由反向代理服务器将请求分配给应用负载均衡服务器，接着由应用负载均衡服务器通过ip模式或者DR模式进行请求转发。
这种方式反向代理服务器不仅用于请求的转发，并且可以缓存静态资源，当请求是静态资源时，可以直接返回，而不是将请求进行转发。如果是动态页面时，则请求后面的应用负载均衡服务器。
由于混合模式需要根据具体场景来灵活搭配各种方式，所以以上的方式仅供参考。
硬件负载均衡
硬件负载均衡是直接在服务器与外部网络间安装负载均衡设备。一般而言，硬件负载均衡在功能、性能上优于软件方式。硬件负载均衡通常用作全局负载均衡，搭配软件负载均衡来实现整个负载均衡架构。常见的硬件负载均衡器有F5和A10。
优点： 能够直接通过智能交换机实现,处理能力更强，而且与系统无关，负载性能强。
缺点： 成本高，配置冗余。负载均衡器可能无法掌握服务器集群的状态，而是从网络的层面来判断负载情况，网络负载正常的情况下，也可能应用层已经阻塞了。
总结
以上主要从负载均衡的分类入手，对各种负载均衡进行介绍，并简单介绍了常见负载均衡架构。
之后会单独聊聊负载均衡的算法。