Spring Cloud -- Ribbon负载均衡

Overview

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

Ribbon提供的主要负载均衡策略介绍

简单轮询负载均衡(RoundRobin)

以轮询的方式依次将请求调度不同的服务器,即每次调度执行i = (i + 1) mod n,并选出第i台服务器。

随机负载均衡 (Random)

随机选择状态为UP的Server

加权响应时间负载均衡 (WeightedResponseTime)

 

区域感知轮询负载均衡(ZoneAware)


域感知负载均衡内置电路跳闸逻辑,可被配置基于区域同源关系(Zone
Affinity,也就是更倾向于选择发出调用的服务所在的托管区域内,这样可以降低延迟,节省成本)选择目标服务实例。它监控每个区域中运行实例的行
为,而且能够实时的快速丢弃一整个区域。这样在面对整个区域故障时,帮我们提升了弹性。

Ribbon自带负载均衡策略比较

策略名 策略声明 策略描述 实现说明
BestAvailableRule public class BestAvailableRule extends ClientConfigEnabledRoundRobinRule 选择一个最小的并发请求的server 逐个考察Server,如果Server被tripped了,则忽略,在选择其中ActiveRequestsCount最小的server
AvailabilityFilteringRule public class AvailabilityFilteringRule extends PredicateBasedRule 过滤掉那些因为一直连接失败的被标记为circuit tripped的后端server,并过滤掉那些高并发的的后端server(active connections 超过配置的阈值) 使用一个AvailabilityPredicate来包含过滤server的逻辑,其实就就是检查status里记录的各个server的运行状态
WeightedResponseTimeRule public class WeightedResponseTimeRule extends RoundRobinRule 根据相应时间分配一个weight,相应时间越长,weight越小,被选中的可能性越低。

个后台线程定期的从status里面读取评价响应时间,为每个server计算一个weight。Weight的计算也比较简单responsetime
减去每个server自己平均的responsetime是server的权重。当刚开始运行,没有形成statas时,使用roubine策略选择
server。

RetryRule public class RetryRule extends AbstractLoadBalancerRule 对选定的负载均衡策略机上重试机制。 在一个配置时间段内当选择server不成功,则一直尝试使用subRule的方式选择一个可用的server
RoundRobinRule public class RoundRobinRule extends AbstractLoadBalancerRule roundRobin方式轮询选择server 轮询index,选择index对应位置的server
RandomRule public class RandomRule extends AbstractLoadBalancerRule 随机选择一个server 在index上随机,选择index对应位置的server
ZoneAvoidanceRule public class ZoneAvoidanceRule extends PredicateBasedRule 复合判断server所在区域的性能和server的可用性选择server 使
用ZoneAvoidancePredicate和AvailabilityPredicate来判断是否选择某个server,前一个判断判定一个
zone的运行性能是否可用,剔除不可用的zone(的所有server),AvailabilityPredicate用于过滤掉连接数过多的
Server。

配置properties file (sample-client.properties)

# Max number of retries    

ribbon.MaxAutoRetries=1     

# Max number of next servers to retry (excluding the first server)  

ribbon.MaxAutoRetriesNextServer=1 

 # Whether all operations can be retried for this client   

ribbon.OkToRetryOnAllOperations=true  

# Interval to refresh the server list from the source   

ribbon.ServerListRefreshInterval=2000   

# Connect timeout used by Apache HttpClient   

ribbon.ConnectTimeout=3000   

# Read timeout used by Apache HttpClient   

ribbon.ReadTimeout=3000   

# Initial list of servers, can be changed via Archaius dynamic property at runtime   

ribbon.listOfServers=testserver1:80,testserver2 :80,testserver3:80    

ribbon.EnablePrimeConnections=true 

Ribbon架构图

时间: 2024-09-12 08:16:16

Spring Cloud -- Ribbon负载均衡的相关文章

Ribbon负载均衡策略配置

在这里吐槽一句:网上很多文章真是神坑,你不看还好,看了只会问题越来越多,就连之前的问题都没有解决!!! 不多说了,Ribbon作为后端负载均衡器,比Nginx更注重的是请求分发而不是承担并发,可以直接感知后台动态变化来指定分发策略.它一共提供了7种负载均衡策略: 策略名 策略声明 策略描述 实现说明 BestAvailableRule public class BestAvailableRule extends ClientConfigEnabledRoundRobinRule 选择一个最小的并

Spring Boot 负载均衡之外置session状态保存

