关于负载均衡:常用负载均衡方案概述

需要背景

面对大量用户拜访，多任务执行，零碎负载会继续升高，目前共有三类解决方案

• 硬件降级：CPU降级，多外围，内存裁减，这一类纯正靠资本，降级老本极高
• 软件层面：采纳高效率开发语言，比方 C/Go/Rust 等底层开发语言，能够编译为操作系统间接执行的二进制文件，不像 Java/Python 等解释型语言须要装置一个语言解释器，导致内存占用较大（尤其是 Java 吃内存很重大），同时速度也不快
• 业务拆分与分布式：负载平衡，解决高并发拜访与多任务执行问题，技术难度与硬件老本角度衡量较为平衡

负载平衡概述

将负载（前端的拜访申请，后盾执行的工作）进行均衡，通过负载平衡算法摊派到多个服务器上进行执行，是解决高性能，单点故障高可用，程度伸缩的终极解决方案

成果

• 减少吞吐量，解决高并发压力（高性能）
• 提供故障转移，解决单节点故障问题（高可用）
• 通过增加或缩小服务器数量，提供网站程度伸缩性（扩展性）
• 网络入口平安防护，在负载平衡设施上做一些过滤，黑白名单等解决，最大水平上保障集群零碎的安全性

负载平衡实现技术

负载平衡在 OSI 网络档次中，层级越低，性能越好，然而技术复杂度也越高

DNS负载平衡(七层负载平衡)

最早的负载平衡技术，利用域名解析实现负载平衡，在 DNS 服务器，配置多个 DNS 记录，这些记录对应的服务器形成集群，大型网站总是局部应用 DNS 解析，作为第一级负载平衡

比方在不同网络环境下，ping baidu.com命令执行获取到指标设施的 IP 是不一样的

长处

• 简略：负载平衡工作交给 DNS 服务器解决，不须要专门的服务器保护
• 性能高：能够反对基于地址的域名解析，解析成间隔用户最近的服务器地址，防止长链路网络传输，放慢访问速度

毛病

• 可用性差：新增 / 批改 DNS 后，解析工夫较长，域名 DNS 服务器产生变更后，须要期待本地 DNS 中域名 DNS 服务器的 TTL 缓存生效，本地 DNS 才会从新发动递归查问，而后全国各地 DNS 能力同步到最新的域名 DNS 服务器名称，该过程须要一到两天的工夫
• 扩展性低：DNS负载平衡的控制权在域名商，扩展性无限

Nginx HTTP负载平衡（七层负载平衡）

能够应用配置实现

依据URL、浏览器类别、语言来决定是否要进行负载平衡

长处

• 对网络稳定性的依赖十分小
• 承当高负载压力且稳固，在硬件不差的状况下个别能撑持几万次的并发量

毛病

• 仅能反对 http、https 和Email协定，在适用范围下面较小

LVS负载平衡(四层负载平衡)

用 Linux 内核集群实现的一个高性能、高可用的负载平衡服务器，具备很好的可伸缩性，可靠性和可管理性

四层负载平衡服务器在承受到客户端申请后，通过批改数据包的地址信息（IP+ 端口号）将流量转发到应用服务器

长处

• 抗负载能力强，在负载平衡软件里的性能最强的，对内存和 cpu 资源耗费比拟低
• 工作稳固，本身有残缺的双机热备计划，如LVS+Keepalived，然而我的项目施行中用得最多的还是LVS/DR+Keepalived
• 无流量，LVS只散发申请，而流量并不从它自身进来，这点保障了均衡器 IO 的性能不会收到大流量的影响
• 利用范畴比拟广，工作在OSI 4 层，所以它简直能够对所有利用做负载平衡，包含http、数据库、在线聊天室等等

毛病

• 软件自身不反对正则表达式解决，不能做动静拆散
• 施行操作简单，技术难度高

HAProxy负载平衡(七层 / 四层负载平衡)

收费的负载平衡软件，能够运行于大部分支流的 Linux 操作系统上，HAProxy提供了 四层 (TCP) 和七层 (HTTP) 负载平衡能力，具备丰盛的性能

长处

• 反对 TCP 协定的负载平衡转发
• 反对 Session 的放弃，Cookie的疏导，同时反对通过获取指定的 url 来检测后端服务器的状态
• 反对虚拟主机的
• 反对负载平衡策略十分多

毛病

• 不反对 HTTP cache 性能
• 重载配置的性能须要重启过程
• 多过程模式反对不够好

IP负载平衡(三层负载平衡)

负载平衡服务器对外仍然提供一个浮动 IP，但集群中不同的机器采纳不同的IP 地址，当负载平衡服务器承受到申请之后，依据不同的负载平衡算法，通过 IP 将申请转发至不同的实在服务器，在网络层通过批改申请指标 IP 地址进行负载

长处

• 在内核过程实现数据散发，比在应用层散发性能更好

毛病

• 所有申请响应都须要通过负载平衡服务器，集群最大吞吐量受限于负载平衡服务器网卡带宽

链路层负载平衡(二层负载平衡)

负载平衡服务器对外仍然提供一个浮动 IP，配置实在物理服务器集群所有机器虚构IP 和负载平衡服务器 IP 地址统一，集群中不同的机器采纳雷同 IP 地址，但机器的 MAC 地址不一样，当负载平衡服务器承受到申请之后，通过改写报文的指标 MAC 地址的形式将申请转发到指标机器实现负载平衡，达到不批改数据包的源地址和指标地址，进行数据散发的目标

