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

最新推荐文章于 2024-05-23 23:45:33 发布

吉吉吉吉吉吉吉吉吉吉

最新推荐文章于 2024-05-23 23:45:33 发布

阅读量2.2k

点赞数 2

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

本文链接：https://blog.csdn.net/liji133122/article/details/126957151

版权

负载均衡概念

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

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

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

总结:

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

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固定规格，只能按峰值配置。

具体区别如下：

负载均衡包含的模块

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

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

使用ECS的优势

弹性

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

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

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

负载均衡的使用场景

这里假设成淘宝购物的应用场景，面对如此多的业务请求的情况下这里一台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进行修改可以改到3022年。但是在淘宝实例中式没问题的，因为在涉及到支付的情况下还是会再次输入密码，造成不了经济上的损失，就算我在淘宝上购买记录被人看光了又如何，购买自由啊。

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

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

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

SLB的优势

阿里云slb的产品优势主要体现在：

高可用

采用全冗余设计，无单点，支持同城容灾。搭配DNS可实现跨地域容灾。

假设，总公司在北京，分公司在上海，这里是不可以将两处的服务器做一个负载均衡来轮巡的只能是在北京总公司做一个负载均衡，上海再做一个负载均衡，然后通过DNS转发，即如果你在北边则享受北京的服务，如果你在南边则享受上海的服务一边有故障还可以转到另一边，做到跨地域的容灾。

可扩展

可以根据业务的需要，随时增加或者减少后端服务器的数量，扩展应用的能力，这里有一个技术叫弹性伸缩。

低成本

与传统硬件负载均衡系统高投入相比，成本可以下降百分之60。

安全

结合云盾，可以提供5Gbps的fan给DDos攻击能力。

高并发

集群支持亿级并发连接，但实例提供千万级并发能力。

SLB提供的功能

调度算法

负载均衡支持轮询、加权轮询(WRR)、加权最小连接数(WLC)和一致性哈希(CH)调度算法。

健康检查

负载均衡会检查后端服务器的运行状况。当探测到后端服务器运行状况不佳时，会停止向其发送流量，然后将流量转发给其他正常运行的后端服务器。

会话保持

负载均衡提供会话保持功能。在会话的生命周期内，可以将同一客户端的请求转发到同一台后端服务器上。

访问控制

负载均衡支持添加黑名单和白名单,灵活控制客户端访问。

高可用

负载均衡可以将流量转发给多个可用区的后端服务器。并且，负载均衡已经在大部分地域支持了多可用区部署，当主可用区出现故障时,负载均衡可自动切换到备可用区上提供服务。

安全防护

结合云盾，可提供5Gbps的防DDoS攻击能力。

SLB的应用场景

负载均衡的应用的场景为高访问量的业务，提高应用程序的可用性和可靠性

应用于高访问量的业务

如果的应用访间量很高可以通过配置监听规则将流量分发到不同的ECS实例上。如果你的门户网站的访问量一天几百一千那其实用不着负载均衡，单单使用一台ECS主机即可，大不了增加ECS主机的性能，但是如果该门户网站一天的访问量达到几十万上百万那一台ECS主机就算性能再好也是不可能运行的了的。那么就要用到，多台服务器，协调配合完成高访问量的业务。

扩展应用程序

可以根据业务发展的需要 ,随时添加和移除ECS实例来扩展应用系统的服务能力。例如我们知道拼多多是没有pc端程序的，包括饿了吗，美团也是一样的，那么当访问量很高的时候也会用到扩展其应用程序能力的功能。

消除点点故障

可以在负载均衡的实例中添加多台ECS主机，当其中一部分ECS主机挂掉后，可以把这些请求分发给正常运行的ECS主机，不至于因为ECS主机挂掉后导致服务也跟着挂掉。

同城容灾（多可用区容灾）

和单点故障类似，可以将一个地域里面使用一个负载均衡，将负载均衡实例部署在支持多可用区的地狱以实现同城容灾，即负载均衡加支持多可用区的ECS主机。

跨地域容灾

在不同地域中部署负载均衡，负载均衡无法跨地狱，可以在例如北京和上海分别部署负载均衡，并分别使用相应地狱内不同可用区的ECS，上层利用云解析做智能DNS，即两个slb负载均衡，用户可以访问北京的也可以访问上海的，一边挂了可以用另一边。

SLB架构详细讲解

在互联网中有很多的流量，当流量非常非常多的时候，仅仅只有一台或者两台服务器的时候肯定无法承受，相对应产生的技术即为slb负载均衡，阿里云业务流量分发。

