微服务架构 | 4.1 基于 Ribbon 的负载均衡详解

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: Spring Cloud Ribbon 是基于 Netflix Ribbon 实现的一套客户端负载均衡的工具;提供客户端的软件负载均衡算法和服务调用;

前言

参考资料
《Spring Microservices in Action》
《Spring Cloud Alibaba 微服务原理与实战》
《B站 尚硅谷 SpringCloud 框架开发教程 周阳》

Spring Cloud Ribbon 是基于 Netflix Ribbon 实现的一套客户端负载均衡的工具;提供客户端的软件负载均衡算法和服务调用;


1. Ribbon 基础知识

1.1 Ribbon 是什么

  • Spring Cloud Ribbon 是基于 Netflix Ribbon 实现的一套客户端负载均衡的工具;提供客户端的软件负载均衡算法和服务调用;
  • Ribbon 客户端组件提供一系列完善的配置项如连接超时,重试等。简单的说,就是在配置文件中列出 Load Balancer(简称LB)后面所有的机器,Ribbon 会自动基于某种规则(如简单轮询,随机连接等)去连接这些机器;
  • 可以很容易使用Ribbon实现自定义的负载均衡算法;

1.2 与 Ribbon 交互的三种级别层次

  • Spring DiscoveryClient:提供了对 Ribbon 和 Ribbon 中缓存的注册服务的最低层次访问;
  • 启用了 RestTemplate 的 Spring DiscoveryClient
  • Netflix Feign 客户端

1.3 Ribbon在工作时分成两步

Ribbon 架构图

  • 第一步先选择 EurekaServer,它优先选择在同一个区域内负载较少的 server;

第二步再根据用户指定的策略,在从 server 取到的服务注册列表中选择一个地址;

1.4 服务的提供者与消费者

  • 提供者:服务提供者将自己注册进注册中心,让消费者发现;在本例中有多个提供者给消费者提供服务;
  • 消费者:消费者使用服务发现,找到提供者并调用提供者服务;在本例中只有一个消费者在多个提供者中选出一个为自己服务;

1.5 Ribbon 核心组件 IRule

IRule 负载均衡

  • 根据特定算法中从服务列表中选取一个要访问的服务;
  • 定义了负载均衡的方式;
  • 有以下几种负载均衡的实现方式:

    • RoundRobinRule:轮询;
    • RandomRule:随机;
    • RetryRule:先按照 RoundRobinRule 的策略获取服务,如果获取服务失败则在指定时间内会进行重试,获取可用的服务;
    • WeightedResponseTimeRule:对 RoundRobinRule 的扩展,响应速度越快的实例选择权重越大,越容易被选择;
    • BestAvailableRule:会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务,然后选择一个并发量最小的服务;
    • AvailabilityFilteringRule:先过滤掉故障实例,再选择并发较小的实例;
    • ZoneAvoidanceRule:默认规则,复合判断 server 所在区域的性能和 server 的可用性选择服务器;


2. 服务消费者获取提供者的三个层次示例

2.1 引入 pom.xml 依赖

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
</dependency>
  • 如果使用 Eureka 作为注册中心,则不用引入该依赖,因为 Eureka 的依赖里包含 ribbon 相关依赖 jar 包;

2.2 使用 Spring DiscoveryClient 查找服务实例

2.2.1 在主程序类上添加注解

  • @EnableDiscoveryClient:表明可以被注册中心发现。是 Sring Cloud 的触发器,其作用是使应用程序能够使用 DiscoveryClient 和 Ribbon 库;

2.2.2 使用 DiscoveryClient 查找信息

在服务消费者的 client 包下;
@Component
public class ProviderDiscoveryClient {

    //自动注入 DiscoveryClient 类,该类用于与 Ribbon 交互
    @Autowired
    private DiscoveryClient discoveryClient;

    public Provide getProvide(String providerId) {
        RestTemplate restTemplate = new RestTemplate();
        //获取服务提供者的所有实例列表,ServiceInstance 用于保存关于服务的特定实例(包括主机名、端口荷 URL)
        List<ServiceInstance> instances = discoveryClient.getInstances("provider-instance-name");

        if (instances.size()==0) return null;
        //检索要调用的服务端点
        String serviceUri = String.format("%s/providers/%s",instances.get(0).getUri().toString(), providerId);

        //使用标准的 Spring REST 模板类去调用服务
        ResponseEntity< provider > restExchange =
                restTemplate.exchange(
                        serviceUri,
                        HttpMethod.GET,
                        null, Provider.class, providerId);
        
        return restExchange.getBody();
    }
}
  • 这种方法存在以下问题:

    • 没有利用 Ribbon 的客户端负载均衡,调用哪个服务实例需要开发人员定义;
    • 开发人员必须构建一个用来调用服务的 URL;
    • 实例化 ResTemplate 类,不符合 Spring IoC 规范;
  • 结合本篇《5. 本地负载均衡器的实现(消费者)》即可用到客户端负载均衡,即:开发人员定义了本地负载均衡器来实现了负载均衡;

