关于负载均衡的一些实现
今天在看高并发架构时，发现负载均衡是有多种实现的，并不仅仅局限在nginx的反向代理、dubbo调用服务提供者时提供的负载均衡，主要有5种：
参考资料：https://kaiwu.lagou.com/course/courseInfo.htm?courseId=2#/detail/pc?id=24
1、HTTP 重定向负载均衡
来自用户的 HTTP 请求到达负载均衡服务器以后，负载均衡服务器根据某种负载均衡算法计算一个新的服务器，通过 HTTP 重定向响应，将新的 IP 地址发送给用户浏览器，用户浏览器收到重定向响应以后，重新发送请求到真正的应用服务器，以此来实现负载均衡。
HTTP 重定向负载均衡的优点是它的设计比较简单，最简单的 HTTP 重定向负载均衡服务器，可能只需要几十行代码就可以完成。但是它的缺点是，用户完成一次访问需要两次请求数据中心，一次请求负载均衡服务器，一次是请求应用服务器；另一个问题是因为响应要重定向到真正的应用服务器，所以需要把应用服务器的 IP 地址暴露给外部用户，这样可能会导致安全性的问题。
2、DNS负载均衡
浏览器访问我们数据中心的时候，通常是用域名进行访问，HTTP 协议则必须知道 IP 地址才能建立通信连接，那么域名是如何转换成 IP 地址的呢？
就是通过 DNS 服务器来完成。当用户从浏览器发起发起 HTTP 请求的时候，他输入域名，首先要到 DNS 域名服务器进行域名解析，解析得到 IP 地址以后，用户才能够根据 IP 地址建立 HTTP 连接，访问真正的数据中心的应用服务器，那么就可以在 DNS 域名解析的时候进行负载均衡，不同的浏览器进行解析的时候，返回不同的 IP 地址，从而实现负载均衡。
问题
目前主要的 DNS 服务商和 DNS 软件都支持 DNS 域名解析负载均衡。DNS 域名解析负载均衡的主要问题有两个方面。一方面它依然是要将 Web 服务器的 IP 地址暴露给浏览器，产生安全问题。另一方面，很多时候，DNS 域名解析服务器是在互联网应用系统之外的一个服务器，它由域名解析服务商提供，不在我们的控制范围之内，所以当我们的服务器不可用的时候，DNS 域名解析服务器并不知道，它依然会将用户请求分发过来。而且域名解析并不是每一次请求都进行解析的，即使我们去域名解析服务商的机器上去更新了域名解析对应的 IP 列表，这个更新也不会立即生效，依然会有大量的请求到达我们的应用服务器。那么这些已经宕机的、不可用的服务器就无法完成用户的需求，在用户看起来就是我们的系统不可用。
虽然 DNS 域名解析负载均衡有这样的一些问题，但是在实践中大型互联网系统几乎都使用域名解析负载均衡，主要原因是在于，这些大型互联网系统，比如像淘宝、Facebook、百度这些系统，根据域名解析出来的 IP 地址，并不是真正的 Web 服务器 IP 地址，是负载均衡服务器的 IP 地址，也就是说这些大型互联网系统，它们都采用了两级负载均衡机制，DNS 域名解析进行一次负载均衡解析出来的 IP 地址是负载均衡服务器的 IP 地址，然后由负载均衡服务器，再做一次负载均衡，将用户的请求分发到应用服务器，这样的话，我们的应用服务器的 IP 地址就不会暴露出去。同时由于负载均衡服务器通常是比较高可用的，也不存在应用程序发布的问题，所以很少有可用性方面的问题。
3、反向代理负载均衡
用户请求到达数据中心以后，最先到达的就是反向代理服务器。反向代理服务器，除了可以提供请求的缓存功能以外，还可以进行负载均衡，将用户的请求分发到不同的服务器上面去。反向代理是工作在 HTTP 协议层上的一个服务器，所以它代理的也是 HTTP 的请求和响应。而 HTTP 协议相对说来，作为互联网第七层的一个协议，它的协议比较重，效率比较低，所以反向代理负载均衡通常用在小规模的互联网系统上，只有几台或者十几台服务器的规模
4、IP层负载均衡(四层负载均衡)
在七层网络通讯之下的另外一种负载均衡方法是在 IP 层进行负载均衡，IP 层是网络通讯协议的第四层，所以有时候叫四层负载均衡。它的主要工作原理是当用户的请求到达负载均衡服务器以后，负载均衡服务器会拿到 TCP/IP 的数据包，对数据包的 IP 地址进行转换，修改 IP 地址，将其修改为 Web 服务器的 IP 地址，然后把数据包重新发送出去。
因为 IP 地址已经是 Web 服务器的 IP 地址，所以这个数据包会重新路由到应用服务器上，以此来实现负载均衡。IP 层负载均衡，比我们刚才提到的工作在第七层的反向代理负载均衡效率要高得多。
缺点：
但是它依然有一个缺陷，就是不管是请求还是响应的数据包都要通过负载均衡服务器进行 IP 地址转换，才能够正确地进行数据分发，或者正确地响应到用户的客户端浏览器。请求的数据通常比较小，一个 URL 或者是一个简单的表单，但是响应的数据不管是 HTML 还是图片，JS、CSS 这样的资源文件通常都会比较大，因此负载均衡服务器会成为响应数据的流量瓶颈
5、数据链路层负载均衡
为了解决IP负载均衡流量瓶颈的问题，将负载均衡的数据传输，再往下放一层，放到了数据链路层，实现数据链路层的负载均衡。
在这一层上，负载均衡服务器并不修改数据包的 IP 地址，而是修改网卡的 MAC 地址。而应用服务器和负载均衡服务器都使用相同的虚拟 IP 地址，这样 IP 路由就不会受到影响，但是网卡会根据自己的 MAC 地址选择负载均衡发送到自己的网卡的数据包，交给对应的应用服务器去处理，处理结束以后，当他把响应的数据包发送到网络上的时候，因为 IP 地址没有修改过，所以这个响应会直接到达用户的浏览器，而不会再经过负载均衡服务器。