负载均衡的前世今生

序言

LB,SLB,ALB，GSLB,CDN，傻傻分不清楚，听风看雨。。。毒鸡汤看多了，我快掩饰不住我的悲伤了。。。

负载均衡，碰到的太多，使用的场景也很多，无论你是传统行业，还是互联网行业，魂牵梦绕的技术，所以谈谈其发展。

前世今生

当业务量小的时候，每天访问的人数就那么几个的时候，我们用一台服务器就够了，上面部署上开发写的应用，部署上数据库服务，再加一个前端程序。

随着业务量的增多，访问的并发越来越高，服务器的负载加大，可能首先进行垂直增加服务器的性能，也就是原来是4C8G，现在增加到32C156G。

随着业务量的进一步增多，服务器的响应时间越来越长，垂直增加性能，一个是成本太高，另外一个是可用性不高，从而需要拆分，并使用集群的方式，也就是应用程序划分多个服务器，进行水平扩容，那么在用户访问的时候，访问那个应用服务器呢？从而就有了负载均衡。

负载均衡，load balance，简称为LB，也可以写成service load balance，从而称之为SLB，也可以写成Application load balance，从而称之为ALB，进一步的负载均衡就是全局负载均衡，就可以写成Global service load balance，当发现性能还是不够的时候，就是CDN，也就是内容分发网络，称之为content delivery network。

可能我们在平时不知不觉中已经接触到了负载均衡，例如常见的LVS四层负载均衡，nginx/httpd/haproxy七层负载均衡，四层和七层有啥区别，区别在于协议不同，七层是应用层协议，一般指的是http和https协议，四层指的是网络层协议，一般指的是tcp/udp协议，当然也可以代理mysql协议

负载均衡根据类型划分，主要划分为三种类型：第一种类型为DNS负载均衡（软硬结合的方式），主要是使用DNS解析出IP的方式，来进行业务流量的分发，并发无上限；第二种类型为硬件负载均衡，例如那些贵的离谱的硬件设备，F5，A10，并发百万级别；第三种类型为软件负载均衡，就是我们常见的负载均衡软件，例如nginx，lvs，并发几万到百万级别

权衡？是不是这三种我们只能选一种，是不是选择最好的哪种？不是的，这三种的使用范围和场景不一样，从而我们可以使用组合的方式来使用。

DNS负载均衡主要适用于的场景是多地集群的方式，也就是可能北京有一个数据中心，在其中部署了一整套的集群提供服务，在上海有一个数据中心，也部署了同样的一套的集群来提供服务，用于预防地震，水灾，整个机房断电的故障，这种可以将请求发送给不同的数据中心，从而可以使用户更加快速的访问到服务，异地恋了解一下。。。数据中心级别的负载均衡

硬件负载均衡，硬件厂商一般能提供强力的服务，稳定性较高，性能较好，能支持百万级别的并发量，缺点就是太贵了，在一个数据中心，一般买俩就够了，做成主备的形式，提供高可靠，高可用。。。集群之间的负载均衡

软件负载均衡，一般就是在前端创建一个SLB，然后在后端挂上真正的物理服务器，成为多个应用服务器的控制器，可以用各种调度算法来进行调度。。。服务器之间的负载均衡

三种的选择，可以是随着业务的发展递增式的使用，先是使用SLB，然后扛不住，上硬件，再扛不住上DNS，再扛不住用GSLB，还不行，上CDN。

权衡，那么在软件负载均衡之中怎么选？建议的类型就是四层SLB使用LVS，性能高，可靠性强，能做健康检查，能做会话同步；七层使用nginx，模块多，扩展性好，当然没有最好，选择你熟悉的，根据业务定制也不错。

分配算法

在SLB选择后端的rs也就是real server真正的服务器处理请求的时候，有多种类型的算法可以选择。

最常用的方式就是RR（round robin）轮询的方式，不管你后端的服务器是什么样的，不管你后端服务器的压力如何都会发送请求过去，这种的优点是简单，但是不能感知到服务器的状态。

改进的方式就是使用WRR（weight round robin）加权轮询的方式，这种会考虑后端的服务器的性能，例如一台服务器的配置是2C4G，一台服务器的配置是4C8G，那么在设置权重的时候，就可以将第一台配置为1，第二台配置为2，从而如果客户端发送了6个请求过来，第一台会处理2个请求，而第二台会处理4个请求， 这种方式只是考虑到了服务器本身的物理配置，而没有考虑到服务器本身的性能。。。这种方式是最常见的使用方式，及时所有的服务器配置一样，也要使用WRR的方式，也就是权重一样，这种便于切流，也就是可以动态的将一台服务器的权重设置为0，从而不会影响业务，而使用RR的方式的时候，有服务器下线会报错，当然，在其中也可以配置相关的如果发现一个请求不通，跳转到另外的机器，但是增加了配置配置文件的复杂度，相对来说WRR更加简单。

