我是怎么想起来学负载均衡的

第一次接触负载均衡，是从章文嵩博士那个著名的lvs开始的——时间大概应该在2005年以前吧。那时我还是一个linux的菜鸟，差不多就会一些软件安装（定制安装都不会）、基本指令而已。也不知道当时是出于什么样的一种想法，就打算实验一把负载均衡。要知道，那些年虚拟化技术还不普及（也许我不知道），要实现负载均衡得准备好几个物理机器。按照章博士文档介绍，我计划使用三台电脑，一台做负载均衡器，另外两台做后端真实提供服务的物理机，并在上边安装最基本的apache服务。

问题来了！当时我工作的场景根本没这个条件。怎么办呢？只能找人一起做实验。我当时有一个台式机，很幸运联系到一个周姓兄弟，他在一家公司做sap技术支持，也对负载均衡技术感兴趣。他那公司周末没人上班，还有两台闲置的台式机。于是我抱着自己的那台主机，到他那公司去做实验——条件是做成功了要告诉他这个实验的关键点。

实验过程很粗糙：后端两个台式机安装apache，前端安装lvs，没有写什么配置文件，直接在命令行用ipvsadm指令敲了几行而已。用浏览器访问负载均衡器ip，能得到apache的默认页面；断掉一个后端服务器，刷新浏览器，还是能访问到apache的默认页面，但偶尔会出现访问不到页面的情形——没有健康检查功能。

虽然现在看起来很low，但当时确实很兴奋，毕竟做成功了。

解释一下负载均衡架构吧

虽然简陋，但那个实验其实已经体现了负载均衡的基本架构。

不论硬件负载均衡，还是软件负载均衡，其基本架构都是两层：前端接受用户请求，并转发请求到后端真正提供服务的系统；后端真实服务器把数据或者请求返还给负载均衡器或者直接返还给真正的请求者（用户）。下图为直接路由模式（DR）架构图，出自章文嵩博士官方网站http://www.linuxvirtualserver.org/VS-DRouting.html 。

负载均衡对用户请求大致提供两种类型的返还方式：直接返还和集中返还。
◎直接返还：负载均衡器充当中介媒介，保持一个三方基本的联系，后端服务提供方直接把数据或者信息发送给用户。由于数据流不通过负载均衡器，这种方式可获得最大的性能或数据吞吐量。数据流向查看上图，为直接路由（DR）模式，隧道模式（TUNNEL）也属于这种模式，由于应用得少，不再赘述。
◎集中返还：与直接返还不同，数据的进出都要经过负载均衡器。使用这种模式的有NAT（网络地址转换）及反向代理等几种情形。

两种模式对比

名称 直接返还 集中返还
性能 最优 一般
网络依赖 高 低
可维护性 高 低
说明：
◆数据流进出都通过负载均衡器很显然比不通过的性能低
◆直接返还模式对网络依赖高，如vip，负载均衡本身ip，后端服务器ip都要在同一个网段；而集中返还模式则不依赖于本地网络，甚至可以跨运营商。
◆直接返还（直接路由模式）vip需要在后端真实提供服务的系统上设置于网络接口，增加了维护成本。

如何理解负载均衡的功能？

个人认为，“负载均衡”不是终极目标，终极目标应该是高可用、可扩展。虽然高可用与负载均衡二者之间不能划等号，但负载均衡一定是实现高可用的一种基本手段。我们不能单纯从字面上来理解这个负载均衡，而忽略了其它两项功能。总结起来，负载均衡实际是三个基本项的组合：负载均衡（Load Balance）、健康检查（Check Health）、失败切换（Failover），少了任意一项，皆不足以构成高可用系统。

◎负载均衡（Load Balance）：负责把众多用户的请求，按某种指定的方式分配到后端各个真实提供服务的系统上，后端服务提供者把数据返还给请求者用户。负载均衡最直接的目标是增加系统的容量，属于横向扩展，比直接在单系统增加资源（内存、cpu等）要有效得多。

◎健康检查（Check Health）：负载均衡器根据设定，探测后端真实服务器提供者提供的服务或者业务是否处于正常状态。如果正常，则把一定的用户请求转发过来，否则就从转发队列中踢掉此服务提供者，而把请求转交给其它正常的服务提供者。一旦后端服务提供者故障得以恢复，负载均衡器能自动将其加入转发队列，继续向该节点提供转发请求。

