大型网站架构系列负载均衡详解.docx
- 文档编号:18414494
- 上传时间:2023-08-16
- 格式:DOCX
- 页数:21
- 大小:26.83KB
大型网站架构系列负载均衡详解.docx
《大型网站架构系列负载均衡详解.docx》由会员分享,可在线阅读,更多相关《大型网站架构系列负载均衡详解.docx(21页珍藏版)》请在冰点文库上搜索。
大型网站架构系列负载均衡详解
《大型网站架构系列:
负载均衡详解(上)》
面对大量用户访问、高并发请求,海量数据,可以使用高性能的服务器、大型数据库,存储设备,高性能Web服务器,采用高效率的编程语言比如(Go,Scala)等,当单机容量达到极限时,我们需要考虑业务拆分和分布式部署,来解决大型网站访问量大,并发量高,海量数据的问题。
从单机网站到分布式网站,很重要的区别是业务拆分和分布式部署,将应用拆分后,部署到不同的机器上,实现大规模分布式系统。
分布式和业务拆分解决了,从集中到分布的问题,但是每个部署的独立业务还存在单点的问题和访问统一入口问题,为解决单点故障,我们可以采取冗余的方式。
将相同的应用部署到多台机器上。
解决访问统一入口问题,我们可以在集群前面增加负载均衡设备,实现流量分发。
负载均衡(LoadBalance),意思是将负载(工作任务,访问请求)进行平衡、分摊到多个操作单元(服务器,组件)上进行执行。
是解决高性能,单点故障(高可用),扩展性(水平伸缩)的终极解决方案。
本文是负载均衡详解的第一篇文章,介绍负载均衡的原理,负载均衡分类(DNS负载均衡,HTTP负载均衡,IP负载均衡,链路层负载均衡,混合型P负载均衡)。
部分内容摘自读书笔记。
一、负载均衡原理
系统的扩展可分为纵向(垂直)扩展和横向(水平)扩展。
纵向扩展,是从单机的角度通过增加硬件处理能力,比如CPU处理能力,内存容量,磁盘等方面,实现服务器处理能力的提升,不能满足大型分布式系统(网站),大流量,高并发,海量数据的问题。
因此需要采用横向扩展的方式,通过添加机器来满足大型网站服务的处理能力。
比如:
一台机器不能满足,则增加两台或者多台机器,共同承担访问压力。
这就是典型的集群和负载均衡架构:
如下图:
∙
应用集群:
将同一应用部署到多台机器上,组成处理集群,接收负载均衡设备分发的请求,进行处理,并返回相应数据。
∙
∙
∙
负载均衡设备:
将用户访问的请求,根据负载均衡算法,分发到集群中的一台处理服务器。
(一种把网络请求分散到一个服务器集群中的可用服务器上去的设备)
∙
负载均衡的作用(解决的问题):
1.解决并发压力,提高应用处理性能(增加吞吐量,加强网络处理能力);
2.提供故障转移,实现高可用;
3.通过添加或减少服务器数量,提供网站伸缩性(扩展性);
4.安全防护;(负载均衡设备上做一些过滤,黑白名单等处理)
二、负载均衡分类
根据实现技术不同,可分为DNS负载均衡,HTTP负载均衡,IP负载均衡,链路层负载均衡等。
2.1DNS负载均衡
最早的负载均衡技术,利用域名解析实现负载均衡,在DNS服务器,配置多个A记录,这些A记录对应的服务器构成集群。
大型网站总是部分使用DNS解析,作为第一级负载均衡。
如下图:
优点
1.
使用简单:
负载均衡工作,交给DNS服务器处理,省掉了负载均衡服务器维护的麻烦
2.
3.
4.
提高性能:
可以支持基于地址的域名解析,解析成距离用户最近的服务器地址,可以加快访问速度,改善性能;
5.
缺点
1.
可用性差:
DNS解析是多级解析,新增/修改DNS后,解析时间较长;解析过程中,用户访问网站将失败;
2.
3.
4.
扩展性低:
DNS负载均衡的控制权在域名商那里,无法对其做更多的改善和扩展;
5.
6.
7.
维护性差:
也不能反映服务器的当前运行状态;支持的算法少;不能区分服务器的差异(不能根据系统与服务的状态来判断负载)
8.
实践建议
将DNS作为第一级负载均衡,A记录对应着内部负载均衡的IP地址,通过内部负载均衡将请求分发到真实的Web服务器上。
一般用于互联网公司,复杂的业务系统不合适使用。
如下图:
2.2 IP负载均衡
在网络层通过修改请求目标地址进行负载均衡。
用户请求数据包,到达负载均衡服务器后,负载均衡服务器在操作系统内核进程获取网络数据包,根据负载均衡算法得到一台真实服务器地址,然后将请求目的地址修改为,获得的真实ip地址,不需要经过用户进程处理。
真实服务器处理完成后,响应数据包回到负载均衡服务器,负载均衡服务器,再将数据包源地址修改为自身的ip地址,发送给用户浏览器。
如下图:
IP负载均衡,真实物理服务器返回给负载均衡服务器,存在两种方式:
(1)负载均衡服务器在修改目的ip地址的同时修改源地址。
将数据包源地址设为自身盘,即源地址转换(snat)。
(2)将负载均衡服务器同时作为真实物理服务器集群的网关服务器。
优点:
(1)在内核进程完成数据分发,比在应用层分发性能更好;
缺点:
(2)所有请求响应都需要经过负载均衡服务器,集群最大吞吐量受限于负载均衡服务器网卡带宽;
2.3链路层负载均衡
在通信协议的数据链路层修改mac地址,进行负载均衡。
数据分发时,不修改ip地址,指修改目标mac地址,配置真实物理服务器集群所有机器虚拟ip和负载均衡服务器ip地址一致,达到不修改数据包的源地址和目标地址,进行数据分发的目的。
实际处理服务器ip和数据请求目的ip一致,不需要经过负载均衡服务器进行地址转换,可将响应数据包直接返回给用户浏览器,避免负载均衡服务器网卡带宽成为瓶颈。
也称为直接路由模式(DR模式)。
如下图:
优点:
性能好;
缺点:
配置复杂;
实践建议:
DR模式是目前使用最广泛的一种负载均衡方式。
2.4混合型负载均衡
由于多个服务器群内硬件设备、各自的规模、提供的服务等的差异,可以考虑给每个服务器群采用最合适的负载均衡方式,然后又在这多个服务器群间再一次负载均衡或群集起来以一个整体向外界提供服务(即把这多个服务器群当做一个新的服务器群),从而达到最佳的性能。
将这种方式称之为混合型负载均衡。
此种方式有时也用于单台均衡设备的性能不能满足大量连接请求的情况下。
是目前大型互联网公司,普遍使用的方式。
方式一,如下图:
以上模式适合有动静分离的场景,反向代理服务器(集群)可以起到缓存和动态请求分发的作用,当时静态资源缓存在代理服务器时,则直接返回到浏览器。
如果动态页面则请求后面的应用负载均衡(应用集群)。
方式二,如下图:
以上模式,适合动态请求场景。
因混合模式,可以根据具体场景,灵活搭配各种方式,以上两种方式仅供参考。
三、负载均衡算法
常用的负载均衡算法有,轮询,随机,最少链接,源地址散列,加权等方式;
3.1轮询
将所有请求,依次分发到每台服务器上,适合服务器硬件同相同的场景。
优点:
服务器请求数目相同;
缺点:
服务器压力不一样,不适合服务器配置不同的情况;
3.2随机
请求随机分配到各个服务器。
优点:
使用简单;
缺点:
不适合机器配置不同的场景;
3.3最少链接
将请求分配到连接数最少的服务器(目前处理请求最少的服务器)。
优点:
根据服务器当前的请求处理情况,动态分配;
缺点:
算法实现相对复杂,需要监控服务器请求连接数;
3.4Hash(源地址散列)
根据IP地址进行Hash计算,得到IP地址。
优点:
将来自同一IP地址的请求,同一会话期内,转发到相同的服务器;实现会话粘滞。
缺点:
目标服务器宕机后,会话会丢失;
3.5加权
在轮询,随机,最少链接,Hash’等算法的基础上,通过加权的方式,进行负载服务器分配。
优点:
根据权重,调节转发服务器的请求数目;
缺点:
使用相对复杂;
四、硬件负载均衡
采用硬件的方式实现负载均衡,一般是单独的负载均衡服务器,价格昂贵,一般土豪级公司可以考虑,业界领先的有两款,F5和A10。
使用硬件负载均衡,主要考虑一下几个方面:
(1)功能考虑:
功能全面支持各层级的负载均衡,支持全面的负载均衡算法,支持全局负载均衡;
(2)性能考虑:
一般软件负载均衡支持到5万级并发已经很困难了,硬件负载均衡可以支持
(3)稳定性:
商用硬件负载均衡,经过了良好的严格的测试,从经过大规模使用,在稳定性方面高;
(4)安全防护:
硬件均衡设备除具备负载均衡功能外,还具备防火墙,防DDOS攻击等安全功能;
(5)维护角度:
提供良好的维护管理界面,售后服务和技术支持;
(6)土豪公司:
F5BigIp价格:
15w~55w不等;A10价格:
55w-100w不等;
缺点
(1)价格昂贵;
(2)扩展能力差;
4.4小结
(1)一般硬件的负载均衡也要做双机高可用,因此成本会比较高。
(2)互联网公司一般使用开源软件,因此大部分应用采用软件负载均衡;部分采用硬件负载均衡。
比如某互联网公司,目前是使用几台F5做全局负载均衡,内部使用Nginx等软件负载均衡。
《大型网站架构系列:
负载均衡详解(上)》
一、软件负载均衡概述
硬件负载均衡性能优越,功能全面,但是价格昂贵,一般适合初期或者土豪级公司长期使用。
因此软件负载均衡在互联网领域大量使用。
常用的软件负载均衡软件有Nginx,Lvs,HaProxy等。
本文参考大量文档,部分为直接拷贝。
二、Ngnix负载均衡
Ngnix是一款轻量级的Web服务器/反向代理服务器,工作在七层Http协议的负载均衡系统。
具有高性能、高并发、低内存使用等特点。
是一个轻量级的Http和反向代理服务器。
Nginx使用epollandkqueue作为开发模型。
能够支持高达50,000个并发连接数的响应。
操作系统:
Liunx,Windows(Linux、FreeBSD、Solaris、MacOSX、AIX以及MicrosoftWindows)
开发语言:
C
并发性能:
官方支持每秒5万并发,实际国内一般到每秒2万并发,有优化到每秒10万并发的。
具体性能看应用场景。
2.1.特点
1.模块化设计:
良好的扩展性,可以通过模块方式进行功能扩展。
2.高可靠性:
主控进程和worker是同步实现的,一个worker出现问题,会立刻启动另一个worker。
3.内存消耗低:
一万个长连接(keep-alive),仅消耗2.5MB内存。
4.支持热部署:
不用停止服务器,实现更新配置文件,更换日志文件、更新服务器程序版本。
5.并发能力强:
官方数据每秒支持5万并发;
6.功能丰富:
优秀的反向代理功能和灵活的负载均衡策略
2.2.功能
2.2.1基本功能
∙
支持静态资源的web服务器。
∙
∙
∙
http,smtp,pop3协议的反向代理服务器、缓存、负载均衡;
∙
∙
∙
支持FASTCGI(fpm)
∙
∙
∙
支持模块化,过滤器(让文本可以实现压缩,节约带宽),ssl及图像大小调整。
∙
∙
∙
内置的健康检查功能
∙
∙
∙
基于名称和ip的虚拟主机
∙
∙
∙
定制访问日志
∙
∙
∙
支持平滑升级
∙
∙
∙
支持KEEPALIVE
∙
∙
∙
支持urlrewrite
∙
∙
∙
支持路径别名
∙
∙
∙
支持基于IP和用户名的访问控制。
∙
∙
∙
支持传输速率限制,支持并发数限制。
∙
2.2.2性能
Nginx的高并发,官方测试支持5万并发连接。
实际生产环境能到2-3万并发连接数。
10000个非活跃的HTTPkeep-alive连接仅占用约2.5MB内存。
三万并发连接下,10个Nginx进程,消耗内存150M。
淘宝tengine团队测试结果是“24G内存机器上,处理并发请求可达200万”。
2.3架构
2.3.1Nginx的基本工作模式
一个master进程,生成一个或者多个worker进程。
但是这里master是使用root身份启动的,因为nginx要工作在80端口。
而只有管理员才有权限启动小于低于1023的端口。
master主要是负责的作用只是启动worker,加载配置文件,负责系统的平滑升级。
其它的工作是交给worker。
那么当worker被启动之后,也只是负责一些web最简单的工作,而其他的工作都是有worker中调用的模块来实现的。
模块之间是以流水线的方式实现功能的。
流水线,指的是一个用户请求,由多个模块组合各自的功能依次实现完成的。
比如:
第一个模块只负责分析请求首部,第二个模块只负责查找数据,第三个模块只负责压缩数据,依次完成各自工作。
来实现整个工作的完成。
他们是如何实现热部署的呢?
其实是这样的,我们前面说master不负责具体的工作,而是调用worker工作,他只是负责读取配置文件,因此当一个模块修改或者配置文件发生变化,是由master进行读取,因此此时不会影响到worker工作。
在master进行读取配置文件之后,不会立即的把修改的配置文件告知worker。
而是让被修改的worker继续使用老的配置文件工作,当worker工作完毕之后,直接当掉这个子进程,更换新的子进程,使用新的规则。
2.3.2Nginx支持的sendfile机制
Sendfile机制,用户将请求发给内核,内核根据用户的请求调用相应用户进程,进程在处理时需要资源。
此时再把请求发给内核(进程没有直接IO的能力),由内核加载数据。
内核查找到数据之后,会把数据复制给用户进程,由用户进程对数据进行封装,之后交给内核,内核在进行tcp/ip首部的封装,最后再发给客户端。
这个功能用户进程只是发生了一个封装报文的过程,却要绕一大圈。
因此nginx引入了sendfile机制,使得内核在接受到数据之后,不再依靠用户进程给予封装,而是自己查找自己封装,减少了一个很长一段时间的浪费,这是一个提升性能的核心点。
以上内容摘自网友发布的文章,简单一句话是资源的处理,直接通过内核层进行数据传递,避免了数据传递到应用层,应用层再传递到内核层的开销。
目前高并发的处理,一般都采用sendfile模式。
通过直接操作内核层数据,减少应用与内核层数据传递。
2.3.3Nginx通信模型(I/O复用机制)
开发模型:
epoll和kqueue。
支持的事件机制:
kqueue、epoll、rtsignals、/dev/poll、eventports、select以及poll。
支持的kqueue特性包括EV_CLEAR、EV_DISABLE、NOTE_LOWAT、EV_EOF,可用数据的数量,错误代码.
支持sendfile、sendfile64和sendfilev;文件AIO;DIRECTIO;支持Accept-filters和TCP_DEFER_ACCEP.
以上概念较多,大家自行XX或谷歌,知识领域是网络通信(BIO,NIO,AIO)和多线程方面的知识。
2.4均衡策略
nginx的负载均衡策略可以划分为两大类:
内置策略和扩展策略。
内置策略包含加权轮询和iphash,在默认情况下这两种策略会编译进nginx内核,只需在nginx配置中指明参数即可。
扩展策略有很多,如fair、通用hash、consistenthash等,默认不编译进nginx内核。
由于在nginx版本升级中负载均衡的代码没有本质性的变化,因此下面将以nginx1.0.15稳定版为例,从源码角度分析各个策略。
2.4.1.加权轮询(weightedroundrobin)
轮询的原理很简单,首先我们介绍一下轮询的基本流程。
如下是处理一次请求的流程图:
图中有两点需要注意,第一,如果可以把加权轮询算法分为先深搜索和先广搜索,那么nginx采用的是先深搜索算法,即将首先将请求都分给高权重的机器,直到该机器的权值降到了比其他机器低,才开始将请求分给下一个高权重的机器;第二,当所有后端机器都down掉时,nginx会立即将所有机器的标志位清成初始状态,以避免造成所有的机器都处在timeout的状态,从而导致整个前端被夯住。
2.4.2.iphash
iphash是nginx内置的另一个负载均衡的策略,流程和轮询很类似,只是其中的算法和具体的策略有些变化,如下图所示:
2.4.3.fair
fair策略是扩展策略,默认不被编译进nginx内核。
其原理是根据后端服务器的响应时间判断负载情况,从中选出负载最轻的机器进行分流。
这种策略具有很强的自适应性,但是实际的网络环境往往不是那么简单,因此要慎用。
2.4.4通用hash、一致性hash
这两种也是扩展策略,在具体的实现上有些差别,通用hash比较简单,可以以nginx内置的变量为key进行hash,一致性hash采用了nginx内置的一致性hash环,可以支持memcache。
2.5场景
Ngnix一般作为入口负载均衡或内部负载均衡,结合反向代理服务器使用。
以下架构示例,仅供参考,具体使用根据场景而定。
2.5.1入口负载均衡架构
Ngnix服务器在用户访问的最前端。
根据用户请求再转发到具体的应用服务器或二级负载均衡服务器(LVS)
2.5.2内部负载均衡架构
LVS作为入口负载均衡,将请求转发到二级Ngnix服务器,Ngnix再根据请求转发到具体的应用服务器。
2.5.3Ngnix高可用
分布式系统中,应用只部署一台服务器会存在单点故障,负载均衡同样有类似的问题。
一般可采用主备或负载均衡设备集群的方式节约单点故障或高并发请求分流。
Ngnix高可用,至少包含两个Ngnix服务器,一台主服务器,一台备服务器,之间使用Keepalived做健康监控和故障检测。
开放VIP端口,通过防火墙进行外部映射。
DNS解析公网的IP实际为VIP。
三、LVS负载均衡
LVS是一个开源的软件,由毕业于国防科技大学的章文嵩博士于1998年5月创立,用来实现Linux平台下的简单负载均衡。
LVS是LinuxVirtualServer的缩写,意思是Linux虚拟服务器。
基于IP层的负载均衡调度技术,它在操作系统核心层上,将来自IP层的TCP/UDP请求均衡地转移到不同的 服务器,从而将一组服务器构成一个高性能、高可用的虚拟服务器。
操作系统:
Liunx
开发语言:
C
并发性能:
默认4096,可以修改但需要重新编译。
3.1.功能
LVS的主要功能是实现IP层(网络层)负载均衡,有NAT,TUN,DR三种请求转发模式。
3.1.1LVS/NAT方式的负载均衡集群
NAT是指NetworkAddressTranslation,它的转发流程是:
Director机器收到外界请求,改写数据包的目标地址,按相应的调度算法将其发送到相应RealServer上,RealServer处理完该请求后,将结果数据包返回到其默认网关,即Director机器上,Director机器再改写数据包的源地址,最后将其返回给外界。
这样就完成一次负载调度。
构架一个最简单的LVS/NAT方式的负载均衡集群RealServer可以是任何的操作系统,而且无需做任何特殊的设定,惟一要做的就是将其默认网关指向Director机器。
RealServer可以使用局域网的内部IP(192.168.0.0/24)。
Director要有两块网卡,一块网卡绑定一个外部IP地址(10.0.0.1),另一块网卡绑定局域网的内部IP(192.168.0.254),作为RealServer的默认网关。
LVS/NAT方式实现起来最为简单,而且RealServer使用的是内部IP,可以节省RealIP的开销。
但因为执行NAT需要重写流经Director的数据包,在速度上有一定延迟;
当用户的请求非常短,而服务器的回应非常大的情况下,会对Director形成很大压力,成为新的瓶颈,从而使整个系统的性能受到限制。
3.1.2LVS/TUN方式的负载均衡集群
TUN是指IPTunneling,它的转发流程是:
Director机器收到外界请求,按相应的调度算法,通过IP隧道发送到相应RealServer,RealServer处理完该请求后,将结果数据包直接返回给客户。
至此完成一次负载调度。
最简单的LVS/TUN方式的负载均衡集群架构使用IPTunneling技术,在Director机器和RealServer机器之间架设一个IPTunnel,通过IPTunnel将负载分配到RealServer机器上。
Director和RealServer之间的关系比较松散,可以是在同一个网络中,也可以是在不同的网络中,只要两者能够通过IPTunnel相连就行。
收到负载分配的RealServer机器处理完后会直接将反馈数据送回给客户,而不必通过Director机器。
实际应用中,服务器必须拥有正式的IP地址用于与客户机直接通信,并且所有服务器必须支持IP隧道协议。
该方式中Director将客户请求分配到不同的RealServer,RealServer处理请求后直接回应给用户,这样Director就只处理客户机与服务器的一半连接,极大地提高了Director的调度处理能力,使集群系统能容纳更多的节点数。
另外TUN方式中的RealServer可以在任何LAN或WAN上运行,这样可以构筑跨地域的集群,其应对灾难的能力也更强,但是服务器需要为IP封装付出一定的资源开销,而且后端的RealServer必须是支持IPTunneling的操作系统。
3.3.3LVS/TUN方式的负载均衡集群
DR是指DirectRouting,它的转发流程是:
Director机器收到外界请求,按相应的调度算法将其直接发送到相应RealServer,RealServer处理完该请求后,将结果数据包直接返回给客户,完成一次负载调度。
构架一个最简单的LVS/DR方式的负载均衡集群RealServer和Director都在同一个物理网段中,Director的网卡IP是192.168.0.253,再绑定另一个IP:
192.168.0.254作为对外界的virtualIP,外界客户通过该IP来访问整个集群系统。
RealServer在lo上绑定IP:
192.168.0.254,同时加入相应的路由。
LVS/DR方式与前面的LVS/TUN方式有些类似,前台的Director机器也是只需要接收和调度外界的请求,而不需要负责返回这些请求的反馈结果,所以能够负载更多的RealServer,提高Director的调度处理能力,使集群系统容纳更多的RealServer。
但LVS/DR需要改写请求报文的MAC地址,所以所有服务器必须在同一物理网段内。
3.3架构
LVS架设的服务器集群系统有三个部分组成:
最前端的负载均衡层(LoaderBalancer),中间的服务器群组层,用ServerArray表示,最底层的数据共享存储层,用SharedStorage表示。
在用户看来所有的应用都是透明的,用户只是在使用一个虚拟服务器提供的高性能服务。
LVS的体系架构如图:
LVS的各个层次的详细介绍:
LoadBalancer层:
位于整个集群系统的最前端,有一台或者多台负载调度器(DirectorServer)组成,LVS模块就安装在DirectorServer上,而Director的主要作用类似于一个路由器,它含有完成LVS功能所设定的路由表,通过这些路由表把用户的请求分发给ServerArray层的应用服务器(RealServer)上。
同时,在DirectorServer上还要安装对RealServer服务的监控模块Ldirectord,此模块用于监测各个RealServer服务的健康状况。
在RealServer不可用时把它从LVS路由表中剔除,恢复时重新加入。
ServerArr
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 大型 网站 架构 系列 负载 均衡 详解