架构设计:负载均衡层设计方案之负载均衡技术总结篇

  1. 云栖社区>
  2. 博客列表>
  3. 正文

架构设计:负载均衡层设计方案之负载均衡技术总结篇

java填坑路 2018-10-12 16:37:33 浏览264 评论0

摘要: 1、概述 通过前面文章的介绍,并不能覆盖负载均衡层的所有技术,但是可以作为一个引子,告诉各位读者一个学习和使用负载均衡技术的思路。虽然后面我们将转向“业务层”和“业务通信”层的介绍,但是对负载均衡层的介绍也不会停止。

1、概述

通过前面文章的介绍,并不能覆盖负载均衡层的所有技术,但是可以作为一个引子,告诉各位读者一个学习和使用负载均衡技术的思路。虽然后面我们将转向“业务层”和“业务通信”层的介绍,但是对负载均衡层的介绍也不会停止。在后续的时间我们将穿插进行负载均衡层的新文章的发布,包括Nginx技术的再介绍、HaProxy、LVS新的使用场景等等。

这篇文章我们对前面的知识点进行总结,并有意进行一些扩展,以便于各位读者找到新的学习思路。

2、负载均衡层的核心思想

2-1、一致性哈希与Key的选取

webp

我们详细介绍了一致性哈希算法。并且强调了一致性Hash算法是现代系统架构中的最关键算法之一,在分布式计算系统、分布式存储系统、数据分析等众多领域中广泛应用。针对我的博文,在负载均衡层、业务通信层、数据存储层都会有它的身影。

一致性算法的核心是:

使用对象的某一个属性(这个属性可以是服务器的IP地址、开放端口 还可以是用户名、某种加密串。凡是你可以想到的有散列意义的属性),算出一个整数,让其分布在0 至 2的32次方 范围内。

一台服务器的某个或者某一些属性当然也可以进行hash计算,并且根据计算分布在这个圆环上的某一个点,也就是图中圆环上的蓝色点。

一个处理请求到来时,根据这个请求的某一个或者某一些属性进行hash计算,并且根据计算记过分布在这个圆环上的某一个点上。也就是上图圆环上的黄色点。

我们约定落在某一个蓝点A左侧和蓝点B右侧的黄色点所代表的请求,都有蓝点A所代表的服务器进行处理,这样就完成解决了“谁来处理”的问题。在蓝色点稳定存在的前提下,来自于同一个Hash约定的请求所落在的位置都是一样的,这就保证了服务处理映射的稳定性。

当某一个蓝色点由于某种原因下线,其所影响到的黄色点也是有限的。即下一次客户端的请求将由其他的蓝色点所代表的服务器进行处理。

2-2、轮询与权

webp

不加权轮询,就是主控节点(任务来源点)在不考虑目标节点的任何因素的情况下(例如CPU性能、磁盘性能、网络性能),按照目标节点的列表顺序将任务依次分配下去。这是最简单的轮询,也是对主控节点实现复杂性要求最低的轮询。我之前的博文《架构设计:负载均衡层设计方案(2)——Nginx安装》、《架构设计:负载均衡层设计方案(4)——LVS原理》 都对这种最简轮询进行了介绍:例如LVS中的“rr”参数。

加权轮询中的“权”,您可以看成是“轮询”依据的意思。“权”可以是很多种可能,可以是目标机器的性能量化值、可以是一个固定的数字(按照固定数字加权)、可以是目标节点的网络速度。例如LVS中的“lc”参数,就是指按照目标机器,现在已有的“连接”数量进行加权:连接数量越少,越有更大的几率获得这个任务的处理权。

2-3、租约与健康检查

webp

租约协议主要为了保证一个事实:如果服务器对客户端的检查操作在“最迟时间”失败后,那么服务器端肯定会注销客户端的登录信息,同时客户端上服务器的连接信息也会消失(并且不在向下提供服务)。每一次检查成功,这个“最迟时间”都会向后推移。

租约协议和我们提到的哈希算法一下一样,也是系统架构设计中最基本的设计思想,并且大量运用在各类型的系统中,它的工作原理是每一位架构师都需要掌握的。例如:zookeeper使用这个协议保证Flow节点和Leader节点的链路是正常的;分布式存储系统用这个协议保证datanode和namenode的连接是正常的;

3、负载均衡层技术汇总

在前面的博文中,我重点介绍了Nginx、LVS、Keepalived技术。由于时间有限,这里我们对博文中提到的几种技术进行一个总结,然后再扩展介绍一下DNS技术、CDN技术和硬件负载技术。

