【SpringCloud(3)】Ribbon负载均衡:IRule原理轮询算法;LB负载均衡;loadbalancer和IRule组件;Ribbon和Ngin负载均衡的区别

本文涉及的产品
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,182元/月
简介: Spring Cloud Ribbon 是基于Netflix Ribbon实现的一套客户端的负载均衡工具简单地说,Ribbon是Netflix发布的开源项目,主要功能是提供客户端的软件负载均衡算法和服务调用。Ribbon客户端组件提供一系列完善的配置项如连接超时、重试等。就在在配置文件中列出Load Balancer(LB)后面所有的机器,Ribbon会自动的帮助你基于某种规则(如简单轮询,随机链接等)去连接这些机器。我们很容易使用Ribbon实现自定义的负载均衡算法

1. Ribbon 负载均衡

Spring Cloud Ribbon 是基于Netflix Ribbon实现的一套客户端的负载均衡工具

简单地说,Ribbon是Netflix发布的开源项目,==主要功能是提供客户端的软件负载均衡算法和服务调用==。Ribbon客户端组件提供一系列完善的配置项如连接超时、重试等。就在在配置文件中列出Load Balancer(LB)后面所有的机器,Ribbon会自动的帮助你基于某种规则(如简单轮询,随机链接等)去连接这些机器。我们很容易使用Ribbon实现自定义的负载均衡算法

  • Ribbon在工作时分成两步:
    1. 先选择EurekaServer,它优先选择在同一个区域内负载较少的server
    2. 再根据用户指定的策略,再从server取到的服务注册列表中选择一个地址

Ribbon提供了多种策略:比如轮询、随机和根据响应时间加权

没有引入Ribbon其实也可以进行使用

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-raibbon</artifactId>
</dependency>

在引入较新版本的Eureka时就内部自带了Rabibbon

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

1.1 LB负载均衡是什么?

简答说就是将用户的请求平摊的分配到多个服务上,从而达到系统的HA(高可用)

常见的负载均衡有软件Nginx,LVS,硬件F5等

1.2 Ribbon本地负载客户端 和 Nginx服务端负载均衡的区别

Nginx是服务器负载均衡,客户端所有请求都会交给Nginx,然后由nginx实现转发请求。即负载均衡是由服务端实现的。

Ribbon本地负载均衡,在调用微服务接口的时候,会在注册中心上获取注册信息服务列表之后缓存到JVM本地,从而在本地实现RPC远程服务调用技术。

1.3 集中式LB(以请求为主)

  • 即在服务的消费方和提供方之间使用独立的LB设施(可以是硬件,如F5,也可以是软件,如Nginx),由该设施负载把访问请求通过某种策略转发至服务的提供方。

1.4 进程内LB(以本地调用为主)

  • 将LB逻辑集成到消费方,消费方从服务注册中心获知有哪些地址可用,然后自己再从这些地址中选择出一个合适的服务器
  • Ribbonb就属于进程内LB,它只是一个类库,集成于消费方进程,消费方通过它来获取到服务提供方的地址

2. 使用Ribbon —— IRule组件

如果在使用自定义负载均衡时报错,大概率是因为版本问题。springcloud在2020.0.0之后,移除掉了netflix-ribbon 使用eureka-client中的loadbalancer,使用自定义负载均衡不使用IRule接口。官方文档上有写,可以写一个配置类,可以与启动类同级

创建一个Config类:

package com.renex.springcloud.config;

import org.springframework.cloud.client.ServiceInstance;
import org.springframework.cloud.loadbalancer.core.RandomLoadBalancer;
import org.springframework.cloud.loadbalancer.core.ReactorLoadBalancer;
import org.springframework.cloud.loadbalancer.core.ServiceInstanceListSupplier;
import org.springframework.cloud.loadbalancer.support.LoadBalancerClientFactory;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.env.Environment;

@Configuration
public class CustomerLoadBalancerConfiguration {
   

    @Bean
    ReactorLoadBalancer<ServiceInstance> randomLoadBalancer(Environment environment, LoadBalancerClientFactory loadBalancerClientFactory) {
   
        String name = environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);

        return new RandomLoadBalancer(loadBalancerClientFactory.getLazyProvider(name, ServiceInstanceListSupplier.class), name);
    }

}

再注册RestTemplate的类上添加上@LoadBalanceClient注解

@Configuration
@LoadBalancerClient(name = "CLOUD-PAYMENT-SERVICE",configuration = CustomerLoadBalancerConfiguration.class)
public class ApplicatonContextConfig {
   

    /**
     * 获得RestTemplate;通过注解方式注入进IOC中
     *
     * @return
     */
    @Bean
    @LoadBalanced// 开启负载均衡
    public RestTemplate getRestTemplate() {
   
        return new RestTemplate();
    }
}

@LoadBalancerClient(name = "提供者名称",configuration = CustomerLoadBalancerConfiguration.class)

3. IRule 原理

负载均衡算法:
rest接口第几次请求书 % 服务器集群总数量 = 实际调用服务器位置下标,每次服务重启后rest接口计数从1开始

List<ServiceInstance> instances = discoveryClient.getInstances("CLOUD_PAYMENT_SERVICE");

当8001+8002组合成集群,它们共计2台机器,集群总数未2,按照轮询算法原理:

  • 当总请求数为1时:1%2=1 对应下标位置为1,则获得服务地址为127.0.0.1:8001
  • 当总请求数为2时:2%2=0 对应下标位置为0,则获得服务地址为127.0.0.1:8002
  • 当总请求数为3时:3%2=1 对应下标位置为1,则获得服务地址为127.0.0.1:8001
  • 当总请求数为4时:4%2=0 对应下标位置为0,则获得服务地址为127.0.0.1:8002
  • ...如此类推

