01前言

在互联网尤其是移动互联网行业中一旦用户量达到一定数量级别之后，会面对高并发和海量数据的挑战，面对这种挑战必须提升系统整体的性能，可以采用垂直扩展和水平扩展两种方式。负载均衡是一种水平扩展的方式，它是建立在现有网络结构之上，它提供了一种有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

02负载均衡分类

常见的负载均衡系统包括3 种：DNS负载均衡、硬件负载均衡和软件负载均衡。

2.1 DNS

DNS是最简单也是最常见的负载均衡方式，一般用来实现地理级别的均衡。例如，北方的用户访问北京的机房，南方的用户访问深圳的机房。DNS负载均衡的本质是DNS 解析同一个域名可以返回不同的IP地址。

【优点】

(1) 简单、成本低：负载均衡工作交给DNS 服务器处理，无须自己开发或维护负载均衡设备。

(2) 就近访问，提升访问速度：DNS解析时可以根据请求来源IP ，解析成距离用户最近的服务器地址，可以加快访问速度，改善性能。

【缺点】

(1) 更新不及时：DNS缓存的时间比较长，修改DNS配置后，由于缓存的原因，还是有很多用户会继续访问修改前的IP，这样的访问会失败，达不到负载均衡的目的，并且也影响用户正常使用业务。

(2) 扩展性差：DNS负载均衡的控制权在域名商那里，无法根据业务特点针对其做更多的定制化功能和扩展特性。

(3) 分配策略比较简单：DNS负载均衡支持的算法少：不能区分服务器的差异（不能根据系统与服务的状态来判断负载）；也无法感知后端服务器的状态。

2.2 硬件负载均衡

硬件负载均衡是通过单独的硬件设备来实现负载均衡功能，这类设备和路由器交换机类似，可以理解为一个用于负载均衡的基础网络设备。目前业界典型的硬件负载均衡设备有两款：F5和A10。

硬件负载均衡的优缺点如下：

【优点】

(1) 功能强大：全面支持各层级的负载均衡，支持全面的负载均衡算法，支持全局负载均衡。

(2) 性能强大：对比一下，软件负载均衡支持到10 万级井发己经很厉害了，硬件负载均衡可以支持100 万以上的并发。

(3) 稳定性高：商用硬件负载均衡，经过了良好的严格测试，经过大规模使用， 在稳定性方面高。

(4) 支持安全防护：硬件均衡设备除具备负载均衡功能外，还具备防火墙、防DDOS攻击等安全功能。

【缺点】

(1) 价格昂贵：最普通的一台F5就是一台“马6”，好一点的就是“宝马、Q7”了。

(2) 扩展能力差：硬件设备，可以根据业务进行配置，但无法进行扩展和定制。

2.3 软件负载均衡

软件负载均衡是通过负载均衡软件来实现负载均衡功能，常见的有Nginx和LVS，其中Nginx是软件的7层负载均衡，LVS是Linux内核的4 层负载均衡。

软件负载均衡的优缺点如下。

【优点】

(1) 简单：无论部署，还是维护都比较简单。

(2) 便直：只要买个Linux服务器，装上软件即可。

(3) 灵活：4层和7层负载均衡可以根据业务进行选择；也可以根绝业务进行比较方便的扩展，例如：可以通过Nginx 的插件来实现业务的定制化功能。

【缺点】

其实以下缺点都是和硬件负载均衡相比的，并不是说软件负载均衡没法用。

(1) 性能一般：一个Nginx 大约能支撑5万并发。

(2) 功能没有硬件负载均衡那么强大。

(3) 一般不具备防火墙和防DDOS攻击等安全功能。

硬件与软件负载均衡区别：

软件和硬件的最主要区别就在于性能，硬件负载均衡性能远远高于软件负载均衡性能。Ngxin的性能是万级，一般的Linux服务器上装一个Nginx大概能到5万／每秒：LVS的性能是十万级，据说可达到80万／每秒；而自性能是百万级，从200万／每秒到800万／每秒都有。

2.4 组合负载均衡

前面我们介绍了3 种常见的负载均衡机制：DNS 负载均衡、硬件负载均衡、软件负载均衡，每种方式都有一些优缺点，但并不意味着在实际应用中只能基于它们的优缺点进行非此即彼的选择，反而是基于它们的优缺点进行组合使用。具体来说，组合的基本原则为：DNS 负载均衡用于实现地理级别的负载均衡；硬件负载均衡用于实现集群级别的负载均衡；软件负载均衡用于实现机器级别的负载均衡。

整个系统分为三层的负载均衡示例如下：

(1) 地理级别负载均衡：www.xxx .com 部署在北京、广州｜、上海三个机房，当用户访问时，DNS 会根据用户的地理位置来决定返回哪个机房的IP ，图中返回了广州机房的IP 地址，这样用户就访问到广州机房了。

(2) 集群级别负载均衡：广州机房的负载均衡用的是FS设备，FS 收到用户请求后，进行集群级别的负载均衡，将用户请求发给3个本地集群中的一个，我们假设FS 将用户请求发给了“广州集群2”。

(3) 机器级别的负载均衡：广州｜集群2 的负载均衡用的是Nginx, Nginx 收到用户请求后，将用户请求发送给集群里面的某台服务器，服务器处理用户的业务请求井返回业务响应。需要注意的是，上图只是一个示例，一般在大型业务场景下才会这样用，如果业务量没这么大，则没有必要严格照抄这套架构。例如，一个大学的论坛完全可以不需要DNS 负载均衡，也不需要自设备，只需要用Nginx 作为一个简单的负载均衡就足够了。

03负载均衡算法

3.1 负载均衡算法分类

