负载均衡

伸缩性架构 – 负载均衡

高伸缩性是大型网站技术架构的一个重要因素。

伸缩性是什么？简单说就是当流量增大时，向集群中添加机器（横向扩容）就可以分散开流量，各个机器提供着没差别服务，机器足够时，不会打垮服务。当机器已然足够，服务仍然挂掉，说明瓶颈并非是机器数量，这就是差的系统伸缩性。

负载均衡可以有效实现伸缩性。

介绍几种负载均衡的实现：

DNS域名解析负载均衡：

在DNS配置多个站点的记录，比如自己的站点www.site.com对应多个IP，这些IP是自己的网站。这样就利用了外部的DNS实现负载均衡。

优点：利用外部的DNS服务实现，比较简单。DNS还有特性，它会就近给用户找网站的服务地，提高了访问速度。
缺点：DNS会做缓存处理。当网站自己做下线处理后，可能会发生用户访问到下线机器。
解决：DNS域名解析配置网站自己负载均衡的IP，并非实际提供web服务的机器。

反向代理负载均衡：

了解nginx的都知道，nginx非常善于干这个。

这里说下『反向』的意思，代理一般是正向的，比如开发中我们常用的fiddler配置个线下域名和IP这种，这样代理一般理解是正向的。反向的意思是，代理的装置是在站点处提供的，比如nginx代理是和站点机房部署在一块的。这种实现，是基于http应用层的转发。

优点：部署简单
缺点：代理装置成为所有入口，可能会成为系统瓶颈。

IP层负载均衡：

IP负载均衡顾名思义是区别与Http应用层转发，是负载均衡拿到系统内核进程的网络包，根据均衡算法，将目的IP变更成后方真实提供web服务的IP。

实现的最复杂点值得一说，即在于 如何让真实web服务器响应包回到负载均衡器。有的同学可能觉得从负载均衡器转发到真实web服务，响应回来这是理所当然的。其实不然，注意这是IP层转发，而非应用层http转发，要知道IP层数据包中的源IP和目的IP。

当用户端请求到负载均衡时，源IP是外网的用户端ip，目的ip是这个负载均衡器的外网IP。经过负载均衡器的IP转换，将数据包的目的IP改成真实web服务器的其中一台（负载算法选择），此时源IP仍然是用户端IP，这将导致真实web服务器没法返回这个包（对于web服务器来说目的IP是这个用户端IP，这样包有去无回了）。因此，当在负载均衡器转发时，修改目的IP的同时，也要修改源IP，修改后的源IP即是负载均衡器的内网IP，这样web服务器就能把响应包返回经过负载均衡器了，此时负载均衡器仍然要修改响应包的源IP（负载均衡的外网IP）和目的IP（用户端IP）。

以上这是一种方法。另一种方法是让这个负载均衡器充当网关，这样进出口都会经过它。

优点：IP层处理转发，性能更高于应用层
缺点：所有请求响应都在负载均衡机器上过，吞吐量限制等会成为瓶颈。
改善：怎么在将响应不在负载均衡机器过。

链路层负载均衡：

链路层解决通信的mac地址。在负载均衡机器上，修改目的mac地址，该种架构中让负载均衡机器IP和真实web服务器虚拟IP一样，负载均衡机器就可以不必修改源IP地址（用户端IP）等。这样真实web服务器处理后，直接响应给用户端，而不必都经过负载均衡器，达到解决响应瓶颈问题。

负载均衡算法

轮询
加权轮询
随机
最少连接

负载均衡设备记录出每个服务器连接数，按少的给分发
原地址散列

对客户端IP进行哈希，这样有个特点就是保证同一个客户端IP多次请求过来能分发到同一个服务器上。这种方式可以解决用户session在集群中不同步的问题。

参考

《大型网站技术架构》

分布式