【云原生&微服务二】SpringCloud之Ribbon自定义负载均衡策略(含Ribbon核心API)

本文涉及的产品
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 【云原生&微服务二】SpringCloud之Ribbon自定义负载均衡策略(含Ribbon核心API)

@[TOC]

一、前置知识

在前一篇文章【云原生&微服务一】SpringCloud之Ribbon实现负载均衡详细案例(集成Eureka、Ribbon)我们讨论了SpringCloud如何集成Eureka和Ribbon,本文就在其基础上讨论一下如何自定义Ribbon的负载均衡策略、以及Ribbon的核心API。

二、Ribbon核心API

博主习惯性的在深入研究一门技术的时候去GitHub上看文档,然而Ribbon在GitHub上的文档(https://github.com/Netflix/ribbon)真的是没啥可看的;就给了一个demo和Release notes。

Ribbon有三个核心接口:ILoadBalancer、IRule、IPing,其中:

  1. ILoadBalancer是负载均衡器;
    在这里插入图片描述
  2. IRule 复杂负载均衡的规则,ILoadBalancer根据其选择一个可用的Server服务器;
    在这里插入图片描述
  3. IPing负责定时ping每个服务器,判断其是否存活。
    在这里插入图片描述

三、自定义负载均衡策略IRule

1、编写IRule实现类

MyRule重写IRule的choose(Object o)方法,每次都访问List<Server>中第一个服务实例;

import com.netflix.loadbalancer.ILoadBalancer;
import com.netflix.loadbalancer.IRule;
import com.netflix.loadbalancer.Server;

import java.util.List;

/**
 * 自定义负载均衡规则,只用第一个实例;
 *
 * @author Saint
 */
public class MyRule implements IRule {

    private ILoadBalancer loadBalancer;

    @Override
    public Server choose(Object o) {
        final List<Server> allServers = this.loadBalancer.getAllServers();
        return allServers.get(0);
    }

    @Override
    public void setLoadBalancer(ILoadBalancer iLoadBalancer) {
        this.loadBalancer = iLoadBalancer;
    }

    @Override
    public ILoadBalancer getLoadBalancer() {
        return loadBalancer;
    }
}

==注意:一般很少需要自己定制负载均衡算法的,除非是类似hash分发的那种场景,可以自己写个自定义的Rule,比如说,每次都根据某个请求参数,分发到某台机器上去。不过在分布式系统中,尽量减少这种需要hash分发的情况。==

下面我接着看如何把自定义的MyRule应用到指定的服务上 或 全部服务上。

2、编写Ribbon配置类

在Ribbon配置类中通过@Bean注解将自定义的IRule实现类MyRule注入到Spring容器中。

import com.netflix.loadbalancer.IRule;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * 自定义Ribbon配置
 *
 * @author Saint
 */
@Configuration
public class MyRibbonConfiguration {

    @Bean
    public IRule getRule() {
        return new MyRule();
    }
}

3、应用到全部服务上(Ribbon全局配置)

Ribbon全局配置有两种方式:一种是依赖Spring的自动扫描、一种是依赖@RibbonClients注解。

1)Spring的自动扫描

所谓Spring的自动扫描,就是将自定义的Ribbon配置类放在Spring容器可以扫描到的包目录下即可。
在这里插入图片描述
如上图所示,程序的启动类RibbonFeignSampleConsumerApplication所在的目录为com.saint,Ribbon配置类MyRibbonConfiguration 所在的目录为com.saint.config;又因没有指定包扫描的路径,所以目录会扫描启动类所在的包com.saint,因此Spring可以自动扫描到MyRibbonConfiguration、进而扫描到MyRule。

注意:Ribbon的配置类一定不能Spring扫描到。因为Ribbon有自己的子上下文,Spring的父上下文如果和Ribbon的子上下文重叠,会有各种各样的问题。比如:Spring和SpringMVC父子上下文重叠会导致事务不生效。

