负载均衡 （一） 工做模式以及工做原理

负载均衡（科普篇）

 
 
负载均衡（Load Balancing），简单地说就是将多台服务器组成一个服务器集群,而后根据咱们设置的规则给服务器集群分配“工做任务”。
 
典型的互联网应用的拓扑结构

 
负载均衡的多种解决方案：

HTTP重定向

当用户发来请求的时候，Web服务器经过修改HTTP响应头中的Location标记来返回一个新的url，而后浏览器再继续请求这个新url，实际上就是页面重定向。
经过重定向，来达到“负载均衡”的目标。例如，咱们在下载PHP源码包的时候，点击下载连接时，为了解决不一样国家和地域下载速度的问题，它会返回一个离咱们近的下载地址。重定向的HTTP返回码是302
这个重定向很是容易实现，而且能够自定义各类策略。可是，它在大规模访问量下，性能不佳。并且，给用户的体验也很差，实际请求发生重定向，增长了网络延时。
 

反向代理负载均衡

反向代理服务的核心工做主要是转发HTTP请求，扮演了浏览器端和后台Web服务器中转的角色。由于它工做在HTTP层（应用层），也就是网络七层结构中的第七层，所以也被称为“七层负载均衡”。能够作反向代理的软件不少，比较常见的一种是Nginx。
Nginx是一种很是灵活的反向代理软件，能够自由定制化转发策略，分配服务器流量的权重等。反向代理中，常见的一个问题，就是Web服务器存储的session数据，由于通常负载均衡的策略都是随机分配请求的。同一个登陆用户的请求，没法保证必定分配到相同的Web机器上，会致使没法找到session的问题。

解决方案主要有两种：
1)配置反向代理的转发规则，让同一个用户的请求必定落到同一台机器上（经过分析cookie），复杂的转发规则将会消耗更多的CPU，也增长了代理服务器的负担。
2)将session这类的信息，专门用某个独立服务来存储，例如Redis/memchache，这个方案是比较推荐的。

反向代理服务，也是能够开启缓存的，若是开启了，会增长反向代理的负担，须要谨慎使用。这种负载均衡策略实现和部署很是简单，并且性能表现也比较好。
可是，它有“单点故障”的问题，若是挂了，会带来不少的麻烦。并且，到了后期Web服务器继续增长，它自己可能成为系统的瓶颈。
 

DNS负载均衡

DNS（Domain Name System）负责域名解析的服务，域名url其实是服务器的别名，实际映射是一个IP地址，解析过程，就是DNS完成域名到IP的映射。而一个域名是能够配置成对应多个IP的。所以，DNS也就能够做为负载均衡服务。
这种负载均衡策略，配置简单，性能极佳。可是，不能自由定义规则，并且，变动被映射的IP或者机器故障时很麻烦，还存在DNS生效延迟的问题。
 

CDN/GSLB负载均衡

咱们经常使用的CDN（Content Delivery Network，内容分发网络）实现方式，其实就是在同一个域名映射为多IP的基础上更进一步，经过GSLB（Global Server Load Balance，全局负载均衡）按照指定规则映射域名的IP。
通常状况下都是按照地理位置，将离用户近的IP返回给用户，减小网络传输中的路由节点之间的跳跃消耗。

CDN在Web系统中，通常状况下是用来解决较大的静态资源（html/Js/Css/图片/视频/文件等）的加载问题，让这些比较依赖网络下载的内容，尽量离用户更近，提高用户体验。
这种方式，和前面的DNS负载均衡同样，性能极佳，并且支持配置多种策略。可是，搭建和维护成本很是高。互联网一线公司，会自建CDN服务，中小型公司通常使用第三方提供的CDN。

IP负载均衡

IP负载均衡服务是工做在网络层（修改IP）和传输层（修改端口，第四层），比起工做在应用层（第七层）性能要高出很是多。
原理是，他是对IP层的数据包的IP地址和端口信息进行修改，达到负载均衡的目的。这种方式，也被称为“四层负载均衡”。
常见的负载均衡方式，是LVS，经过IPVS（IP Virtual Server，IP虚拟服务）来实现。

LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。

 
这个项目在1998年5月由章文嵩博士成立，是中国国内最先出现的自由软件项目之一。
 

Lvs 提供几种负载均衡集群机制：

 

DR模式  直接路由模式
NAT模式 网络地址转换模式
TUN模式 隧道模式
FULLNAT模式

LB 负载均衡（Load Balance）
RS 真实服务器（Real Server）
 

1.DR模式（Direct Routing）

　　DR模式下，客户端的请求包到达负载均衡器的虚拟服务IP端口后，负载均衡器不会改写请求包的IP和端口，可是会改写请求包的MAC地址为后端RS的MAC地址，而后将数据包转发；真实服务器处理请求后，响应包直接回给客户端，再也不通过负载均衡器。因此DR模式的转发效率是最高的，特别适合下行流量较大的业务场景，好比请求视频等大文件。
 
