Spring Cloud 之 Ribbon 学习笔记

简介：

Spring Cloud Ribbon 是一个基于HTTP 和TCP 的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud 的封装， 可以让我们轻松地将面向服务的REST 模板请求自动转换成客户端负载均衡的服务调用。Spring Cloud Ribbon 虽然只是一个工具类框架，它不像服务注册中心、配置中心、API 网关那样需要独立部署， 但是它几乎存在于每一个Spring Cloud 构建的微服务和基础设施中。因为微服务间的调用，API 网关的请求转发等内容实际上都是通过Ribbon 来实现的

Ribbon采用客户端负载均衡：

在客户端负载均衡中， 所有客户端节点都维护着自己要访问的服务端清单， 而这些服务端的清单来自于服务注册中心。同服务端负载均衡的架构类似， 在客户端负载均衡中也需要心跳去维护服务端清单的健康性， 只是这个步骤需要与服务注册中心配合完成。

微服务架构中使用客户端负载均衡调用：

• 服务提供者只需要启动多个服务实例并注册到一个注册中心或是多个相关联的服务注册中心。
• 服务消费者直接通过调用被@LoadBalanced 注解修饰过的RestTemplate 来实现面向服务的接口调用。

重试机制：

由于Spring Cloud Eureka实现的服务治理机制强调了CAP原理中的AP,即可用性与可靠性，它与ZooKeeper这类强调CP( 一致性、可靠性）的服务治理框架最大的区别就是，Eureka为了实现更高的服务可用性， 牺牲了一定的一致性， 在极端情况下它宁愿接受故障实例也不要丢掉“ 健康” 实例， 比如， 当服务注册中心的网络发生故障断开时， 由于所有的服务实例无法维持续约心跳， 在强调AP的服务治理中将会把所有服务实例都剔除掉，而Eureka则会因为超过85%的实例丢失心跳而会触发保护机制，注册中心将会保留此时的所有节点， 以实现服务间依然可以进行互相调用的场景， 即使其中有部分故障节点， 但这样做可以继续保障大多数的服务正常消费。

由于Spring Cloud Eureka在可用性与一致性上的取舍， 不论是由于触发了保护机制还是服务剔除的延迟， 引起服务调用到故障实例的时候， 我们还是希望能够增强对这类问题的容错。所以， 我们在实现服务调用的时候通常会加入一些重试机制。从CamdenSR2版本开始，Spring Cloud整合了Spring Retry来增强RestTernplate的重试能力， 对于开发者来说只需通过简单的配置， 原来那些通过RestTemplate 实现的服务访问就会自动根据配置来实现重试策略。

# 开启重试机制，默认是关闭的
spring.cloud.loadbalancer.retry.enabled=true

# 断路器的超时时间需要大于Ribbon的超时时间，不然不会触发重试
hystrix.command.default.execution.isolation.thread.timeoutInMlliseconds=1000

# 请求连接的超时时间（my-service是调用的对应服务名）
my-service.ribbon.ConnectTimeout=250

# 请求处理的超时时间
my-service.ribbon.ReadTimeout=250

# 对所有操作请求都进行重试
my-service.ribbon.OkToRetryOnAllOperations=true

# 切换实例的重试次数
my-service.ribbon.MaxAutoRetriesNextServer=3

# 对当前实例的重试次数
my-service.ribbon.MaxAutoRetries=2

根据如上配置，当访问到故障请求的时候， 它会再尝试访问一次当前实例（次数由MaxAutoRetries配置）， 如果不行， 就换一个实例进行访问， 如果还是不行， 再换一次实例访问（更换次数由MaxAutoRetriesNextServer配置）， 如果依然不行， 返回失败信息