2.3 使用带有 Ribbon 功能的 Spring RestTemplate 调用服务

2.3.1 在主程序类上添加注解

@SpringBootApplication //只需要这个注解即可
public class Application {
  @LoadBalanced //告诉 Spring Cloud 创建一个支持 Ribbon 的 RestTemplate
  @Bean
  public RestTemplate getRestTemplate(){
      return new RestTemplate();
  }
  public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
  }
}
  • Spring Cloud 早期版本中,RestTemplate 类默认自动支持 Ribbon;
  • 自从 Spring Cloud 发布 Angel 版本后,Spring Cloud 中的 RestTemplate 不再支持 Ribbon;
  • 因此,后续版本必须使用 @LoadBalanced 注解显式标注,才能将 Ribbon 和 RestTemplate 一起使用;
  • *RestTemplate 不一定放在主程序类里;也可以在 config 包下新建一个 ApplicationContextConfig 配置类,将 RestTemplate 放在该类里:
@Configuration
public class ApplicationContextConfig{
    @Bean
    @LoadBalanced
    public RestTemplate getRestTemplate(){
        return new RestTemplate();
    }
}

2.3.2 使用 Ribbon 的 RestTemplate 来调用服务

在服务消费者的 client 包下;
@Component
public class ProviderRestTemplateClient {
    //自动注入即可,不用实例化
    @Autowired
    RestTemplate restTemplate;

    public Provider getProvider(String providerId){
        ResponseEntity<Provider> restExchange =
                restTemplate.exchange(
                        //使用 Eureka 服务 ID 来构建目标 URL
                        "http://provider-instance-name/providers/{providerId}",
                        HttpMethod.GET,
                        null, Provider.class, providerId);
        return restExchange.getBody();
    }
}
  • 通过使用 RestTemplate 类,Ribbon 将在所有服务实例之间轮询负载均衡所有请求;

2.4 使用 Netflix Feign 客户端调用服务

Feign 相关知识将在下篇《4.2 基于 Feign 与 OpenFeign 的服务接口调用》中说明,这里仅把重点放在与上述两种调用提供者服务的区别与对比;

2.4.1 在主程序类上添加注解

@EnableFeignClients:表示启用 Feign 客户端;

2.4.2 定义用于调用服务提供者的 Feign 接口

@FeignClient("provider-instance-name") //标识服务为 feign 的客户端
public interface ProviderFeignClient {
    //定义端点的路径和动作
    @RequestMapping( 
            method= RequestMethod.GET,
            value="/providers/{providerId}",
            consumes="application/json")
    //定义传入端点的参数,该方法可以由客户端调用以触发组织服务        
    Provider getProvider(@PathVariable("providerId") String providerId);
}
  • 要是用 ProviderFeignClient 类,开发人员只需要自动装配并使用它即可;


3. 通过 java 配置类自定义负载均衡算法示例(消费者服务)

指切换默认的负载均衡算法,切换后的仍为现成的(与本地负载均衡器有所区别,本地负载均衡器要自己实现);

3.1 编写配置类

  • 注意:自定义配置类不能放在 @ComponentScan 所扫描的当前包下以及子包下,否则自定义的配置类会被所有的Ribbon客户端所共享,达不到自定义的目的;
  • @ComponentScan 注解被封装到主启动类上的 @SpringBootApplication 注解。其默认扫描主启动类所在包及其子包,因此我们要返回上一级目录新建一个 myRule 目录存放我们自定义的负载均衡配置类;

自定义负载均衡算法的文件目录结构

@Configuration
public class MySelfRule {
    @Bean
    public IRule myRule(){
        return new RandomRule();//定义为随机
    }
}

3.2 主启动类上添加注解

  • @RibbonClient(name = "provider-instance-name" ,configuration=MySelfRule.class):表示使用自定义负载均衡算法;

    • name:指定服务提供者的实例名称;
    • configuration:指定需要使用哪个配置类的负载均衡;
    • 表示 provider 服务使用 MySelfRule 对应的 Ribbon 配置;
  • 同样,需要对 RestTemplate 类用 @LoadBalanced 注解显示声明;


4. 通过配置自定义负载均衡算法示例(消费者服务)

指切换默认的负载均衡算法,切换后的仍为现成的(与本地负载均衡器有所区别,本地负载均衡器要自己实现);

4.1 修改 bootstrap.yml 配置文件

  • 上述 java 配置类的效果等价于下面这样的配置文件:
#服务提供者的实例名称
provider-instance-name:
  ribbon:
    #代表 Ribbon 使用的负载均衡策略,属性的值为:IRule 的实现类
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
    
    #其他可用的配置属性
    # NFLoadBalancerClassName : 配置 ILoadBalancer 的实现类
    # NFLoadBalancerPingClassName : 配置 IPing 的实现类
    # NIWSServerListClassName: 配置 ServerList 的实现类
    # NIWSServerListFilterClassName: 配置 ServerListtFilter 的实现类

