负载均衡之总结篇

需要考虑的问题
　　
在提出具体的负载平衡解决方案之前，我们需要首先讲解一下在设计负载平衡系统时我们所需要考虑的一些事情。
　　
首先要说的就是要在负载平衡系统设计时留意它的高可用性及扩展性。在一开始的讲解中，我们就已经提到过通过使用负载平衡，由众多服务器实例所组成的服务具有很高的可用性及扩展性。当其中一个服务实例失效的时候，其它服务实例可以帮助它分担一部分工作。而在总服务容量显得有些紧张的时候，我们可以向服务中添加新的服务实例以扩展服务的总容量。
　　
但是由于所有的数据传输都需要经过负载平衡服务器，因此负载平衡服务器一旦失效，那么整个系统就将无法使用。也就是说，负载平衡服务器的可用性影响着整个系统的高可用性。
　　
解决这个问题的方法要根据负载平衡服务器的类型来讨论。对于L3/4负载平衡服务器而言，为了能够让整个系统不失效，业界中的常用方法是在系统中使用一对负载平衡服务器。当其中一个负载平衡服务器失效的时候，另一个还能够为整个系统提供负载平衡服务。这一对负载平衡服务器可以按照Active-Passive模式使用，也可以按照Active-Active模式使用。
　　
在Active-Passive模式中，一个负载平衡服务器处于半休眠状态。其将会通过向另外一个负载平衡服务器发送心跳消息来探测对方的可用性。当正在工作的负载平衡服务器不再响应心跳的时候，那么心跳应用将会把负载平衡服务器从半休眠状态唤醒，接管负载平衡服务器的IP并开始执行负载平衡功能。

而在Active-Active模式中，两台负载平衡服务器会同时工作。如果其中一台服务器发生了故障，那么另一台服务器将会承担所有的工作：

可以说，两者各有千秋。相较而言，Active-Active模式具有较好的抵抗访问量大幅波动的情况。例如在通常情况下，两个服务器的负载都在30%左右，但是在服务使用的高峰时间，访问量可能是平时的两倍，因此两个服务器的负载就将达到60%左右，仍处于系统可以处理的范围内。如果我们使用的是Active-Passive模式，那么平时的负载就将达到60%，而在高峰时间的负载将达到负载平衡服务器容量的120%，进而使得服务无法处理所有的用户请求。
　　
反过来，Active-Active模式也有不好的地方，那就是容易导致管理上的疏忽。例如在一个使用了Active-Active模式的系统中，两个负载平衡服务器的负载常年都在60%左右。那么一旦其中的一个负载平衡服务器失效了，那么剩下的唯一一个服务器同样将无法处理所有的用户请求。
　　
或许您会问：L3/4负载平衡服务器一定要有两个么？其实主要由各负载平衡服务器产品自身来决定的。在前面我们已经讲过，实际上探测负载平衡服务器的可用性实际上需要很复杂的测试逻辑。因此如果一旦我们在一个负载平衡系统中使用了过多的L3/4负载平衡服务器，那么这些负载平衡服务器之间所发送的各种心跳测试将消耗非常多的资源。同时由于很多L3/4负载平衡服务器本身是基于硬件的，因此它能够非常快速地工作，甚至可以达到与其所支持的网络带宽所匹配的处理能力。因此在一般情况下，L3/4负载平衡服务器是成对使用的。
　　
如果L3/4负载平衡服务器真的接近其负载极限，那么我们还可以通过DNS负载平衡来分散请求：

这种方法不仅仅可以解决扩展性的问题，更可以利用DNS的一个特性来提高用户体验：DNS可以根据用户所在的区域选择距离用户最近的服务器。这在一个全球性的服务中尤为有效。毕竟一个中国用户访问在中国架设的服务实例要比访问在美国架设的服务实例快得多。
　　
反过来由于L7负载平衡服务器主要是基于软件的，因此很多L7负载平衡服务器允许用户创建较为复杂的负载平衡服务器系统。例如定义一个具有两个启用而有一个备用的一组L7负载平衡服务器。
　　
讲解完了高可用性，我们就来介绍一下负载平衡服务器的扩展性。其实在上面我们刚刚介绍过，L3/4负载平衡服务器拥有很高的性能，因此一般的服务所使用的负载平衡系统不会遇到需要扩展性的问题。但是一旦出现了需要扩展的情况，那么使用DNS负载平衡就可以达到较好的扩展性。而L7负载平衡则更为灵活，因此扩展性更不是问题。
　　
但是一个负载平衡系统不可能都是由L3/4负载平衡服务器组成的，也不可能只由L7负载平衡服务器组成的。这是因为两者在性能和价格上都具有非常大的差异。一个L3/4负载平衡服务器实际上价格非常昂贵，常常达到上万美元。而L7负载平衡服务器则可以使用廉价服务器搭建。L3/4负载平衡服务器常常具有非常高的性能，而L7负载平衡服务器则常常通过组成一个集群来达到较高的整体性能。
　　
在设计负载平衡系统时，还有一点需要考虑的那就是服务的动静分离。我们知道，一个服务常常由动态请求和静态请求共同组成。这两种请求具有非常不同的特点：一个动态请求常常需要大量的计算而传输的数据常常不是很多，而一个静态的请求常常需要传输大量的数据而不需要太多的计算。不同的服务容器对这些请求的表现差异很大。因此很多服务常常将其所包含的服务实例分为两部分，分别用来处理静态请求和动态请求，并使用适合的服务容器提供服务。在这种情况下，静态请求常常被置于特定的路径下，如“/static”。这样负载平衡服务器就可以根据请求所发送到的路径而将动态请求和静态请求进行适当地转发。
　　
最后要提到的就是L3/4负载平衡服务器的一个软件实现LVS（Linux Virtual Server）。相较于硬件实现，软件实现需要做很多额外的工作，例如对数据包的解码，为处理数据包分配内存等等呢个。因此其性能常常只是具有相同硬件能力的L3/4负载平衡服务器的1/5到1/10。鉴于其只具有有限的性能但是搭建起来成本很低，如利用已有的在Lab里闲置的机器等，因此其常常在服务规模不是很大的时候作为临时替代方案使用。

负载平衡解决方案
　　
在文章的最后，我们将给出一系列常见的负载平衡解决方案，以供大家参考。
　　
在一般情况下，一个服务的负载常常是通过某些方式逐渐增长的。相应地，这些服务所拥有的负载平衡系统常常是从小到大逐渐演化的。因此我们也将会按照从小到大的方式逐次介绍这些负载平衡系统。
　　
首先是最简单的包含一对L7负载平衡服务器的系统：

如果服务的负载逐渐增大，那么该系统中唯一的L7负载平衡服务器很容易变成瓶颈。此时我们可以通过添加一个SSL Farm以及运行LVS的服务器来解决问题：

如果我们还要应对增长的负载，那么就需要使用真正的基于硬件的L3/4负载平衡服务器来替代LVS，并增加各层的容量：

由于该解决方案的下面三层基本都有理论上无限的扩展性，因此最容易出现过载的就是最上面的L3/4负载平衡服务器。在这种情况下，我们就需要使用DNS来分配负载了：