==所以不推荐使用这种方式。==

2)@RibbonClients注解

在启动类所在目录的父目录(com.saint)中新建config文件夹(com.config),并将MyRibbonConfiguration类移动到其中,代码目录结构如下:
在这里插入图片描述
这样操作之后,Ribbon配置类讲不会被Spring扫描到。所以需要利用@RibbonClients注解做一些配置;

在com.saint.config目录下新增GreetingServiceRibbonConf类:

package com.saint.config;

import com.config.MyRibbonConfiguration;
import org.springframework.cloud.netflix.ribbon.RibbonClients;
import org.springframework.context.annotation.Configuration;

/**
 * @author Saint
 */
@Configuration
@RibbonClients(defaultConfiguration = MyRibbonConfiguration.class)
public class GreetingServiceRibbonConf {
}

3、应用到指定服务上(Ribbon局部配置)

针对Ribbon局部配置,有两种方式:代码配置 和 属性配置,上面提到的@RibbonClients就属于代码配置的方式,区别在于Ribbon局部配置使用的是@RibbonClient注解;

1)代码配置 -- @RibbonClient

将GreetingServiceRibbonConf类的内容修改如下:

package com.saint.config;

import com.config.MyRibbonConfiguration;
import org.springframework.cloud.netflix.ribbon.RibbonClient;
import org.springframework.context.annotation.Configuration;

/**
 * 自定义 调用greeting-service服务时 使用的配置
 *
 * @author Saint
 */
@Configuration
@RibbonClient(name = "GREETING-SERVICE", configuration = MyRibbonConfiguration.class)
public class GreetingServiceRibbonConf {
}

当然我们也可以不使用GreetingServiceRibbonConf作为一个配置类,直接将@RibbonClient(name = "GREETING-SERVICE", configuration = MyRibbonConfiguration.class)加在启动类中也是一样的。

2)属性配置 -- application.yml

首先将GreetingServiceRibbonConf类中的内容全部注释掉:
在这里插入图片描述

然后在application.yml文件中添加如下内容:

# GREETING-SERVICE为要调用的微服务名
GREETING-SERVICE:
  ribbon:
    NFLoadBalancerRuleClassName: com.saint.config.MyRule

3)两种方式对比:

  • 代码配置:基于代码、更加灵活;但是线上修改得重新打包、发布,并且还有小坑(父子上下文问题)
  • 属性配置: 配置更加直观、优先级更高(相对代码配置)、线上修改无需重新打包、发布;但是极端场景下没有代码配置方式灵活。

注意:如果代码配置和属性配置两种方式混用,属性配置优先级更高。

4)细粒度配置-最佳实践:

  1. 尽量使用属性配置,属性方式实现不了的情况下再考虑代码配置。
  2. 同一个微服务内尽量保持单一性,使用同样的配置方式,避免两种方式混用,增加定位代码的复杂性。

4、使用浏览器进行调用服务消费者

结合博文:【云原生&微服务一】SpringCloud之Ribbon实现负载均衡详细案例(集成Eureka、Ribbon),我们已经依次启动了eureka-server、ribbon-feign-sample-8081、ribbon-feign-sample-8082、ribbon-feign-sample-consumer;三个服务、四个实例。

此处我们针对服务消费者ribbon-feign-sample-consumer做四次接口调用,分别为:

  1. http://localhost:9090/say/saint
  2. http://localhost:9090/say/saint2
  3. http://localhost:9090/say/saint3
  4. http://localhost:9090/say/saint4

在这里插入图片描述
然后我们去看ribbon-feign-sample-8081、ribbon-feign-sample-8082的控制台输出:

1> ribbon-feign-sample-8081控制台输出:
在这里插入图片描述

2> ribbon-feign-sample-8082控制台输出:
在这里插入图片描述

3> 结果说明:
我们可以发现,四个请求,ribbon-feign-sample-8082实例处理了所有的请求,我们自定义的IRule已经生效。

