详细介绍负载均衡,让它更透彻

        在理解学习负载均衡时,须要了解下网络协议的模型,须要知道每一层都支持哪些协议,又是如何进行负载均衡,是使用软件,仍是使用硬件,熟悉了解后才能更好的掌握负载均衡的实质.

 

网络协议

请移步至OSI七层网络模型进行详细了解.

小知识:

多层负载解释说明:            

二层负载均衡会经过一个虚拟MAC地址接收请求，而后再分配到真实的MAC地址；            

三层负载均衡会经过一个虚拟IP地址接收请求，而后再分配到真实的IP地址；            

四层负载均衡会经过虚拟IP+端口接收请求，而后再分配到真实的服务器；            

七层负载均衡会经过虚拟的URL或主机名接收请求，而后再分配到真实的服务器。

1、什么是负载均衡

负载均衡（Load Balance）

        其意思就是分摊到多个操做单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工做任务。单从字面上的意思来理解就能够解释N台服务器平均分担负载，不会由于某台服务器负载高宕机而某台服务器闲置的状况。那么负载均衡的前提就是要有多台服务器才能实现，也就是两台以上便可。

2、负载均衡的优势

        减小服务器的压力，将本来一台服务器索要承受的访问量分给多台，并提升项目的可用性，当一台服务器挂掉的时候不会致使项目瘫痪。

3、四层负载均衡和七层负载均衡

       七层负载均衡，主要仍是着重于应用普遍的HTTP协议，因此其应用范围主要是众多的网站或者内部信息平台等基于B/S开发的系统。 四层负载均衡则对应其余TCP应用，例如基于C/S开发的ERP等系统。

        四层负载均衡工做在OSI模型的传输层，主要工做是转发，它在接收到客户端的流量之后,经过修改数据包的地址信息将流量转发到应用服务器。

能够这样理解经过发布三层的IP地址（VIP），而后加四层的端口号，来决定哪些流量须要作负载均衡，对须要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个链接的全部流量都一样转发到同一台服务器处理。

四层负载和七层负载

        七层负载均衡工做在OSI模型的应用层，由于它须要解析应用层流量，因此七层负载均衡在接到客户端的流量之后，还须要一个完整的TCP/IP协议栈。七层负载均衡会与客户端创建一条完整的链接,并将应用层的请求流量解析出来，再按照调度算法选择一个应用服务器，并与应用服务器创建另一条链接将请求发送过去，所以七层负载均衡的主要工做就是代理。七层负载均衡 也称为“内容交换”，也就是主要经过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

能够这样理解为在四层的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，好比同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否须要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，若是你的Web服务器分红两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就能够当用户来访问你的域名时，自动辨别用户语言，而后选择对应的语言服务器组进行负载均衡处理。

七层应用须要考虑的问题。

1.是否真的必要。

        七层应用的确能够提升流量智能化，同时必不可免的带来设备配置复杂，负载均衡压力增高以及故障排查上的复杂性等问题。在设计系统时须要考虑四层七层同时应用的混杂状况。

2.是否真的能够提升安全性。

        例如SYN Flood攻击，七层模式的确将这些流量从服务器屏蔽，但负载均衡设备自己要有强大的抗DDoS(一种网络黑客方式,详细了解请搜索"DDOS")能力，不然即便服务器正常而做为中枢调度的负载均衡设备故障也会致使整个应用的崩溃。

3.是否有足够的灵活度。

        七层应用的优点是可让整个应用的流量智能化，可是负载均衡设备须要提供完善的七层功能，知足客户根据不一样状况的基于应用的调度。最简单的一个考核就是可否取代后台Nginx或者Apache等服务器上的调度功能。可以提供一个七层应用开发接口的负载均衡设备，可让客户根据需求任意设定功能，才真正有可能提供强大的灵活性和智能性。

        七层负载均衡的优势：

         1.经过对HTTP报头的检查，能够检测出HTTP400、500和600系列的错误信息，于是能透明地将链接请求从新定向到另外一台服务器，避免应用层故障。

