阿里云SLB负载均衡理论与操作

最新推荐文章于 2024-05-11 01:29:40 发布

芒地狠

最新推荐文章于 2024-05-11 01:29:40 发布

阅读量5.7k

点赞数 2

文章标签：负载均衡阿里云服务器

本文链接：https://blog.csdn.net/m0_71521555/article/details/127038493

版权

一、负载均衡概念

负载均衡(Server Load Balancer）是将访问流量根据转发策略分发到后端多台云服务器（ECS实例)的流量分发控制服务。负载均衡扩展了应用的服务能力，增强了应用的可用性。

*通过设置虚拟服务地址，将添加的同一地域的多台ECS实例虚拟成一个高性能、高可用的后端服务池，并根据转发规则，将来自客户端的请求分发给后端服务器池中的ECS实例。

*默认检查云服务器池中的ECS实例的健康状态，自动隔离异常状态的ECS实例，消除了单台ECS实例的单点故障，提高了应用的整体服务能力。此外，负载均衡还具备抗DDoS攻击的能力，增强了应用服务的防护能力。

总结:负载均衡即均衡负载，应对高访问量业务的情况且一台服务器不够用需要多台的情况，这里需要注意的是我们平常使用的虚拟机这里叫ECS主机实际上是一个概念，专业术语中的ECS实例即在ECS主机且在其中配置的服务，负载均衡还自带了高可用的功能即自动监听，消除单点故障。

二、SLB

1、CLB与ALB

阿里云SLB包含面向4层(TCP/UDP)的传统型负载均衡CLB和面向7层(HTTP/HTTPS/QuIC)的应用型负载均衡ALB。实际上只存在CLB和ALB，CLB即为传统负载均衡，可以直接理解为ALB功能比CLB好。

应用型负载均衡（ALB）和传统型负载均衡（CLB）的差异？

1. 定位不同ALB七层处理能力强，面向应用交付，CLB四层处理能力强，面向网络交付。

2. 能力不同，性能，云原生集成能力，ALB都要强于CLB。

3. 弹性不同ALB可根据业务量自动弹性伸缩，而CLB固定规格，只能按峰值配置。

具体区别如下：

2、负载均衡包含的模块

监听：用来检查客户端请求，并且将客户端请求交割后台服务器，并且也会对后台服务进行检查，即当监听部分接收到客户端的请求后将按照原来的负载均衡策略分配任务。

后端服务器：光搭建负载均衡没有服务器是没用的，那么就是说由一台服务器来配置负载均衡，一台服务器做监听，一台服务器做接受前端请求，除去监听需要两台服务器做冗余，一台服务器无论如何都是不可能做到冗余的。所以即由这三个部分组成。

3、使用ECS的优势

弹性

支持分钟级别创建1000台实例，多种弹性付费选择更贴合业务现状，同时带来弹性的扩容能力，实例与带宽均可随时升降配，云盘可扩容。

本身一台ECS服务器的升级，cpu，内存，云盘，带宽等，同时增加实例的数量也是一种弹性，实例数量增加后要被管理，在将来我们做业务的时候，客户要求的服务特别多，一台服务器肯定不够用，那么我们就可以利用ECS主机本身的特性来扩展其性能，比如额外购买cpu，内存，云盘容量，带宽够更好的主机，对服务器本身进行升级，再者可以购买多台ECS主机完成性能扩展，那么扩展出来的ECS主机共同承担业务员即由负载均衡分配任务。

总结：相比于vmware中的虚拟机，ECS主机可以灵活的横向升级或者纵向升级，更加灵活，同时服务器与服务器之间更好搭配。

3、负载均衡的使用场景

这里假设成淘宝购物的应用场景，面对如此多的业务请求的情况下这里一台ECS主机肯定是不够的，不够咱就加，咱可以先纵向加其功能给他升升级。

还不够那就横向加

这里有可用区和地域的问题，我们假设这里只针对例如湖北省范围的架构，那么现在就有三台服务器来完成各种业务，那么怎么让这三台服务器配合完成任务呢

即使用负载均衡，均衡的让多台服务器完成存在有压力的业务

流量分发：众所周知淘宝的用户非常多，很多用户都要来找我的服务器，那么一个用户即可以称之为一个流量，这些流量都会经过负载均衡，并且由负载均衡来负责流量分发，即通过轮询或者加权轮询来完成流量分发，

