社区微信群开通啦,扫一扫抢先加入社区官方微信群
社区微信群
资料参考:《Spring Cloud 微服务实战》
目录
经过上一节对Spring Cloud Ribbon的源码的大概的了解,详解自己对Ribbon的几个重要的接口已经有一些了解。下面我将去学习一下Ribbon在使用时的各种配置方式。
由于Ribbon中定义的每一个接口都有多种不同的策略,同时接口直接又有依赖关系,使得我们在用的时候不知道如何选择具体的实现策略已经组织他们的依赖关系。Spring Cloud Ribbon的自动化配置恰好能解决这样的痛点,在引入Spring Cloud Ribbon的依赖之后,就能够自动化构建下面这些接口的实现。
上面这些自动化配置内容仅在没有引入SpringCloudEureka等服务治理框架时如此,在同时引入Eurcka和Ribbon依赖时,自动化配置会有一些不同,后续我们会做详细的介绍。
通过自动化配置的实现,我们可以轻松地实现客户端负载均衡。同时,针对一些个性化需求,我们也可以方便地替换上面的这些默认实现。只需在Spring Boot应用中创建对应的实现实例就能覆盖这些默认的配置实现。比如下面的配置内容,由于创建了PingUrl实例,所以默认的NoOpPing就不会被创建。
另外,也可以通过使用@RibbonClient注解来实现更细粒度的客户端配置,比如下面的代码实现了为hello-service服务使用HelloServiceConfigurstion中的配置。
对于Ribbon的参数配置通常有两种方式:全局配置以及指定客户端配置。
ribbon. ConnectTimeout 250
全局配置可以作为默认值进行设置,当指定客户端配置了相应key的值时,将覆盖全局配置的内容。‘
指定客户端的配置方式采用<client>.ribbon. <key>=<value>的格式进行配置。其中,<key>和<value>的含义同全局配置相同,而<client>代表了 客户端的名称,如上文中我们在@RibbonClient 中指定的名称,也可以将它理解为是一-个服务名。为了方便理解这种配置方式,我们举一一个具体的例子: 假设,有一个服务消费者通过RestTemplate来访问hello-service服务的/hello接口,这时我们会这样调用restTemplate . getForEntity ("http://hello-service/hello", String.class) .getBody();.如果没有服务治理框架的帮助,我们需要为该客户端指定具体的实例清单,可以指定服务名来做详细的配置,具体如下:
hello-service.ribbon.listOfServers-localhost: 8001. localhost:8002, 1ocalhost:8003
对于Ribbon参数的key以及value类型的定义,可以通过查看com. netflix. client.config. CommonClientConfigKey类获得更为详细的配置内容
hystrix:
command: #用于控制HystrixCommand的行为
default:
execution:
isolation:
strategy: THREAD #控制HystrixCommand的隔离策略,THREAD->线程池隔离策略(默认),SEMAPHORE->信号量隔离策略
thread:
timeoutInMilliseconds: 1000 #配置HystrixCommand执行的超时时间,执行超过该时间会进行服务降级处理
interruptOnTimeout: true #配置HystrixCommand执行超时的时候是否要中断
interruptOnCancel: true #配置HystrixCommand执行被取消的时候是否要中断
timeout:
enabled: true #配置HystrixCommand的执行是否启用超时时间
semaphore:
maxConcurrentRequests: 10 #当使用信号量隔离策略时,用来控制并发量的大小,超过该并发量的请求会被拒绝
fallback:
enabled: true #用于控制是否启用服务降级
circuitBreaker: #用于控制HystrixCircuitBreaker的行为
enabled: true #用于控制断路器是否跟踪健康状况以及熔断请求
requestVolumeThreshold: 20 #超过该请求数的请求会被拒绝
forceOpen: false #强制打开断路器,拒绝所有请求
forceClosed: false #强制关闭断路器,接收所有请求
requestCache:
enabled: true #用于控制是否开启请求缓存
collapser: #用于控制HystrixCollapser的执行行为
default:
maxRequestsInBatch: 100 #控制一次合并请求合并的最大请求数
timerDelayinMilliseconds: 10 #控制多少毫秒内的请求会被合并成一个
requestCache:
enabled: true #控制合并请求是否开启缓存
threadpool: #用于控制HystrixCommand执行所在线程池的行为
default:
coreSize: 10 #线程池的核心线程数
maximumSize: 10 #线程池的最大线程数,超过该线程数的请求会被拒绝
maxQueueSize: -1 #用于设置线程池的最大队列大小,-1采用SynchronousQueue,其他正数采用LinkedBlockingQueue
queueSizeRejectionThreshold: 5 #用于设置线程池队列的拒绝阀值,由于LinkedBlockingQueue不能动态改版大小,使用时需要用该参数来控制线程数
实例配置只需要将全局配置中的default换成与之对应的key即可。
hystrix:
command:
HystrixComandKey: #将default换成HystrixComrnandKey
execution:
isolation:
strategy: THREAD
collapser:
HystrixCollapserKey: #将default换成HystrixCollapserKey
maxRequestsInBatch: 100
threadpool:
HystrixThreadPoolKey: #将default换成HystrixThreadPoolKey
coreSize: 10
配置文件中相关key的说明
HystrixComandKey对应@HystrixCommand中的commandKey属性;
HystrixCollapserKey对应@HystrixCollapser注解中的collapserKey属性;
HystrixThreadPoolKey对应@HystrixCommand中的threadPoolKey属性。
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!