　　2.可根据流经的数据类型（如判断数据包是图像文件、压缩文件或多媒体文件格式等），把数据流量引向相应内容的服务器来处理，增长系统性能。

　    3.能根据链接请求的类型，如是普通文本、图象等静态文档请求，仍是asp、cgi等的动态文档请求，把相应的请求引向相应的服务器来处理，提升系统的性能及安全性。

注*第七层负载均衡受到其所支持的协议限制（通常只有HTTP），这样就限制了它应用的普遍性，而且检查HTTP报头会占用大量的系统资源，势必会影响到系统的性能，在大量链接请求的状况下，负载均衡设备自身容易成为网络总体性能的瓶颈。

4、负载均衡软/硬件

 

负载均衡架构图

　软/硬件负载均衡

　　软件负载均衡解决方案是指在一台或多台服务器相应的操做系统上安装一个或多个附加软件来实现负载均衡，负载均衡软件有Nginx(web服务器软件)、LVS(Linux Virtual Server linux虚拟服务器软件)、HaProxy(代理软件)等是目前使用最普遍的三种负载均衡软件。它的优势是基于特定环境，配置简单，使用灵活，成本低廉，能够知足通常的负载均衡需求。

　　软件解决方案缺点也较多，由于每台服务器上安装额外的软件运行会消耗系统不定量的资源，越是功能强大的模块，消耗得越多，因此当链接请求特别大的时候，软件自己会成为服务器工做成败的一个关键；软件可扩展性并非很好，受到操做系统的限制；因为操做系统自己的Bug，每每会引发安全问题。

　　硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备，这种设备咱们一般称之为负载均衡器，因为专门的设备完成专门的任务，独立于操做系统，总体性能获得大量提升，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。 

　　负载均衡器有多种多样的形式，除了做为独立意义上的负载均衡器外，有些负载均衡器集成在交换设备中，置于服务器与Internet连接之间，有些则以两块网络适配器将这一功能集成到PC中，一块链接到Internet上，一块链接到后端服务器群的内部网络上。

负载均衡器一般称为四层交换机或七层交换机。四层交换机主要分析IP层及TCP/UDP层，实现四层流量负载均衡。七层交换机除了支持四层负载均衡之外，还有分析应用层的信息，如HTTP协议URI或Cookie信息。

一、负载均衡分为L4 switch（四层交换），即在OSI的第4层工做，就是TCP层。此种Load Balance不理解应用协议（如HTTP/FTP/MySQL等等）。例子：LVS，F5(一种负载均衡硬件很贵,用于大型有实力有钱的公司)。

二、另外一种负载均衡分为L7 switch（七层交换），OSI的最高层，应用层。此时，该Load Balancer能理解应用协议。例子：  haproxy，MySQL Proxy。　　注意：上面的不少Load Balancer 既能够作四层交换，也能够作七层交换。

　　通常而言，硬件负载均衡在功能、性能上优于软件方式，不过成本昂贵。

负载均衡设备也常被称为"四到七层交换机"，那么四层和七层二者到底区别在哪里？

第一，技术原理上的区别。

        所谓四层负载均衡，也就是主要经过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

        以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即经过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改成后端服务器IP），直接转发给该服务器。TCP的链接创建，即三次握手是客户端和服务器直接创建的，负载均衡设备只是起到一个相似路由器的转发动做。在某些部署状况下，为保证服务器回包能够正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。 

         所谓七层负载均衡，也称为“内容交换”，也就是主要经过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

        以常见的TCP为例，负载均衡设备若是要根据真正的应用层内容再选择服务器，只能先代理最终的服务器和客户端创建链接(三次握手)后，才可能接受到客户端发送的真正应用层内容的报文，而后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。负载均衡设备在这种状况下，更相似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别创建TCP链接。因此从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。 