◎失败切换（Failover）：失败切换是在两个负载均衡器之间进行的，在正常情况下，负载均衡器是成对出现，一主一备的角色。主负载故障或者不可用时，备用负载均衡自动接替主负载均衡的工作—监控检查及负载均衡。一旦主负载均衡器从故障中得以恢复，备用负载均衡器将自动把所有权移交过来，甘当配角。

再强调一下，负载均衡是健康检查、负载均衡（这两项在同一个系统内）及失败切换（在两个独立系统之间）组合而成。单负载均衡（云服务商不公开提供havip，估计是希望用户购买它的负载均衡服务吧），可以实现健康检查及负载均衡能力，也不需要设定vip，虽然存在单点，但总比没有强吧。

让用户无感知地可扩展是负载均衡的重要价值！

负载均衡架构完全可以根据业务需求，动态的增加或者缩减后端真实服务提供者的数量，这种操作基本做到用户无感知。大致操作方法如下：
（1） 备用负载均衡器（BACKUP）上进行设置--增加或删除对象；
（2） 人工停止主负载均衡器（MASTER），备用负载均衡器会自动充当主负载均衡器的角色，启动负载均衡与健康检查功能。如果发现有问题，可立即启动未做任何修改任何的主负载均衡器；
（3） 修改主负载均衡器，并启动之。

完成负载均衡必须跨越三个坑

负载均衡有三个必备条件

1、 一对负载均衡器。可以是物理服务器/商用负载均衡设备（F5、Netscaler一大波厂商），也可以是虚拟系统。若使用虚拟系统，求你别在同一个物理设备上虚拟出的两个系统上部署负载均衡！负载均衡为用户提供服务是通过vip进行的，这个ip地址不被手工设置到系统的网络接口上。当然，为了支持提供更多的服务、提高资料利用率，可在负载均衡器上配置多个vip——有人可能会问，最多能配多少？其实我也不知道，我也不打算配很多。

2、 多于两个独立的后端服务提供者系统（有些人称真实服务器RealServer）。根据经验，最好是3个及以上。如果为了省钱，只搞两个，一旦死掉一个，所有用户用户额的服务都打到活着的那个后端服务提供者上边，很可能这个独苗不堪负重给也给打死了，连个喘息的机会都没有。与负载均衡器类似，如果后端服务提供者使用虚拟系统的话，这些虚拟系统最好分布到不同的物理设施上。

3、 资源配置尽量一致。两个负载均衡器资源配置尽量一致，后端多个真实服务提供者资源资源配置也尽量一致。如果资源配置相差大，维护成本因此增加，这是因为作为技术人员的你，不得不去维护一个资源表及权重分配表。

哪里需要负载均衡？

有高可用、可扩展要求的业务场景，是首先考虑的因素，而不是访问量本身。在跟人讨论方案的时候，往往有人会强调：“现在没有那么多的访问用户，因此暂时不需要考虑高可用性”。我只能质问：“你的系统停止服务，你能忍受多久；由此引起的损失，是否能负担得起”？当然，也不是所有的业务/系统都要放在负载均衡体系内，这样既浪费资源又可能增加成本，也可能没有效率。

具体一点来说，重要的业务（一旦停止可能造成经济损失或者糟糕的社会影响）在设计阶段，就应当考虑高可用、可扩展性。而一些不太重要的、或者耗费大量资源的（比如大量图片、视频等），可通过缓存等技术方式来提高性能，再辅助以备份，基本无忧。假定有数TB容量的图片，如果用负载均衡来实现，这样不但成本高（数台同样容量的设备或者系统）、而且极度浪费资源。

十来年的职业生涯中，负载均衡用得最多的地方是web集群，然后有一些静态对象缓存以及mysql多个从库采用负载均衡，还有对自行开发的tcp服务做负载。静态对象缓存的负载均衡，与web一类需要登录的服务有个差异，就是不用考虑会话保持。这个怎么理解呢？比如一张图片，a用户第一次可能从A服务器取得，刷新一下浏览器，又可以从B服务器取得。相反，如果是需要登录的业务，a用户打开网站，从A服务器取得页面，接着填写用户名和密码，然后点“登录”，如果负载均衡把它转发给B服务器的话，这个登录一直无法成功了。

干货：负载均衡怎么分类

有很多维度的分类方法，这里列举一些以供参考。