用户通过internet访问我们的服务器，如果说我们的服务器存在多台的情况下，我们就可以在互联网与服务器之间搭建一个负载均衡器，这个负载均衡器可以实现互联网上大量的流量的分发让我们的服务器可以均衡的获得用户的流量，是我们的服务器可以完成用户的访问

这里有两组slb架构第一组架构对互联网上的流量进行分发，这个架构是非常普遍的。

第二组架构在对外围服务器或者边缘服务器服务的时候也可以搭建一个slb，此处可以随意发挥随意组合

SLB应用实战

先打开阿里云官网

https://www.aliyun.com

然后进行登录

几乎所有的操作都在控制台中

创建专有网络及安全组

首先搭建一个slb的专有网络，然后再搭建一个安全组就是防火墙

点击控制台

控制台左上方有一个菜单点击菜单

接下来就可以开始创建vpc专有网络，创建专有网络是为了分割应用，就是区分搭建的不同的应用，其实可以直接理解把搭建的负载均衡看成一台服务器，给这台服务器一个IP地址

在菜单左侧就可以发现

点击按量付费，因为是在实验

选择区域，这里实际上是跟你所在的区域决定的，如果我人再南京那就选择离南京近的地区，然后选择可用区，之前在创建专有网络的时候选择的是可用区A那么这里也选择可用区A

选择筛选条件，这里cpu和内存的推荐的是一比二，即2核cpu则选择4g内存，根据当前所需要的业务能力来选择

当你拥有多台服务器并组成了内网后，就需要考虑内网宽带和内网收发包，多花钱罢了有钱就是爹，并且需要考虑是否需要ipv6功能

这里我选择了共享计算型，七毛一小时

选择使用的镜像

这里选择centos镜像，因为我们是运维人员（狗头）这里是存在鄙视链的，我们使用centos镜像的运维人员是看不起使用乌班图的大部分也是开发人员在使用，因为他有图形化界面，好操作，且对很多软件的支持很到位

选择版本

这边给到系统盘40g，这次实验呢只需要添加系统盘即可，数据盘没必要了，数据盘可以直接理解为windows中的D盘E盘F盘

如果需要增加备份功能即选择即可花钱罢了，还是那句话有钱能享受到的服务就多

开始配置网络和安全组

这里选择之前创建的专有网络

配置公网ip，我们之前学的网络也能知道网络分为内网和外网，这里如果想要让用户访问到内网那么则必须要给他配置公网ip，系统会自动分配ip

这里有两种供选择，一个是流量一个是固定带宽，流量模式是按公网出方向的实际发生的网络流量进行收费，适用于业务场景对网络带宽需求变化较大的场景，如平时带宽使用较低但间歇性的出现网络访问高峰的场景；为了防止突然爆发的流量产生较高的费用，可以指定容许的最大网络带宽进行限制。后付费模式，按使用流量（单位为GB）计费，每小时扣费，但是你的账户里得随时保持有钱，不然就g。选择固定带宽后就不需要考虑这些，则不需要考虑有多少用户来访问，即固定带宽你的用户人群稳定。

这里峰值调成最小，得加钱

配置安全组

默认把下面的端口全部打开，我这里使用的是默认的，也可以创建安全组，点击右上创建安全组

这里给安全组起名字，网络选择之前创建的专有网络，资源组默认即可

规则的话这里一般是使用默认，除非你有特殊需求，这里的授权对象是0.0.0.0缺省网段，即所有网段，这里需要注意的是在搭建一套架构的情况下是无法避免搭建数据库的，这里的规则切记不能选择mysql端口允许所有人，那不然直接下一份工作了搞不好还要吃牢饭

然后点击创建安全组即可

点击确认订单后开始配置

系统设置

首先是登录凭证，这里可以选择密钥对方式和自定义密码设置是针对ECS主机的，当然可以创建密钥对，密钥对生成后只能下载一次，没保存或者忘了，那么直接就gg了

这里我选用自定义密码

按照要求的来设置完成后，实例名称可写可不写，其含义其实就是ecs主机能让用户看到的名称，如果有多台主机的话他会自动安排后缀名，即001，002以此类推。

最后一部分即分组设置，这里无需管他，不重要点点的事情。最后确认订单，最后配置结果如下：

点击管理控制台即可看到购买的ECS主机

当我们有了ECS主机后就可以创建SLB实例了通过SLB实例将两台ECS主机添加进去就可以实现两台主机的负载均衡

点击远程连接

点击左上角立即登录，输入密码

在这里需要创建一个测试页面则之间安装阿帕奇即可