第二，应用场景的需求。

        七层应用负载的好处，是使得整个网络更"智能化"。例如访问一个网站的用户流量，能够经过七层的方式，将对图片类的请求转发到特定的图片服务器并可使用缓存技术；将对文字类的请求能够转发到特定的文字服务器并可使用压缩技术。固然这只是七层应用的一个小案例，从技术原理上，这种方式能够对客户端的请求和服务器的响应进行任意意义上的修改，极大的提高了应用系统在网络层的灵活性。不少在后台，例如Nginx或者Apache上部署的功能能够前移到负载均衡设备上，例如客户请求中的Header重写，服务器响应中的关键字过滤或者内容插入等功能。另一个经常被提到功能就是安全性。网络中最多见的SYN Flood攻击，即黑客控制众多源客户端，使用虚假IP地址对同一目标发送SYN攻击，一般这种攻击会大量发送SYN报文，耗尽服务器上的相关资源，以达到Denial of Service(DoS)的目的。从技术原理上也能够看出，四层模式下这些SYN攻击都会被转发到后端的服务器上；而七层模式下这些SYN攻击天然在负载均衡设备上就截止，不会影响后台服务器的正常运营。另外负载均衡设备能够在七层层面设定多种策略，过滤特定报文，例如SQL Injection等应用层面的特定攻击手段，从应用层面进一步提升系统总体安全。如今的7层负载均衡，主要仍是着重于应用HTTP协议，因此其应用范围主要是众多的网站或者内部信息平台等基于B/S开发的系统。 4层负载均衡则对应其余TCP应用，例如基于C/S开发的ERP等系统。 

4、负载均衡算法

通常来讲负载均衡设备都会默认支持多种负载均衡分发策略

轮询（RoundRobin）将请求顺序循环地发到每一个服务器。当其中某个服务器发生故障，AX就把其从顺序循环队列中拿出，不参加下一次的轮询，直到其恢复正常。

比率（Ratio）：给每一个服务器分配一个加权值为比例，根椐这个比例，把用户的请求分配到每一个服务器。当其中某个服务器发生故障，AX就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

优先权（Priority）：给全部服务器分组，给每一个组定义优先权，将用户的请求分配给优先级最高的服务器组（在同一组内，采用预先设定的轮询或比率算法，分配用户的请求）；当最高优先级中全部服务器或者指定数量的服务器出现故障，AX将把请求送给次优先级的服务器组。这种方式，实际为用户提供一种热备份的方式。

最少链接数（LeastConnection）：AX会记录当前每台服务器或者服务端口上的链接数，新的链接将传递给链接数最少的服务器。当其中某个服务器发生故障，AX就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

最快响应时间（Fast Reponse time）：新的链接传递给那些响应最快的服务器。当其中某个服务器发生故障，AX就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

哈希算法( hash): 将客户端的源地址，端口进行哈希运算，根据运算的结果转发给一台服务器进行处理，当其中某个服务器发生故障，就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

基于数据包的内容分发：例如判断HTTP的URL，若是URL中带有.jpg的扩展名，就把数据包转发到指定的服务器。

 

5、健康检查

健康检查用于检查服务器开放的各类服务的可用状态。

负载均衡设备通常会配置各类健康检查方法，例如Ping，TCP，UDP，HTTP，FTP，DNS等。

        Ping属于第三层的健康检查，用于检查服务器IP的连通性，TCP/UDP属于第四层的健康检查，用于检查服务端口的UP/DOWN，若是要检查的更准确，就要用到基于7层的健康检查，例如建立一个HTTP健康检查，Get一个页面回来，而且检查页面内容是否包含一个指定的字符串，若是包含，则服务是UP的，若是不包含或者取不回页面，就认为该服务器的Web服务是不可用（DOWN）的。好比，负载均衡设备检查到172.16.20.3这台服务器的80端口是DOWN的，负载均衡设备将不把后面的链接转发到这台服务器，而是根据算法将数据包转发到别的服务器。建立健康检查时能够设定检查的间隔时间和尝试次数，例如设定间隔时间为5秒，尝试次数为3，那么负载均衡设备每隔5秒发起一次健康检查，若是检查失败，则尝试3次，若是3次都检查失败，则把该服务标记为DOWN，而后服务器仍然会每隔5秒对DOWN的服务器进行检查，当某个时刻发现该服务器健康检查又成功了，则把该服务器从新标记为UP。健康检查的间隔时间和尝试次数要根据综合状况来设置，原则是既不会对业务产生影响，又不会对负载均衡设备形成较大负担。

 

