企业运维训练营之云上网络原理与实践课程
第二讲 负载均衡CLB（上）- 产品和架构
视频地址：
https://developer.aliyun.com/learning/course/991/detail/14970
课程目标
- 了解负载均衡CLB的产品功能
- 了解负载均衡CLB的底层架构与相关技术
- 掌握负载均衡CLB的最佳实践
- 熟知负载均衡CLB的常见问题与解决思路
课程目录
- 概述
- 相关概念与产品功能
- 产品技术架构
- 最佳实践
- 常见问题与解决思路
正文：
一、概述
CLB（Classic Load Balancer）通过设置虚拟服务地址，将添加的同一地域的多台ECS实例虚拟成一个高性能和高可用的后端服务池，并根据转发规则，将来自客户端的请求分发给后端服务器池中的ECS实例。
CLB默认检查云服务器池中的ECS实例的健康状态，自动隔离异常状态的ECS实例，消除了单台ECS实例的单点故障，提高了应用的整体服务能力。此外，CLB还具备抗DDoS攻击的能力，增强了应用服务的防护能力。
１. 为什么需要负载均衡
CLB架构图
- 应对高流量的业务访问
大批量用户可以正常同时访问一个接入点,是因为负载均衡器做了一定量的分发；
- 消除单点故障
一台服务器出现故障，其他服务器仍然对外可以提供正常服务，用户使用不受影响；
- 对外提供统一的入口
多个IP地址对外只暴露一个，对外的入口是统一的，运维管理起来比较容易；
- 开箱即用
云产品的特点，即买即用，快速高效；
２. 负载均衡行业趋势与挑战
- 负载均衡云化趋势明显加速
负载均衡越来越多以云方式部署，云提供商逐渐成为主要玩家，传统硬件厂家加速向云转型，提供基于云化的解决方案；
- 5G/IoT等技术带来机遇与挑战
5G/IoT将加速催生更大流量洪峰，底层通信协议的升级将网络瓶颈转移至应用层面，万物互联使得IPv4加速退出历史舞台，IPv6时代到来；
- 网络环境日益复杂安全性需求凸显
愈加复杂的网络环境、越来越深入的面向应用系统交付，对安全提出了更高要求；
- 云原生:从流量入口到面向应用交付
- 面向云原生基于7层高级特性加速企业应用快速交付能力，负载均衡从面向网络层演进到面向应用层；
- 云原生4要素：微服务、容器化、DevOps、持续交付。
二、相关概念与产品功能
１. 负载均衡产品大图
负载均衡产品
a. 实例：
- 监听：负载均衡以监听为实例提供服务，如TCP监听、UDP监听、http(s)监听等，然后将请求流量分发至后端服务器；
- 服务器组：负载均衡是转发模块，并不承载TCP业务，实际的业务通过服务器组和负载均衡产生关联，将服务器组绑定到监听上，如默认服务器组、虚拟服务器组、主备服务器组等，其中虚拟服务器支持转发策略；
b. 访问控制ACL
可以针对不同的监听，设置访问白名单或黑名单，如某些金融客户只允许特定的IP地址访问；
c. 证书管理
https证书会对流量进行相应保护，在https监听下，负载均衡会对证书进行托管、加解密转发控制；
d. 日志
- 访问日志：相当于NGINX的access.log，可以通过分析负载均衡的访问日志了解客户端用户行为、客户端用户的地域分布，排查问题等；
- 健康检查日志：后续将有详细介绍。
２. 负载均衡SLB的核心能力：面向超大规模业务的流量入口
- IPv6/IPv4公网入口
IPv6采用6To4方案，前端对外暴露IPv6地址对外提供V6服务，后端采用V4连接到ECS，轻松实现业务向从V4向V6的平滑迁移。
- 最大500万并发连接，应对大流量、大并发场景
丰富的实例规格，支持各种规模的业务场景,弹性计费,应对业务峰值的同时优化成本。
三、产品技术架构
１. 产品架构
阿里云负载均衡CLB产品总体技术架构如下：
- 双AZ容灾高可用架构
双可用区部署，主备容灾实现高可用，业务Always Online；
- 海量4层业务处理能力
LVS高性能集群处理4层业务流量应对海量业务洪峰；
- 基于内容的7层业务路由
Tengine集群处理7层业务流量，基于内容的业务路由；
- 高性能HTTPS加解密
硬解密卡实现高效HTTPS流量终结,节省后端服务器算力；
２. 全链路流量走向
- 所有流量都需要经过LVS集群进行转发；
- LVS集群内的每一台节点服务器均匀地分配海量访问请求；
- 7层监听会额外经过Tengine集群,HTTPS协议首次请求还会经过Key Server集群；
- CLB与后端ECS、ENI通信走内网；
３. 健康检查
健康检查是对CLB集群对后端进行一个探测，多台ECS同时提供一个服务，通过健康检查可以追踪的故障服务，避免了后端ECS异常对总体服务的影响。
- 健康检查可以感知到后端ECS的可用性
- 探测源均是承载业务的转发集群
- 探测源IP段为100.64.0.0/10
a. TCP监听
CLB向后端发起一个TCP三次握手的信报，后端响应完成，以RST方式断开连接。
- 请求方式：TCP三次握手或HTTP GET；
- 判定成功逻辑：超时时间内收到了SYN_ACK；
- 判定失败逻辑：超时时间内未收到SYN_ACK；
- 关闭连接方式：发送RST数据包；
问题一：为什么选择RST方式而不是传统的四次挥手断开连接？
因为健康检查是用CLB额外引入的逻辑，对后端ECS具有一定的负担，为了尽可能地减少健康检查的开销，采用了RST方式，只需要单向的一个包就可以立即断开，两端的内核都不再去维护TCP五元组连接的管理。
问题二：使用RST可能带来哪些问题？
RST在TCP/IP定义里属于非正常状态，在某些程序比如java程序会频繁提示“connection reset by peer”，只要确定探测源是100.64.0.0/10，就可以认为这是健康检查探测的逻辑，可以忽略该异常信息。
b. UDP监听
UDP是面向无连接的协议，一般用于如DNS、syslog协议场景，UDP监听的规则是发出报文，在规定时间内，收到回应表示失败，未收到报文表示成功（也可以设置为返回特定字符串来判定成功）。
- 请求方式：UDP报文；
- 判定成功逻辑：超时时间内没有收到ICMP端口不可达；
- 判定失败逻辑：超时时间内收到了ICMP端口不可达；
c. HTTP(s)监听
- 请求方式：HTTP GET方法或HEAD方法，可能包含Host头，默认使用HEAD方法（尽可能地降低健康检查给后端ECS带来的影响，HEAD方式只返回响应头部字节数，开销也比较小）；
- 判定成功逻辑：超时时间内收到了配置的正常状态码（如200）；
- 判定失败逻辑：除上述以外的情况（如收到了502状态码、收到了RST、建连失败等）；
d. 滞后性和探测频率
滞后性：如果机器出现故障时，CLB需要一定的时间才能感应到；
探测频率：探测频率会由于机器数量而倍增，需要在灵敏性和业务可容忍的范围内，适当设定该频率；
４. 服务器组
a. 默认服务器组（某监听上没有配置任何的转发策略，也没关联任何的虚拟服务器组，流量就会转发到此组，一个CLB实例只有一个默认服务器组）
- 兜底服务器组
b. 虚拟服务器组（最灵活，操作成本最低）
- 转发策略
- 监听维度
c. 主备服务器组（比较灵活，是备用服务机器转发到主服务机器上，不适合常见业务，只适合特定的主备业务）
- 一主一备
- 始终对主进行健康检查
５. 转发策略
CLB转发策略流程图
- 提高单个实例的使用率；
- 统一管理入口；
- 灵活调度流量；
