谈谈大型网站架构系列：负载均衡详解

面对大量用户访问、高并发请求，海量数据，可使用高性能的服务器、大型数据库，存储设备，高性能Web服务器，采用高效率的编程语言好比(Go,Scala)等，当单机容量达到极限时，咱们须要考虑业务拆分和分布式部署，来解决大型网站访问量大，并发量高，海量数据的问题。

从单机网站到分布式网站，很重要的区别是业务拆分和分布式部署，将应用拆分后，部署到不一样的机器上，实现大规模分布式系统。分布式和业务拆分解决了，从集中到分布的问题，可是每一个部署的独立业务还存在单点的问题和访问统一入口问题，为解决单点故障，咱们能够采起冗余的方式。将相同的应用部署到多台机器上。解决访问统一入口问题，咱们能够在集群前面增长负载均衡设备，实现流量分发。

负载均衡（Load Balance），意思是将负载（工做任务，访问请求）进行平衡、分摊到多个操做单元（服务器，组件）上进行执行。是解决高性能，单点故障（高可用），扩展性（水平伸缩）的终极解决方案。

本文是负载均衡详解的第一篇文章，介绍负载均衡的原理，负载均衡分类（DNS负载均衡,HTTP负载均衡，IP负载均衡，链路层负载均衡,混合型P负载均衡）。部份内容摘自读书笔记。

本次分享大纲

1. 负载均衡原理
2. DNS负载均衡
3. HTTP负载均衡
4. IP负载均衡
5. 链路层负载均衡
6. 混合型P负载均衡

1、负载均衡原理

系统的扩展可分为纵向（垂直）扩展和横向（水平）扩展。纵向扩展，是从单机的角度经过增长硬件处理能力，好比CPU处理能力，内存容量，磁盘等方面，实现服务器处理能力的提高，不能知足大型分布式系统（网站），大流量，高并发，海量数据的问题。所以须要采用横向扩展的方式，经过添加机器来知足大型网站服务的处理能力。好比：一台机器不能知足，则增长两台或者多台机器，共同承担访问压力。这就是典型的集群和负载均衡架构：以下图：

• 应用集群：将同一应用部署到多台机器上，组成处理集群，接收负载均衡设备分发的请求，进行处理，并返回相应数据。
• 负载均衡设备：将用户访问的请求，根据负载均衡算法，分发到集群中的一台处理服务器。（一种把网络请求分散到一个服务器集群中的可用服务器上去的设备）

 负载均衡的做用（解决的问题）：

1.解决并发压力，提升应用处理性能（增长吞吐量，增强网络处理能力）；

2.提供故障转移，实现高可用；

3.经过添加或减小服务器数量，提供网站伸缩性（扩展性）；

4.安全防御；（负载均衡设备上作一些过滤，黑白名单等处理）

2、负载均衡分类

根据实现技术不一样，可分为DNS负载均衡，HTTP负载均衡，IP负载均衡，链路层负载均衡等。

2.1DNS负载均衡

最先的负载均衡技术，利用域名解析实现负载均衡，在DNS服务器，配置多个A记录，这些A记录对应的服务器构成集群。大型网站老是部分使用DNS解析，做为第一级负载均衡。以下图：

优势

1. 使用简单：负载均衡工做，交给DNS服务器处理，省掉了负载均衡服务器维护的麻烦
2. 提升性能：能够支持基于地址的域名解析，解析成距离用户最近的服务器地址，能够加快访问速度，改善性能；

缺点

1. 可用性差：DNS解析是多级解析，新增/修改DNS后，解析时间较长；解析过程当中，用户访问网站将失败；
2. 扩展性低：DNS负载均衡的控制权在域名商那里，没法对其作更多的改善和扩展；
3. 维护性差：也不能反映服务器的当前运行状态；支持的算法少；不能区分服务器的差别（不能根据系统与服务的状态来判断负载）

 实践建议

将DNS做为第一级负载均衡，A记录对应着内部负载均衡的IP地址，经过内部负载均衡将请求分发到真实的Web服务器上。通常用于互联网公司，复杂的业务系统不合适使用。以下图：

1.3  IP负载均衡

在网络层经过修改请求目标地址进行负载均衡。

用户请求数据包，到达负载均衡服务器后，负载均衡服务器在操做系统内核进程获取网络数据包，根据负载均衡算法获得一台真实服务器地址，而后将请求目的地址修改成，得到的真实ip地址，不须要通过用户进程处理。

