第四章：客户端负载均衡

第4章：客户端负载均衡Spring Cloud Ribbon

Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，基于Netflix Ribbon实现。Spring Cloud Ribbon虽然只是一个工具类框架，不像

注册中心、配置中心、API网关那样需要独立部署，但是它几乎存在于每一个Spring Cloud 构建的微服务和基础设施中。因为微服务间的调用，API网关的

请求转发等内容实际上通过Ribbon实现的。

客户端负载均衡

负载均衡在系统架构中是一个非常重要，并且是不得不去实施的内容。因为负载均衡是对系统高可用、网络压力的缓解和处理能力扩容的重要手段之一。

通常说的负载均衡都是服务端负载均衡，其中分为硬件负载均衡和软件负载均衡。硬件负载均衡主要通过在服务节点之间安装专门用于负载均衡的设备，

比如F5等；软件负载均衡则是通过在服务器上安装一些具有负载均衡功能或模块的软件来完成请求分发工作，比如Nginx等。

类似架构图：

硬件负载均衡的设备或是软件负载均衡的软件模块都会维护一个可以下挂可用服务端清单，通过心跳检测来剔除故障的服务端点，以保证清单中都是可以正常

访问的服务端节点。当客户端发送请求到负载均衡设备的时候，设备安照某种算法(比如线性轮询、按权负载、按流量负载)从维护的可用服务端清单中

取出一台服务端的地址，然后进行转发。

而客户端负载均衡和服务端负载均衡最大的不同在于上面所提到的服务清单所存储的位置。在客户端负载均衡中，所有客户端节点都维护着自己要访问的服务清单，

而这些服务清单来自于服务注册中心，比如Eureka Server，同服务端负载均衡的机构类似，在客户端负载均衡中也需要心跳去维护服务清单的健康性，

只是这个步骤需要服务注册中心配合完成。在Spring Cloud实现的服务治理框架中，默认会创建针对各个服务治理框架的Ribbon自动化整合配置，比如Eureka中

的org.springframework.cloud.netflix.ribbon.eureka.RibbonEurekaAutoConfiguration,Consul中的org.springframework.cloud.consul.discovery.RibbonConsulAAAutoConfiguraation

在实际使用的时候，可以通过查看这两个类的实现，找到它们的配置详情来帮助我们更好地使用它。

通过Spring Cloud Ribbon的封装，我们在微服务架构中使用客户端负载均衡调用非常简单，只需要2步：

服务提供者只需要启动多个服务实例并注册到一个注册中心或多个相关联的服务注册中心。

服务消费者直接通过调用被@LoadBlanced注解修饰过的RestTemplate来实现面向服务的接口调用。

RestTemplate详解

分析LoadBalanceClient接口所属包org.

配置详解

自动化配置：由于Ribbon中定义的每一个接口都有多种不同的策略实现，同时这些接口之间有一定的依赖。Spring Cloud Ribbon中的自动配置。

IClientConfig：Ribbon的客户端配置，默认采用com.netflix.client.config.DefaultClientConfigImpl实现。

IRue：Ribbon的负载均衡策略，默认采用com.netflix.loadbalaancer.ZoneAvoidanceRule实现，该策略能够在多区域环境下选出最佳的实例进行访问。

IPing：Ribbon的实例检查策略是一个特殊的实现，实际上它不会检查实例是否可用，而是始终返回true，默认认为所有服务实例都是可用的。

ServerList<Server>：服务实例清单的维护机制，默认采用com.netflix.loadbalancer.ConfigurationBaseServerList实现。

ServerListFilter<Server>：服务实例清单过滤机制，默认采用org.springframework.cloud.netflix.ribbon.ZonePreferenceServerListFilter实现，该策略能够优先过滤

出与请求调用方处于同区域的服务实例。

ILoadBalancer：负载均衡器，默认采用com.netflix.loadbalancer.ZoneAwareLoadBalancer实现，具备区域感知能力。

参数配置：

对于Ribbon的参数配置通常有两种方式：全局配置及指定客户端配置

全局配置，只需要使用ribbon.<key>=<value>格式进行配置。比如ribbon.ConnectTimeout=250

全局配置可以作为默认配置，当指定客户端配置了相应key的值时，将覆盖全局配置的内容。

指定客户端配置采用<client>.ribbont.<key>=<value>格式进行配置。

对于Ribbon参数的key以及value类型的定义，可以查看com.netflix.client.config.CommonClientConfigKey类获得更为详细的配置内容。

与Eurerka结合

Spring Cloud 应用中同时引入Spring Cloud Ribbon和Spring Cloud Eureka依赖时，会触发Eureka中实现对Ribbon的自动化配置。这时ServerList的维护

机制将被com.netflix.niws.loadbalancer.DiscoveryEnabledNIWSServerList的实例所覆盖，该实现会将服务清单交给Eureka的服务治理机制来维护；IPing

的实现将被com.netflix.niws.loadbalancer.NIWSDiscoveryPing的实例所覆盖，该实现也将实例检查的任务交给了服务治理框架进行维护。默认情况下，用于

获取实例请求的ServerList接口实现将采用Spring Cloud Eureka中封装的org.springframework.cloud.netflix.ribbon.eureka.DomainExtractingServerList，其目的

是为了让实例维护策略更加通用，所以将使用物理元数据进行负载，而不是使用原生的AWS AMI元数据。

Spring Cloud Ribbon默认实现了区域亲和策略。可以通过配置Eureka实例的元数据来实现区域化的实例配置方案。可以将不同机房的实例配置成不同的区域值，

以作为跨区域的容错机制实现。只需要在服务实例的元数据增加zone参数来指定自己所在的区域，eureka.instance.metadaMap.zone=shanghai

也可以通过参数配置的方式禁用Eureka对Ribbon服务实例的维护实现。在配置文件中增加，ribbon.eureka.enable=false

重试机制- 配置如

hello-service服务调用为例

spring.cloud.loadbalancer.retry.enable=true

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000

hello-service.ribbon.ConnectTimeout=250

hello-service.ribbon.ReadTimeout=1000

hello-service.ribbon.OkToRetryOnAllOperations=true

hello-service.ribbon.MaxAutoRetriesNextServer=2

hello-service.ribbon.MaxAutoReties=1