阿里云负载均衡理论

目录

负载均衡概念

         总结:

CLB与ALB

负载均衡包含的模块

使用ECS的优势

负载均衡的使用场景

SLB的优势

SLB提供的功能

SLB的应用场景

---

负载均衡概念

        负载均衡(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负载均衡，用户可以访问北京的也可以访问上海的，一边挂了可以用另一边。