◎按设施可分为硬件负载和软件负载。
（1）硬件负载均衡通常封装成一个盒子，以商业产品对外出售，成本包括硬件、品牌及附加的服务。购买盒子，相对来说比较省事，稳定性也有保障，还有售后保障。也有缺点，比如成本高，灵活性差，维修周期长。特别有感受的是，一次要更换F5的内存，一个条子好几千；另外一次，某个Netscaler坏掉了，只剩下一个在顶着所有的流量，代理商还要先提供日志，再转交给厂商分析，也不清楚多久能更换或者维修，除了等待和催促，真的只有靠运气—另外一台不要再出篓子。
（2）软件负载均衡用得多得是开源方案。用一对配置低的服务器，部署上lvs等软件以后即可提供服务。自己部署不但成本低，而且灵活性高。假定某个负载均衡出故障，可立即找一台空闲的机器，装上软件做好配置，立马就可以恢复高可用，周期远比向服务器采购或者等待更换设备时间短。同时，要扩充新的业务，新增新的负载均衡，也是很快就能部署上去，成本也远低于商业盒子。当然缺点是对技术人员要求高，什么都得自己搞定，也没任何厂商支持你。

◎按TCP/IP层级分传输层与应用层负载均衡。
（1）网络层负载均衡即通常所说的四层负载均衡，根据ip地址加端口号进行识别和处理。个人认为互联网遵照的是TCP/IP协议，简化成4层了，因此是不是叫传输层负载均衡更合适呢？
（2）应用层负载均衡即通常说的七层负载均衡，可根据具体的应用，如url识别和转发请求。

◎其它分类。
按应用类型分web负载均衡、数据库负载均衡、其它应用程序负均衡。
按网络协议主要TCP负载均衡与UDP负载均衡。
按范围分全局负载均衡与局部负载均衡。

关于专栏

由于要求环境比较高，普通运维人员很难有机会接触和系统学习负载均衡的系统知识和实际操作技巧，所以可以说负载均衡的技术水平也是衡量初级和中级以上运维技术水平的重要标尺。

老田同学依托自己十余年的IT运维经验，以实际工作经验为基础，介绍不同场景下，负载均衡的实现方式，以及负载均衡的日常维护。

专栏按传统的三部曲划分。主要以实际工作经验为基础，介绍不同场景下，负载均衡的实现方式，以及负载均衡的日常维护。

在第一部分，我们讲述基础概念。主要围绕三个基本功能进行描述，以及最初为实现负载均衡所做的一些有趣的事情
1.基本机制及类型介绍
2.负载均衡的规划

从第二部分开始，你将会了解更多实践内容。
1.部署keepalived
2.部署 haproxy
3.部署nginx
4.部署lvs
5.web类负载均衡
6.mysql数据库负载均衡
7.非会话保持类负载均衡
8.虚拟化场景的负载均衡实现
9.负载均衡的性能及安全
10.oracle集群--另类负载均衡

系统24小时运行以便于随时对用户提供服务，我们不可能一直盯在屏幕上，也不可能等发生故障后用户或者老板来电话通知。因此需要合理的设置监控策略，来充当不休息的眼睛，当发生异常时，有效地报告问题所在，便于快速进行判断和业务恢复。

在第三部分中，我们将会超越常规的做法。回顾专栏中的内容，并介绍一些相关的主题，比如安全、规划和操作系统中的性能提升。
1.监控负载均衡
2.日常维护
3.规模化
4.常见问题汇总

本课程适合于一直徘徊在运维初级未找到入佳境之门的运维工程师，也适合对负载均衡有兴趣了解和学习的技术爱好者。跟着老田学完这个系列课程，不仅学知识，更是涨薪、升职、进心仪公司的一大捷径！

老田的啰嗦：由搬主机到别人办公室做实验所想到的

“老田的啰嗦”内容与技术内容无关，没兴趣的可以无视。

卢姓同事老婆的同学，长相普通，学历也不高。在中关村电脑城一带找工作，面试了好多次都没有成功。那阵子天气又热，中关村还在搞建设，遍地都是尘土，处处碰壁加上这种恶劣环境，换做我也受不了。一次，一个小公司的老板委婉地拒绝她：“你看，我们这里都没电脑，你来的话，拿什么办公呢”?这女人应承了一句：“我知道了”。第二天一早，她背着主机箱和显示器，直接到那个公司找老板，说自己带了电脑，不需要公司给配备。要知道那时的显示器是CRT（Cathode Ray Tube），好大一坨呢。与之相比较，我搬个主机箱到别人办公室做实验，根本算不了啥。