6、会话保持

如何保证一个用户的两次http请求转发到同一个服务器，这就要求负载均衡设备配置会话保持。

会话保持用于保持会话的连续性和一致性，因为服务器之间很难作到实时同步用户访问信息，这就要求把用户的先后访问会话保持到一台服务器上来处理。

    举个例子，用户访问一个电子商务网站，若是用户登陆时是由第一台服务器来处理的，但用户购买商品的动做却由第二台服务器来处理，第二台服务器因为不知道用户信息，因此本次购买就不会成功。这种状况就须要会话保持，把用户的操做都经过第一台服务器来处理才能成功。固然并非全部的访问都须要会话保持，例如服务器提供的是静态页面好比网站的新闻频道，各台服务器都有相同的内容，这种访问就不须要会话保持。

绝大多数的负载均衡产品都支持两类基本的会话保持方式：源/目的地址会话保持和cookie会话保持，另外像hash，URL Persist等也是比较经常使用的方式，但不是全部设备都支持。基于不一样的应用要配置不一样的会话保持，不然会引发负载的不均衡甚至访问异常。咱们主要分析B/S结构的会话保持。

 

7、基于B/S结构的应用：

        对于普通B/S结构的应用内容，例如网站的静态页面，能够不用配置任何的会话保持，可是对于一个基于B/S结构尤为是中间件平台的业务系统来讲，必须配置会话保持，通常状况下，咱们配置源地址会话保持能够知足需求，可是考虑到客户端可能有上述不利于源地址会话保持的环境，采用Cookie会话保持是一个更好的方式。Cookie会话保持会把负载均衡设备选择的Server信息保存在Cookie中发送到客户端，客户端持续访问时，会把该Cookie带来，负载均衡器经过分析Cookie把会话保持到以前选定的服务器。Cookie分为文件Cookie和内存cookie，文件cookie保存在客户端计算机硬盘上，只要该cookie文件不过时，则不管是否重复关闭开放浏览器都能保持到同一台服务器。内存Cookie则是把Cookie信息保存在内存中，Cookie的生存时间从打开浏览器访问开始，关闭浏览器结束。因为如今的浏览器对Cookie都有必定默认的安全设置，有些客户端可能规定不许使用文件Cookie，因此如今的应用程序开发多使用内存Cookie。

        然而，内存Cookie也不是万能的，好比浏览器为了安全可能会彻底禁用Cookie，这样Cookie会话保持就失去了做用。咱们能够经过Session-id来实现会话保持，即将session-id做为url参数或者放在隐藏字段<input type="hidden">中，而后分析Session-id进行分发。

        另外一种方案是：将每一会话信息保存到一个数据库中。因为这个方案会增长数据库的负载，因此这个方案对性能的提升并很差。数据库最好是用来存储会话时间比较长的会话数据。为了不数据库出现单点故障，而且提升其扩展性，数据库一般会复制到多台服务器上，经过负载均衡器来分发请求到数据库服务器上。

        基于源/目的地址会话保持其实不太好用，由于客户多是经过DHCP，NAT或者Web代理来链接Internet的，其IP地址可能常常变换，这使得这个方案的服务质量没法保障。

        NAT(Network Address Translation，网络地址转换):当在专用网内部的一些主机原本已经分配到了本地IP地址(即仅在本专用网内使用的专用地址)，但如今又想和因特网上的主机通讯(并不须要加密)时，可以使用NAT方法。这种方法须要在专用网链接到因特网的路由器上安装NAT软件。装有NAT软件的路由器叫作NAT路由器，它至少有一个有效的外部全球IP地址。这样，全部使用本地地址的主机在和外界通讯时，都要在NAT路由器上将其本地地址转换成全球IP地址，才能和因特网链接。

