开发者学堂课程【高校精品课-华东师范大学 - Python 数据科学基础与实践：阿里云云计算 ACP 认证（4）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1006/detail/15119
阿里云云计算 ACP 认证（4）
内容介绍：
一、负载均衡 SLB
二、弹性伸缩 AS
一、负载均衡 SLB
从背景来讲，负载均衡主要是为了解决访问量跟数据流量增长之后，单一的服务器无法承受大量的访问跟数据流量。随着业务的发展，接触的业务越来越多，单一的服务器无法承载。而通过升级服务器的硬件，这种传统的做法会带来一些问题：成本增加，资源不够分配等等。在传统的环境下生配往往会是顶格需求买单，我们的资源在很多时候可能都是沉睡的，因为业务并不是24小时跑满的。
并且单一服务器的扩展性不具备特性，这时候就有一种想法产生：是否可以化整为零？将一台服务器的任务分配到多台低级服务器上进行处理，将结果再返回到客户端，这时就实现了化整为零。
在此背景下，为了让左边的用户访问使用不需要记住 ip 地址，因为一般通过域名的方式。这时候产生负载平衡的设备，用户将域名输入到负载平衡的设备，负载平衡提供虚拟 ip ，将域名发送给客户端进行处理。
所谓的负载平衡即将工作任务均衡分摊，或者通过某种策略调度到后端的多个业务单元进行执行的设备，属于网络优化的硬件设备。在基本不改变网络基础架构上，提供有效的方案来提升设备接入的能力，使得带宽，吞吐量，数据的处理能力都得到提升。并且该架构提现了一定的灵活性和可用性，所谓的灵活性是指这时加节点或者减节点并不会像升配一样升上去，用不上也降不回来，在这样的架构下相对低配。增减节点被负载平衡屏蔽掉，用户不了解到底有多少台机器对自己进行服务。流量都是到达负载平衡，由负载平衡调度的。在这种情况下，少到一台机器多到 n 台机器，其实对于用户来说，其感受都是一样的。
我们只要有好的检查，故障定位的机制，系统的平均负载低移除节点或者说将故障节点移除，比较容易控制后端服务器的经济成本并且对于用户的体验不会有太大的影响。所以负载平衡的这种思想并不是新型的，从出现到现在已经出现了近40多年时间。从早期的硬件设备到早期的负载平衡的技术，再到现在的大量云上服务提供都是秉承这种思想。
SLB 作为阿里云负载均衡的产品或者可以说一系列产品， SLB 作为负载平衡的家族，其本身的定位是什么呢？是阿里云的结合自身弹性计算机的特点跟自己的优势提供的一套软件负载平衡的解决方案，来更好的帮助弹性计算平台负载平衡的需求，其本质上是把流量按需分发的这样的一种服务。
把流量分摊到后端各种不同的服务器来进行处理，以此来扩展业务系统的吞吐能力。同时后端超过一台服务器的服务即有两台或者多台来提供服务，就叫做这样的架构消除了单点故障，提升了应用系统的可用性，这就是阿里云 SLB 产品家族的定位。发展到现在阿里云已经不再是早期的传统负载平衡的形态，现在的 SLB 包含两大类的负载平衡的实现。具体介绍如下图：
现在的 SLB 分为两大类，原来的 SLB 即更名为传统的 CLB ，新增加的用来处理七层业务的应用型负载均衡 ALB ，两者的区别和特点在这里均列举出来。传统的 SLB 主要是处理的面向四层的负载平衡的处理能力，支持 TCP/UDP/HTTP/HTTPS 等等协议，主要是面向传输层交付负载平衡能力。
如果有用过早期的 SLB 的同学，其实是知道其具有七层处理能力的，比如说这里说到的 HTTP 实际上是一个七层的协议，事实上其也是具有基础的七层能处理能力。现在七层的进阶的能力，基本上都集中在 ALB 的形态。产品性能来讲，传统负载平衡是基于物理架构，那么单实力可以到达500w的 QBS ，应用型的负载平衡可以理解为主要是工作在云原生的基础之上，是虚拟化的设备。单实力可以支撑到100w 的 QBS ，这里所提到的实力是虚拟的实力，单实力是物理机上的实力，在 CLB 打满500w 的要求，你需要将一台物理服务器， SBL 物理服务器性能打满，这个地方的服务器实际上是一个虚拟化的实力，其两者之间并不是在一个维度上进行比较的。从业务的可用性来讲， CLB 是99.5的可用性，而 ALB 是99,。995的可用性的承诺。
运维方式，其传统的 CLB 是按照规格进行售卖的，比如说：小规格，中规格，大规格，其后面会附有 QBS 的参考值可自行选择，需要去购置其峰值带宽。应用型负载平衡自动弹缩，应用型带宽自动进行匹配的。所以其事实上， ALB 是官方的 ingress 的网关。就是云原生的七层负载， ingress 的网关直接采用 ALB ，所以其天然可以跟 k8s 结合，支持流量的拆分，镜像，灰度发布，蓝绿测试等等，像这样的一些能力。那么传统的 SLB 是需要跟阿里云的云器服务 ACK/ASK 容器服务结合使用，所以两者之间既有服务又有联系。尽管底层架构采用的是一样的类似的，均是在 LVS+TN 架构基础之上去进行进一步的扩展跟延伸的。
因为各自承担的目标使命不同。所以产生的形态，各自的性能，表现是形式有所不同。各自的应用场景也是具有区别的， CLB 其实更偏向于传统场景下的负载平衡的业务场景到云上很自然的想到通过 CLB 来实现。比如说以前云下通过 F5 这样的负载平衡的设备做一些架构，到云上来很自然的想到用 CLB F5 来进行等价的替换。用 ECS 跟原来的服务器，刀片机做一个等地位的替换。传统的业务上云可以找到替代品， ALB 是更时髦的更新潮的以云原生的基础架构。可以更好的跟容器云进行无缝的对接，提供了一些七层服务处理的更高级的处理技能，一些处理的能力，比如说高级路由，或者 HGP 这种报文的报头，或者说 kukei 里面的一些字段进行一些转发重写，重新定向等等。像这些能力是传统的 CLB 不具备的， ALB 这种应用型的负载平衡才具有。
接下来的讨论不区分 SLB 和 ALB ，底层的东西大部分比较相近，包括一些流量调度，算法，会话保持，健康检查等等，像这样的一些特性，尽管功能上有些区别，但是其本质上承担的意义跟目的是一样的。所以在此时对其功能进行一个讨论，目前来看四层跟七层负载平衡的幅度，四层是 TCP/UDP，七层的是 HTTP/HTTPS ，当然像websocket ，ws 跟 wss 的协议本身必然也是支持的，其本身就是基于七层协议的扩展。
从调度算法来看，比较常见的有这几类，一类是轮询的调度算法，所谓的轮询即我的请求达到负载平衡的设备，后端也就是 backendServer 所了解的一个负载平衡设备实力，它的构成比较简单。即对方本身有负载平衡的实力，应该会对应 cip ，如果是 ALB 可能会更复杂一些，其本质上差不多。需要创造一个监听，某个端口或者某个访问的地址的前缀所对应的访问的前缀。