长处

• 性能好

毛病

• 配置简单

负载平衡算法

负载均衡器通过负载平衡算法决定申请转发到哪台设施

• 轮询Round Robin

  程序循环将申请一次程序循环地连贯每个服务器，以轮询的形式顺次申请调度不同的服务器；实现时，个别为服务器带上权重

​ 长处：服务器申请数目雷同；实现简略、高效；易程度扩大

​ 毛病：服务器压力不一样，不适宜服务器配置不同的状况；申请到目标结点的不确定，造成其无奈实用于有写操作的场景

​ 利用场景：数据库或应用服务层中只有读的场景

• 比率Ratio

​ 给每个服务器调配一个加权值为比例，根椐这个比例，把用户的申请调配到每个服务器

• 优先权Priority

​ 给所有服务器分组，给每个组定义优先权，当最高优先级中所有服务器呈现故障，将申请送给次优先级的服务器组，这种形式，理论为用户提供一种热备份的形式

• 起码连贯

​ 将申请调配到连接数起码的服务器

​ 长处：依据服务器以后的申请解决状况，动态分配

​ 毛病：算法实现绝对简单，须要监控服务器申请连接数

• 最快模式Fastest

​ 传递连贯给那些响应最快的服务器

• 察看模式Observed

  连贯数目和响应工夫这两项的最佳均衡为根据为新的申请抉择服务器

• 预测模式Predictive

​ 利用收集到的服务器以后的性能指标，进行预测剖析，抉择一台服务器在下一个工夫片内，其性能将达到最佳的服务器相应用户的申请

• 动静性能调配Dynamic Ratio-APM

​ 依据收集到的应用程序和应用服务器的各项性能参数，动静调整流量调配

• 动静服务器补充Dynamic Server Act

​ 当主服务器群中因故障导致数量缩小时，动静地将备份服务器补充至主服务器群

• 服务质量QoS

​ 按不同的优先级对数据流进行调配

• 服务类型ToS

​ 按不同的服务类型（在 Type of Field 中标识）负载平衡对数据流进行调配

基于主机资源的零碎负载平衡

前述所有负载平衡和算法策略，都是针对负载均衡器的，利用于短期执行工作（广泛是 10 秒或者 1 分钟这样短期内做出应答的服务），对于长期执行的工作，同时会耗费大量资源的负载平衡不是很实用于下面的负载平衡技术，最佳的解决方案是参考 k8s pod 调度策略的基于主机资源的零碎负载平衡（寰球最强的超大规模集群编排解决方案，有着谷歌数十年的超大规模集群运维零碎教训与验证，是集群编排技术的大一统）

k8s调度器

在 Kubernetes 中，调度是指将 Pod 搁置到适合的节点上，以便对应节点上的 Kubelet可能运行这些Pod

调度器通过 Kubernetes 的监测 Watch 机制来发现集群中新创建且尚未被调度到节点上的Pod，调度器会将所发现的每一个未调度的Pod 调度到一个适合的节点上来运行

pod调度步骤

1. 过滤阶段：过滤阶段会将所有满足 Pod 调度需要的 Node 选出来，例如，PodFitsResources 过滤函数会查看候选Node 的可用资源是否满足 Pod 的资源申请，在过滤之后，得出一个Node 列表，外面蕴含了所有可调度节点；通常状况下，这个Node 列表蕴含不止一个Node，如果这个列表是空的，代表这个Pod 不可调度

   执行的过滤规定

   • PodFitsHostPorts：查看 Node 上是否不存在以后被调度 Pod 的端口，如果被调度 Pod 用的端口已被占用，则此 Node 被Pass
   • PodFitsResources：查看 Node 是否有闲暇资源 (如CPU 和内存)以满足 Pod 的需要
   • CheckNodeMemoryPressure：对于内存有压力的Node，则不会被调度Pod
   • CheckNodePIDPressure：对于过程 ID 有余的Node，则不会调度Pod
   • CheckNodeDiskPressure：对于磁盘存储已满或者靠近满的Node，则不会调度Pod

2. 打分阶段：在过滤阶段后调度器会为Pod 从所有可调度节点中选取一个最合适的Node，依据以后启用的打分规定，调度器会给每一个可调度节点进行打分，最初，kube-scheduler 会将Pod 调度到得分最高的Node 上，如果存在多个得分最高的Node，kube-scheduler 会从中随机选取一个

   打分规定

   • SelectorSpreadPriority：优先缩小节点上属于同一个 Service 或 Replication Controller 的 Pod 数量
   • InterPodAffinityPriority：优先将 Pod 调度到雷同的拓扑上（如同一个节点、Rack、Zone 等）
   • LeastRequestedPriority：节点上搁置的 Pod 越多，这些 Pod 应用的资源越多，这个 Node 给出的打分就越低，所以优先调度到 Pod 少及资源应用少的节点上
   • MostRequestedPriority：尽量调度到曾经应用过的 Node 上，将把打算的 Pods 放到运行整个工作负载所需的最小节点数量上
   • BalancedResourceAllocation：优先均衡各节点的资源应用

参考浏览

负载平衡算法及计划 - 知乎

Nginx、HAProxy、LVS三者的优缺点 - 博客园

解决 k8s 调度不平衡问题

这应该是最全的 K8s-Pod 调度策略了 - 腾讯云

Kubernetes 调度器 -k8s官网文档