3-1、Nginx技术

在负载均衡层这个大的章节中,我有三篇文章都在直接介绍Nginx的原理和使用。但是之后有朋友给我反映还想了解更多的Nginx知识,特别点名要求我再做一篇文章介绍Nginx的动态缓存。是的,我在后面的时间里是有计划介绍Nginx的动态缓存技术,还会介绍Nginx和多款主流的反向代理软件的性能对比。但这需要时间,特别是我不想去网上找一些已有的性能对比图,还是自己一边做这样的性能测试,一边做性能报告比较靠谱。

下面这些技术是我在博文中已经重点介绍过得,我们再做一下总结:

Nginx中的连接数限制问题

重要的配置项包括:worker_processes、worker_connections。但是光是配置这些属性是不够的,最关键的是我们要打开操作系统级别的“最大文件数”限制问题。使用“ulimit -n 65535”设置本次会话的“最大文件数”限制;还要使用“vim /etc/security/limits.conf”命令,修改内核的配置信息。主要是以下两项:

* soft nofile 65535* hard nofile 65535

另外,还要注意和nginx配置项中的“worker_rlimit_nofile”属性共同使用:

user root root; worker_processes4; worker_rlimit_nofile65535;#error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info;#pid logs/nginx.pid; events {     use epoll;     worker_connections65535; }

Nginx中的Gzip技术

gzip是Nginx进行HTTP Body数据压缩的技术。下面这段Nginx配置信息是启用gzip压缩的实例:

#开启gzip压缩服务, gzipon;#gzip压缩是要申请临时内存空间的,假设前提是压缩后大小是小于等于压缩前的。例如,如果原始文件大小为10K,那么它超过了8K,所以分配的内存是8 * 2 = 16K;再例如,原始文件大小为18K,很明显16K也是不够的,那么按照 8 * 2 * 2 = 32K的大小申请内存。如果没有设置,默认值是申请跟原始数据相同大小的内存空间去存储gzip压缩结果。 gzip_buffers28k;#进行压缩的原始文件的最小大小值,也就是说如果原始文件小于5K,那么就不会进行压缩了 gzip_min_length5K;#gzip压缩基于的http协议版本,默认就是HTTP 1.1 gzip_http_version1.1;# gzip压缩级别1-9,级别越高压缩率越大,压缩时间也就越长CPU越高 gzip_comp_level5;#需要进行gzip压缩的Content-Type的Header的类型。建议js、text、css、xml、json都要进行压缩;图片就没必要了,gif、jpge文件已经压缩得很好了,就算再压,效果也不好,而且还耗费cpu。 gzip_typestext/HTMLtext/plainapplication/x-javascripttext/cssapplication/xml;

http返回数据进行压缩的功能在很多场景下都实用:

a、 如果浏览器使用的是3G/4G网络,那么流量对于用户来说就是money。

b、 压缩可节约服务器机房的对外带宽,为更多用户服务。按照目前的市场价良好的机房带宽资源的一般在200RMB/Mbps,而服务器方案的压力往往也来自于机房带宽。

c、 不是Nginx开启了gzip功能,HTTP响应的数据就一定会被压缩,除了满足Nginx设置的“需要压缩的http格式”以外,客户端(浏览器)也需要支持gzip(不然它怎么解压呢),一个好消息是,目前大多数浏览器和API都支持http压缩。

Nginx中的rewrite(重写)技术

Nginx的强大在于其对URL请求的重写(重定位)。Nginx的rewrite功能依赖于PCRE Lib,请一定在Nginx编译安装时,安装Pcre lib。

下面是一段rewrite的示例:

#示例1:location ~* ^/(.+)/(.+)\.(jpg|gif|png|jpeg)$ {    rewrite ^/orderinfo/(.+)\.(jpg|gif|png|jpeg)$ /img/$1.$2break;    root   /cephclient;}#location在不进行大小写区分的情况下利用正则表达式对$url进行匹配。当匹配成功后进行rewrite重定位。#rewrite进行重写url的规则是:regex表达式第一个括号中的内容对应$1,regex表达式第二个括号中的内容对应$2,以此类推。#这样重定位的意义就很明确了:将任何目录下的文件名重定位到img目录下的对应文件名,#并且马上在这个location中(注意是Nginx,而不是客户端)执行这个重写后的URL定位。#示例2:server {    。。。。    。。。。    location ~* ^/orderinfo/(.+)\.(jpg|gif|png|jpeg)$ {        rewrite ^/orderinfo/(.+)\.(.+)$ /img/$1.$2last;    }    location / {        root   /cephclient;    }}#在server中,有两个location位置,当url需要访问orderinfo目录下的某一个图片时,rewrite将重写这个url,#并且重新带入这个url到server执行,这样“location /”这个location就会执行了,并找到图片存储的目录。

