在现代分布式微服务架构中，负载均衡是保证系统高可用、高性能的关键组件之一。Netflix Ribbon 作为 Netflix 开源的负载均衡库，为微服务架构提供了强大的负载均衡能力，极大地促进了微服务间的通信和协作。

Netflix Ribbon 的架构

Ribbon 的架构主要由以下几个核心组件构成：

• IRule 接口：提供了选择服务实例的方法，具体选择哪个服务实例取决于实现该接口的负载均衡规则。
• ILoadBalancer 接口：提供了负载均衡的核心功能，包括选择服务实例、维护服务实例列表以及进行健康检查。
• ServerList 接口：提供了服务实例的管理和过滤功能。
• ServerListFilter 接口：允许自定义过滤规则，以决定负载均衡器最终选择的服务实例。

Ribbon 的负载均衡流程

Ribbon 的负载均衡流程如下：

1. Ribbon 会从服务发现组件（如 Netflix Eureka）获取服务实例列表。 2. Ribbon 会根据配置的负载均衡规则选择一个服务实例。 3. 最后，Ribbon 会向选定的服务实例发起请求。

Ribbon 的具体使用

在 Spring Boot 项目中使用 Ribbon 非常简单，只需在配置中添加以下代码即可：

```java @Bean public IRule ribbonRule() { return new AvailabilityFilteringRule(); } @Bean public IPing ribbonPing() { return new PingUrl(); } ```

以上配置将使用基于可用性的负载均衡规则和通过 HTTP 请求进行健康检查的策略。

可以通过 RestTemplate 发起服务调用：

```java @Autowired private RestTemplate restTemplate; public String callService() { return restTemplate.getForObject("http://SERVICE-PROVIDER/api", String.class); } ```

总结

本文对 Netflix Ribbon 的底层实现原理进行了简要介绍，涵盖了其核心组件、架构、负载均衡流程以及实现原理的基本概念。深入理解 Netflix Ribbon 对于构建高性能、高可用的微服务架构至关重要，希望能对您有所帮助。

---

springcloud常见功能

Spring Cloud是一系列用于构建云原生应用的工具和服务，常见的功能包括服务发现、负载均衡、容错处理、配置管理等。 1. 服务发现：在微服务架构中，服务发现是至关重要的一部分。 Spring Cloud通过Netflix Eureka或者Consul等工具提供了服务发现的功能。 这意味着，在一个复杂的系统中，每个服务都能自动找到其他服务，无需进行硬编码。 比如，一个订单服务可能需要找到用户服务以验证用户信息，服务发现功能就能自动帮助它找到用户服务的地址。 2. 负载均衡：在微服务架构中，由于服务被拆分成许多小的部分，负载均衡变得尤为重要。 Spring Cloud集成了Ribbon，这是一个客户端的负载均衡工具，能够很好地控制HTTP和TCP的客户端行为。 这就意味着，当有多个实例提供同一服务时，Ribbon可以帮助我们均衡这些实例的负载。 3. 容错处理：在分布式系统中，容错处理是必不可少的。 Spring Cloud通过Hystrix提供了容错处理的功能。 Hystrix能够在一个服务调用另一个服务出现失败时，提供回退逻辑，保证系统的稳定运行。 比如，当我们调用一个用户服务的接口时，如果失败，Hystrix可以提供一个预设的回退逻辑，如返回一个默认用户信息。 4. 配置管理：随着微服务数量的增加，配置管理变得越来越复杂。 Spring Cloud集成了Spring Cloud Config Server，提供了一个中心化的配置管理方式。 所有的配置信息都被存储在一个中心服务器，各个微服务可以实时从服务器获取自己的配置信息，这样，当配置信息变动时，我们无需重启服务，就能使配置生效。 以上这些功能都是Spring Cloud在构建云原生应用时提供的关键功能。 当然，Spring Cloud还提供了许多其他的功能，比如消息驱动、分布式事务等，这些功能都为构建大规模分布式系统提供了强有力的支持。

