《从 0 开始学架构》学习归整(八)高性能负载均衡:分类、架构及算法

内容纲要

单机性能再这么优化,总有极限。当单机性能达到极限后,要扩展系统的能力,需要通过构建集群的方式来解决。

高性能集群

高性能集群的本质就是通过增加服务器的数量来提升系统的整体计算能力。

复杂性

  • 增加任务分配器(负载均衡器)
    • “负载均衡”的名称有一定的误导性
      • 它不只是是为了计算单元的负载达到均衡状态
      • 不同的分配算法,有得基于负载,有的基于性能
  • 为分配器选择合适的任务分配算法

负载均衡的分类

DNS 负载均衡

一般用来实现地理级别的负载均衡。

图片标题

优点

  1. 简单,成本低:负载均衡工作交给 DNS 服务器处理,无需自己开发维护负载均衡
  2. 就近访问,提升访问速度:DNS 解析根据来源 IP,解析为最近的服务器地址

缺点

  1. 更新不及时:DNS 缓存时间较长,修改 NDS 后一段时间内,用户可能还是会访问到旧的配置的地址上
  2. 扩展性差:DNS 服务器在运营商手中,无法根据业务特点做更精细的控制
  3. 分配策略简单:DNS 支持的负载均衡算法少;不能区分系统与服务的状态来判断负载;无法感知后端服务状态

HTTP-DNS:使用 HTTP 实现一套私有的 DNS 系统,解决了公用 DNS 的缺点,但同时公有 DNS 的优点也变成了 HTTP-DNS 的缺点

硬件负载均衡

硬件负载均衡通过单独的硬件实现负载均衡。

优点

  1. 功能强大:支持膈肌负载均衡;支持全面负载均衡算法;支持全局负载均衡
  2. 性能强大:轻松支持百万并发(比软件负载均衡性能高出数倍)
  3. 稳定性高:商用负载均衡经过严格测试、大规模使用
  4. 支持安全防护:具备防火墙、防 DDoS 攻击功能

缺点

  1. 价格昂贵(是真的贵 ╮(╯▽╰)╭):小公司用不起,大公司可以考虑
  2. 扩展能力差:硬件设备通病

软件负载均衡

软件负载均衡通过软件来实现负载均衡。常见的如Nginx(7层负载均衡,支持 HTTP、E-mail 协议等)、LVS(4层负载均衡,和协议无关)等。7 层 和 4 层的差别在于协议灵活性

优点

  1. 部署维护简单
  2. 便宜(相比硬件负载均衡)
  3. 灵活:4 层 7 层可以根据业务进行选择;可以根据业务扩展(Nginx 插件等)

缺点

  1. 性能一般(相比硬件负载均衡)
  2. 功能欠缺(相比硬件负载均衡)
  3. 一般不具备安全防护功能

负载均衡的架构

负载均衡并非非此即彼的选择,他们可以进行组合。

基本原则:

  • DNS 负载均衡用于实现地理级别负载均衡
  • 硬件负载均衡用于实现集群级别负载均衡
  • 软件负载均衡用于实现机器级别负载均衡

图片标题

通常来说只有大型的系统才需要三者组合,大部分业务只需要其中一到两种即可。

负载均衡的算法

任务平分类

将任务平分到服务器上(按绝对平均或权重平均)。

轮询

负载均衡器收到请求后,按顺序轮流分配给不同的服务器。

优点
  • 简单
缺点
  • 简单
    • 不关注服务器本身状态(只要服务器在运行,运行状态不关注;服务器不在运行状态,则会进行相应处理)

加权轮询

负载均衡系统根据服务器权重进行分配(一般是静态分配;也可动态分配,但复杂度较高)。

优点
  • 可以根据服务器状态差异进行不同的分配策略
缺点
  • 不关注服务器本身状态(只要服务器在运行,运行状态不关注;服务器不在运行状态,则会进行相应处理)

负载均衡类

按服务器负载进行分配(CPU、内存、I/O 压力、网络吞吐等)。

不同场景有不同的分配衡量指标,如:

  • LVS(4 层)
    • 根据连接数判断;连接数越低,服务器压力越小
  • Nginx(7 层)
    • 根据 HTTP 请求数(Nginx 本身不支持,需要扩展来完成)等判断
  • 自研负载均衡
    • 根据不同的业务来判断(如:CPU 密集型,以 CPU 负载来判断;I/O 密集型,以 I/O 负载来判断)
优点
  • 解决负载均衡对服务器状态无感知问题(服务器负载)
缺点
  • 复杂度增加
    • 连接数负载判断:要求统计每个服务器当前建立的连接数,对于负载均衡和服务器系统之间是使用连接池方式的系统无效。
    • CPU 负载判断:要求负载均衡系统手机每个服务器的 CPU 使用状态;且标准不同(1 分钟负载;15 分钟负载等),时间过长有不准的风险,过短则消耗系统资源,且有频繁波动的情况

性能最优类

根据响应时间来分配,将任务分配到响应对快的服务器上。

优点
  • 解决负载均衡对服务器状态无感知问题(响应时间)
缺点
  • 复杂度增加
    • 响应时间判断:系统需要收集每个服务器的响应时间,这种操作本身消耗资源不少
      • 为了减少消耗,可以使用采样的方式;但会存在采样率不好确定等问题
        • 采样周期不好确定

Hash 类

将部分任务信息进行 Hash 运算,将相同的 Hash 值的任务分配到相同的服务器上。

源地址 Hash

  • 原理:将同一个 IP 来源的请求分配给同一个服务器进行处理
  • 场景:存在事务、会话的业务

ID Hash

  • 原理:将某 ID 标识的业务分配到同一服务器处理
  • 场景:会话业务、同类型任务等
优点
  • 简单
缺点
  • 服务器数量动态增加场景下,分配策略可能需要动态调整(较复杂)

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注