早期的互联网应用，由于用户流量比较小，业务逻辑也比较简单，往往一个单服务器就能满足负载需求。随着现在互联网的流量越来越大，稍微好一点的系统，访问量就非常大了，并且系统功能也越来越复杂，那么单台服务器就算将性能优化得再好，也不能支撑这么大用户量的访问压力了，这个时候就需要使用多台机器，设计高性能的集群来应对。
那么，多台服务器是如何去均衡流量、如何组成高性能的集群的呢？
此时就需要请出 「负载均衡器」 入场了。
负载均衡（Load Balancer）是指把用户访问的流量，通过「负载均衡器」，根据某种转发的策略，均匀的分发到后端多台服务器上，后端的服务器可以独立的响应和处理请求，从而实现分散负载的效果。负载均衡技术提高了系统的服务能力，增强了应用的可用性。
目前市面上最常见的负载均衡技术方案主要有三种：
基于DNS负载均衡
基于硬件负载均衡
基于软件负载均衡
三种方案各有优劣，DNS负载均衡可以实现在地域上的流量均衡，硬件负载均衡主要用于大型服务器集群中的负载需求，而软件负载均衡大多是基于机器层面的流量均衡。在实际场景中，这三种是可以组合在一起使用。下面来详细讲讲：
基于DNS负载均衡
基于DNS来做负载均衡其实是一种最简单的实现方案，通过在DNS服务器上做一个简单配置即可。
其原理就是当用户访问域名的时候，会先向DNS服务器去解析域名对应的IP地址，这个时候我们可以让DNS服务器根据不同地理位置的用户返回不同的IP。比如南方的用户就返回我们在广州业务服务器的IP，北方的用户来访问的话，我就返回北京业务服务器所在的IP。
在这个模式下，用户就相当于实现了按照「就近原则」将请求分流了，既减轻了单个集群的负载压力，也提升了用户的访问速度。
使用DNS做负载均衡的方案，天然的优势就是配置简单，实现成本非常低，无需额外的开发和维护工作。
但是也有一个明显的缺点是：当配置修改后，生效不及时。这个是由于DNS的特性导致的，DNS一般会有多级缓存，所以当我们修改了DNS配置之后，由于缓存的原因，会导致IP变更不及时，从而影响负载均衡的效果。
另外，使用DNS做负载均衡的话，大多是基于地域或者干脆直接做IP轮询，没有更高级的路由策略，所以这也是DNS方案的局限所在。
基于硬件负载均衡
硬件的负载均衡那就比较牛逼了，比如大名鼎鼎的 F5 Network Big-IP，也就是我们常说的 F5，它是一个网络设备，你可以简单的理解成类似于网络交换机的东西，完全通过硬件来抗压力，性能是非常的好，每秒能处理的请求数达到百万级，即 几百万/秒 的负载，当然价格也就非常非常贵了，十几万到上百万人民币都有。
因为这类设备一般用在大型互联网公司的流量入口最前端，以及政府、国企等不缺钱企业会去使用。一般的中小公司是不舍得用的。
采用 F5 这类硬件做负载均衡的话，主要就是省心省事，买一台就搞定，性能强大，一般的业务不在话下。而且在负载均衡的算法方面还支持很多灵活的策略，同时还具有一些防火墙等安全功能。但是缺点也很明显，一个字：贵。
基于软件负载均衡
软件负载均衡是指使用软件的方式来分发和均衡流量。软件负载均衡，分为7层协议 和 4层协议。
网络协议有七层，基于第四层传输层来做流量分发的方案称为4层负载均衡，例如 LVS，而基于第七层应用层来做流量分发的称为7层负载均衡，例如 Nginx。这两种在性能和灵活性上是有些区别的。
基于4层的负载均衡性能要高一些，一般能达到 几十万/秒 的处理量，而基于7层的负载均衡处理量一般只在 几万/秒 。
基于软件的负载均衡的特点也很明显，便宜。在正常的服务器上部署即可，无需额外采购，就是投入一点技术去优化优化即可，因此这种方式是互联网公司中用得最多的一种方式。
上面讲完了常见的负载均衡技术方案，那么接下来咱们看一下，在实际方案应用中，一般可以使用哪些均衡算法？
轮询策略
负载度策略
响应策略
哈希策略
下面来分别介绍一下这几种均衡算法/策略的特点：
NO.1—— Random 随机
这是最简单的一种，使用随机数来决定转发到哪台机器上。
优点：简单使用，不需要额外的配置和算法。
缺点：随机数的特点是在数据量大到一定量时才能保证均衡，所以如果请求量有限的话，可能会达不到均衡负载的要求。
NO.2—— Round Robin 轮询
这个也很简单，请求到达后，依次转发，不偏不向。每个服务器的请求数量很平均。
缺点：当集群中服务器硬件配置不同、性能差别大时，无法区别对待。引出下面的算法。
NO.3—— Weighted Round Robin 加权轮询
这种算法的出现就是为了解决简单轮询策略中的不足。在实际项目中，经常会遇到这样的情况。
比如有5台机器，两台新买入的性能等各方面都特别好，剩下三台老古董。这时候我们设置一个权重，让新机器接收更多的请求。物尽其用、能者多劳嘛！
这种情况下，“均衡“就比较相对了，也没必要做到百分百的平均。
NO.4—— Least Connections 最少连接
这是最符合负载均衡算法的一个。需要记录每个应用服务器正在处理的连接数，然后将新来的请求转发到最少的那台上。
NO.5—— Source Hashing 源地址散列
根据请求的来源ip进行hash计算，然后对应到一个服务器上。之后所有来自这个ip的请求都由同一台服务器处理。
https://www.cnblogs.com/saixing/p/6730201.html
https://blog.51cto.com/13732225/2175804
负载均衡构建在原有网络结构之上，它提供了一种透明且廉价有效的方法扩展服务器和网络设备的带宽、加强网络数据处理能力、增加吞吐量、提高网络的可用性和灵活性。
拥有大量用户的企业，经常会面临如下的难题：在高并发的情况下，经常会导致服务器响应速度慢，严重的情况会直接导致服务器停止服务。此时，会导致企业的业务中断，影响客户的正常访问。
负载均衡应运而生
<u>需求：本次实验最低需求两台云服务器ECS</u>
上图创建了两台云服务器ECS实例和一个负载均衡实例，它们各自拥有各自的弹性IP地址
在浏览器两个页面分别输入两台云服务器ECS的弹性IP访问
比较两台ECS的访问结果，发现部署的网站内容相同，只是显示的后端服务器IP不同。
在阿里云登陆界面选择用RAM用户登录
使用实验提供的 子用户名称 和 子用户名密码 登陆阿里云管理控制台
<img src="https://upload-images.jianshu.io/upload_images/20425542-fa1a73a6dc138f09.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" alt="4.登陆.png" style="zoom:50%" />
<img src="https://upload-images.jianshu.io/upload_images/20425542-4d17f4b440d7c9a5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" alt="5.登陆.png" style="zoom:50%" />
登录后点击左侧 导航栏的 产品与服务 选择 负载均衡
<img src="https://upload-images.jianshu.io/upload_images/20425542-3bad79d4ddfed80d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" alt="6.png" style="zoom: 67%" />
a. 在控制台点击左侧 实例管理 ，在右侧页面中的红框处看到负载均衡的 公网服务地址
该公网服务地址即为负载均衡实例的弹性IP地址
b.在浏览器上输入a的公网服务地址并访问
可见后端服务器IP尾数为131（ECS-2)，但当我们刷新一遍后，如下图
后端服务器IP尾数变为130(第二台ECS-1)
当我们不停的刷新，会发现后端服务器IP 实在这两台ECS的 内外地址 之间轮流转换
因为我们在第二步配置的两台ECS的权重是相同的
下一步我们试着改变两台ECS的权重不相同看看效果如何
a.进入控制台--选择负载均衡--实例管理--点击进入实例--默认服务器组，进入如下图所示
b.勾选两台服务器--点击修改权重
c.设置权重 30，90，效果如下图
d.在浏览器中，刷新多次 负载均衡服务地址 的页面，统计页面的 后端服务器IP 。
可以发现：每 4 次刷新，将有 3 次访问 权重 为 90 的 ECS实例， 1 次访问权重为 30 的 ECS实例。
用户可以根据实际情况调整负载均衡器的请求分发，一般将 配置高的服务器设置的权重调高 ， 配置较低的服务器设置的权重调低 。这样可以避免在高并发时，配置较低的服务器因为压力较大服务异常的发生。
a.实例管理界面---监听---修改监听配置
b.点击修改
c.开启会话保持、可选择修改会话保持超时时间
d.依次点击下一步，不修改
e. 再次在浏览器中输入 负载均衡 的 IP地址 ， 多次刷新 ，发现在会话保持的超时时间内请求 只会分发到某一台 ECS 上（究竟是哪一台 ECS 没有规定），时间超出后，重新按照权重比例分发。
a.进入实例
b.点击停止
<img src="https://upload-images.jianshu.io/upload_images/20425542-e7d5f08534cd1938.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" alt="28.png" style="zoom:67%" />
c.返回，显示如下图所示，ECS-2已关闭
d.在监听页面和实例管理页面，健康状态显示异常
e. 再次刷新浏览器中 负载均衡 的 IP地址 ，此时，请求发送到 健康检查状态 为 正常 的ECS-1上。
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）