Ribbon负载均衡

简介: 本文深入讲解Spring Cloud中Ribbon实现客户端负载均衡的原理,涵盖负载均衡概念、分类、常见算法,详解@LoadBalanced注解的作用机制,演示如何自定义策略及配置饥饿加载,并对比不同技术实现方式,帮助读者全面理解微服务负载均衡核心知识。

在上一节我们引入Eureka的同时,不知读者朋友们是否还有印象:我们在启动类getRestTemplate方法上追加了注解 @LoadBalanced,为什么加这个注解?这个注解解决了什么问题?本节笔者将给读者们做详尽的讲解。

1.负载均衡

1.1 什么是负载均衡

传统架构下的网站,随着流量的增加,高并发、海量数据的挑战逐步而来。为了提升系统的性能,架构师们往往开始从垂直扩展、水平扩展两个角度来解决问题:

垂直扩展

网站发展的早期可以通过增加服务器的硬件处理能力:CPU、内存、磁盘等方面提升服务器处理的能力,然而单机的瓶颈总是存在的,一旦触及瓶颈想再提升,付出的成本会极高,显然这不符合分布式系统的设计理念。

水平扩展

通过集群部署的方式,将一台服务器的请求压力,分摊到多台机器上,集群中的应用服务器通常被设计成无状态。但是如何将流量均匀分摊到各机器上,或优先分配到高性能机器上又成了一个问题,由此引申出“负载均衡”的概念。

负载均衡(Load Balance)是如今高并发、高可用系统中不可或缺的关键组件,目标是:尽力将用户流量按照架构设计分发(并非一定均匀)到集群中多台服务器上,从而提高系统整体的响应速度和可用性。

1.2 负载均衡分类

硬件负载均衡(包括但不限于)

  • F5
  • A10

软件负载均衡(包括但不限于)

  • Nginx
  • HAProxy
  • LVS

1.3 负载均衡算法

为不影响章节重点,需做进一步了解的可移步:负载均衡算法

2.Ribbon如何实现负载均衡

Ribbon与大多数负载均衡实现机制一样在客户端实现(不同于后续我们讲解的Nacos,Nacos在服务端实现),其主要流程为:

  • 在RestTemplate标注@LoadBalanced注解,此时通过RestTemplate发起的RESTful请求都会被负载均衡
  • 当请求发起时,会被LoadBalancedInterceptor拦截,其主要实现两个功能:
  • 从多个可用Server中选择一个Server,选择算法即上述1.3中之一
  • 重构请求URI:服务名-->具体ip、端口
  • LoadBalancerClient内部持有LoadBalancer并调用getServer方法得到一个Server,而这个Server是通过Eureka服务注册,ILoadBalancer持有的upServerList、allServerList中获取(底层依赖ServerListUpdater动态更新所有serverList)

完整源码交互流程总结如下,感兴趣的可做进一步研究:

3.Ribbon自定义负载均衡策略

1.代码声明式注册

在启动类追加以下代码即可,此优先级更高,但修改必须重启应用,且全局生效

@Bean
public IRule getRandomRule() {
    return new RandomRule();
}

通过查看IRule实现类,可以做其余负载均衡实现方案的更多测试

2.配置文件声明式配置

此配置优点在于不用重启应用,打包发布,但缺点是无法做到全局配置,必须声明规则对应的服务

userservice: # 给某个微服务配置负载均衡规则,这里是userservice服务
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则

4.Ribbon饥饿加载

在上述的测试中不知是否有读者发现:当请求第一次到某个实例时,其响应速度明细要慢一点,这里就是因为Ribbon默认采用饥饿加载,只有访问时才会创建LoadBalanceClient,从而导致第一次时间要长点,日志如下:

  • 修改饥饿加载前启动日志

  • 修改饥饿加载前访问日志

修改饥饿加载机制,通过在配置文件中追加以下配置即可

ribbon:
  eager-load:
    enabled: true  # 开启饥饿加载
    clients: userservice # 指定饥饿加载服务
  • 修改饥饿加载后启动日志

  • 修改饥饿加载后访问日志

至此我们的工程如下,有需自行下载导入📎cloud.zip

5.总结

上一节就已经实现的负载均衡笔者并未深入探讨,本节通过分析负载均衡算法、Ribbon实现负载均衡的底层原理和实现过程,让大家对负载均衡有了一个大体认识,同时针对Ribbon自定义负载均衡策略,饥饿加载让大家对于Ribbon的了解又多一些。Ribbon实现的负载均衡只是方案之一,我们可以尽量多了解但不要局限于此。

