须要考虑的问题
在提出详细的负载平衡解决方式之前，我们须要首先解说一下在设计负载平衡系统时我们所须要考虑的一些事情。
首先要说的就是要在负载平衡系统设计时留意它的高可用性及扩展性。在一開始的解说中。我们就已经提到过通过使用负载平衡。由众多server实例所组成的服务具有非常高的可用性及扩展性。当当中一个服务实例失效的时候，其他服务实例能够帮助它分担一部分工作。
而在总服务容量显得有些紧张的时候，我们能够向服务中加入新的服务实例以扩展服务的总容量。
可是因为全部的传输数据都须要经过负载平衡server。因此负载平衡server一旦失效，那么整个系统就将无法使用。也就是说，负载平衡server的可用性影响着整个系统的高可用性。
解决问题的方法要依据负载平衡server的类型来讨论。对于L3/4负载平衡server而言，为了能够让整个系统不失效，业界中的经常用法是在系统中使用一对负载平衡server。当当中一个负载平衡server失效的时候，还有一个还能够为整个系统提供负载平衡服务。
这一对负载平衡server能够依照Active-Passive模式使用，也能够依照Active-Active模式使用。
在Active-Passive模式中。一个负载平衡server处于半休眠状态。其将会通过向另外一个负载平衡server发送心跳消息来探測对方的可用性。
当正在工作的负载平衡server不再响应心跳的时候，那么心跳应用将会把负载平衡server从半休眠状态唤醒。接管负载平衡server的IP并開始执行负载平衡功能。
而在Active-Active模式中。两台负载平衡server会同一时候工作。
假设当中一台server发生了故障。那么还有一台server将会承担全部的工作：
能够说，两者各有千秋。相较而言，Active-Active模式具有较好的抵抗訪问量大幅波动的情况。比如在通常情况下，两个server的负载都在30%左右，可是在服务使用的高峰时间，訪问量可能是平时的两倍，因此两个server的负载就将达到60%左右，仍处于系统能够处理的范围内。假设我们使用的是Active-Passive模式，那么平时的负载就将达到60%。而在高峰时间的负载将达到负载平衡server容量的120%。进而使得服务无法处理全部的用户请求。
反过来，Active-Active模式也有不好的地方，那就是easy导致管理上的疏忽。比如在一个使用了Active-Active模式的系统中，两个负载平衡server的负载常年都在60%左右。
那么一旦当中的一个负载平衡server失效了，那么剩下的唯一一个server相同将无法处理全部的用户请求。
也许您会问：L3/4负载平衡server一定要有两个么？事实上主要由各负载平衡server产品自身来决定的。
在前面我们已经讲过。实际上探測负载平衡server的可用性实际上须要非常复杂的測试逻辑。
因此假设一旦我们在一个负载平衡系统中使用了过多的L3/4负载平衡server，那么这些负载平衡server之间所发送的各种心跳測试将消耗非常多的资源。同一时候因为非常多L3/4负载平衡server本身是基于硬件的，因此它能够非常高速地工作。甚至能够达到与其所支持的网络带宽所匹配的处理能力。因此在普通情况下，L3/4负载平衡server是成对使用的。
假设L3/4负载平衡server真的接近其负载极限，那么我们还能够通过DNS负载平衡来分散请求：
这样的方法不仅仅能够解决扩展性的问题。更能够利用DNS的一个特性来提高用户体验：DNS能够依据用户所在的区域选择距离用户近期的server。
这在一个全球性的服务中尤为有效。
毕竟一个中国用户訪问在中国架设的服务实例要比訪问在美国架设的服务实例快得多。
反过来因为L7负载平衡server主要是基于软件的。因此非常多L7负载平衡server同意用户创建较为复杂的负载平衡server系统。比如定义一个具有两个启用而有一个备用的一组L7负载平衡server。
解说完了高可用性，我们就来介绍一下负载平衡server的扩展性。
事实上在上面我们刚刚介绍过，L3/4负载平衡server拥有非常高的性能，因此一般的服务所使用的负载平衡系统不会遇到须要扩展性的问题。可是一旦出现了须要扩展的情况，那么使用DNS负载平衡就能够达到较好的扩展性。而L7负载平衡则更为灵活，因此扩展性更不是问题。
可是一个负载平衡系统不可能都是由L3/4负载平衡server组成的，也不可能仅仅由L7负载平衡server组成的。
这是因为两者在性能和价格上都具有非常大的差异。一个L3/4负载平衡server实际上价格非常昂贵。经常达到上万美元。而L7负载平衡server则能够使用便宜server搭建。L3/4负载平衡server经常具有非常高的性能，而L7负载平衡server则经常通过组成一个集群来达到较高的总体性能。
在设计负载平衡系统时，还有一点须要考虑的那就是服务的动静分离。
我们知道，一个服务经常由动态请求和静态请求共同组成。这两种请求具有非常不同的特点：一个动态请求经常须要大量的计算而传输的数据经常不是非常多，而一个静态的请求经常须要传输大量的数据而不须要太多的计算。不同的服务容器对这些请求的表现差异非常大。因此非常多服务经常将其所包括的服务实例分为两部分，分别用来处理静态请求和动态请求，并使用适合的服务容器提供服务。
在这样的情况下，静态请求经常被置于特定的路径下，如“/static”。
这样负载平衡server就能够依据请求所发送到的路径而将动态请求和静态请求进行适当地转发。
最后要提到的就是L3/4负载平衡server的一个软件实现LVS（Linux Virtual Server）。相较于硬件实现，软件实现须要做非常多额外的工作。比如对数据包的解码，为处理数据包分配内存等等呢个。因此其性能经常仅仅是具有相同硬件能力的L3/4负载平衡server的1/5到1/10。
鉴于其仅仅具有有限的性能可是搭建起来成本非常低，如利用已有的在Lab里闲置的机器等。因此其经常在服务规模不是非常大的时候作为暂时替代方案使用。
负载平衡解决方式
在文章的最后，我们将给出一系列常见的负载平衡解决方式，以供大家參考。
在普通情况下。一个服务的负载经常是通过某些方式逐渐增长的。对应地。这些服务所拥有的负载平衡系统经常是从小到大逐渐演化的。因此我们也将会依照从小到大的方式逐次介绍这些负载平衡系统。
首先是最简单的包括一对L7负载平衡server的系统：
假设服务的负载逐渐增大，那么该系统中唯一的L7负载平衡server非常easy变成瓶颈。此时我们能够通过加入一个SSL Farm以及执行LVS的server来解决问题：
假设我们还要应对增长的负载，那么就须要使用真正的基于硬件的L3/4负载平衡server来替代LVS，并添加各层的容量：
因为该解决方式的以下三层基本都有理论上无限的扩展性。因此最easy出现过载的就是最上面的L3/4负载平衡server。
在这样的情况下，我们就须要使用DNS来分配负载了：