4.2 主程序类

  • 不需要 @RibbonClient 注解;
  • 同样,需要对 RestTemplate 类用 @LoadBalanced 注解显示声明;


5. 本地负载均衡器的实现(消费者)

本地负载均衡器不同于自定义负载均衡算法;前者的负载均衡算法需要自己手动实现,后者只是切换成另一种现成的负载均衡算法;

5.1 不使用 RestTemplate

  • 即主程序类不需要对 RestTemplate 类用 @LoadBalanced 注解显示声明;
  • 可以删去也可以注释 @LoadBalanced 注解;

5.2 定义负载均衡接口

可以新建一个包,专门存放我们自己写的负载均衡算法;
public interface LoadBalancer{
    ServiceInstance instances(List<ServiceInstance> serviceInstances);
}

5.3 实现负载均衡接口

  • 可以根据业务要求写不同的负载均衡算法,这里仅提供一种示例;
  • 该示例实现了一种较为简单的原子性的负载均衡算法;
@Component
public class MyLB implements LoadBalancer{
    private AtomicInteger atomicInteger = new AtomicInteger(0);
    public final int getAndIncrement(){
        int current;
        int next;

        do {
            current = this.atomicInteger.get();
            next = current >= 2147483647 ? 0 : current + 1;
        }while(!this.atomicInteger.compareAndSet(current,next));
        System.out.println("*****第几次访问,次数next: "+next);
        return next;
    }

    //负载均衡算法:rest接口第几次请求数 % 服务器集群总数量 = 实际调用服务器位置下标  ,每次服务重启动后rest接口计数从1开始。
    @Override
    public ServiceInstance instances(List<ServiceInstance> serviceInstances){
        int index = getAndIncrement() % serviceInstances.size();
        return serviceInstances.get(index);
    }
}

5.4 在 controller 接口中使用本地负载均衡器

  • 类似于本篇《2.2 使用 Spring DiscoveryClient 查找服务实例》;
  • 不同之处在于 2.2 没有负载均衡功能,这里在 2.2 的基础上,开发人员自己定义了本地负载均衡器,不使用 Ribbon 提供的负载均衡,故《5.1 不使用 RestTemplate》中提到的不用对 RestTemplate 类使用 @LoadBalanced 注解显示声明
@RestController
public class OrderController{
    //服务提供者示例的名字
    public static final String PAYMENT_URL = "http://provider-instance-name";
    @Resource
    private RestTemplate restTemplate;
    @Resource
    private LoadBalancer loadBalancer;
    @Resource
    private DiscoveryClient discoveryClient;
 
    @GetMapping(value = "/provider/mylb")
    public String getProviderLB(){
        //获取服务提供者的所有实例列表
        List<ServiceInstance> instances = discoveryClient.getInstances("provider-instance-name");
        if(instances == null || instances.size() <= 0){
            return null;
        }
        //使用本地负载均衡器选出提供者服务
        ServiceInstance serviceInstance = loadBalancer.instances(instances);
        URI uri = serviceInstance.getUri();
        return restTemplate.getForObject(uri+"/provider/mylb",String.class);
    }
}



相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
25天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
6天前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
1月前
|
负载均衡 Java Nacos
Ribbon负载均衡
Ribbon负载均衡
27 1
Ribbon负载均衡
|
24天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
6天前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
102 68
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
24天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
40 1
服务架构的演进:从单体到微服务的探索之旅
|
22天前
|
消息中间件 监控 安全
后端架构演进:从单体到微服务####
在数字化转型的浪潮中,企业应用的后端架构经历了从传统单体架构到现代微服务架构的深刻变革。本文探讨了这一演进过程的背景、驱动力、关键技术及面临的挑战,揭示了如何通过微服务化实现系统的高可用性、扩展性和敏捷开发,同时指出了转型过程中需克服的服务拆分、数据管理、通信机制等难题,为读者提供了一个全面理解后端架构演变路径的视角。 ####
45 8
|
23天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
43 5
|
26天前
|
监控 API 微服务
后端技术演进:从单体架构到微服务的转变
随着互联网应用的快速增长和用户需求的不断演化,传统单体架构已难以满足现代软件开发的需求。本文深入探讨了后端技术在面对复杂系统挑战时的演进路径,重点分析了从单体架构向微服务架构转变的过程、原因及优势。通过对比分析,揭示了微服务架构如何提高系统的可扩展性、灵活性和维护效率,同时指出了实施微服务时面临的挑战和最佳实践。
47 7
|
24天前
|
Kubernetes 负载均衡 Cloud Native
云原生架构下的微服务治理策略
随着云原生技术的不断成熟,微服务架构已成为现代应用开发的主流选择。本文探讨了在云原生环境下实施微服务治理的策略和方法,重点分析了服务发现、负载均衡、故障恢复和配置管理等关键技术点,以及如何利用Kubernetes等容器编排工具来优化微服务的部署和管理。文章旨在为开发者提供一套实用的微服务治理框架,帮助其在复杂的云环境中构建高效、可靠的分布式系统。
32 5