开发者学堂课程【高校精品课-华东师范大学 - Python 数据科学基础与实践：阿里云云计算 ACP 认证（4）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1006/detail/15119
阿里云云计算 ACP 认证（4）
比如 SLB ，与 ingress 对应，监听需要定义协议，端口，以及我们需要的对象，对象就是转给后端的服务器，这里叫做 backendServer 。
这里涉及到几个问题：转发给后端的服务器，采用什么样的方式去转发？这就产生了调度算法的问题，用什么样的方式去转发？后端的服务器损坏该怎么办？我要怎么去发现它？比如说SLB 有这样的能力即后端服务器损坏之后，及时将其从集群当中摘除掉，因为还有其他服务器提供服务，所以业务并不会因此断掉。接受到告警后及时处理这台机器，当这台机器坏了及时摘除掉，不会将请求转移到这里来，这样用户就不会报错，这称之为健康巡查的发现。当我们处理完这台机器，它又自动的恢复正常了，又将其重新加入到集群，这是健康检查的自愈机制。
涉及到设计一个负载平衡的产品，需要考虑功能与方方面面都很多。回到之前的调度算法问题，一种是轮询模式，即大家轮着来，比如说现在有一个请求达到 SOB ，根据请求顺序，给到第一台 ECS，第二个请求给到第二台 ECS，第三个请求给到第三台 ECS ，人人有份，永不落空。
接着就是4,5,6,7,8,9这个顺序。最小连接数是另外一种模式，每一次遵循都会检查后端的 ECS ，当前的哪台 ECS 链接数是最少的就直接转入。
假设现在有一个请求运行过来了，右边的 ECS 是三个链接，所以它的连接数是最少的，第一个请求会来到这里，第二个请求会来到会在3和4之间的任意位置，当到达5的位置又会去到最小的连接位置。以此类推，到了数字5选五号连接，按这个顺序过来。还有一种方式是加权轮询的方式，人为的在后台对 ECS 做一些权重的设置，因为系统的 ECS 并不知道自己要处理多少业务，后端的 ECS 性能，存在的地位，可能是不一样的。所以我们人为的在后端 ECS 打一些标记，设置一些权重。
那么 SLB 会将请求按照权重进行转发，比如说：图中的 20,30,50 表示后端的请求有 50/（20+30+50）刚好是50%的流量会转给50位点处理，30%的流量会转给30位点处理，20%的流量会转给20位点处理。这是比较常见的调度模式，第一种和第三种方法在 k8s 中是先天支持的，很容易去理解配置。
接下来观察会话保持功能，服务器在进行交互处理的时候，我们在进行某一步动作的时候往往需要了解上一步交互的处理结果，只有知道上一步处理结果，才能知道下一步要怎么做。但是很多时候代码或者部署业务的交互过程可能都是由同一台服务器完成的。
如果负载平衡不做出一些限制，如果按照调度算法的方法进行会造成一种结果就是代码或者部署的业务会被甩到后端不同的服务器上去处理。所以，当这种服务器在处理后端业务有状态需求的时候，就是数据是连续的或者说某些数据存储到某台 ECS 上，比如说上一步的数据存储到左边位置，那么下一步转到其他位置处理，就会变成缺失数据。要么将前面的数据拉过来或者将后者的数据同步过去，才有可能继续处理，否则业务可能会不正确。这时候我们就会想到能否通过一种方式，面临这样的场景，干脆让同一个绘画生命周期内的客户端都跟某一台固定的 ECS 产生绑定关系。
即在绘画周期内固定由某台 ECS 处理，这样就可以有效的解决之前的疑问。但是事实上产生这个问题的根本原因并不是负载平衡四层就是错误的而是负载平衡天然拥有一个潜规则，即希望后端的服务器是无状态的，无状态就是 ECS 上面不存数，因为集群里面 ECS 的数量有可能多也有可能少。但是有数据就会涉及到数据的同步问题，遇到数据刚好没有的情况会产生数据不正确的问题。所以解决这种问题的最好方式是不要将状态数据存储到 ECS 当中，比如说这些状态数据需要入库存入到 RDS 当中，因为很小可以存入到 redis 当中都可以。这些都是中心化的服务，是高可用的，所以 ECS 不保存跟业务相关的数据，存储日志可以，那么就可以解决这个问题，不开绘画保持，也可以保证后端处理业务，状态业务也不会因此出现错误都会在相同的地方。
绘画保持是为了兼容一些年代久远的应用，往云上进行搬迁的时候，可能没有条件去改造其代码，或者其业务本身就不支持数据跟状态数据进行分离，所以没有办法只能开起绘画保持，保证业务可以正常走完。
绘画保持功能是有可能导致负载不均衡的，比如说开启了绘画保持，那么这时后端的 ECS 的客户端的连接产生一对一的关系，只要客户之间的关系不断开，他们之间的连接就会一直存在。客户的行为是阻止不了的，有的客户一连接两个小时不下线，有的客户可能30秒就退走了。所以这时候的连接必然会导致后端连接不稳定的一个状态，容易产生不均衡。、
健康检查存在的意义就是检查后端的 ECS ，发现不正常的就将其屏蔽掉，这时候业务不中转，确保请求不能转发到不能请求的 ECS 上，避免用户端报错，同时它还会检查后端的 ECS 正常就将其加回，提高整体业务的可用性，该图描述健康检查的原理。四层检查基于连接进行检查，本身就是 TCP 的连接，利用三次握手的原理，只要连接断开的马上就可以侦查到。
七层的需要设置检查的 EYL 然后返回的状态码，发送请求 HEAD 请求，根据状态码来去进行判断。比如我认为返回值200,200多，300多都是正常的，如果返回是400多，500多是不正常的。之所以四层跟七层要分开跟负载平衡本身飞天部署有关系。
在飞天机房当中整个 SBL 集群当中的部署分为三大类集群： RDS 集群、tengine 集群，keyserver 集群。假设其后端存在各种 ECS ，业务流量到达 ECS 处理，无论是四层请求或者是七层请求，都会先到达 LVS ，LVS 去判断，如果是四层请求就直接往下层发送，然后它会开启 flat 模式， ECS 跟另一边的客户端最终会形成点对点的连接。所以四层请求是一个透传的架构，最终客户端和 ECS 形成一个长连接。
如果是七层连接会先到达 tengine 集群，比如说你是 HTEP ，HTTP，HTPS 的，进行解包将证书进行卸载，证书卸载完毕继续往下走。如图所示，七层的连接是绕了一圈的，所以其连接不具备长连接，基于连接没办法做七层的健康检查的。七层只能通过状态码的方式来检查。
虚拟服务器组是后端装 ECS 后端没有装组，其需要响应每个监听，监听80装口，每台都需要响应80接口。如果是有若干个监听，都默认转给大的池中，要求每一台 ECS 都需要去响应这些接口，事实上，真实情况下，业务很难是这样部署的。不可能100台服务器将业务都响应，都去安装一遍，去对 ECS 分组，比如说1号到10号进行处理一个业务，11号到20号处理一个业务。比如作为一个游戏业务来讲，拿出五台进行客户的登录，再拿出五台进行业务的支付，拿20台进行业务战斗准备。
那么其中有的 ECS 能力强，有的 ECS 能力没有那么强，所以有的 ECS 只能装一个程序，只受理一个端口的连接；有的 ECS 可以处理多个业务都没有问题，所以我们需要一个更灵活的结构就是对后端的 ECS 进行分组，所以就产生了虚拟组的概念。其意义在于通过给后端打标签的方式，1号跟2号作为虚拟组 a 拿去处理 a 端口的请求，2号跟3号作为虚拟组 b ，因为2号的能力比较强，一号的 ECS 只需要有 a 这个程序就行，三号 ECS 只需要有 b 这个程序就可以。2号的 ECS 可能要同时装 a，b 两组，完全可以按照我们的需求灵活的进行组织。通过虚拟组件可以更加灵活的进行调度。 SLB 配置的流程包括以下几步：创建 ECS 、搭建应用、创建 SLB 、添加监听和后端服务器、域名解析（可选），
先要有 ECS,因为 SUB 一定会将流量转发到 ECS 上进行处理，其本身是不是处理业务的，所以 ECS 和 SOB 是结合着使用的。然后在 ECS 上搭建应用，然后再来创建 SOB 的实例，来监听跟后端的服务器，最后进行域名的解析。最好基于域名， IP 有时候是会变化的，比如 SOB 不再使用或者 SOB 被换掉，网站还好， APP 锁死需要升级 APP 去换包，过程复杂。使用域名来解析其实是一种好的方式，关于 SOB 的实践，展示如下：
公网的流量入口，这是一种典型的方式，在 ECS 上部署无状态的应用，使用 SOB 作为公网的流量入口来提高系统的可用性。应答流量都是通过 SOB 出去了，所以 ECS 不需要提供 IP公网带宽的。它仅需要通过内网就可以，这时候通过外网的 IP 和带宽主要附着在 SOB 上。
第二个是实现相同路径的不同域名的转发，与 ingress 类似，基于虚拟服务器组+ uil 的转发规则实现把相同域名转发到不同路径当中，制作游戏就可以这么做。
