域名负载均衡_这些高性能负载均衡架构知识点，90%的人分不清！

无论单台服务器如何优化，硬件有多好，总是会存在性能天花板，当单台服务器的性能无法满足业务需求时，就需要设计高性能的集群，来提高系统整体的处理性能。

高性能集群的本质很简单：增加更多的服务器可以提高系统整体的计算能力。由于计算本身有一个特性：相同的输入数据和逻辑无论在哪台服务器上执行都应该产生相同的输出，因此高性能集群设计的复杂性主要体现在任务分配部分。需要设计合理的任务分配策略，将计算任务分配到多台服务器上执行。

高性能集群的复杂度主要在于需要增加任务分发器，并为任务选择合适的任务分发算法。任务分发器现在比较流行的通用名称是“负载均衡器”。但这个名字有些误导，让人潜意识地以为任务分发的目的是为了让各个计算单元的负载保持均衡。其实任务分发并不单单考虑计算单元的负载均衡，不同的任务分发算法有不同的目标，有的是基于负载的考虑，有的是基于性能（吞吐量、响应时间）的考虑，有的是基于业务的考虑。考虑到“负载均衡”已经成为事实上的标准用语，我在这里也用“负载均衡”来代替“任务分发”，但请永远记住，负载均衡并不单单是为了让计算单元的负载保持均衡。

负载均衡的分类

常见的负载均衡系统有三种：DNS负载均衡、硬件负载均衡、软件负载均衡。

DNS 负载平衡

DNS 是最简单也是最常见的负载均衡方式，一般用于实现地域均衡。比如北方用户访问北京机房，南方用户访问深圳机房。DNS 负载均衡的本质就是 DNS 在解析同一个域名时，可​​以返回不同的 IP 地址。比如北方用户解析后得到的地址是 61.135.165.224（这是北京机房的 IP），南方用户解析后得到的地址是 14.215.177.38（这是深圳机房的 IP）。

以下是DNS负载均衡的简单图：

DNS负载均衡实现简单，成本低廉，但也存在粒度粗，负载均衡算法少等缺点。仔细分析其优缺点，其优点有：

缺点是：

针对DNS负载均衡的一些不足，有些公司针对延迟、故障敏感的业务，实现了HTTP-DNS，也就是利用HTTP协议实现私有的DNS系统，这种方案和一般的DNS相比，优点和缺点正好相反。

硬件负载平衡

硬件负载均衡是通过单独的硬件设备来实现的，这种设备类似于路由器或者交换机，可以算是负载均衡的基础网络设备。目前业界比较典型的硬件负载均衡设备有F5和A10两种，这类设备性能强劲，功能强大，但是价格不菲，一般只有“有钱”的公司才会考虑使用这样的设备，一般业务量大的公司用不起，一来业务量也没有那么大，用了这些设备反而有点浪费。

硬件负载均衡的优点是：

硬件负载平衡的缺点是：

软件负载平衡

软件负载均衡是通过负载均衡软件来实现负载均衡的，比如Nginx、LVS等。Nginx是基于软件的七层负载均衡，LVS是基于Linux内核的四层负载均衡。四层和七层的区别在于协议和灵活性。Nginx支持HTTP、E-mail协议，而LVS是与协议无关的四层负载均衡，几乎所有的应用都可以使用，比如聊天、数据库等。

软件与硬件的主要区别在于性能。硬件负载均衡性能远高于软件负载均衡性能。Ngxin的性能在万级别，一般Linux服务器上安装一个Nginx可以达到5万/秒左右；LVS的性能在十万级别，据说可以达到80万/秒；而F5的性能在百万级别，从200万/秒到800万/秒不等（数据来源：互联网，仅供参考，如需使用请根据实际业务场景进行性能测试）。当然软件负载均衡最大的优势就是便宜，普通Linux服务器批发价在万元左右，和F5的价格相比，就是一辆自行车和一辆宝马的差别。

除了使用开源系统进行负载均衡外，如果业务特殊，也可以基于开源系统进行定制（例如Nginx插件）甚至进行自主开发。

以下是Nginx的负载均衡架构图：