8、负载均衡项目需求分析

负载均衡方案应是在网站建设初期就应考虑的问题，不过有时随着访问流量的爆炸性增加，超出决策者的意料，这也就成为不得不面对的问题。当咱们在引入某种负载均衡方案乃至具体实施时，像其余的许多方案同样，首先是肯定当前及未来的应用需求，而后在代价与收效之间作出权衡。

　　针对当前及未来的应用需求，分析网络瓶颈的不一样所在，咱们就须要确立是采用哪一类的负载均衡技术，采用什么样的均衡策略，在可用性、兼容性、安全性等等方面要知足多大的需求，如此等等。 

　　无论负载均衡方案是采用花费较少的软件方式，仍是购买代价高昂在性能功能上更强的第四层交换机、负载均衡器等硬件方式来实现，亦或其余种类不一样的均衡技术，下面这几项都是咱们在引入均衡方案时可能要考虑的问题：

　　性能：性能是咱们在引入均衡方案时须要重点考虑的问题，但也是一个最难把握的问题。衡量性能时可将每秒钟经过网络的数据包数目作为一个参数，另外一个参数是均衡方案中服务器群所能处理的最大并发链接数目，可是，假设一个均衡系统能处理百万计的并发链接数，但是却只能以每秒2个包的速率转发，这显然是没有任何做用的。性能的优劣与负载均衡设备的处理能力、采用的均衡策略息息相关，而且有两点须要注意：1、均衡方案对服务器群总体的性能，这是响应客户端链接请求速度的关键；2、负载均衡设备自身的性能，避免有大量链接请求时自身性能不足而成为服务瓶颈。有时咱们也能够考虑采用混合型负载均衡策略来提高服务器群的整体性能，如DNS负载均衡与NAT负载均衡相结合。另外，针对有大量静态文档请求的站点，也能够考虑采用高速缓存技术，相对来讲更节省费用，更能提升响应性能；对有大量ssl/xml内容传输的站点，更应考虑采用ssl/xml加速技术。

　　可扩展性：IT技术突飞猛进，一年之前最新的产品，如今或许已经是网络中性能最低的产品；业务量的急速上升，一年前的网络，如今须要新一轮的扩展。合适的均衡解决方案应能知足这些需求，能均衡不一样操做系统和硬件平台之间的负载，能均衡HTTP、邮件、新闻、代理、数据库、防火墙和 Cache等不一样服务器的负载，而且能以对客户端彻底透明的方式动态增长或删除某些资源。

　　灵活性：均衡解决方案应能灵活地提供不一样的应用需求，知足应用需求的不断变化。在不一样的服务器群有不一样的应用需求时，应有多样的均衡策略提供更普遍的选择。

　　可靠性：在对服务质量要求较高的站点，负载均衡解决方案应能为服务器群提供彻底的容错性和高可用性。但在负载均衡设备自身出现故障时，应该有良好的冗余解决方案，提升可靠性。使用冗余时，处于同一个冗余单元的多个负载均衡设备必须具备有效的方式以便互相进行监控，保护系统尽量地避免遭受到重大故障的损失。

　　易管理性：无论是经过软件仍是硬件方式的均衡解决方案，咱们都但愿它有灵活、直观和安全的管理方式，这样便于安装、配置、维护和监控，提升工做效率，避免差错。在硬件负载均衡设备上，目前主要有三种管理方式可供选择：1、命令行接口（CLI：Command Line Interface），可经过超级终端链接负载均衡设备串行接口来管理，也能telnet远程登陆管理，在初始化配置时，每每要用到前者；2、图形用户接口（GUI：Graphical User Interfaces），有基于普通web页的管理，也有经过Java Applet 进行安全管理，通常都须要管理端安装有某个版本的浏览器；3、SNMP（Simple Network Management Protocol，简单网络管理协议）支持，经过第三方网络管理软件对符合SNMP标准的设备进行管理

注:文章若有疑问或错误之处,请留言评论指出,必将学习之.