云监控：其实就是一个功能，他能实时监控每台主机的cpu使用率，内存使用率或者磁盘使用率，云监控自动帮你看，它可以知道当前主机情况，并且做出调整，比如说某一个服务器出现了问题，他会告诉负载均衡告诉他哪台坏了让负载均衡做出调整，负载均衡会一直查看ECS主机存活情况，一般ECS主机会不断的回应。

ip哈希：根据客户的ip地址将上一次请求继续给这台ECS，例如，你在访问淘宝的时候，打开一个卖衣服的页面，购买完毕，发现还缺一条裤子，继续访问，在这种情况下该用户的请求交给一台ECS主机最合适，一条龙服务。当用户的流量进来之后，会把客户的ip地址记载下来，并且进行哈希的计算，把计算结果保存下来之后，当该ip再次出现之后，他就会知道该ip应该继续发送给这台ECS主机，但是ip哈希是存在缺点的，当ECS主机增加或减少之后那么就会产生问题，原本经过哈希计算的结果是发送给1号主机的但是因为主机的增加或减少导致最后计算错位了，发给另一个了这是大概率会发生的，除非主机不变说几个就几个使用ip哈希是很合适的。

一致性哈希：它是一种很完善的方式，计算完哈希的值之后，会排一个很长的列，每次都去找列中匹配的值，或者匹配的值后面的ECS，所以当哈希值计算出来要去2号ECS，但这个时候2号挂了，那我就去3号ECS，但是前提是找匹配的，原来是2号的就跑去3号，原来3号的还是3号，1号的还是1号，所以不会存在ip哈希出现的问题

会话保持：例如，当你在访问淘宝的时候，你已经挑好要购买的东西了，在付钱的时候，你不能让客户再登陆一次吧，那太不合理了，那还买个啥用户体验极差，但是如果客户保持在一个页面30分钟没有进行任何活动，那就可以让用户在登录一次为了保证账号安全，这是合理的，那么在30分钟以内要保持用户的账号的保持状态，即出现了会话保持，这里延伸出了两种会话保持的技术，即cookie和session。

cookie：即服务器给用户一个通行证，举个例子即我们都会做核酸，做完核酸之后你的健康码中会出现核酸检测阴性，那么你就可以在二天内畅通无阻了，二天后核酸失效，那你也是哪都不能去了，当用户访问服务器之后，服务器就会生成一个通行证即cookie，并且把cookie发送到用户的浏览器中，以后用户在规定时间内即可畅通无阻，当然cookie也是会更新的，如果你在淘宝的页面一直在操作一直在浏览到了30分钟后服务器还会再生成一个cookie再次发送给用户的浏览器，那么用户仍然可以畅通无阻，当然cookie是由安全性隐患的，再次连想到核酸，核酸做完后的证明，如果有会p图的把时间无限延长了呢，那么就算时间到了还是可以用，这里cookie是公开的，发送到用户的浏览器中，稍微懂行的即可对cookie进行修改可以改到2999年。但是在淘宝实例中式没问题的，因为在涉及到支付的情况下还是会再次输入密码，造成不了经济上的损失，就算我在淘宝上购买记录被人看光了又如何，购买自由啊。

session：客户登录进来后，服务器就不会发送通行证了，服务器会把这条记录到自己的小本本上，并且也会和用户说一声，你是多少号用户可以连想到去饭店吃饭，当你进门一瞬间，服务员问你您贵姓？啊姓王，王先生里面请，此时服务员记录下来王先生来了坐在了50号桌子吃饭，就算你中途去洗手间，没事服务员这里记录着呢，你饭还没吃完呢，继续吃啊，session同理，服务器将此记录记在自己的小本本上面，谁都改不了，你就是说改了，也没用，我这里是最终记录。

这里又有一个概念，例如当ECS主机挂了，一个用户之前一直是2号ECS服务的，但是因为2号ECS挂了只能再分配去3号，但是3号又不认识，又要求用户重新登录，那也是不行的，所以这里就需要每台主机上的小本本都得统一。

总结：负载均衡提供了很多的功能，云监控，一致性哈希，cookie&session，它所提供的功能可以让用户得到更好的体验，确保后端服务器的安全性，高可用性，以及抗灾能力。