开发者学堂课程【企业运维之云上网络原理与实践课程：【视频】第二讲-负载均衡CLB】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/991/detail/14970
【视频】第二讲-负载均衡CLB
内容介绍：
一．课程目标
二.概述
三.相关概念与产品功能
四.产品技术架构
五.最佳实践
六.常见问题与解决思路
一．课程目标：
1.了解负载均衡CLB的产品功能
2.了解负载均衡CLB的底层架构与相关技术
3.掌握负载均衡CLB的最佳实践
4.熟知负载均衡CLB的常见问题与解决思路
二.概述
为什么需要负载均衡
1.应对高流量的业务访问
例子：在使用 Windows 电脑时，会使用到 Windows 更新服务。全球这么多机器都会用 Windows 更新去访问微软的服务器，为什么它能扛得住这么多机器，而且很可能它的接入点是一个 IP，或仅有的少量 IP。为什么这个 IP 可以扛住全球这么大的访问。
2.消除单点故障
CLB 大概架构：
很多情况下需要统一的业务入口。比如更新的功能，客户端只认域名对应的 IP 地址，但是到了 IP地址后大有乾坤，会经过各个模块转发到真正的服务器上。这时需要一个负载均衡器做流量的分发。
如果使用一台服务器对外提供服务，因为一些原因服务器当机了，用了负载均衡。后台有三台机器，一台机器挂了。还有两台机器可以提供业务，对外客户的感觉 IP 地址还能正常工作，消除了单点故障。
3.对外提供统一的入口
三台机器都有对外的 IP 地址，客户端会同时解析出三个 IP 地址，对于运维管理不方便，配置或进行运维操作。对外 CLB 可以只报一个 IP 地址非常方便。
4.开箱即用
及时购买及时使用
5、负载均衡行业趋势与挑战
负载均衡云化趋势明显加速
负载均衡越来越多以云方式部署，云提供商逐渐成为主要玩家，传统硬件厂家加速向云转型，提供基于云化的解决方案
5G/IOT等技术带来机遇与挑战
5G/IOT将加速催生更大流量洪峰
底层通信协议的升级将网络瓶颈转移至应用层面万物互联使得IPv4加速退出历史舞台，IPv6时代到来
网络环境日益复杂安全性需求凸显
愈加复杂的网络环境、越来越深入的面向应用系统交付对安全提出了更高要求
云原生:从流量入口到面向应用交付
面向云原生基于7层高级特性加速企业应用快速交付能力负载均衡从面向网络层演进到面向应用层
云原生四要素：微服务 容器化 DevOps 持续交付
三．相关概念与产品功能
1、负载均衡产品
当购买了 CLB 之后，获得了一个 CLB 但是不能直接用。因为 CLB是以监听为督去提供服务。比如开一个外围网站，可以创建一个HTTP的监听或者TCP监听，只有监听创建出来以后，才能提供实际的服务。
CLB 只是一个转发的模块，并不承载实际的业务。实际的业务通过服务器组产生关联。三种服务器组默认服务器、虚拟服务器、主备服务器，常用的是前两个。同时如果需要使用 CLB 的功能，比如转发策略，只有虚拟服务器才支持转发策略。
将服务器组绑定到监听上，虚拟服务器、主备服务器与监听是完全解耦的。
金融客户对 CLB 有更高的安全要求，只允许特定的IP地址访问到 CLB，这时使用访问控制 ACL ，它的功能是指定一个白名单或者黑名单来控制哪些客服端能访问关联的实例，同样它们之间是严格解耦的，通过关联的方式将 ACL 关联到监听上。
在 HTTP（s）下有一个证书的概念，对所有的流量进行加密保护，对转发流量进行加减密控制,用户上传的证书会保存在证书管理模块内，实例与证书管理在一个地域下是完全解耦的。上传的证书可以同时运用在当前地域下所有实例上。
每天有很多业务请求，假设出了问题没有任何回溯的方式看业务数据，因为 CLB 对用户来说是黑客，提供的能力对内是无法看到的，这时日志生成。
分为两种，一种是访问日志一种健康检查日志。访问日志记录了所有客服端请求 CLB 的详细内容，包含客户端原 IP，访问日志只有HTTP（s）监听，TCP 和 UDP 监听暂时没有日志，但在其上有高清度秒级监控。TCP 和 UDP 监听只提供传输的能力，并不关心上层提供什么服务，所有并不能提供上层的业务。如果需要访问日志建议直接用 HTTP（s）监听或者 ALB。健康检查日志可以看到完整的切换动作，什么时候出问题在出问题时进行回溯、排查。通过空间换时间的方式，将历史上转发记录通过 SS 方式陈列下来。
2、产品核心能力-面向超大规模业务的流量入口
IPv6/IPv4公网入口
IPv6采用6To4方案，前端对外暴露IPv6地址对外提供V6服务后端采用V4连接到ECS，轻松实现业务向从V4向V6的平滑迁移。
最大500万并发连接，应对大流量、大并发场景
超强性能
丰富的实例规格，支持各种规模的业务场景，弹性计费，应对业务峰值的同时优化成本
四．技术架构
1、阿里云负载均衡CLB产品总体技术架构
• 双AZ容灾高可用架构
双可用区部署，主备容灾实现高可用，业务 AlwaysOnline
• 海量4层业务处理能力
LVS 高性能集群处理4层业务流量应对海量业务洪峰
• 基于内容的7层业务路由
Tengine 集群理处理7层业务流量基于内容的业务路由
• 高性能 HTTPS 加解密
硬解密卡实现高效 HTTPS 流量终结，节省后端服务器算力
任何 CLB 都有高可用特征，体现在很多方面，一个方面 CLB 是冷热集群主备。买了 CLB 之后会在两个可用区同时创建转化集群，一个主一个备。正常情况下只有主集群存在流量，流量从 CLB IP地址进入后直接打到主集群，只有因为一些不可抗因素，主集群A失联了，通过路由切换的模式将流量切换到可用区B上，体现了在可用区的高可用。CLB 内部也做了高可用。
2、深入产品内部-技术架构
·所有流量都需要经过 LVS 集群进行转发
·LVS 集群内的每一台节点服务器均匀地分配海量访问请求
·7层监听会额外经过 Tengine 集群，HTTPS 协议还会经过KeyServer 集群
·CLB 与后端 ECS、ENI 通信走内网
在 LVS 集群中做四层的流量转发，是应用内核的组件，可以提供流量转发，流量代理。在其中会部署若干台机器，当一台机器挂了其他机器同样可以提供转发流量。
任何一台机器都是多机流量部署。Tengine 集群是为 HTTP 提供服务的，当使用了 HTTP 监听会提供额外的能力，包括记录访问日志，提供转发策略。Tengine 集群同样是多机部署，至少四台以上机器部署。如果使用 HTTPS 为了提高效率会额外部署 Key Server 集群。
四层的 UDP和 TCP 监听，首先从客服端到公网，经过公网路由到 CLB 入口后经过 LVS 集群进行转发，直接打到 ECS 上。只有 HTTP 和 HTTPS 监听继续走到 Tengine 集群，如果是 HTTPS 监听第一次需要经过 KeyServer 集群在回到 ECS。集群的机器都是热备机器，所有的流量流经所有的集群同时承载流量。所有的集群与 ECS 交互都是走内网。
七层的监听无论是 HTTP 还是 HTTPS 为了提高通行效率 CLB 和后台 ECS 全部走 HTTP。HTTP 不需要加减运法通行效率更高，第二认为这个链路是安全可靠的。结合效率和安全性做的权衡考虑。
3、健康检查
·健康检查可以感知到后端ECS的可用性
·探测源均是承载业务的转发集群
·探测源IP段为100.64.0.0/10
健康检查是 CLB 集群对后端 ECS 做的探测，因为实际上有多台 ECS 同时进行服务，万一一台机器挂了，怎么知道这台机器不能正常提供服务了，这时需要健康检查。
因为要保证业务流量转发通用诞生健康检查，所以发起源一定是承载业务的转发集群。
探测源IP段为100.64.0.0/10在阿里云上网段被用作所有云服务的通讯地址。
4、健康检查-TCP监听
·请求方式:
TCP 三次握手或 HTTP GET
·判定成功逻辑
超时时间内收到了 SYN_ACK
·判定失败逻辑
超时时间内未收到 SYN_ACK
·关闭连接方式:
发送 RST 数据包
TCP 监听健康检查首先 CLB 会对后端的 ECS 发起 SYN,后端收到 ACK 以后，再进行一次 ACK 同时立即发一个 RST 给后端 ECS。
健康检查判定成功逻辑
在 SYN 和 SYN+ACK 之间的时间内收到了 SYN+ACK，这个时间是响应超时时间在控制台上由用户进行配置，一般来说三秒或五秒。在相应时间内收到了SYN_ ACK认为是健康的除此以外所有的健康检查都是失败的。
为什么要以 RST 方式断开连接
首先健康检查实际上 CLB 额外引入的逻辑，对于 ECS 有一定负担。CLB 为了尽可能降低健康检查的开销所以用到 RST,RST 可以立即断开连接让两端的内核都不再维护 TCP，第二它只需要单向的一个包就可以将连接拆掉。但会有其他问题 RST 在规定里不是太正常的状态。如果探测源是100.64就可以认为是健康检查的逻辑，甚至可以进行一次抓包。如果发现 RST 前的交互逻辑就是 SYN SYN+ACK ACK RST,可以大胆的认为就是健康检查可以忽略，在代码上异常，去判断源IP是不是100.64如果是直接忽略异常。其它业务程序以此类推。
5、健康检查-UDP监听
·请求方式:
UDP报文
·判定成功逻辑
超时时间内没有收到ICMP端口不可达
·判定失败逻辑
超时时间内收到了ICMP端口不可达
CLB 发一个探测报文，报文的内容可以自己选，报文传送到后只要在规定的响应超时时间段内没有收到 ICMP Unreachable 报错，那么健康检查是成功的。思维与 TCP 完全相反，只有在 UDP 监听发出后，收到了报文才能判定监听失败。根据 UDP RFC 规定，当后端没有进行 UDP 监听时，收到了 UDP 报文机器必须要回 ICMP 报文，同时回目标不可达，端口不可达报错，这时认为出现问题。否则认为报文达到 ECS。判断逻辑为在配置的响应时间内没有收到任何报错，那么探测成功。可以自定义报文回应。
6、健康监听-HTTP(s)监听
·请求方式:
HTTPGET方法或HEAD方法，可能包含Host头
·判定成功逻辑
超时时间内收到了配置的正常状态码(如200)
·判定失败逻辑
除上述以外的情况(如收到了502状态码、收到了RST建连失败等)
响应的超时时间可以在控制台配置
探测方法官网默认使用 HEAD 方法，尽可能降低健康检查对后端 ECS 的影响，对于 HTTP 下的 HEAD请求，ECS 只会响应响应器的投入。一方面可以降低返回的字节数，另一方面 HEAD请求对 ECS 的开销小。
判断健康检查正常，有两个条件第一个在超时时间内收到了配置的正常状态码，除此以外所有的场景都是失败。
HEAD请求内可以进行自定义的配置检查端口等，如果后端机器是虚拟组织不同的命名不同的配置会返回不同的结果。
7、健康检查-滞后性和探测频率
滞后性当机器出现问题时，CLB 需要一定的时间去感应到
绿色的线是起点，配置的健康检查响应超时5s，健康检查间隔2s。不健康的余值次数是3次。
在此场景下 CLB 需要19s时间感应到后端 ECS 是失败的
第一次失败5s,休息2s第二次开启5s失败等2s,第三次5s
灵敏性和业务上能容忍的滞后性综合的博弈。如果对业务要求高可以设置超时时间和间隔时间减小。减小的负面影响是在单位时间内后端 ECS 收到探测包的量增加。
假设 LVS 集群有四台机器，配置的探测频率被放大四倍，配置的响应时间5s，间隔2s那么按理1分钟内只能收到30次探测，但是引入了4台机器后探测频率会提高四倍，1分钟收到120次探测。如果使用的是 HTTP 监听7-8台机器，探测的频率进一步放大，怎么去权衡滞后性和探测频率需要和业务方讨论。有更好的感应时间，探测频率会增大。如果希望后端 ECS 减小健康检查的负担必然会带来滞后性。
8、服务器组
·默认服务器组
.兜底服务器组
·虚拟服务器组
.转发策略
.监听维度
·主备服务器组
.一主一备
.始终对主进行健康检查
真正的业务承载在 ECS 内，通过服务器组的方式组成一个服务器池来提供服务。当需要使用高级特性时建议使用虚拟服务器。虚拟服务器是相对来说最灵活操作成本最低的方式，将若干个服务器放入虚拟服务器组里组成虚拟的池子，后端 ECS 将请求根据对应的录入规则转发到虚拟服务器组上。
如果某个监听没有配置任何转发策略也没有关联任何虚拟服务器组那么流量就会转到默认服务器组上。默认服务器组一个LB实例只能有一个默认服务器组，所有监听共享。虚拟服务器组实例上解耦，一个虚拟服务器组可以关联多个监听上。主备服务器组会有自带的特性，有两台机器一主一备冷备，在任意一个时刻 CLB 只会将流量转发给主机器，当主机器健康检查失败时会将流量转发给备，这时虽然流量到了备机器，健康检查依然对主进行检查，一旦发现主正常，将流量立即切回主机器。主备服务器的特征不适合常见的业务，只适合特定的业务形态，一主一备平时只需要一台机器提供服务的特点。
9、转发策略
·提高单个实例的使用率
·统一管理入口
·灵活调度流量
转发策略的功能类似虚拟主机的概念，CLB 根据不同的域，转发给不同的虚拟服务器组。
假设a.com下面的a此时流量转发给 ECS 虚拟服务器组A,访问b可以转发给虚拟服务器组B。A、B服务器组内部的机器可以相同可以不相同，提供统一的入口也可以提高 CLB 的使用效率，对于后端可以精细化的部署不同机器来提供不同的服务。
五．最佳实践
·典型使用场景
·存储日志配置
·监控转发策略
·获取客户端IP
1、阿里云负载均衡CLB典型部署方案
海量访问流量分发
负载均衡SLB作为业务流量入口处理超高并发流量
多层次容灾架构
DNS跨地域部署和双AZ多活实现不同层次的业务容灾
CLB 是入口处或靠近入口处的设备无论是业务上直接将域名直接解析成 CLB 的地址或者用 DNS 通过多记录将流量分批转发给 CLB 。
2、开启访问日志及健康检查日志
负载均衡
·访问日志 ·健康检查日志
日志服务
·简单·实时·弹性
日志存储在日志服务云产品中，云上各个产品之间有密切的交互，CLB 产生的日志不会存在自己的设备中而是通过内部的电路存到日志服务。通过日志服务控制台不同的查询条件筛选不同的字段拿到想要的结果。获得了观察 CLB 工作的能力，如果希望在后端 ECS 自己部署日志涉及到多台机器上报汇总，用日志服务免去。
通过控制台不同的关键字筛选后，通过仪表盘或直方图的统计非常直观看到很多信息。
第二张图通过日志服务查询语法搜集了在一定时间内所有请求来的客户端的UA情况，以及按出现的频次导序结果。
3、使用HTTPS监听
HTTP 1.0
·增加Header、状态码
·增加HEAD POST方法
·默认TCP短连接
HTTP 1.1
·默认TCP长连接
·支持Range
·支持伪管道传输(Pipeline)
·增加了Host头
HTTP 2.0
·基于二进制格式
·支持多路复用
·全双工通信
HTTP 3.0(GQUIC)
·基于UDP
·强制加密
基于上述原因，我们建议:
·尽可能使用HTTPS
·证书可托管在CLB
另外.....
·CLB提供HTTP重定向到HTTPS的功能
·部分高级功能依赖HTTPS(如HTTP2、 WebSocket)
目前处于HTTP 2.0。很多用户、网站都会考虑HTTP 2.0，因为HTTP 2.0基于二进制格式，会有更高效的通信，之前的1.0和1.1都是基于ASCLL码的可读的形式，虽然方便人的阅读，但是通信效率非常低。
HTTP 2.0还支持多路复用。在1.1版本以前TCP的连接原则上只能发出串型请求，虽然1.1支持Pipeline可以一次性发送多个请求，但是给响应时依然要依次的给响应，并不高效。
HTTP 2.0还支持全双工通信：正常情况下是客户端发请求之后，服务端才能收响应，但在WebSocket是双向的，即便客户端不发消息服务端也可以给客户端推送消息，在2.0内也支持这个功能。
展望HTTP 3.0：一个是GQUIC协议，一个是标准工作组推出的协议。
GQUIC是基于UDP同时要强制加密。
4、配置报警规则
CLB 会将底层所有的数据推送给云监控，统一在云监控进行报警规则的配置。
使用云监控配置报警规则，重点关注:
时序类报警:数据跟着时间时序上报，是二维的数据。在不同的时刻上报一个值。
实例维度:
·后端不健康服务器数量：某一时刻对后端 ECS 做的探测不正常的 ECS 的数量。
4层监听维度:
假设 CLB 的流量超出了实力规格上线后丢弃连接、丢弃数据包指标会体现出来不为0。丢弃连接每秒超过了10个KPS 需要快速的检查是否规格超限或者意料之外的大流量业务出现。如果确定业务流量建议升配，如果是异常的流量需要进行业务分析或者考虑部署安全类服务。
出入流量是当前监听出入的BPS 数量。
·丢弃连接、丢弃数据包
·出入流量
7层监听维度:
对响应码提供监控能力，假设后台收到了5XX或4XX状态码会进行报警。根据HTTP协议5和4开头的通常是异常的响应，4是客户端的异常，5是服务端的异常。
·5xx、4xx状态码
·XXX
事件类报警:
并不会在某一时序上持续的发出数据,某一个时刻有一个点，点本身没有数值的概念，只有事件的概念。ECS 出现了当机，当机迁移这一事件通过短信电话告诉用户，为事件类的报警。
7层监听:
证书到期提醒(提前N天)
5、获取客户端真实IP
将场景分为3类，一类是使用IPv4四层监听，一类是IPv6四层监听，一类是七层监听。在不同场景下获取客户端真实IP不相同。
IPv4监听是最方便的，CLB 内置的模块可以透明的完全无感知的获得客户端真实IP。在 CLB IPv4感知不到前面有一个模块，看起来是与客户端直接通信，看到的三层IP toa 就是真实的客户IP。CLB 和后端 ECS 的物理机上做了模块改写，在源IP头送入 ECS 内部之前做了更改。
假设后端有其他的因素无法直接获取客户端真实IP，提供另外一种可选的方式 Proxy Protocol 协议，通过三次握手后简短的插入一个包让后端的 ECS 可以获取真实的客户端IP。IPv6四层监听可以通过Proxy Protocol获取真实客户端IP，少了一种直接获取的方式。后端 ECS 与 CLB 通信的协议 IPv4。
七层监听有一种方式获取客户端真实IP也是目前业界比较通用的方式，通过请求头中的 x-forwarded-for 字段来获取真实IP。只支持固定的请求头获取真实的IP。如果有一个模块做了不安分的动作替换掉了x-forwarded-for，可以用 ALB 对请求做定制化的操作。
6、获取客户端真实IP-toa
目标IP为VPC下绑定了EIP的SLB，五元组如下:
120.195.13.68:12345 -TCP-> 123.56.169.153:443
CLB 在做转发时对第三次握手的三次包做 ACK 动作,TCP Option 是公有的字段且最大只有20个字节。目前 TCP 协议会做很多动作，协商 mss 做 sack 动作都是TCP里的高级功能。为了保证不影响正常业务的通信协商 CLB 选用第三个 ACK 包，第三个包是信号包往往不带数据。
TCP三次握手第三个ACK包的完整十六进制dump，加粗部分即为完整的TCP Option:
0000 00 16 3e 34 07 96 58 60 5f 72 1e 00 08 00 45 14
0010 00 3c ac a3 40 00 2f 06 e9 7b 64 79 b8 15 0a 19
0020 8e e1 7c da 01 bb 88 77 6a 56 ad 5c bc aa a0 10
0030 00 e5 35 62 00 00 fc 14 30 39 78 c3 0d 44 19 70
0040 09 00 c0 a8 00 5b 01 bb 01 01
依次为:
TCP Option Kind==252(0xfc)
长度(从Kind开始算):20字节(0x14)
客户端源端口: 12345->30 39(网络字节序/大端)
客户端IP地址:120.195.13.68->78 c3 0d 44
VPC TunnellD: 618521->19 70 09 00(主机字节序/小端)
vip: 192.168.0.91->c0 a8 00 5b
vport: 443->01 bb (网络字节序/大端)
原始包如下，将 CLB 的第三次握手第三个 ACK包载出，toa包是通过第三次握手第三个 ACK 包在 TCP Option 内将真实的IP塞入 TCP Options。toa 全称 TCP Option。
7、获取客户端真实IP-ProxyProtocol
在三次握手后 CLB 自己生成一个小包转给后端的 ECS ，包在三次握手之后而且是 CLB 生成的包。后端的服务器必须要支持 ProxyProtocol。ProxyProtocol有两种版本v1、v2。v1类似 HTTP 人可读的协议，v2是机器可读的二进制的方式。CLB 目前支持v2协议，特征是挨个进行解读。
五元组:120.195.13.68.34270-TCP->47.98.108.43.10086
0000 00 16 3e 12 90 f5 ee ff ff ff ff ff 08 00 45 00
0010 00 8c 7a b7 40 00 66 06 49 cb 78 c3 0d 44 c0 a8
0020 09 3a 85 de 01 bb 10 a9 24 18 c2 df 78 02 50 18
0030 13 88 64 6f 00 00 0d 0a Od 0a 00 0d 0a 51 55 49
0040 54 0a 21 11 00 54 78 c3 0d 44 2f 62 6c 2b 85 de
0050 27 66 03 00 04 8a 65 79 c5 04 00 3e 00 00 00 00
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0090 00 00 00 00 00 00 00 00 00 00
从加粗的第0x36个字节开始，是TCP的payload(加粗部分)，接下去就是:
1.12个字节是Proxy Protocol的固定签名:
x0D\x0A\x0D\x0A\x00\x0D\x0A\x51\x55\x49\x54\x0A
2.4bit的版本号，这里是0x2，意为V2的版本
3.4bit的command，这里是0x1，意为Proxy(0x0==Local)
4.4bit的地址族，这里是0x1，意为AF_INET(IPv4)，其余的为0x0// AF_ UNSPEC Ox2 // AF_INET6(IPv6)0x3//AF_UNIX
5.4bit的transportprotocol，提示接下去是哪一种传输层的协议，这里是0x1，意为STREAM(TCP)，其余的为0x0//UNSPEC 0x2//DGRAM(UDP)
6.2字节表明接下去的长度，网络字节序，这里是0x0054==84，说明接下去的84字节都是PP本身的payload(斜体部分)
7.4字节的源IP，78 c3 0d 44转换成点分十进制即为120.195.13.68
8.4字节的目标IP，2f 62 6c 2b 转换成点分十进制即为47.98.108.43
9.2字节的源端口，网络字节序，0x85de==34270
10.2字节的目标端口，网络字节序，0x2766 ==10086
8、获取客户端真实IP-x-forwarded-for
在后端的 ECS 上做抓包，并将请求头打印如下，讲过 CLB 的转发，请求头中多出一个请求头 X-Forwarded-For,这个值为 CLB 内部塞的真实的客户端地址。
请求头中包含以下key-value:
X-Forwarded-For: 用户真实IP代理服务器1-IP，代理服务器2-IP，...
六.常见问题与解决思路
.访问CLB失败
.健康检查失败
.获取客户端真实IP
.访问出现50x
.负载不均
.压测性能不符合预期
1、无法访问CLB
SLB IP被清洗或黑洞：云网络上常见的一个状态，当公网IP地址被大流量的攻击时，为了保证后端机器的负载正常以及整个云网络环境的稳定性，超过的会被拉入清洗或者被拉入黑洞，这时候访问IP地址有可能不通。
解决方法：清洗：在控制台上解除清洗。黑洞：迁移业务，等待黑洞结束（当 CLB 达到了5Gbps 为了保证机器不挂掉，为了维持网络环境的稳定性IP地址会被拉黑洞，这时只能迁移业务或等待黑洞结束。
）
RS 全部健康检查失败：假设后端的 RS 健康检查全部失败，是因为CLB没办法将请求转发到后端的RS上，这个请求自然没有办法处理，4层会返回 Connection reset by peer 或 Connection refused,7层会返回502状态码。
2、健康检查失败
四、七层监听：当尝试引入模块时业务一定要保证能兼容或匹配新引入的模块。
屏蔽了健康将检查源IP：健康检察源IP一分钟有100次请求，如果设置的探测频率较高，如果机器内部不属于监听软件，发现100次请求次高，会自动将100源IP屏蔽，CLB 无法接受响应健康检查失败。
后端ECS端口是否监听：机器内部业务程序没有经历端口，后端没办法响应自然握手。
后端ECS监听队列是否溢出：例如：Linux对于处理三次握手是自己完成的，当业务量非常大或者是攻击的，Linux内核的全连接队列满了以后没办法继续处理三次握手。
安全软件是否进行了拦截：安全软件内部一些安全防护软件拦截探测源IP。
七层监听：后端WebServer是否可以做出正确响应：七层监听 Head请求做监听，WebServer没有开启 Head请求会返回405，健康检查配置的正常的预期结果是2XX、3XX，405为异常。
开了健康检查日志时，健康检查失败日志里会体现的具体表现
·TCP监听:
TCP connect time out
TCP connect error
·UDP监听:
UDP connect error
·HTTP(s)监听:
check protocol error check time out
time out 表示请求超时，error 在代码上是从远端收到了非预期的结果得到的记录信息比如后端没有监听 CLB 预期收到 ACK 然而收到了其他包符合 TCP connect error。
3、访问出现4XX、5XX
502虽然收到了响应但后端机器有异常
● proxy和后端ECS 三次握手过程中，后端ECS主动回复了RST
● proxy 和后端ECS三次握手成功，但在等待响应的过程中后端ECS主动回复了 RST
● 所有后端ECS 健康检查失败
504没有收到及时的响应
● proxy和RS三次握手建连超时（超时时间为 5秒），如syn一直在重传，upstream_response_time 填充为 5秒（可能会有正负一点误差，如5.001)， upstream_ status 为 504
● proxy和RS三次握手成功，但是等待HTTP 响应超时（超时时间为 60秒），upstream_response time 填充为60秒（可能会有正负一点误差，如60.001），upstream_status为504
4、负载不均
CLB 某种情况下转发的流量不均匀，表现很多种，在后端 ECS 上的业务日志量不同。监听转发最小的力度是不同的，观察的点与转发的点不同。假设是四层监听，转发的最小监听是 TCP 连接。如果业务关心的 HTTP 请求但是使用长连接，只用一个 TCP 连接就承载了业务所有请求，负载不均。
七层监听是 HTTP 转发的请求。后端健康检查抖动，每一次抖动转发的连接会被重置。
四台机器，第一个连接转发给 ECSa，第二个连接转发给 ECSb，某一台机器抖动，计数值会被重置，因为后端 ECS 特性发生变化，从四台缩小到三台，转发连接的计数器发生变化。
5、压测性能不符合预期
施压前，关闭健康检查尽可能关闭额外的流量，关闭会话保持关闭额外的原因，减少额外的开销更真实的表现 CLB 能提供的业务预期。
施压中，可以观察不同的业务指标去动态的获取当前系统的状态，访问日志通过 ECS 仪表盘、查询语句动态获取到5XX、4XX的状态码，以及通过云监控看当前 CLB 整体的容量状态。upstream_response_time 后端 ECS 整体的响应时间，可以直观看到后端 ECS 的压力。施压过程长时间的压测，压测足够的时间才能体现问题或流量跑完所有的模块，不要机械的压测，当发现5XX已经丢弃连接，这时停止压测。回头判断为什么丢弃连接，整改完后再进行一次压测，不断的进行反馈压测反馈的过程。只有足够多的客户源 IP，所有集群内机器才能均匀承载能量。如果源 IP较少可能流量只流经一台机器。施压后，根据业务不同要求评估查看不同的业务指标。
压测性能不符合预期更可能是客服端的施压机出现流量跑满等情况。压测是非常长的链路，从施压机到域名，到 CLB CLB 后会有很多 ECS,甚至 ECS 之后有更多数据持久化模块比如数据库。通过各种方式缩小问题的原因点。
注意：CLB 最开始的形态是可独立提供服务的产品，随着产品的发展，CLB 逐渐可以做拆解。
