【SpringCloud】Ribbon 负载均衡策略设置以及点对点直连

在这里插入图片描述

1、Ribbon 负载均衡策略设置

示例项目接上一篇文章:【SpringCloud】什么是 Ribbon 以及入门案例_风落_的博客-优快云博客

1.1、全局

在启动类或配置类中注入负载均衡策略对象。所有服务请求均使用该策略。

@Bean
public RandomRule randomRule() {
    return new RandomRule();
}

多次访问 http://localhost:9090/order/1,控制台打印的 服务提供者 ip 和端口号如下,即随机策略

image-20220511200057791

1.2、局部

修改配置文件指定服务的负载均衡策略。格式:服务应用名.ribbon.NFLoadBalancerRuleClassName: 对应策略类的全限定名(包名+类名)

# 负载均衡策略
# service-provider 为调用的服务的名称
service-provider:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

多次访问 http://localhost:9090/order/1,控制台打印的 服务提供者 ip 和端口号如下,即随机策略

image-20220511201338726

2、Ribbon 点对点直连

点对点直连是指绕过注册中心,直接连接服务提供者获取服务,一般在测试阶段使用比较多。

2.1、添加依赖

在 pom 文件中引入 ribbon,需要注意如果 pom 中有 eureka 的依赖,则需要去除 eureka 依赖

<!-- netflix-ribbon 依赖 -->
<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
</dependency>

2.2、配置文件

配置文件中关闭 eureka,添加直连的服务地址。如果不设置负载均衡策略默认使用轮询策略。

server:
  port: 9090 # 端口

spring:
  application:
    name: service-consumer # 注册名称

# 配置 Eureka Server 注册中心
#eureka:
#  client:
#    register-with-eureka: false # 是否将自己注册到注册中心,默认为 true
#    registry-fetch-interval-seconds: 10 # 表示 Eureka Client 间隔多久去服务器拉取信息,默认为 30 秒
#    service-url: # 设置服务注册中心地址
#      defaultZone: http://root:123456@localhost:8761/eureka/,http://root:123456@localhost:8762/eureka/

# 负载均衡策略
# service-provider 为调用的服务的名称
service-provider:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
    listOfServers: http://localhost:7070,http://localhost:7071

# 关闭 Eureka 实现 Ribbon 点对点直连
ribbon:
  eureka:
    enabled: false # false 关闭

image-20220511202746526

关闭 eureka 注册中心,服务提供者由于无法连接至注册中心所以会报连接异常,但是服务是可以正常消费的,所以目前使用的是点对点的方式进行调用的。

多次访问 http://localhost:9090/order/1,控制台打印的 服务提供者 ip 和端口号如下,即随机策略,因为我们配置的是随机策略,可以自行在配置文件中更改。

至此,Ribbon 的学习就告一段落了!继续加油!

<think>好的,我现在要回答用户关于客户端负载均衡和服务端负载均衡区别的问题。首先,我需要回顾一下已有的引用内容,确保准确理解两者的定义和特点。 根据引用[2]和[3],客户端负载均衡是由客户端自己选择服务器,而服务端负载均衡通过中间设备或软件分发请求。服务端负载均衡通常由专门的硬件(如F5)或软件(如Nginx)实现,维护可用服务器列表并通过心跳检测确保节点健康。客户端负载均衡的例子包括Spring Cloud Ribbon,它内置在客户端应用中,根据算法直接选择目标服务器。 接下来,我需要组织两者的区别点。根据引用[1]和[4],主要区别在于实现位置、维护主体、网络开销和适用场景。例如,客户端负载均衡减少了一次网络跳转,但增加了客户端的复杂性;服务端负载均衡对客户端透明,但可能成为瓶颈。 还要注意引用[5]提到的算法,如轮询、随机等,客户端负载均衡通常由这些算法驱动。需要指出服务端和客户端各自常用的算法,以及它们如何影响性能。 最后,确保回答结构清晰,分点对比,并举例说明,帮助用户更好理解。同时,生成的相关问题要围绕区别、优缺点、实现技术等展开,以便用户深入探索。</think>### 客户端负载均衡 vs 服务端负载均衡 区别与对比 #### 1. **实现位置与主体** - **客户端负载均衡** 由客户端(如应用程序)直接实现负载均衡逻辑。客户端通过内置算法(如轮询、随机等)从已知的服务端列表中动态选择目标服务器[^5]。例如,Spring Cloud Ribbon 在微服务架构中通过客户端库实现请求分发[^5]。 **特点**: - 客户端需维护可用服务端列表(如通过注册中心获取) - 减少一次网络跳转(无需经过独立负载均衡设备) - 适用于高动态、分布式场景(如微服务)[^2] - **服务端负载均衡** 通过独立的中间层(硬件或软件)实现请求分发。例如,Nginx、F5 等设备或工具接收客户端请求后,按规则转发至后端服务器[^3]。 **特点**: - 负载均衡逻辑对客户端透明 - 需额外维护负载均衡服务器(可能成为单点瓶颈) - 适用于传统架构或需要集中管理的场景[^3] --- #### 2. **核心差异对比** | **维度** | **客户端负载均衡** | **服务端负载均衡** | |------------------|-----------------------------------------------------------------------------------|-----------------------------------------------------------------------------------| | **实现位置** | 客户端内部(如应用代码、SDK) | 独立中间层(硬件设备或专用软件) | | **网络开销** | 客户端直连目标服务器,减少中间节点 | 请求需先经过负载均衡设备,增加一跳网络延迟 | | **可维护性** | 客户端需集成负载均衡逻辑,升级复杂 | 集中管理配置,易于维护和扩展 | | **适用场景** | 微服务、动态扩缩容场景(如Kubernetes + Ribbon) | 传统Web服务、静态服务器集群(如Nginx反向代理) | | **算法灵活性** | 支持自定义算法(如一致性哈希、最小连接数)[^4] | 依赖负载均衡设备的预设算法(如加权轮询、IP哈希) | | **单点故障风险** | 无中心节点依赖,但客户端需自行处理服务端故障 | 负载均衡设备故障可能导致整个系统不可用(需通过集群缓解) | --- #### 3. **典型技术实现** - **客户端负载均衡** - **Spring Cloud Ribbon**:基于客户端库的负载均衡,支持轮询、随机等算法。 - **gRPC客户端负载均衡**:通过Name Resolver和LoadBalancer接口动态选择服务实例。 - **示例代码逻辑**(伪代码): ```python def choose_server(servers, algorithm="round_robin"): if algorithm == "random": return random.choice(servers) # 其他算法实现... ``` - **服务端负载均衡** - **Nginx**:通过`upstream`配置定义服务器组,支持加权轮询、IP哈希等[^3]。 - **AWS ALB(应用负载均衡器)**:基于HTTP/HTTPS的七层负载均衡,支持路径路由。 --- #### 4. **选择建议** - 选择**客户端负载均衡**若: - 系统需高频动态扩缩容 - 减少网络延迟是关键需求 - 客户端具备较强的容错能力(如重试、熔断)[^1] - 选择**服务端负载均衡**若: - 需要统一管理流量策略(如SSL终止、全局限速) - 后端服务相对稳定,无需频繁变更 - 客户端无法修改(如遗留系统)[^3] ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

风落_

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值