Monthly Archive: April 2021

0

负载均衡的种类

我们在前文中对负载均衡做了一些简单的介绍,本文继续来介绍一下负载均衡的种类。 我们应该都听说过OSI的七层网络协议以及其对应的TCP/IP四层模型。详细的介绍可以见下图,那么负载均衡一般会在哪一层发生呢?一般来说我们可以把负载均衡按照发生的层次分为第四层负载均衡和第七层负载均衡。  第四层负载均衡  顾名思义,第四层负载均衡就是发生在OSI第四层也就是传输层上的负载均衡。从上图中我们可以看到,这一层能看到的协议就是TCP和UDP,所以这一层的负载均衡就是基于TCP以及UDP的协议来管理相关的传输信息。它看不到传输的具体内容,也就是说你的请求是什么media类型,什么规则它统统不知道,也就不能基于这些内容来进行传输的管理。所以我们认为它就是简单的包层面的负载均衡。 第四层负载均衡在早期服务器性能不是很强大的时候很流行,因为它对CPU、memory的性能要求相比第七层负载均衡要小很多。而随着如今服务器性能越来越强大,第四层负载均衡相比第七层在这方面的优势已经越来越小了。 第七层负载均衡 第七层负载均衡其实严格意义上来说并不是对应到OSI的第七层,它更多的像是对应到TCP/IP中的应用层。在这一层,它可以看到很多的内容,就比如常见的HTTP协议,它可以基于其中的内容(比如URL或者cookie等等)来进行请求的分发。 相比于第四层的负载均衡,第七层负载均衡对CPU的要求要更高一点,但是还没有到达能够影响性能的地步。而因为其能获取的有效信息更多,所以它所能做的负载均衡相比于第四层要更加灵活和有效。 除了简单的请求转发,这一层的负载均衡可以做更多的事情,比如说可以做解密也就是说假如后面的服务器都是内容同一个数据库中心的话,可能不需要再进行严格的加密和解密操作,这样也可以让被选择的服务器可以更高效地被用来执行对应的操作。 另外这一层负载均衡的一个比较典型的场景就是可以根据对应的用户端会话信息来把同样的请求发送到同一个服务器。通常来说用户端都会有一个会话信息保存在本地浏览器中,所以会希望同样的会话能尽可能的访问同样的服务器,这样一来相应的性能会比访问不同服务器来得更好(有些网页可能会因为访问不同服务器而发生错误)。这也就要求我们的负载均衡可以识别相应的信息,并把它们发送到同样的服务器。而这也只能在第七层负载均衡中实现。

2

负载均衡

现如今,分布式系统非常普遍,而提到分布式系统,就不得不提它其中很重要的一个部分:负载均衡。本文就来介绍一下负载均衡相关的内容。 负载均衡的发展 我们知道当我们自己开发一个小的实验网站的时候,也许就是一台服务器一个数据库就可以了。如下图1所示: 图1 小型实验网站 而当我们开发一个商用的网站,会把他部署到网络上,然后在用户量达到一定量级之后,就需要进行性能的提升。我们聪明的开发者开始把对应的web, application, database都部署到不同的server上,这样相应的server都只要处理特定的内容,从而提升效率和性能,如下图2所示。 图2 小型商用网站 然而很快我们就会发现这样的处理也不能满足我们日益增长的需求,就像我们自己的电脑一样,这个时候就需要进行扩展,扩展的方法总得来说有两种,一种为纵向扩展,就是用更高配置的机器来实现性能的提升,比如以前是双核,我们现在可以改成4核,8核,16核的机器,这样就可以达到性能提升的效果。 然而单个机器的升级毕竟是有极限的,显然不能满足用户数量增长的需求。于是就有了另外一种扩展方式,我们称之为横向扩展,就是通过更多的机器来同时满足类似的需求,这些机器的性能可能都很一般,但是他们组合在一起就能够达到我们所需的结果。如下图3所示。 图3 横向扩展示意图 也就在这个时候负载均衡出现了,简单地说,他就是用来决定如何分发所收到的请求到不同的机器。当它收到相应请求的时候,通过一定的算法,可以决定这个请求发送到哪个服务器,这样一来即使某一个服务器发生问题,也不会影响整体的系统功能的正常运行。我们可以想象,正是有了负载均衡,我们才能够更好地合理使用各个服务器,从而提高响应速度。同时它也可以提高可靠性以及监测分析各个请求的性能从而可以为我们是否需要进行优化提供更好的依据,甚至可以做到动态的优化,比如说发现请求过多,已有的服务器无法做出高效的响应,动态加入更多机器之类的操作。 负载均衡的算法 那么负载均衡是如何来决定相关的请求应该发送到哪一个服务器的呢?这里有两个方面的内容,首先的一点就是会选择一个”健康”的服务器,其次是根据一系列算法来选择一个“最好的”服务器。 健康监测 这个其实很好理解,假如一个服务器已经不能正常进行服务了,比如说断电了,网络断了之类的,那么我们肯定都不应该再选择它。健康监测有很多的方法,总得来说会通过周期性的连接或者请求的发送来确保相应的服务器能够及时的响应,假如负载均衡发现某一个服务器在一段时间内没有反应,那么它就需要把这个服务器从候选列表中清除,直到它恢复正常为止。 算法 负载均衡选择的算法有很多种方法,下面是一些常见的算法: 连接最少:这个方法会选择目前有效连接最少的服务器来发送请求,这个方法对于固定连接分布不均衡的情况比较有效。 响应时间最少:这就是我们俗称的选择响应最快的服务器来进行分发。粗看之下它比较合理,但事实上由于各个请求本身的响应时间有很大差别,如果某一个服务器正好遇到延时很大的请求(请求本身的性能很差),这种方法就会不那么合理。 最大剩余带宽:这种方法会分析目前各个服务已经使用的带宽,然后来看哪一个服务器还有最大的带宽可供使用。 循环:就是从开始一个一个选择对应的服务器,选择到最后一个之后再继续进行下一轮循环。这种方法对各个机器都一样且没有持久连接的情况比较适用。 有权重循环:因为服务器和服务器之间本身可能有差别,比如有些服务器是单核的,有些服务器是双核的,那么直接按照同样权重进行循环就会不太合理,这个时候我们可以给每一个服务器一个权重,让那些高配的服务器有更多的机会被选中,这就是有权重循环。 IP哈希:通过哈希客户端的IP来选择服务器。 冗余负载均衡 从上面我们可以看到负载均衡有很多好处,这时候你不仅会问,假如负载均衡它本身出问题了,岂不是啥都不能做了。是的,所以在现实的设计中,负载均衡也会不止一个,如下图所示,这样一来即使一个负载均衡发生问题,另外一个负载均衡也能够及时取而代之,避免了单点的问题。  硬件负载均衡 通常我们提到的负载均衡更多指的是软件的负载均衡,事实上还有专门的硬件可以做负载均衡,相比软件来说,硬件负载均衡的性能会更好,但是它的缺点也很明显,就是价格很高。即使是大型的公司一般也只会在比较重要的地方,比如和用户接触的第一个点来使用硬件负载均衡。