负载均衡算法数量较多，而且可以根据－些业务特性进行定制开发，抛开细节上的差异，根据算法期望达到的目的，大体上可以分为如下几类。

(1) 任务平分类：负载均衡系统将收到的任务平均分配给服务器进行处理，这里的“平均”可以是绝对数量的平均，也可以是比例或权重上的平均。

(2) 负载均衡类：负载均衡系统根据服务器的负载来进行分配，这里的负载井不一定是通常意义上我们说的“CPU负载”，而是系统当前的压力，可以用CPU负载来衡量，也可以用连接数、I/O使用率、网卡吞吐量等来衡量系统的压力。

(3) 性能最优类：负载均衡系统根据服务器的响应时间来进行任务分配，优先将新任务分配给响应最快的服务器。

(4) Hash类：负载均衡系统根据任务中的某些关键信息进行Hash 运算，将相同Hash值的请求分配到同一台服务器上。常见的有源地址Hash、目标地址hash、session id hash、用户id hash等。

3.2 轮询

• 某个服务器当前因为触发了程序bug进入了死循环导致CPU负载很高，负载均衡系统是不感知的，还是会继续将请求源源不断地发送给它。

• 集群中有新的机器是32核的，老的机器是16核的，负载均衡系统也是不关注的，新老机器分配的任务数是一样的。

需要注意的是负载均衡系统无须关注“服务器本身状态”，这里的关键词是“本身”。也就是说，只要服务器在运行，运行状态是不关注的，但如果服务器直接岩机了，或者服务器和负载均衡系统断连了，则负载均衡系统是能够感知的，也需要做出相应的处理。例如，将服务器从可分配服务器列表中删除，否则就会出现服务器都岩机了，任务还不断地分配给它，这明显是不合理的。

3.3 加权轮询

负载均衡系统根据服务器权重进行任务分配，这里的权重一般是根据硬件配置进行静态配置的，采用动态的方式计算会更加契合业务，但复杂度也会更高。加权轮询是轮询的一种特殊形式，其主要目的就是为了解决不同服务器处理能力有差异的问题。

例如，集群中有新的机器是32 核的，老的机器是16 核的，那么理论上我们可以假设新机器的处理能力是老机器的2 倍，负载均衡系统就可以按照2 : 1 的比例分配更多的任务给新机器，从而充分利用新机器的性能。加权轮询解决了轮询算法中无法根据服务器的配置差异进行任务分配的问题，但同样存在无法根据服务器的状态差异进行任务分配的问题。

3.4 负载最低优先

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

例如：

• LVS 这种4 层网络负载均衡设备，可以以“连接数”来判断服务器的状态，服务器连接数越大，表明服务器压力越大。

• Nginx 这种7 层网络负载系统，可以以“ HTTP 请求数”来判断服务器状态CNginx 内置的负载均衡算法不支持这种方式，需要进行扩展）。

• 如果我们自己开发负载均衡系统，可以根据业务特点来选择指标衡量系统压力。如果是CPU 密集型，可以以“ CPU 负载”来衡量系统压力：如果是I/O 密集型，则可以以“IIO负载”来衡量系统压力。负载最低优先的算法解决了轮询算法中无法感知服务器状态的问题，由此带来的代价是复杂度要增加很多。

3.5 性能最优类

负载最低优先类算法是站在服务器的角度来进行分配的，而性能最优优先类算法则是站在客户端的角度来进行分配的，优先将任务分配给处理速度最快的服务器，通过这种方式达到最快响应客户端的目的。

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

• 负载均衡系统需要收集和分析每个服务器每个任务的响应时间， 在大量任务处理的场景下，这种收集和统计本身也会消耗较多的性能。

• 为了减少这种统计上的消耗，可以采取采样的方式来统计，即不统计所有任务的响应时间，而是抽样统计部分任务的响应时间来估算整体任务的响应时间。采样统计虽然能够减少性能消耗，但使得复杂度进一步上升， 因为要确定合适的采样率，来样率太低会导致结果不准确，采样率太高会导致性能消耗较大，找到合适的来样率也是一件复杂的事情。无论全部统计，还是采样统计，都需要选择合适的周期：是10 秒内性能最优，还是1分钟内性能最优，还是5 分钟内性能最优……没有放之四海而皆准的周期，需要根据实际业务进行判断和选择， 这也是一件比较复杂的事情，甚至出现系统上线后需要不断地调优才能达到最优设计。

3.6 Hash

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

• 源地址Hash

将来源于同一个源IP 地址的任务分配给同一个服务器进行处理，适合于存在事务、会话的业务。例如，当我们通过浏览器登录网上银行时，会生成一个会话信息，这个会话是临时的， 关闭浏览器后就失效。网上银行后台无须持久化会话信息，只需要在某台服务器上临时保存这个会话就可以了，但需要保证用户在会话存在期间，每次都能访问到同一个服务器，这种业务场景就可以用源地址Hash 来实现。

• ID Hash

将某个ID 标识的业务分配到同一个服务器中进行处理，这里的ID一般是临时性数据的ID（例如，session id）。例如，上述的网上银行登录的例子，用session id hash 同样可以实现同一个会话期间，用户每次都是访问到同一台服务器的目的。

04总结

通常在设计系统的架构之初，经过需求调研和业务分析等，来具体考量需要采用哪种负载均衡策略和算法。除此之外，还需要结合软件系统的框架和技术栈，以及考虑公司的经营成本，硬件负载均衡器虽然性能相比要高很多，但是价格成本更高，如：F5和A10。软件负载均衡策略成本低，但是相对来说性能也不高，并且还不具备防火墙和防DDOS攻击等安全功能，如：Nginx。所以如何选取一个合适的负载均衡策略需要多方面综合考量。