Nginx的图片处理模块

http_image_filter_module 是nginx的图片处理模块,是使用nginx进行静态资源和动态资源分开管理的关键引用技术。通过这个模块可以对静态资源进行缩放、旋转、验证。

需要注意的是,http_image_filter_module模块所处理的缩率图片是不进行保存的,完全使用节点的CPU性能进行计算,使用节点的内存进行临时存储。所以如果要使用http_image_filter_module进行图片处理,一定要根据客户端的请求规模进行nginx节点的调整。并且当站点的PV达到一定的规模时,一定要使用CDN技术进行访问加速、对图片的访问处理手段进行规划。

由于我们在之前涉及Nginx的文章中,并没有详细讲解Nginx的图片处理模块,只是说了要进行介绍,所以这里我给出一个较为详细的安装和配置示例:

nginx的http_image_filter_module模块由GD library进行支持,所以要使用这个图片处理模块,就必须进行第三方依赖包的安装:

yuminstallgd-devel

然后,Nginx要进行重新编译:

configure--with-http_image_filter_modulemake&&make install

使用图片处理模块的配置示例:

location ~* /(.+)_(\d+)_(\d+)\.(jpg|gif|png|ioc|jpeg)$ {set$h$3;set$w$2;    rewrite /(.+)_(\d+)_(\d+)\.(jpg|gif|png|ioc|jpeg)$ /$1.$4break;    image_filter resize$w$h;    image_filter_buffer2M;}

其中关于正则表达式的语法和已经介绍过的rewrite的语法就不再进行介绍了,主要看http_image_filter_module相关的属性设置:

image_filter test:测试图片文件合法性

image_filter rotate:进行图片旋转,只能按照90 | 180 | 270进行旋转

image_filter size:返回图片的JSON数据

image_filter resize width height:按比例进行图片的等比例缩小,注意,是只能缩小,第二缩小是等比例的。

image_filter_buffer:限制图片最大读取大小,没有设置就是1M;根据不同的系统最好设置为2M—3M

image_filter_jpeg_quality:设置jpeg图片的压缩比例(1-99,越高越好)

image_filter_transparency:禁用gif和png图片的透明度。

和Nginx类似的其他技术/软件

目前行业内也有很多与Nginx解决同类问题的软件,他们分别是Apache基金会的 Apache HTTP Server、淘宝开源的Tengine、Haproxy、包括Windows 下运行的IIS,也支持反向代理 。

这里笔者再次重点提到Tengine,建议各位读者有时间的时候可以使用一下,这个对Nginx进行了深度再开发的软件。

3-2、LVS技术

LVS是Linux Virtual Server的简写,意即Linux虚拟服务器,是一个虚拟的服务器集群系统。本项目在1998年5月由章文嵩博士成立。

LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率,将请求均衡地转移到不同的服务器上执行,且调度器自动屏蔽掉服务器的故障,从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的,而且无需修改客户端和服务器端的程序。

在我的系列文章中,《架构设计:负载均衡层设计方案(4)——LVS原理》 、《架构设计:负载均衡层设计方案(5)——LVS单节点安装》 、《负载均衡层设计方案(7)——LVS + Keepalived + Nginx安装及配置》 都涉及到LVS的讲解。

这里我们再总结一下LVS中的三种工作模式:

3-2-1、NAT模式

NAT方式是一种由LVS Master服务节点收到数据报,然后转给下层的Real Server节点,当Real Server处理完成后回发给LVS Master节点然后又由LVS Master节点转发出去的工作方式。LVS的管理程序IPVSADMIN负责绑定转发规则,并完成IP数据报文和TCP数据报文中属性的重写。

webp

LVS-NAT模式的优点在于:

配置管理简单。LVS-NAT的工作方式是LVS三种工作模式中最容易理解、最容易配置、最容易管理的工作模式。

节省外网IP资源,一般机房分配给使用者的IP数量是有限的,特别是您购买的机架的数量不多时。LVS-NAT工作方式将您的系统架构封装在局域网中,只需要LVS有一个外网地址或外网地址映射就可以实现访问了。

系统架构相对封闭。在内网环境下我们对防火墙的设置要求不会很高,也相对容易进行物理服务器的运维。您可以设置来源于外网