ribbon负载均衡详解

服务端负载均衡：在客户端和服务端中间使用代理，lvs 和 nginx。 硬件负载均衡的设备或是软件负载均衡的软件模块都会维护一个下挂可用的服务端清单，通过心跳检测来剔除故障的服务端节点以保证清单中都是可以正常访问的服务端节点。 当客户端发送请求到负载均衡设备的时候，该设备按某种算法（比如线性轮询、按权重负载、按流量负载等）从维护的可用服务端清单中取出一台服务端端地址，然后进行转发。 客户端负载均衡：根据自己的情况做负载。 Ribbon。 客户端负载均衡和服务端负载均衡最大的区别在于 服务端地址列表的存储位置，以及负载算法在哪里。 2、Spring Cloud的负载均衡机制的实现 Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。 通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。 Ribbon实现客户端的负载均衡，负载均衡器提供很多对http和tcp的行为控制。 Spring cloud Feign已经集成Ribbon，所以注解@FeignClient的类，默认实现了ribbon的功能。 Ribbon主要包括如下功能 1.支持通过DNS和IP和服务端通信 2.可以根据算法从多个服务中选取一个服务进行访问 3.通过将客户端和服务器分成几个区域（zone）来建立客户端和服务器之间的关系。 客户端尽量访问和自己在相同区域(zone)的服务，减少服务的延迟 4.保留服务器的统计信息，ribbon可以实现用于避免高延迟或频繁访问故障的服务器 5.保留区域(zone)的统计数据，ribbon可以实现避免可能访问失效的区域(zone)Ribbon负载均衡主要是通过LoadBalancerClient类实现的，而LoadBalancerClient又将具体处理委托给ILoadBalancer处理； 每个服务都有一个ILoadBalancer，ILoadBalancer里面有该服务列表。 每个服务 Map<服务名，ILoadBalancer> ILoadBalancer通过配置IRule、IPing等信息，并通过ServerList获取服务器注册列表的信息，默认以每10s的频率想服务列表中每个服务实例发送ping请求，检测服务实例是否存活，最后使用负责均衡策略对ServerListFilter过滤得到最终可用的服务实例列表进行处理，然后交给服务调用器进行调用； ILoadBalance也是一个接口，提供了3个具体实现，分别是DynamicServerListLoadBalancer、ZoneAwareLoadBalancer和NoOpLoadBalancer； DynamicServerListLoadBalancer继承自ILoadBalancer基础实现BaseLoadBalancer，在基础的负载均衡功能上增加了运行期间对服务实例动态更新和过滤的功能； NoOpLoadBalancer没有操作的实现；ZoneAwareLoadBalancer（ILoadBalancer的默认的实现类是：ZoneAwareLoadBalancer。 ）则是继承DynamicServerListLoadBalancer，在此基础上增加防止跨区域访问的问题； 首先它会剔除符合这些规则的Zone区域：所属实例数位零的Zone区域；Zone区域内实例等平均负载小于零，或者实例故障率（断路器断开次数／实例数）大于等于阀值（默认为0.）。 然后根据Zone区域等实例平均负载计算出最差的Zone区域，这里的最差指的是实例平均负载最高的Zone区域。 如果在上面的过程中没有符合剔除要求的区域，同时实例最大平均负载小于阀值（默认为20%），就直接返回所有Zone区域为可用区域。 否则，从最坏Zone区域集合中随机选择一个，将它从可用Zone区域集合中剔除。 ▪️当获得的可用Zone区域集合不为空，并且个数小于Zone区域总数，就随机选择一个Zone区域。 ▪️在确定了某个Zone区域后，则获取了对应Zone区域的服务均衡器，并调用chooseServer来选择具体的服务实例，而在chooseServer中将使用IRule接口的choose函数来选择具体的服务实例。 在这里，IRule接口的实现会使用ZoneAvoidanceRule来挑选出具体的服务实例。 服务列表就是客户端负载均衡所使用的(同一注册中心集群)各服务的服务实例列表。 Ribbon在实现上支持以下几种服务列表方式 静态服务器列表：通过Ribbon的BaseLoadBalancer所提供的setServerList()方法，初始化时直接进行动态设置指定； 基于配置的服务器列表：需要在项目配置文件中通过<服务名称>进行设置。 （如=） 基于服务发现的服务器列表：同时使用Ribbon和Eureka时，默认使用该方式，在应用启动时Ribbon就会从Eureka服务器中获取所有注册服务的列表数据，并保持同步。 该组件会对原始服务列表使用一定策略进行过滤返回有效可用的服务器列表给客户端负载均衡器使用。 常用服务列表过滤器如下：ZoneAffinityServerListFilter：基于区域感知的方式，实现对服务实例的过滤，仅返回与本身所处区域一直的服务提供者实例列表；ServerListSubsetFilter：该过滤器继承自ZoneAffinityServerListFilter，在进行区域感知过滤后，仅返回一个固定大小的服务列表。 默认将返回20个服务实例，可以通过进行设置； ZonePreferenceServerListFilter：使用Eureka和Ribbon时默认的过滤器。 实现通过配置或者Eureka所属区域来过滤出同区域的服务实例列表。 它实现了通过配置或者Eureka实例元数据的所属区域（Zone）来过滤出同区域的服务实例。 如下面的源码所示，它的实现非常简单，首先通过父类ZoneAffinityServerListFilter的过滤器来获得“区域感知”的服务实例列表，然后遍历这个结果，取出根据消费者配置预设的区域Zone来进行过滤，如果过滤掉结果是空就直接返回父类获取的结果，如果不为空就返回通过消费者配置的Zone过滤后的结果。 用来检测一个微服务实例是否存活是否有响应，Ribbon通过该组件来判断所持有的服务实例列表中各服务可用情况，如果检测到某服务实例不存在/一定时间未响应，则会从持有服务列表中及时移除。 PingUrl：通过定期访问指定的URL判断； PingConstant：不做任何处理，只返回一个固定值，用来表示该服务是否可用，默认值为true； NoOpPing：不做任何处理，直接返回true，表示该服务器可用，默认策略； DummyPing：直接返回true，但实现了initWithNiwsConfig方法； NIWSDiscoverPing：根据DiscoveryEnabledServer中InstanceInfo的InstanceStatus属性判断，如果该属性的值为，则表示服务器可用； 作用就是选择一个最终服务实例地址作为负载均衡处理结果。 Ribbon提供的选择策略有随机 (Random)、轮询 (RoundRobin)、一致性哈希 (ConsistentHash)、哈希 (Hash)、加权（Weighted）。 IRule负载均衡策略：通过实现该接口定义自己的负载均衡策略。 它的choose方法就是从一堆服务器列表中按规则选出一个服务器。 默认实现： ZoneAvoidanceRule（区域权衡策略）：复合判断Server所在区域的性能和Server的可用性，轮询选择服务器。 其他规则： BestAvailableRule（最低并发策略）：会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量最小的服务。 逐个找服务，如果断路器打开，则忽略。 RoundRobinRule（轮询策略）：以简单轮询选择一个服务器。 按顺序循环选择一个server。 RandomRule（随机策略）：随机选择一个服务器。 AvailabilityFilteringRule（可用过滤策略）：会先过滤掉多次访问故障而处于断路器跳闸状态的服务和过滤并发的连接数量超过阀值得服务，然后对剩余的服务列表安装轮询策略进行访问。 WeightedResponseTimeRule（响应时间加权策略）：据平均响应时间计算所有的服务的权重，响应时间越快服务权重越大，容易被选中的概率就越高。 刚启动时，如果统计信息不中，则使用RoundRobinRule(轮询)策略，等统计的信息足够了会自动的切换到WeightedResponseTimeRule。 响应时间长，权重低，被选择的概率低。 反之，同样道理。 此策略综合了各种因素（网络，磁盘，IO等），这些因素直接影响响应时间。 RetryRule（重试策略）：先按照RoundRobinRule(轮询)的策略获取服务，如果获取的服务失败则在指定的时间会进行重试，进行获取可用的服务。 如多次获取某个服务失败，就不会再次获取该服务。 主要是在一个时间段内，如果选择一个服务不成功，就继续找可用的服务，直到超时。 1. <clientName>：这是调用ribbon的客户端名称，如果此值为没有配置，则此条属性会作用到所有的客户端。 2. <nameSpace>：默认值为 “ribbon”3. <propertyName>：所有的可用的属性都在。 <clientName>.<nameSpace>=xx <clientName>.<nameSpace>=xx <clientName>.<nameSpace>=xx <clientName>.<nameSpace>=xx <clientName>.<nameSpace>=xx ：Ribbon的客户端配置，默认采用实现。 ：Ribbon的负载均衡策略，默认采用实现，该策略能够在多区域环境下选出最佳区域的实例进行访问。 ：Ribbon的实例检查策略，默认采用实现，该检查策略是一个特殊的实现，实际上它并不会检查实例是否可用，而是始终返回true，默认认为所有服务实例都是可用的。 ：服务实例清单的维护机制，默认采用实现。 ：服务实例清单过滤机制，默认采，该策略能够优先过滤出与请求方处于同区域的服务实例。 ：负载均衡器，默认采用实现，它具备了区域感知的能力。 上面的配置是在项目中没有引入spring Cloud Eureka，如果引入了Eureka和Ribbon依赖时，自动化配置会有一些不同。 通过自动化配置的实现，可以轻松的实现客户端的负载均衡。 同时，针对一些个性化需求，我们可以方便的替换上面的这些默认实现，只需要在springboot应用中创建对应的实现实例就能覆盖这些默认的配置实现。 @Configuration public class MyRibbonConfiguration { @Bean public IRule ribbonRule(){ return new RandomRule(); } } 这样就会使用P使用了RandomRule实例替代了默认的。 也可以使用@RibbonClient注解实现更细粒度的客户端配置对于Ribbon的参数通常有二种方式：全局配置以及指定客户端配置 全局配置的方式很简单 只需要使用ribbon.<key>=<value>格式进行配置即可。 其中，<key>代表了Ribbon客户端配置的参数名，<value>则代表了对应参数的值。 比如，我们可以想下面这样配置Ribbon的超时时间 =250 =2000 ribbon获取服务定时时间 全局配置可以作为默认值进行设置，当指定客户端配置了相应的key的值时，将覆盖全局配置的内容 指定客户端的配置方式 <client>.<key>=<value>的格式进行配置.<client>表示服务名，比如没有服务治理框架的时候（如Eureka），我们需要指定实例清单，可以指定服务名来做详细的配置， =localhost:8080,localhost:8081,localhost:8082 对于Ribbon参数的key以及value类型的定义，可以通过查看类。 当在spring Cloud的应用同时引入Spring cloud Ribbon和Spring Cloud Eureka依赖时，会触发Eureka中实现的对Ribbon的自动化配置。 这时的serverList的维护机制实现将被的实例所覆盖，该实现会讲服务清单列表交给Eureka的服务治理机制来进行维护。 IPing的实现将被的实例所覆盖，该实例也将实例接口的任务交给了服务治理框架来进行维护。 默认情况下，用于获取实例请求的ServerList接口实现将采用Spring Cloud Eureka中封装的，其目的是为了让实例维护策略更加通用，所以将使用物理元数据来进行负载均衡，而不是使用原生的AWS AMI元数据。 在与Spring cloud Eureka结合使用的时候，不需要再去指定类似的的参数来指定具体的服务实例清单，因为Eureka将会为我们维护所有服务的实例清单，而对于Ribbon的参数配置，我们依然可以采用之前的两种配置方式来实现。 此外，由于spring Cloud Ribbon默认实现了区域亲和策略，所以，可以通过Eureka实例的元数据配置来实现区域化的实例配置方案。 比如可以将不同机房的实例配置成不同的区域值，作为跨区域的容器机制实现。 而实现也非常简单，只需要服务实例的元数据中增加zone参数来指定自己所在的区域，比如： =shanghai 在Spring Cloud Ribbon与Spring Cloud Eureka结合的工程中，我们可以通过参数禁用Eureka对Ribbon服务实例的维护实现。 这时又需要自己去维护服务实例列表了。 =false. 由于Spring Cloud Eureka实现的服务治理机制强调了cap原理的ap机制（即可用性和可靠性），与zookeeper这类强调cp（一致性，可靠性）服务质量框架最大的区别就是，Eureka为了实现更高的服务可用性，牺牲了一定的一致性，在极端情况下宁愿接受故障实例也不要丢弃健康实例。 比如说，当服务注册中心的网络发生故障断开时候，由于所有的服务实例无法维护续约心跳，在强调ap的服务治理中将会把所有服务实例剔除掉，而Eureka则会因为超过85%的实例丢失心跳而触发保护机制，注册中心将会保留此时的所有节点，以实现服务间依然可以进行互相调用的场景，即使其中有部分故障节点，但这样做可以继续保障大多数服务的正常消费。 在Camden版本，整合了spring retry来增强RestTemplate的重试能力，对于我们开发者来说，只需要简单配置，即可完成重试策略。 =true = =250 =1000 =true =2 =1 :该参数用来开启重试机制，它默认是关闭的。 ：断路器的超时时间需要大于Ribbon的超时时间，不然不会触发重试。 ：请求连接超时时间。 ：请求处理的超时时间 ：对所有操作请求都进行重试。 ：切换实例的重试次数。 ：对当前实例的重试次数。 根据以上配置，当访问到故障请求的时候，它会再尝试访问一次当前实例（次数由maxAutoRetries配置），如果不行，就换一个实例进行访问，如果还是不行，再换一个实例访问（更换次数由MaxAutoRetriesNextServer配置），如果依然不行，返回失败项目启动的时候会自动的为我们加载LoadBalancerAutoConfiguration自动配置类，该自动配置类初始化条件是要求classpath必须要有RestTemplate这个类，必须要有LoadBalancerClient实现类。 LoadBalancerAutoConfiguration为我们干了二件事，第一件是创建了LoadBalancerInterceptor拦截器bean，用于实现对客户端发起请求时进行拦截，以实现客户端负载均衡。 创建了一个 RestTemplateCustomizer的bean，用于给RestTemplate增加LoadBalancerInterceptor拦截器。 每次请求的时候都会执行的intercept方法，而LoadBalancerInterceptor具有LoadBalancerClient（客户端负载客户端）实例的一个引用， 在拦截器中通过方法获取服务名的请求url（比如），及服务名（比如user-service），然后调用负载均衡客户端的execute方法。 执行负载客户端RibbonLoadBalancerClient（LoadBalancerClient的实现）的execute方法，得到ILoadBalancer（负载均衡器）的实现ZoneAwareLoadBalancer，并且通过调用其chooseServer方法获得服务列表中的一个实例，比如说user-service列表注册到eureka中一个实例。 然后向其中的一个具体实例发起请求，得到结果。 Ribbon详解Spring cloud系列六 Ribbon的功能概述、主要组件和属性文件配置Ribbon的ZoneAwareLoadBalancerRibbon的实际使用本人有道云笔记中记录的参考文章 文档：04_ribbon 负载均衡 链接：