再使用的方式就是使用WLC（weighted least connection）最少连接数的方式，在此种情况下，判断服务器的性能主要靠检测后端服务器的连接数量，如果连接过多，就认为你的负载很大，如果连接很少，那么可以理解为分配给这台服务器处理，性能会更高。这种方式主要是从服务器端来考虑，也就是考虑服务器的性能，在此处可以定义不同的检测方式，例如如果是CPU密集型，那么可以使用CPU的负载来进行衡量，如果是IO密集型，那么可以使用IO的负载来进行衡量。在LVS中就是通过连接数来进行衡量，而在nginx中，可以使用http连接数来进行衡量。

还有使用的方式就是站在客户端角度来考虑服务器的性能，主要就是统计和分析客户端到服务端的请求响应时间来判断性能好坏，如果一台服务器的RTT（round trip time） 往返时间很短，可以理解为性能很好，从而可以将请求发送给这台服务器进行处理。

在以上的分配算法当中，没有考虑会话的情况，在很多的应用场景下都需要考虑会话需要保持在同一台服务器中，最简单的例子就是你登录一个网站的时候，刷新一下不需要重新登录，说明你的请求发送给了同一台服务器进行处理，在保持会话的时候，可以根据源ip进行hash，也可以对目标ip进行hash，或者是通过session id或者user id进行hash分配到同一台服务器进行处理，在LVS中是通过IP hash进行会话同步，在nginx中可以通过session id进行会话同步。

分配算法，站在不同的角度考虑问题，站在服务端，你需要考虑服务器的cpu负载，io负载，网卡的吞吐，网络连接数；站在客户端，我主要关注的是请求和响应的时间。。。

一个人的压力大小和负载其实是一样的，负载来源于哪里，让你去做事，你不做，你说你压力大。。。团队中分配任务也是一样的，你是采用轮询？还是采用加权轮询？还是采用任务数量？还是采用做任务的速度？。。种种策略和工作一样一样的

站在不同的角度，其实就是第一个指你本身解决问题的能力；第二个客户需要你的什么能力。。。合理的运用你的能力，这个本身也是一种能力。。。珍珑棋局了解一下。。。

GSLB和CDN了解一下

GSLB其实是DNS轮询方式的一种改进，因为DNS轮询的时候比较傻，它不能对后端的服务进行健康检查，没准有一个机房挂了，但是。。。。它依旧把请求发送给那个机房，从而就有了GSLB。

DNS还有一个缺点就是在DNS解析的时候，一般会先向本地的DNS服务器进行解析，但是这并不是客户端的真实的IP地址，从而有可能分配的时候，并不是距离上最近的或者是性能最好的，从而也就有GSLB。

DNS的轮询其实是GSLB的一种实现方式，所以这种也能称之为GSLB，而DNS轮询这种说法比较少，而GSLB的实现方式中，还有一种方式就是HTTP 302跳转，将GSLB的IP地址作为域名的A记录，然后访问GSLB的时候，会将请求返回给客户端，然后给一个302响应，让客户端跳转到真正的地址（此种方式GSLB能看到客户端的真实的IP地址，从而给出距离跟进的服务器ip地址）。

在上面一种实现中，只能代理http的请求，而其他的请求不能代理，从而就有了ip欺骗的方式，我不怕你骗我，我就怕。。。你骗不到我。。如下：

在这种时候，zone1的位置的服务器会修改源ip地址，修改为GSLB的ip，从而直接发送给客户端。但是这种本身上会有部分性能和响应的损耗。

当使用GSLB的时候，性能不能满足怎么办。。。欲求不满啊。。。

CDN，内容分发网络，其实好像也没啥神奇的，就是使用缓存，你请求web页面慢，我缓存你，你请求图片慢，我缓存你，你请求视频慢，我缓存你。。。没有缓存不能解决的事。。。cpu的L1 cache和L2 cache，还有L3 cache了解一下

在CDN中，GSLB变成了其中的一部分，指向的地址修改为各大缓存的地址，可以是squid，或者是varnish，或者是nginx的缓存，缓存。。。缓存热点数据，有就直接返回，没有就到源里面去取，然后再缓存，再返回给客户端。