负载均衡作为现如今架构必须考量的一个点,要了解和深入学习的地方还很多,如下一节我们要学习的Nacos是怎么实现的?它为什么反其道而行要在服务端实现?ZK也可作为注册中心它是怎么实现的?网关GateWay也可做负载均衡它又是怎么实现的呢?篇幅问题,更多的答案留给读者朋友们在未来的工作生涯中慢慢思考。


思考问题

  • Ribbon是什么?解决了什么问题?
  • Ribbon实现的是客户端,还是服务端负载均衡?
  • Ribbon如何实现负载均衡?
  • 还有哪些技术点可以实现负载均衡?
  • 负载均衡算法?如何实现?还有哪些技术有体现
相关文章
|
3月前
|
Java 测试技术 数据库
Spring Boot中的项目属性配置
本文介绍Spring Boot中配置管理的常用方法:通过`@Value`读取单个配置,使用`@ConfigurationProperties`封装多个配置项,并实现开发与生产环境配置文件(如application-dev.yml和application-pro.yml)的灵活切换,提升项目可维护性。
|
3月前
|
SQL 关系型数据库 数据库
分布式事务
本文介绍了分布式事务的概念、典型场景及解决方案。在微服务架构下,一次业务操作需跨多个数据库和远程调用协作完成,传统本地事务无法保证整体一致性。通过Seata框架可实现分布式事务控制,其AT模式无侵入、高性能,基于两阶段提交与undo log实现最终一致;XA模式则提供强一致性但性能较低。文章还结合下单、支付等场景演示了Seata的集成与应用。
|
3月前
|
缓存 JSON 前端开发
Spring Boot集成Thymeleaf模板引擎
Thymeleaf 是现代Java模板引擎,支持静态原型与动态数据融合,可直接浏览器预览,提升前后端协作效率,适用于Spring Boot项目,实现页面自然展示与高效开发。
Spring Boot集成Thymeleaf模板引擎
|
3月前
|
JSON 缓存 Java
Spring Boot集成 Swagger2 展现在线接口文档
Swagger是一款用于生成和管理API文档的工具,解决前后端分离架构中接口文档更新不及时的问题。通过集成Swagger2,可自动生成在线接口文档,支持实时查看与测试接口,提升开发效率。本文介绍其在Spring Boot中的配置与常用注解使用方法。
|
3月前
|
存储 Java API
Spring Boot使用slf4j进行日志记录
本文介绍了在Spring Boot项目中使用SLF4J结合Logback进行日志管理的方法。通过配置`application.yml`和`logback.xml`,实现日志级别、输出格式、文件存储与滚动策略的灵活控制,并推荐使用SLF4J门面模式替代直接调用具体日志实现,提升系统可维护性与扩展性。
|
3月前
|
监控 Java Sentinel
熔断降级
熔断降级是防止服务雪崩的核心机制,通过Sentinel实现。熔断由客户端断路器统计异常或慢请求比例,超阈值后拦截请求;降级则返回默认数据保障体验。结合使用可快速失败、避免级联故障。
|
3月前
|
人工智能 监控 Java
请求限流
本文介绍如何使用Sentinel实现接口限流与降级,通过配置QPS阈值保护商品查询接口,并结合JMeter进行压测验证。同时讲解了线程隔离机制,包括信号量隔离的应用,确保系统在高并发下的稳定性。
请求限流
|
3月前
|
Java 关系型数据库 MySQL
Spring Boot事务配置管理
本文介绍了Spring Boot中事务的使用及常见陷阱。通过@Transactional注解可轻松实现事务管理,确保数据操作的原子性。重点剖析了三大易踩坑点:异常类型不匹配导致未回滚、try-catch吞掉异常、事务与锁范围不一致引发并发问题,助你在实际项目中有效规避风险。
|
3月前
|
XML Java 数据库连接
Spring Boot集成MyBatis
本文系统讲解Spring Boot集成MyBatis的两种方式:基于XML和注解。涵盖依赖配置、yml设置、驼峰命名映射,并详解@Select、@Insert等注解用法及@Param、@Results问题解决方案,结合实战示例,具有较强实用性,适用于日常开发参考。
|
3月前
|
监控 Java API
Spring Boot中的切面AOP处理
AOP(面向切面编程)旨在分离关注点,将核心业务与辅助逻辑解耦。通过Spring Boot中的@Aspect、@Pointcut、@Before、@After等注解,可实现日志记录、性能监控、事务管理等功能,提升代码模块化与可维护性,灵活应对业务变化。