🥸🏏SpringCloud微服务专栏

  1. 【SpringCloud(1)】初识微服务架构:创建一个简单的微服务;java与Spring与微服务;初入RestTemplate

💕👉博客专栏

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
目录
相关文章
|
1月前
|
负载均衡 算法 Java
【SpringCloud(2)】微服务注册中心:Eureka、Zookeeper;CAP分析;服务注册与服务发现;单机/集群部署Eureka;连接注册中心
1. 什么是服务治理? SpringCloud封装了Netfix开发的Eureka模块来实现服务治理 在传统pc的远程调用框架中,管理每个服务与服务之间依赖关系比较复杂,管理比较复杂,所以需要使用服务治理,管理服务于服务之间依赖关系,可以实现服务调用、负载均衡、容错等,实现服务发现与注册
201 1
|
1月前
|
算法 Java 微服务
【SpringCloud(1)】初识微服务架构:创建一个简单的微服务;java与Spring与微服务;初入RestTemplate
微服务架构是What?? 微服务架构是一种架构模式,它提出将单一应用程序划分为一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。 每个服务允许在其独立的进程中,服务于服务间采用轻量级的通信机制互相协作(通常是Http协议的RESTful API或RPC协议)。 每个服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环境、类生产环境等。另外应当尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据上下文,选择合适的语言、工具对其进行构建
416 127
|
1月前
|
负载均衡 算法 Java
【SpringCloud(4)】OpenFeign客户端:OpenFeign服务绑定;调用服务接口;Feign和OpenFeign
Feign是一个WebService客户端。使用Feign能让编写WebService客户端更加简单。 它的使用方法是定义一个服务接口然后再上面添加注解。Feign也支持可拔插式的编码器和解码器。SpringCloud对Feign进行了封装,十七支持了SpringMVC标准注解和HttpMessageConverters。 Feign可用于Eureka和Ribbon组合使用以支持负载均衡
605 138
|
1月前
|
负载均衡 算法 Java
【SpringCloud(5)】Hystrix断路器:服务雪崩概念;服务降级、服务熔断和服务限流概念;使用Hystrix完成服务降级与服务熔断
多个微服务之间的调用,结社微服务A调用微服务B和微服务C,微服务B和微服务C有调用其他的微服务,这就是所谓的“扇出”如果扇出的链路上某个微服务的调用响应时间过长或者不可用,对微服务A的调用就会占用越来越多的系统资源,进而引起系统崩溃,所以的 “雪崩效应”
454 138
|
2月前
|
存储 缓存 负载均衡
Gateway 网关坑我! 被这个404 问题折腾了一年?
小富分享了一个困扰团队一年多的 SpringCloud Gateway 路由 404 问题。通过日志追踪和源码分析,发现是网关在 Nacos 配置更新后未能正确清理旧的路由权重缓存,导致负载均衡时仍使用已删除的路由数据。最终通过监听路由刷新事件并手动更新缓存,成功解决了问题。
640 125
Gateway 网关坑我! 被这个404 问题折腾了一年?
|
1月前
|
NoSQL 关系型数据库 MySQL
改了 Nacos 一行配置,搞崩线上支付系统!
Nacos服务注册默认使用临时实例,通过心跳机制实时感知服务状态,适合支付、订单等动态业务。持久化实例由服务端探活,适用于MySQL、Redis等静态组件。配置中心所有配置均持久化,无“临时”概念,动态更新指内容变更而非生命周期短暂。正确理解差异,避免因`ephemeral=false`误配导致生产事故。
112 1
|
2月前
|
XML Java Nacos
Spring Boot 整合Nacos 版本兼容适配 史上最详细文档
本文介绍SpringBoot整合Nacos的完整流程,涵盖Nacos下载安装、配置中心与服务发现集成、版本兼容性问题及实战配置。重点解决SpringBoot 3.3.0与Nacos版本适配难题,推荐使用Spring Cloud Alibaba方案,并提供项目开源地址供参考学习。
|
18天前
|
人工智能 数据可视化 Java
Spring AI Alibaba、Dify、LangGraph 与 LangChain 综合对比分析报告
本报告对比Spring AI Alibaba、Dify、LangGraph与LangChain四大AI开发框架,涵盖架构、性能、生态及适用场景。数据截至2025年10月,基于公开资料分析,实际发展可能随技术演进调整。
1056 152
|
1月前
|
XML JSON Java
【SpringBoot(三)】从请求到响应再到视图解析与模板引擎,本文带你领悟SpringBoot请求接收全流程!
Springboot专栏第三章,从请求的接收到视图解析,再到thymeleaf模板引擎的使用! 本文带你领悟SpringBoot请求接收到渲染的使用全流程!
171 3
|
1月前
|
人工智能 监控 Java
零代码改造 + 全链路追踪!Spring AI 最新可观测性详细解读
Spring AI Alibaba 通过集成 OpenTelemetry 实现可观测性,支持框架原生和无侵入探针两种方式。原生方案依赖 Micrometer 自动埋点,适用于快速接入;无侵入探针基于 LoongSuite 商业版,无需修改代码即可采集标准 OTLP 数据,解决了原生方案扩展性差、调用链易断链等问题。未来将开源无侵入探针方案,整合至 AgentScope Studio,并进一步增强多 Agent 场景下的观测能力。
1241 32

热门文章

最新文章