在使用spring boot做负载均衡的时候,多个app之间的session要保持一致,这样负载到不同的app时候,在一个app登录之后,而打到另外一台服务器的时候,session丢失.   常规的解决方案都是使用:如apache使用mod_jk.conf.   在开发spring boot app的时候可以借助 spring session 和redis,用外置的redis来存储session的状态.   直接上代码,我这边直接默认你使用spring boot,如果你是普通的spring we

《Spring Cloud与Docker微服务架构实战》配套代码

不才写了本使用Spring Cloud玩转微服务架构的书,书名是<Spring Cloud与Docker微服务架构实战> - 周立,已于2017-01-12交稿.不少朋友想先看看源码,现将代码放出. 本次放出的代码: 共计70+个DEMO 覆盖Eureka.Ribbon.Feign.Hystrix.Zuul.Spring Cloud Config.Spring Cloud Bus.Spring Cloud Sleuth.Docker.Docker Compose等. 1-11章代码地址: ht

Spring Cloud构建微服务架构:服务网关(路由配置)【Dalston版】

在上一篇<Spring Cloud构建微服务架构:服务网关(基础)>一文中,我们通过使用Spring Cloud Zuul构建了一个基础的API网关服务,同时也演示了Spring Cloud Zuul基于服务的自动路由功能.在本文中,我们将进一步详细地介绍关于Spring Cloud Zuul的路由功能,以帮助读者可以更好的理解和使用它,以完成更复杂的路由配置. 传统路由配置 所谓的传统路由配置方式就是在不依赖于服务发现机制的情况下,通过在配置文件中具体指定每个路由表达式与服务实例的映射关系来

spring cloud源码分析-zuul路由的部分源码解析

版本:spring-boot:1.5.3.RELEASE:spring cloud:Dalston.RELEASE(1.3.0.RELEASE) 路由定位器 配置所在jar包:spring-cloud-netflix-core-1.3.0.RELEASE.jar 顶层接口:RouteLocator 可刷新的路由:RefreshableRouteLocator extends RouteLocator 路由处理器:CompositeRouteLocator implements Refreshab

编码实现Spring Cloud微服务负载均衡调用(eureka、ribbon)

Spring 封装.揉和了一批开源项目,其中以Netflix开源的为主,比如zuul.eureka.hystrix.robbin等:然后就有了现在的Spring cloud微服务架构.这也充分展现了Spring的揉合能力. Spring cloud通过封装使这些项目融入spring的bean管理机制中,从而方便使用.这套微服务的核心功能还是使用这些项目的. 由本篇的标题可以想到本篇就是不使用Spring的注解和配置来使用这套微服务.看看现在网上关于Spring cloud的示例,千篇一律那几行注

ribbon客户端负载均衡

一.三种配置方式 集成eureka.注解.配置文件 1.集成erueka 在application.yml中配置(其实会默认配置好,但是最好显示配置出来) ribbon: # 开启eureka与ribbon的集成 eureka: enabled: true 2.注解 在启动类中添加注解 // 通过注解的方式定义了一个针对service-by-annotation服务的负载均衡器(service-by-annotation是服务的名称也是负载均衡器的名称) @RibbonClients(value

Spring Cloud实战小贴士:Ribbon的饥饿加载(eager-load)模式

2017年架构师最重要的48个小时 | 8折倒计时 我们在使用Spring Cloud的Ribbon或Feign来实现服务调用的时候,如果我们的机器或网络环境等原因不是很好的话,有时候会发现这样一个问题:我们服务消费方调用服务提供方接口的时候,第一次请求经常会超时,而之后的调用就没有问题了.下面我们就来说说造成这个问题的原因,以及如何解决的方法. 问题原因 造成第一次服务调用出现失败的原因主要是Ribbon进行客户端负载均衡的Client并不是在服务启动的时候就初始化好的,而是在调用的时候才会去

Spring Boot与Docker(四):额外的微服务、更新容器、Docker Compose和负载均衡

本文讲的是Spring Boot与Docker(四):额外的微服务.更新容器.Docker Compose和负载均衡,[编者的话]本篇是<使用Spring Boot和Docker构建微服务架构>系列的第四篇,本篇我们我们将添加一些额外的服务/容器,并且更新容器,采用Docker Compose以及使用HAProxy容器进行负载均衡.原文作者为3Pillar环球旗下美国Adbanced技术集团的总监Dan Greene,Dan有十八年的软件设计和开发经验,包括在电子商务.B2B集成.空间分析.S