slb调度方式
- **轮询调度：**顾名思义就是顺序的分配流量，它保证每台机器接受的请求量是相同的。这个算法不能解决问题，因为我们现在就是不能让每台机器接收的请求量相同，我们的要求是性能好的机器接收的多，性能差的机器接收的少，故pass。
- **加权轮询：**这个方法给每台机器加了一个权重，比如默认可以都设置成100，这样所有服务接收等量的请求。也可以设置成100,100,80，这样如果有3台机器和280个请求，三台机器分别接收100，100，80个请求。看起来很美好，但是现实很骨感。它没法动态的调整权重，特别对于突发情况，必须人为手动去更改slb配置。更严重的是，对slb的操作会偶尔持续失败（阿里的slb也可能正在上线、维护），这对于及时处理问题可有不小的麻烦，故pass。
- **最小连接数优先：**乍看起来可能觉得不错，其实和轮询调度一样的问题，它总尝试把所有机器的连接数压成一致，也就是说尽量保证每个机器的请求量一致，这就会使得性能差的机器cpu一直被压满。我们要的就是流量不均衡的调度，而不是这种非得保证流量均衡的调度，故pass。
调度算法还需要解决问题
- 集中失败问题 观察实际情况发现，当一个服务性能突然下降时，会有大量的请求同时失败。由于我们的算法是记录连续失败次数的时间段，这就可能导致机器的权重瞬间降至0（如果瞬间100次超时，就会出现这种情况），从而该服务获取不到流量。解决这个问题的方式是在降权一次后忽略接下来一个时间段内的失败次数（比如设置5秒或者10秒），这样把这些瞬间失败归为同一拨。
- 升权问题 阿里云的机器突发这种系统cpu飙高的情况持续的时间不一定，有的时候持续几分钟，有的时候持续几小时甚至几天，当这种情况恢复正常时，调度算法能够逐渐恢复该机器的请求数量。所以，可以在合适的时机试探性的增加流量。我的做法是：在一定的权值基础上，如果算法正常工作超过10分钟（10分钟内没有再发生降权的情况），可以尝试把权重+1，这样就多分配10%的流量，流量增加10%后还可能会由于性能不够导致降权。
- 比率问题 假如w=10时，服务在10秒内接收到100个请求，其中失败了10次，算法降权后w=9；w=9时，服务在10秒内接收了90个请求，失败了9次，这个时候应不应该降权呢？要降！因为w=9之所以失败次数少，是因为调用次数少，但是这同样说明服务的性能是有问题的。所以，在一开始我们的算法思路说的不完全准确，不是固定时间固定的失败次数，而是需要按照权重不断调整失败次数。w=10时，10s内失败10次就要降权；w=9时，10s内失败9次就要降权；以此类推。
- 保底策略 由于我们是统计失败10次所用的时间长度，可能在某些情况下（比如上线的时候，算法配置时间段，失败次数，不合理）会造成对某些机器一直降权，而真实情况是后端机器性能并没有差到哪去，这会造成机器资源浪费并且还会有更多的请求拒绝。所以算法需配置一个机器权重下限，比如设置成6，就能保证最起码有该机器正常情况下流量的60%会发送到该机器上。
解决方式：
- 快速选择机器 每个服务对应一个调用次数：request_cnt，算法每次选择该服务时就对其累加+1。我们设置初始权重为w，当前权重为cur_w，那么当request_cnt % w < cur_w时，流量分配给该服务，否则跳过，这样就保证了安装权重分配流量。
- 解耦 为了解耦调度算法与具体环境，我们抽象一套算法接口。
业务架构：
监听设计：
监听协议：
SLB 支持创建 TCP/UCP/HTTP/HTTPS 这 4 种协议的监听。您可参考以下表格，根据业务情况选择适合的协议创建监听：
协议类型
建议的应用场景
特性
TCP
●注重可靠性，对数据准确性要求高，速度可以相对较慢的场景；
●示例：文件传输、发送或接收邮件、远程登录、无特殊要求的 Web 应用
●面向连接的协议；
●在正式收发数据前，必须和对方建立可靠的连接；
●基于源地址会话保持，在网络层可直接看到来源地址；
●监听支持 TCP 和 HTTP 两种方式进行健康检查；
●转发路径短，所以性能比 7 层更好，数据传输速度更快
HTTP
需要对数据内容进行识别的应用，如 Web 应用、小的手机游戏等
●应用层协议，主要解决如何包装数据；
●基于 Cookie 会话保持；使用 X-Forward-For 获取源地址；
●监听只支持 HTTP 方式健康检查
HTTPS
有更高的安全性需求，需要加密传输的应用
●加密传输数据，可以阻止未经授权的访问；
●统一的证书管理服务，用户可以将证书上传到负载均衡，解密操作直接在负载均衡上完成
UDP
●关注实时性而相对不注重可靠性的场景；
●示例：视频聊天、金融实时行情推送
●面向非连接的协议；
●在数据发送前不与对方进行三次握手，直接进行数据包发送，不提供差错恢复和数据重传；
●可靠性相对低；数据传输快
补充说明
- 并非只要 Web 网站就必须使用 HTTP 协议。大部分没有特殊 HTTP 要求的 Web 网站，使用 TCP 监听 80 端口就可以满足业务需求。
- SLB 集群采用 LVS 和 Tengine 实现。其中 4 层监听（TCP/UDP）经过 LVS 后直接到达后端服务器，而 7 层监听（HTTP/HTTPS）经过 LVS 后，还需要再经过 Tengine 转发，最后达到后端服务器，由于比 4 层多了一个处理环节。因此，7 层监听的性能相对要差一些。
选择后端服务器集模式
SLB 后端服务器支持按 3 种逻辑创建服务器集。要点如下：
集合模式
配置权重
指定服务端口
服务器数量限制
其它特性
后端服务器
支持
不支持
无限制
创建监听时的默认映射服务器集
虚拟服务器组
支持
支持
无限制
有更大的灵活性
主备服务器组
支持
支持
2 台
只能在 TCP/UDP 监听上使用
建议
- 按业务逻辑创建不同的虚拟服务器组，然后创建相应的监听与之对应。
- 无论创建何种服务器集合，均结合 SLB 多可用区特性，同时加入位于不同可用区的服务器，以实现跨可用区容灾。
- 设置过多转发规则会增加业务维护的复杂度，建议尽量精简策略条目。
网络层面解决方案：
**控制器：**对全网转发PE、CPE、VPE等设备进行统一的资源管理、信息收集、配置下发，监控告警以及路径计算规划，实现全网资源的统一调度和管理。
**骨干网边界：**全网PE和RR组成SR-TE骨干网核心层，用于实现多路径转发，流量调度；骨干网边界对外主要接入CPE、M-Core、VPE&VCPE等设备。
**接入侧边界：**接入侧分为三种设备类型：CPE、M-Core、VPE&VCPE。
**CPE：**主要用于接入本地专线客户；
**M-Core：**公有云MAN网络核心，实现各城域网接入骨干网；
**VPE：**通过Internet或者4G/5G网络接入用户分支机构的VCPE设备，提供用户混合组网能力。
智能控制器：
其中数据采集主要包括：
- 基本的IGP拓扑信息（节点、链路、IGP度量值）
- BGP EPE（Egress peer Engineering）信息
- SR信息（SRGB、Prefix-SID、Adj-SID、Anycast-SID等）
- TE链路属性（TE度量、链路延迟度量、颜色亲和属性等）
- SR Policy信息（头端、端点、颜色、Segment列表、BSID等）
智能
可靠
- **全球核心节点专线组网：**节点之间提供运营商级的专线资源，SLA可达99.99%；
- 双PE节点 Anycast-SID保护：地域级的双PE配置Anycast-SID标签，实现路径的ECMP和快速容灾收敛；
- Ti-LFA无环路径保护：100%覆盖故障场景，50ms内完成备份路径切换；
- SR-TE主备路径保护：SR-TE路径中规划主备Segment-List，实现路径转发高可用；
- SR-TE路径快速逃生：SR-TE故障场景下可以一键切换到SR-BE转发路径（IGP最短路径转发）；
- Internet级骨干网备份：为了保障新一代骨干网的高可靠性，在每个地域的PE设备旁路上两台公网路由器，规划了一张1:1的Internet骨干网，当某地域专线故障时可以自动切换到Internet线路上；同时使用Flex-Algo技术基于Internet级骨干网规划出一张公网转发平面用于日常管理流量引流。
可调度：
-
根据五元组，识别并定义应用，支持Per-destination、Per-Flow调度；
-
跨域之间根据应用业务分类定义多条不同类型SR-TE隧道；
-
每种类型隧道定义主备路径，支持SR-TE一键逃生；
-
通过灵活算法定义Delay、带宽、TCO（链路成本）、公网隧道等多种网络切片平面；
-
智能控制器支持自动下发、自动计算、自动调整、自动引流和自动调度。
当前根据业务需求规划了如下几种骨干网调度策略：
**IGP：**最低开销转发，ISIS接口的cost根据点到点之间专线物理距离延迟*100得到；
**Delay：**最低延迟转发，ISIS接口配置PM功能，动态探测点到点之间实际延迟；
TCO：最优成本转发，控制器根据每条专线的实际成本计算出最优成本路径；
FM：自定义转发，控制器根据业务临时需求下发需求路径；
FBN：公网隧道转发，每个地域之间提供公网VPN线路，提供备份转发路径。、