真实服务器处理完成后，响应数据包回到负载均衡服务器，负载均衡服务器，再将数据包源地址修改成自身的ip地址，发送给用户浏览器。以下图：

IP负载均衡，真实物理服务器返回给负载均衡服务器，存在两种方式：（1）负载均衡服务器在修改目的ip地址的同时修改源地址。将数据包源地址设为自身盘，即源地址转换（snat）。（2）将负载均衡服务器同时做为真实物理服务器集群的网关服务器。

 优势：

（1）在内核进程完成数据分发，比在应用层分发性能更好；

缺点：

（2）全部请求响应都须要通过负载均衡服务器，集群最大吞吐量受限于负载均衡服务器网卡带宽；

2.4链路层负载均衡

在通讯协议的数据链路层修改mac地址，进行负载均衡。

数据分发时，不修改ip地址，指修改目标mac地址，配置真实物理服务器集群全部机器虚拟ip和负载均衡服务器ip地址一致，达到不修改数据包的源地址和目标地址，进行数据分发的目的。

实际处理服务器ip和数据请求目的ip一致，不须要通过负载均衡服务器进行地址转换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。也称为直接路由模式（DR模式）。以下图：

优势：性能好；

缺点：配置复杂；

实践建议：DR模式是目前使用最普遍的一种负载均衡方式。

2.5混合型负载均衡

因为多个服务器群内硬件设备、各自的规模、提供的服务等的差别，能够考虑给每一个服务器群采用最合适的负载均衡方式，而后又在这多个服务器群间再一次负载均衡或群集起来以一个总体向外界提供服务（即把这多个服务器群当作一个新的服务器群），从而达到最佳的性能。将这种方式称之为混合型负载均衡。

此种方式有时也用于单台均衡设备的性能不能知足大量链接请求的状况下。是目前大型互联网公司，广泛使用的方式。

方式一，以下图：

以上模式适合有动静分离的场景，反向代理服务器（集群）能够起到缓存和动态请求分发的做用，当时静态资源缓存在代理服务器时，则直接返回到浏览器。若是动态页面则请求后面的应用负载均衡（应用集群）。

方式二，以下图：

以上模式，适合动态请求场景。

因混合模式，能够根据具体场景，灵活搭配各类方式，以上两种方式仅供参考。

分享是快乐的，也是我的成长的过程。文章通常是本身的学习总结，工做经验，不足之处在所不免，请你们指正，共同进步。创建了一个以架构为中心的KK群466097527 ，欢迎你们加入。专一大型分布式网站架构，大数据，架构模式，设计模式。

 

3、负载均衡算法

经常使用的负载均衡算法有，轮询，随机，最少连接，源地址散列，加权等方式；

3.1 轮询

将全部请求，依次分发到每台服务器上，适合服务器硬件同相同的场景。

优势：服务器请求数目相同；

缺点：服务器压力不同，不适合服务器配置不一样的状况；

3.2 随机

请求随机分配到各个服务器。
优势：使用简单；

缺点：不适合机器配置不一样的场景；

3.3 最少连接

将请求分配到链接数最少的服务器（目前处理请求最少的服务器）。

优势：根据服务器当前的请求处理状况，动态分配；

缺点：算法实现相对复杂，须要监控服务器请求链接数；

3.4 Hash（源地址散列）

根据IP地址进行Hash计算，获得IP地址。

优势：未来自同一IP地址的请求，同一会话期内，转发到相同的服务器；实现会话粘滞。

缺点：目标服务器宕机后，会话会丢失；

3.5 加权

在轮询，随机，最少连接，Hash’等算法的基础上，经过加权的方式，进行负载服务器分配。

优势：根据权重，调节转发服务器的请求数目；

缺点：使用相对复杂；

4、硬件负载均衡

采用硬件的方式实现负载均衡，通常是单独的负载均衡服务器，价格昂贵，通常土豪级公司能够考虑，业界领先的有两款，F5和A10。

使用硬件负载均衡，主要考虑一下几个方面：

（1）功能考虑：功能全面支持各层级的负载均衡，支持全面的负载均衡算法，支持全局负载均衡；

（2）性能考虑：通常软件负载均衡支持到5万级并发已经很困难了，硬件负载均衡能够支持

（3）稳定性：商用硬件负载均衡，通过了良好的严格的测试，从通过大规模使用，在稳定性方面高；

（4）安全防御：硬件均衡设备除具有负载均衡功能外，还具有防火墙，防DDOS攻击等安全功能；

