微服务入门（四） | 基础概念理解 | 负载均衡概述

目录

定义

目的

架构图

服务端负载均衡

客户端负载均衡

实现原理

服务端清单

服务端负载均衡的存放

客户端负载均衡的存放

常见的负载均衡方式

服务端——负载均衡实现方式

客户端——负载均衡算法

Reference

---

• 定义

负载均衡是指将负载（工作任务）进行平衡、分摊到多个操作单元上进行运行，例如FTP服务器、Web服务器、企业核心应用服务器和其它主要任务服务器等，从而协同完成工作任务。

负载均衡可以分为服务端负载均衡、客户端负载均衡，通常所说的负载均衡都指的是服务端负载。

• 目的

负载均衡是对系统的高可用、网络压力的缓解和处理能力扩容的重要手段之一。

负载均衡在系统架构中是一个非常重要，并且是不得不去实施的内容。

• 架构图

  • 服务端负载均衡

服务端负载均衡分为硬件负载均衡和软件负载均衡。

硬件负载均衡主要通过在服务器节点之间按照专门用于负载均衡的设备，比如F5等；而软件负载均衡则是通过在服务器上安装一些用于负载均衡功能或模块等软件来完成请求分发工作，比如LVS、Nginx等。

 

• • 客户端负载均衡

相比较服务器负载均衡而言，客户端负载均衡是一个非常小众的概念，客户端负载均衡是在spring-cloud分布式框架组件Ribbon中定义的。

我们在使用spring-cloud分布式框架时，同一个服务大概率同时启动多个，当一个请求过来时，Ribbon通过策略决定本次请求使用哪一个服务的方式就是客户端负载均衡。

 

• 实现原理

服务端清单 + 负载均衡算法

• • 服务端清单

客户端负载均衡与服务端负载均衡的主要区分点在于服务清单的存放位置。

• • • 服务端负载均衡的存放

      • 服务器负载均衡服务列表由中间服务单独维护。
      • 硬件负载均衡的设备或是软件负载均衡的软件模块都会维护一个下挂可用的服务端清单，通过心跳检测来剔除故障的服务端节点以保证清单中都是可以正常访问的服务端节点。

    • 客户端负载均衡的存放

      • 所有客户端节点都维护着自己要访问的服务端清单。
      • 这些服务端清单来自于服务注册中心，例如 Eureka Server。
      • 通过心跳检测来维护服务端清单的健康性，默认会创建针对各个服务治理框架的Ribbon 自动化整合配置。

  • 常见的负载均衡方式

    • 服务端——负载均衡实现方式

      • DNS域名解析负载均衡

        • 假设我们的域名指向了多个IP地址，当一个域名请求来时，DNS服务器机进行域名解析将域名转换为IP地址是在1:N的映射转换中实现负载均衡。
        • DNS服务器提供简单的负载均衡算法，但当其中某台服务器出现故障时，通知DNS服务器移除当前故障IP。

      • 反向代理负载均衡

        • 反向代理只指对服务器的代理，代理服务器接受请求，通过负载均衡算法，将请求转发给后端服务器，后端服务返回给代理服务器然后代理服务器返回到客户端。
        • 反向代理服务器的优点是隔离后端服务器和客户端，使用双网卡屏蔽真实服务器网络，安全性更好。
        • 相比较于DNS域名解决负载均衡，反向代理在故障处理方面更灵活，支持负载均衡算法的横向扩展。
        • 目前使用非常广泛，但也需要考虑很多问题，比如单点故障，集群部署等。

      • IP负载均衡

        • LVS-NAT
          • LVS-NAT是一种位于传输层的负载均衡，它通过修改接受的数据包目标地址的方式实现负载均衡。
          • Linux2.6.x以后版本内置了IPVS，专注用于实现IP负载均衡，故而在Linux上IP负载均衡使用非常广泛。
        • LVS-DR
          • LVS-DR工作在数据链路层，比LVS-NAT更霸道的时候它直接修改数据包的MAC地址。
        • LVS-TUN
          • LVS-TUN是基于IP隧道的请求转发机制，将调度器收到的IP数据包进行封装，转交给服务器，然后服务器返回数据，通过调度器实现负载均衡。这种方式支持跨网段调度。
        • 总结
          • 反向代理位于应用层（HTTP），本身开销相对大一些，对性能有一定影响，LVS在更底层，更有优势。
          • LVS-DR和LVS-TUN都适合响应和请求不对称的Web服务器，如何从它们中做出选择，取决于你的网络部署需要，因为LVS-TUN可具有跨地域性，有类似这种需求的，就应该选择LVS-TUN。

    • 客户端——负载均衡算法

当客户端发送请求到负载均衡设备的时候，该设备按某种算法（比如线性轮询、按权重负载、按流量负载等）从维护的可用服务端清单中取出一台服务端端地址，然后进行转发。这种算法就是负载均衡算法。

• • • • 静态负载均衡算法

        • 轮询（Round Robin）
          • 顺序循环将请求一次顺序循环地连接每个服务器。
          • 当其中某个服务器发生第二到第七层的故障，BIG-IP 就把其从顺序循环队列中拿出，不参加下一次的轮询，直到其恢复正常。
        • 比率（Ratio）
          • 给每个服务器分配一个加权值为比例，根椐这个比例，把用户的请求分配到每个服务器。
          • 当其中某个服务器发生第二到第七层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配, 直到其恢复正常。
        • 优先权（Priority）
          • 给所有服务器分组，给每个组定义优先权。
          • BIG-IP 用户的请求，分配给优先级最高的服务器组（在同一组内，采用轮询或比率算法，分配用户的请求）；当最高优先级中所有服务器出现故障，BIG-IP 才将请求送给次优先级的服务器组。
          • 实际为用户提供一种热备份的方式。

      • 动态负载均衡算法

        • 最少的连接方式（Least Connection）
          • 传递新的连接给那些进行最少连接处理的服务器。
          • 当其中某个服务器发生第二到第七层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配, 直到其恢复正常。
        • 最快模式（Fastest）
          • 传递连接给那些响应最快的服务器。
          • 当其中某个服务器发生第二到第七层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。
        • 观察模式（Observed）
          • 连接数目和响应时间以这两项的最佳平衡为依据为新的请求选择服务器。
          • 当其中某个服务器发生第二到第七层的故障，BIG-IP就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。
        • 预测模式（Predictive）
          • BIG-IP利用收集到的服务器当前的性能指标，进行预测分析，选择一台服务器在下一个时间片内，其性能将达到最佳的服务器相应用户的请求。
        • 动态性能分配(Dynamic Ratio-APM)
          • BIG-IP 收集到的应用程序和应用服务器的各项性能参数，动态调整流量分配。
        • 动态服务器补充(Dynamic Server Act.)
          • 当主服务器群中因故障导致数量减少时，动态地将备份服务器补充至主服务器群。
        • 服务质量(QoS）
          • 按不同的优先级对数据流进行分配。
        • 服务类型(ToS)
          • 按不同的服务类型（在Type of Field中标识）负载均衡对数据流进行分配。
        • 规则模式
          • 针对不同的数据流设置导向规则，用户可自行。

• Reference

• Ribbon详解

https://www.jianshu.com/p/1bd66db5dc46

• 终于把服务器负载均衡和客户端负载均衡讲清楚了

https://www.cnblogs.com/gucb/p/11237765.html

• 什么是负载均衡？

https://www.cnblogs.com/fanBlog/p/10936190.html

• 微服务负载均衡技术

https://www.cnblogs.com/x-jingxin/p/12922987.html