认识达内从这里开始

我们在上文中给大家简单介绍了负载均衡的一些概念，而今天我们就通过案例分析来了解一下，负载均衡的基础功能都有哪些。

负载均衡设备要实现基本负载均衡能力，有三项能力是必须具备的：一是负载均衡算法;二是会话保持功能;三是对服务器的健康检查方法。针对这三项基础功能的常用指标进行了测评和分析，没有针对各项功能的种类数目进行横向对比(如负载均衡算法种类数量、健康检查方法数量等)。所测试的国内厂商对以上基本功能均支持，但重点对比了细节，以便更客观地反映出负载均衡产品的成熟度。

(1) 负载均衡算法

上图所示功能厂商均可支持，在这里重点分析“比率负载均衡算法”机制差异。比率的负载均衡算法，初是用在一组服务器集群内服务器之间存在不同性能差异场景，因此按照不同比率在不同的服务器间进行流量分配。然而，现在使用的更多场景为：当一个业务系统有新的功能或新的应用架构要上线部署，经常会采用在原有服务器集群中增加含有新功能或新应用架构服务器的方式，并通过比率的算法把总交易量逐量切到新服务器上，待验证新服务器业务功能无问题后，然后通过调整算法将全量交易平均分配到后端所有服务器上，或者再把老服务器平滑下线。

在采用以上比率算法进行连接配备时，不同的分配机制会带来不同的结果。例如在四台服务器上设置比率100:100:100:1之后，负载均衡设备连接分配原理有如下两种：

一种分配机制是将一个连接分配给比率为100的服务器一，接着二个连接分配给比率为100的服务器二，依次三个连接分配给比率为100的服务器三，四个连接分配给比率为1的服务器四，后续的连接将在三台比率为100的服务器间轮询分配，直到该三台服务器分配完100个连接后，接着的下一个连接会再次分配给比率为1的服务器四，依次循环;

二种分配机制是将前100个连接会先全部先分配给比率为100的服务器一，之后的100个连接全部分配给比率为100的服务器二，依此类推，301个连接才会到比率为1的服务器四。

显然一种分配原理更优，如果是二种原理，比率为100服务器若无法承受瞬时100个连接的压力，将导致该服务对外服务异常。尽管如此，在测试的厂商中仍有厂商采用的是二种分配原理。

(2) 会话保持功能

Cookie的会话保持功能在Web应用场景一般都是佳的选择。在Cookie的会话保持中常采用Cookie插入方式，即负载均衡设备会在HTTP Respond头部插入Cookie值返回给客户端，客户端接下来的访问将会带上这个cookie值。然而，该Cookie值会包含后端服务器信息，如服务器真实IP或服务端口等。经测试仍有厂商不支持对Cookie值采用公有加密算法进行加密，而是通过相关公式反转得出的密文Cookie值。这意味着对方一旦知道加密公式就可反推出服务器的相关真实信息，如果是在互联网环境中传输对服务器来说就会存在一定的安全隐患。

(3) 健康检查方法

在健康检查方法上，对于多种健康检查方法的组合需求，其中一家厂商仅支持两种组合，无法配置两种以上的健康检查组合。针对“健康检查探测端口要与服务器对外提供的服务端口不同”这一需求，也仍有厂商不支持，而该需求在实际生产环境多数是为了既能减轻对真实服务端口的探测压力，又能达到反应服务器健康状态的应用场景。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!