1.参数配置
对于Ribbon的参数配置通常有两种方式:全局配置以及指定客户端配置:
全局配置:ribbon.<key>=<value>格式进行配置即可。<key>代表了Ribbon客户端配置的参数名,<value>代表了对应参数值。比如设置超时时间:
ribbon.connectTimeout=250
全局配置可以作为默认值进行设置,当指定客户端配置了相应key值时,将覆盖全局配置的内容。
客户端配置:<client>.ribbon.<key>=<value>的格式进行配置。<key>和<value>含义与全局配置相同,而<client>代表了客户端的名称,可以理解为一个服务名。如:
hello-service.ribbon.listOfServers=localhost:8001,localhost:8002
对于Ribbon参数的key以及value类型的定义可以通过查看com.netflix.client.config.commonClientConfigKey类看详细配置。
2.与Eureka结合
当Spring Cloud的应用中引入Spring Cloud Ribbon和Spring Cloud Eureka依赖时,会触发Eureka中实现的对Ribbon的自动化配置。这时ServerList的维护机制实现将被com.netflix.niws.loadbalancer.DiscoveryEnabledNIWSServerList的实例所覆盖,该实现会将服务清单列表交给Eureka的服务治理机制来进行维护。
在与Spirng Cloud Eureka结合使用的时候,不需要通过类似hello-service.ribbon.listOfServers的参数来指定具体的服务实例清单,因为Eureka会为我们维护所有服务的实例清单。对于Ribbon的参数配置,我们依然可以使用之前的两种配置方式实现,而指定客户端的配置方式可以直接使用Eureka中的服务名作为<client>来完成对各个微服务的个性化配置。
如果想要禁止Eureka对Ribbon服务实例的维护实现。只需要加入如下参数:
ribbon.eureka.enabled=false
3.重试机制
在Spring Cloud Eureka实现的服务治理机制强调了CAP原理中的AP(可用性与可靠性),Zookeeper这类强调CP(一致性与可靠性)的服务治理框架最大的区别是Eureka为了实现更高的服务可用性,牺牲了一定的一致性,在极端情况下它宁愿接受故障实例也不会丢掉“健康”实例。
spring.cloud.loadbalancer.retry.enabled=true
spring.cloud.loadbalancer.retry.enabled该参数用来开启重试机制,它默认是关闭的。
spring.cloud.loadbalancer.retry.enabledhystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000hello-service.ribbon.ConnectTimeout=250
hello-service.ribbon.ReadTimout=1000
hello-service.ribbon.OkToRetryOnAllOperations=true
hello-service.ribbon.MaxAutoRetriesNextServer=2
hello-service.ribbon.MaxAutoRetries=1
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds:断路器的超时时间需要大于Ribbon的超时时间,不然不会触发重试。 hello-service.ribbon.ConnectTimeout:请求连接的超时时间。 hello-service.ribbon.ReadTimout:请求处理的超时时间。 hello-service.ribbon.OkToRetryOnAllOperations:对所有操作请求都进行重试。 hello-service.ribbon.MaxAutoRetriesNextServer:切换实例的重试次数。 hello-service.ribbon.MaxAutoRetries:对当前实例的重试次数。
根据如上配置当访问到故障请求的时候,它会再尝试访问一次当前实例(次数由MaxAutoRetries配置),如果不行就换一个实例进行访问。如果还是不行再换一次实例访问(更换次数由MaxAutoRetriesNextServer配置)如果依然不行,返回失败信息。