在这里我遇到了一个问题，我把此内容加进网页后，死活访问不了，防火墙关了，curl本地网站也能正常，权限chmod 777 index.html也做了，出来的结果都是403，这里出现的问题是在安全组那边，因为我使用的是默认安全组，没有允许其他用户访问80端口即http，所以死活都是403

解决方法：

直接点击主机点击安全组

点击配置规则

点击手动添加

将80端口加入即可

最后问题解决

在另一台主机也安装http服务

创建slb的实例并完成slb于ECS的对接

点击左上角菜单找到负载均衡

这里有三种负载均衡分别为ALB,NLB,CLB

ALB

工作在 proxy 模式的七层负载均衡，主要面向基于 HTTP 和 HTTPS 的 WEB 应用程序，其在请求级别运行，可以为应用层业务提供更加出色的服务。

NLB

有状态四层负载均衡，专注于提供四层有状态负载均衡服务，主要面向基于 TCP 的四层有状态业务，可提供高性能、低延时、会话保持等四层应用服务能力。

这里我们选择传统负载均衡

选择按量付费

选择地区，还是离那里近选择哪里

选择按量计费

点击立即购买

点击点我开始配置

选择http

监听端口填80

这里可以添加访问控制策略

点击创建访问孔子之策略组

按照上方提示添加即可

非常简单不需要配监听

添加SLB后端服务器

点击默认服务器组

勾选两个ECS主机

权重越小得到的业务流量就越少，根据需求来配置即可

这里的健康检查的意思即在你后端的服务器在使用过程中g了一台，那么这个健康检查就会自动把g了的服务器踢出slb确保用户访问的网页都是正确的。

提交即可

配置完成

访问验证

这边有一个slb的公网IP地址，用我们浏览器来访问这个网址，设置的两个网页是不同内容，所以可以展现实验结果

数据流向是用户到负载均衡器到内网

第一次

第二次

第三次

第四次

ESS概念

弹性伸缩ESS—根据用户的业务需求和策略，经济地自动调整弹性计算资源的管理服务。

特点

1.可以监控集群，随时自动替换不健康的实力，节省运维成本。

2.可以管理集群，在高峰期自动增加ECS实例，在业务回落时自动减少ECS实例，节省基础设施成本。

3.与SLB/RDS紧密集成，自动管理SLB后端服务器和RDS白名单，节省操作成本。——>随需应变，自动化，伸缩模式丰富、智能。

ESS使用场景

弹性扩张

当业务升级时,弹性伸缩为自动完成资源升级,避免访问延时和资源超负荷运行。

弹性收缩

当业务需求下降时,弹性伸缩为自动完成底层资原样政,避免资源浪费。

弹性自愈

弹性伸缩提供健康检查功能,自动监控伸缩组内的ECS实例的健康状态,避免伸缩组内健康ECS实例低于设置的最小值。

ESS的工作流程

创建伸缩组，伸缩配置，伸缩规则，伸缩触发任务，系统会自动执行以下流程。

在这里就出现了一个名词伸缩活动

伸缩活动的状态

拒绝伸缩活动在请求阶段被拒绝，未执行扩张或收缩动作。

场景①

伸缩组的伸缩最大实例数为100

伸缩组内已有100台ECS实例

伸缩规则要求自动创建10台ECS实例

结果：伸缩活动未通过条件检验，被拒绝执行，无后续流程。伸缩活动结束后，伸缩组内实例数仍然为100。

执行中伸缩活动通过条件检验，正在执行中。

弹性伸缩会根据伸缩最大实例数和伸缩最小实例数，自动调整需要扩张或收缩的ECS实例数量。

场景②

伸缩组的伸缩最大实例数为100

伸缩组内已有95台ECS实例

伸缩规则要求自动创建10台ECS实例

结果：伸缩活动通过条件检验，可以执行，但自动创建的ECS实例数量会调整为5台。伸缩活动结束后，伸缩组内实例数变为100。

成功伸缩活动执行完成，所有目标ECS实例加入或移出了伸缩组。

场景③

伸缩组的伸缩最大实例数为100

伸缩组内已有90台ECS实例

伸缩规则要求自动创建10台ECS实例

结果：伸缩活动通过条件检验，可以执行。伸缩活动结束后，伸缩组内实例数变为100。

警告伸缩活动执行完成，至少有一台目标ECS实例加入或移出了伸缩组，且至少有一台目标ECS实例未能加入或移出伸缩组。成功加入伸缩组表明ECS实例的创建、加入SLB实例后端服务器组、加入RDS访问白名单三个步骤都成功，任一步骤失败即认为该ECS实例加入伸缩组失败。ECS实例加入伸缩组失败时会触发回滚，详细信息请参见ECS实例回滚。