软件负载平衡的优点：

其实，与硬件负载均衡相比，有以下缺点，并不意味着软件负载均衡不能使用。

负载均衡典型架构

前面我们介绍了三种常见的负载均衡机制：DNS负载均衡、硬件负载均衡、软件负载均衡。每种方式都有各自的优缺点，但这并不意味着在实际应用中只能根据其优缺点选择其中一种，而是可以根据其优缺点进行组合使用。具体来说，组合使用的基本原则是：

我们用一个假设的例子来说明这种组合，如下图所示。

整个系统的负载均衡分为三层。

需要注意的是，上图只是举例，一般用于大规模业务场景，如果业务量没那么大，没必要严格照搬这个架构，比如高校论坛就不需要DNS负载均衡，也不需要F5设备，使用Nginx做一个简单的负载均衡就可以了。

负载均衡算法

负载均衡算法有很多种，也可以根据一些业务特点进行定制开发。抛开细节上的差异，按照算法期望实现的目的，大致可以分为以下几类。

接下来我们来介绍一下负载均衡算法以及它们的优缺点。

轮询

负载均衡系统接收到请求后，按顺序分发到各个服务器。

轮询是最简单的策略，不需要关注服务器本身的状态，例如：

需要注意的是，负载均衡系统并不需要关注“服务器本身的状态”，这里的关键词是“本身”。也就是说，只要服务器在运行，运行状态就不是问题。但如果服务器宕机了，或者服务器与负载均衡系统断开了连接，负载均衡系统是可以感知到的，需要采取相应的措施，比如将服务器从可分配服务器列表中删除。否则，就会出现服务器已经宕机，但任务还在分配给它的情况，这显然是不合理的。

综上所述，“简单”是轮询算法的优点，但也是它的缺点。

加权循环

负载均衡系统是根据服务器权重来分配任务的，这里的权重一般都是根据硬件配置静态配置的，动态计算会更符合业务，但也会更复杂一些。

加权轮询是轮询的一种特殊形式，它的主要目的是解决不同服务器处理能力不同的问题。例如集群中有一台 32 核的新机器和一台 16 核的旧机器，那么理论上我们可以假设新机器的处理能力是旧机器的两倍，负载均衡系统可以按照 2:1 的比例将更多的任务分配给新机器，从而充分利用新机器的性能。

加权轮询解决了轮询算法中无法根据服务器配置差异进行任务分配的问题，但是仍然存在无法根据服务器状态差异进行任务分配的问题。

最低负荷优先

负载均衡系统会把任务分配给当前负载最小的服务器，这里的负载可以根据不同的任务类型和业务场景，用不同的指标来衡量。例如：

最低负载优先级算法解决了轮询算法无法感知服务器状态的问题，但代价是复杂度增加很多。例如：

最低负载优先级算法基本可以完美解决轮询算法的不足，因为采用这种算法之后，负载均衡系统需要感知服务器当前的运行状态。当然，代价就是复杂度的大幅增加。一般来说，轮询可能是一个5行代码就能实现的算法，而最低负载优先级算法可能需要1000行代码才能实现，甚至需要负载均衡系统和服务器双方开发代码。如果最低负载优先级算法本身设计得不够好或者不适合业务的运行特点，算法本身可能会成为性能瓶颈或者引发很多莫名其妙的问题。所以，虽然最低负载优先级算法看上去效果不错，但实际上它的实际应用场景并没有轮询（包括加权轮询）那么多。

最佳表现级别

最低负载优先级算法是从服务器的角度来分配任务，而最佳性能优先级算法则是从客户端的角度来分配任务，优先将任务分配给处理速度最快的服务器，从而实现对客户端的最快响应。

与最低负载优先算法类似，最佳性能优先算法本质上也是感知服务器状态，但是通过响应时间这个外在标准来衡量服务器状态。因此最佳性能优先算法的问题与最低负载优先算法类似，复杂度很高，主要体现在：

哈希类

负载均衡系统根据任务中的某些关键信息进行哈希运算，将哈希值相同的请求分发到同一台服务器上。这主要是为了满足特定的业务需求。例如：