（5）维护角度：提供良好的维护管理界面，售后服务和技术支持；

（6）土豪公司：F5 Big Ip 价格：15w~55w不等；A10 价格：55w-100w不等；

缺点

（1）价格昂贵；

（2）扩展能力差；

4.4小结

（1）通常硬件的负载均衡也要作双机高可用，所以成本会比较高。

（2）互联网公司通常使用开源软件，所以大部分应用采用软件负载均衡；部分采用硬件负载均衡。

好比某互联网公司，目前是使用几台F5作全局负载均衡，内部使用Nginx等软件负载均衡。

5、本次分享总结

 以上主要从负载均衡原理，分类，算法，硬件负载均衡进行了介绍。下次分享，负载均衡详解（三），主要介绍：软件负载均衡（LVS,Nginx，Haproxy，Apache特色，架构），负载均衡软件技术选型比较，应用负载均衡的问题和解决方案等方面。

分享是快乐的，也是我的成长的过程。文章通常是本身的学习总结，工做经验，不足之处在所不免，请你们指正，共同进步。创建了一个以架构为中心的KK群466097527 ，欢迎你们加入。专一大型分布式网站架构，大数据，架构模式，设计模式。

 

本次分享大纲

1. 软件负载均衡概述
2. Ngnix负载均衡
3. Lvs负载均衡
4. Haproxy负载均衡
5. 本次分享总结

1、软件负载均衡概述

硬件负载均衡性能优越，功能全面，可是价格昂贵，通常适合初期或者土豪级公司长期使用。所以软件负载均衡在互联网领域大量使用。经常使用的软件负载均衡软件有Nginx，Lvs，HaProxy等。本文参考大量文档，部分为直接拷贝，参考出处见负载均衡详解（4）。

2、Ngnix负载均衡

Ngnix是一款轻量级的Web服务器/反向代理服务器，工做在七层Http协议的负载均衡系统。具备高性能、高并发、低内存使用等特色。是一个轻量级的Http和反向代理服务器。Nginx使用epoll and kqueue做为开发模型。可以支持高达 50,000 个并发链接数的响应。

操做系统：Liunx，Windows（Linux、FreeBSD、Solaris、Mac OS X、AIX以及Microsoft Windows）

开发语言：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
• 支持url rewrite
• 支持路径别名
• 支持基于IP和用户名的访问控制。
• 支持传输速率限制，支持并发数限制。

2.2.2扩展功能

2.2.3性能

Nginx的高并发，官方测试支持5万并发链接。实际生产环境能到2-3万并发链接数。10000个非活跃的HTTP keep-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、rt signals、/dev/poll 、event ports、select以及poll。

支持的kqueue特性包括EV_CLEAR、EV_DISABLE、NOTE_LOWAT、EV_EOF，可用数据的数量，错误代码.

支持sendfile、sendfile64和sendfilev;文件AIO；DIRECTIO;支持Accept-filters和TCP_DEFER_ACCEP.

以上概念较多，你们自行百度或谷歌，知识领域是网络通讯（BIO,NIO,AIO）和多线程方面的知识。

2.4均衡策略

nginx的负载均衡策略能够划分为两大类：内置策略和扩展策略。内置策略包含加权轮询和ip hash，在默认状况下这两种策略会编译进nginx内核，只需在nginx配置中指明参数便可。扩展策略有不少，如fair、通用hash、consistent hash等，默认不编译进nginx内核。因为在nginx版本升级中负载均衡的代码没有本质性的变化，所以下面将以nginx1.0.15稳定版为例，从源码角度分析各个策略。

2.4.1. 加权轮询（weighted round robin）

轮询的原理很简单，首先咱们介绍一下轮询的基本流程。以下是处理一次请求的流程图：

 

图中有两点须要注意，第一，若是能够把加权轮询算法分为先深搜索和先广搜索，那么nginx采用的是先深搜索算法，即将首先将请求都分给高权重的机器，直到该机器的权值降到了比其余机器低，才开始将请求分给下一个高权重的机器；第二，当全部后端机器都down掉时，nginx会当即将全部机器的标志位清成初始状态，以免形成全部的机器都处在timeout的状态，从而致使整个前端被夯住。

2.4.2. ip hash

ip hash是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。

分享是快乐的，也是我的成长的过程。文章通常是本身的学习总结，工做经验，不足之处在所不免，请你们指正，共同进步。创建了一个以架构为中心的KK群466097527 ，欢迎你们加入。专一大型分布式网站架构，大数据，架构模式，设计模式。