springcloud微服务调用配置

  • Jmater中的参数

循环次数是,12个线程同时发送请求,每个线程发送2次,第二次发送时要在第一次返回之后再发送。
Ramp-Up时间,是几秒内把线程启动,例如设置成36 ,则36秒启动12个线程,每3秒启动一个。


1.熔断线程能极大减轻业务线程压力
2.httpclient只提供连接池功能,没有线程池
3.熔断的信号量方式,用的是业务线程,没法控制超时时间,没法控制超时熔断时间,只能通过控制链接超时时间控制

  • tomcat配置
server:
  port: 8082
  tomcat:
    max-connections: 0  #最大链接数,这个数值要大于等于max-threads+accept-count
    max-threads: 1  #最大工作线程数,业务处理都放在这个线程上
    accept-count: 100  #等待队列,在线程不够用时用到

accept-count   :设置200以上按200计算,默认100,如设置150 ,会把链接放到队列中,消耗很小的CPU资源
max-connections :  可以接收的最大链接数,如设置500   ,会把链接放到select的队列上,相对会消耗CPU一些
最终能和服务建立链接的请求数为:accept-count +  max-connections   ,处于“ESTABLISHED”的连接数是500+150 =650 个,链接没有设置超时时间,会一直存在,直到有一份退出。
其他请求被拒绝  failed: Connection refused: connect

max-threads  :最大工作线程数,决定了服务器的处理能力

  • 关于熔断

1.如果没有熔断,任务都压在tomcat的工作线程上,会一直等待后台系统返回。
没有隔离,会被服务(包括优先级低)挤占满。

2.信号量的隔离方式,只能控制服务接入数量,占用的线程是tomcat工作线程。但是无法控制熔断超时间,只能靠通讯超时处理。

3.如果是线程隔离方式,也会占用tomcat工作线程,但是熔断超时后就会释放tomcat工作线程,不会导致占用时间过长的情况。

4.
#ribbon的超时时间

ribbon:
  OkToRetryOnAllOperations: false #对所有操作请求都进行重试,默认false,这个时候只针对get请求进行重试,当为true时,对put请求重试,注意幂等问题
  ReadTimeout: 10000   #负载均衡超时时间,默认值5000
  ConnectTimeout: 2000 #ribbon请求连接的超时时间,默认值2000
  MaxAutoRetries: 0     #对当前实例的重试次数,默认0
  MaxAutoRetriesNextServer: 1 #对切换实例的重试次数,默认1

#hystrix的

hystrix:
  #threadpool:
  #  default:
   #   coreSize: 20 # THREAD 模式 线程数
  command:
    default:  #default全局有效,service id指定应用有效
      execution:
        timeout:
          #是否开启超时熔断
          enabled: true
        isolation:
          #熔断模式 THREAD SEMAPHORE
          strategy: SEMAPHORE
          #semaphore熔断模式 参数 begin
          semaphore:
            maxConcurrentRequests: 10
          #semaphore熔断模式 参数 end
          thread:
            timeoutInMilliseconds: 15000 #断路器超时时间,默认1000ms,信号量的情况下这个参数也起作用,同时通过hystix-timer线程实现的

信号量方式时
timeoutInMilliseconds时间大于ReadTimeout时间时,按读超时抛出异常,进入熔断
即使timeoutInMilliseconds时间小于ReadTimeout时间,熔断发生的tomcat的工作线程也不会释放掉,直到readTimeout为止,才会释放线程,释放链接资源


线程方式时,tomcat的工作线程处于阻塞状态,不能去干其他的事情
timeoutInMilliseconds时间小于ReadTimeout时间,精确的熔断时间点,链接会直接关闭,释放链接资源
timeoutInMilliseconds时间大于ReadTimeout时间,按读超时抛出异常,进入熔断

#hystrix的

circuitBreaker:
  requestVolumeThreshold: 10 #当在配置时间窗口内达到此数量的失败后,进行短路。默认20个
  sleepWindowInMilliseconds: 5 #短路多久以后开始尝试是否恢复,默认5s
  errorThresholdPercentage: 50% #出错百分比阈值,当达到此阈值后,开始短路。默认50%

以上参数只用于线程模式时
十个熔断回调之后,开关打开,之后所有的请求都会报异常:java.lang.RuntimeException: Hystrix circuit short-circuited and is OPEN
5秒后开关处于半关闭,每次只放行一个请求,直到有成功的出现后才会关闭

当信号模式时
10个熔断回调之后,开关打开,之后所有的请求都会报异常:java.lang.RuntimeException: Hystrix circuit short-circuited and is OPEN
5秒后开关处于半关闭,每次只放行一批(信号量总数量)请求,然后进入打开状态,再5秒后开关处于半关闭,每次只放行一批
直到有成功的出现后才会关闭状态


熔断降级主要解决服务雪崩效应,主要支持如下机制:
    隔离(线程池隔离和信号量隔离):限制调用分布式服务的资源使用,某一个调用的服务出现问题不会影响其他服务调用。
    降级机制:超时降级、资源不足时(线程或信号量)降级,降级后可以配合降级接口返回托底数据。
    熔断:当失败率达到阀值自动触发降级(如因网络故障/超时造成的失败率高),熔断器触发的快速失败会进行快速恢复。
    缓存:提供请求缓存、请求合并实现。
    支持实时监控、报警、控制

猜你喜欢

转载自blog.csdn.net/weixin_41701609/article/details/114501962