四、自定义服务实例是否存活判定策略IPing

和IRule的自定义方式一样,这里只提供自定义的IPing,具体配置方式和IRule一样。

1、自定义IPing

MyPing表示实例永不失活,因为其isAlive(Server server)永远返回TRUE。

package com.saint.config;

import com.netflix.loadbalancer.IPing;
import com.netflix.loadbalancer.Server;

/**
 * 自定义IPing,判断每个服务是否还存活
 * @author Saint
 */
public class MyPing implements IPing {
    @Override
    public boolean isAlive(Server server) {
        return true;
    }
}

2、修改Ribbon配置类

package com.config;

import com.netflix.loadbalancer.IPing;
import com.netflix.loadbalancer.IRule;
import com.saint.config.MyPing;
import com.saint.config.MyRule;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * 自定义Ribbon配置
 *
 * @author Saint
 */
@Configuration
public class MyRibbonConfiguration {

    @Bean
    public IRule getRule() {
        return new MyRule();
    }

    @Bean
    public IPing getPing() {
        return new MyPing();
    }

}

五、性能优化-饥饿加载

Ribbon默认是懒加载微服务,所以第一次调用特别慢,我们可以修改饥饿加载。

ribbon:
  eager-load:
    # 开启饥饿加载
    enabled: true
    # 开启饥饿加载的微服务列表,多个以,分隔
    clients: user-center,xxx
相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
21天前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
1月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
43 3
|
1月前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
1月前
|
运维 Kubernetes Cloud Native
云原生技术:容器化与微服务架构的完美结合
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术以其灵活性和高效性成为企业的新宠。本文将深入探讨云原生的核心概念,包括容器化技术和微服务架构,以及它们如何共同推动现代应用的发展。我们将通过实际代码示例,展示如何在Kubernetes集群上部署一个简单的微服务,揭示云原生技术的强大能力和未来潜力。
|
22天前
|
Kubernetes Cloud Native Docker
云原生之旅:从容器化到微服务
本文将带领读者踏上云原生的旅程,深入探讨容器化和微服务架构的概念、优势以及它们如何共同推动现代软件的发展。我们将通过实际代码示例,展示如何在Kubernetes集群上部署一个简单的微服务应用,并解释相关的配置和操作。无论你是云原生新手还是希望深化理解,这篇文章都将为你提供有价值的见解和实操指南。
|
25天前
|
Cloud Native API 持续交付
云原生时代的微服务架构设计
随着云计算的蓬勃发展,云原生概念逐渐成为IT行业的热点。本文将通过深入浅出的方式,介绍在云原生环境下,如何设计一个高效、可扩展的微服务架构。文章不仅涉及理论概念,还将结合实际代码示例,帮助读者理解微服务架构的核心要素和设计原则,以及如何在云平台上实现这些设计。
|
28天前
|
Kubernetes Cloud Native 开发者
云原生入门:从容器到微服务
本文将带你走进云原生的世界,从容器技术开始,逐步深入到微服务架构。我们将通过实际代码示例,展示如何利用云原生技术构建和部署应用。无论你是初学者还是有经验的开发者,这篇文章都将为你提供有价值的信息和启示。
|
1月前
|
消息中间件 运维 Cloud Native
云原生架构下的微服务优化策略####
本文深入探讨了云原生环境下微服务架构的优化路径,针对服务拆分、通信效率、资源管理及自动化运维等核心环节提出了具体的优化策略。通过案例分析与最佳实践分享,旨在为开发者提供一套系统性的解决方案,以应对日益复杂的业务需求和快速变化的技术挑战,助力企业在云端实现更高效、更稳定的服务部署与运营。 ####
|
1月前
|
Cloud Native 云计算 Docker
云原生技术的崛起:从容器化到微服务架构
云原生技术的崛起:从容器化到微服务架构
|
1月前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
49 5