　　DR模式的特色：
数据包在LB转发过程当中，源/目的IP端口都不会变化
　　LB只是将数据包的MAC地址改写为RS的MAC地址，而后转发给相应的RS。
 
每台RS上都必须在环回网卡上绑定LB的虚拟服务IP
　　由于LB转发时并不会改写数据包的目的IP，因此RS收到的数据包的目的IP还是LB的虚拟服务IP。为了保证RS可以正确处理该数据包，而不是丢弃，必须在RS的环回网卡上绑定LB的虚拟服务IP。这样RS会认为这个虚拟服务IP是本身的IP，本身是可以处理这个数据包的。不然RS会直接丢弃该数据包！
 
RS上的业务进程必须监听在环回网卡的虚拟服务IP上，且端口必须和LB上的虚拟服务端口一致
　　由于LB不会改写数据包的目的端口，因此RS服务的监听端口必须和虚拟服务端口一致，不然RS会直接拒绝该数据包。
 
RS处理完请求后，响应直接回给客户端，再也不通过LB
　　由于RS收到的请求数据包的源IP是客户端的IP，因此理所固然RS的响应会直接回给客户端，而不会再通过LB。这时候要求RS和客户端之间的网络是可达的。
 
LB和RS须位于同一个子网
　　由于LB在转发过程当中须要改写数据包的MAC为RS的MAC地址，因此要可以查询到RS的MAC。而要获取到RS的MAC，则须要保证两者位于一个子网，不然LB只能获取到RS网关的MAC地址。

 

2.NAT模式（Network Address Translation）

　　NAT模式下，请求包和响应包都须要通过LB处理。当客户端的请求到达虚拟服务后，LB会对请求包作目的地址转换（DNAT），将请求包的目的IP改写为RS的IP。当收到RS的响应后，LB会对响应包作源地址转换（SNAT），将响应包的源IP改写为LB的IP。

 
　　NAT模式的特色：

LB会修改数据包的地址
　　对于请求包，会进行DNAT；对于响应包，会进行SNAT。
 
LB会透传客户端IP到RS（DR模式也会透传）
　　虽然LB在转发过程当中作了NAT转换，可是由于只是作了部分地址转发，因此RS收到的请求包里是能看到客户端IP的。
 
须要将RS的默认网关地址配置为LB的浮动IP地址
　　由于RS收到的请求包源IP是客户端的IP，为了保证响应包在返回时能走到LB上面，因此须要将RS的默认网关地址配置为LB的虚拟服务IP地址。固然，若是客户端的IP是固定的，也能够在RS上添加明细路由指向LB的虚拟服务IP，不用改默认网关。
 
LB和RS须位于同一个子网，而且客户端不能和LB/RS位于同一子网
　　由于须要将RS的默认网关配置为LB的虚拟服务IP地址，因此须要保证LB和RS位于同一子网。
 
　　又由于须要保证RS的响应包能走回到LB上，则客户端不能和RS位于同一子网。不然RS直接就能获取到客户端的MAC，响应包就直接回给客户端了，不会走网关，也就走不到LB上面了。这时候因为没有LB作SNAT，客户端收到的响应包源IP是RS的IP，而客户端的请求包目的IP是LB的虚拟服务IP，这时候客户端没法识别响应包，会直接丢弃。
 

3.TUN模式 (tunnel)

　　采用NAT模式时，因为请求和响应的报文必须经过调度器地址重写，当客户请求愈来愈多时，调度器处理能力将成为瓶颈。
为了解决这个问题，调度器把请求的报文经过IP隧道转发到真实的服务器。真实的服务器将响应处理后的数据直接返回给客户端。
这样调度器就只处理 入站请求报文，因为通常网络服务应答数据比请求报文大不少，采用TUN模式后，集群系统的最大吞吐量能够提升10倍。
　　 
　　TUN和NAT模式不一样的是，它在LB和RS之间的传输不用改写IP地址。而是把客户请求包封装在一个IP tunnel里面，而后发送给RS节点服务器，节点服务器接收到以后解开IP tunnel后，进行响应处理。
而且直接把包发送给客户端，不用通过LB服务器。
 

4.FULLNAT模式

FULLNAT模式
　　FULLNAT模式下，LB会对请求包和响应包都作SNAT+DNAT。
 
　　FULLNAT模式的特色：

LB彻底做为一个代理服务器　　FULLNAT下，客户端感知不到RS，RS也感知不到客户端，它们都只能看到LB。此种模式和七层负载均衡有点类似，只不过不会去解析应用层协议，而是在TCP层将消息转发LB和RS对于组网结构没有要求　　不一样于NAT和DR要求LB和RS位于一个子网，FULLNAT对于组网结构没有要求。只须要保证客户端和LB、LB和RS之间网络互通便可。