48

轻拢慢捻,微服务熔断大总管

 4 years ago
source link: https://www.tuicool.com/articles/26VBvuB
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

e6JBVrU.gif

原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。

我这篇文章来的晚了些,因为 hystrix 已经进入维护模式。但已经有非常多的同学入坑了,那么本篇文章就是及时雨。 本文将说明熔断使用的一些注意事项,可能会细的让你厌烦。

前半段,是理论部分,各种熔断都适用。后半段,是参数部分,适合微调。

那我们开始。

通常来说,皇帝在微服务里想夜生活过得舒服,能够大刀阔斧单刀直入,不因私事丢江山,就不得不靠 熔断大总管

时过境迁。提到 熔断大总管 就不得不说他手下最突出的三位公公:sentinel,或 hystrix ,也可能是resilience4j。

这三位都是解决一类问题的,如著名的 雪崩 :A→B→C互相依次调用,但C项目很可能出现问题(流量过大或者报错等),引发线程一直进行等待,导致拖垮整个链路层,线程资源耗尽。

ERBzy26.jpg!web

一、背景

假如是用的spring全家桶系列,在接口调用上大多会走这个路线。我们这里依然是在说hystrix,虽然现在不再受宠。

Feign —-→

Hystrix —-→

Ribbon —-→

Http Client(apache http components/Okhttp)

具体如下图所示:

uIJfyaQ.jpg!web

二、配置

首先来点理论性的东西。好吃不贵。

Ⅰ隔离方式

线程隔离(默认):使用一个线程池来存储当前的请求,线程池对请求作处理,设置任务返回处理超时时间,堆积的请求堆积入线程池队列。这种方式需要为每个依赖的服务申请线程池,有一定的资源消耗,好处是可以应对突发流量(流量洪峰来临时,处理不完可将数据存储到线程池队里慢慢处理)

信号隔离:使用一个原子计数器(或信号量)来记录当前有多少个线程在运行,请求来先判断计数器的数值,若超过设置的最大线程个数则丢弃改类型的新请求,若不超过则执行计数操作请求来计数器+1,请求返回计数器-1。这种方式是严格的控制线程且立即返回模式,无法应对突发流量(流量洪峰来临时,处理的线程超过数量,其他的请求会直接返回,不继续去请求依赖的服务)

Ⅱ熔断

如果某个目标服务调用慢或者大量超时,则此时熔断该服务的调用,对于后续调用请求,不再继续调用目标服务,直接返回,快速释放资源。如果目标服务情况好转,则恢复调用。

这个过程,可以想象成保险丝的行为。

行为虽然简单,但需要调节的参数却非常多。

使用方式

1.引入依赖

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>

2.配置参数

feign:
hystrix:
#不配置或为false则不生效
enabled: true
hystrix:
command:
default:
execution:
isolation:
thread:
#若配置了重试则超时时间= (1 + MaxAutoRetries + MaxAutoRetriesNextServer) * ReadTimeout
timeoutInMilliseconds: 60000
threadpool:
default:
coreSize: 10
maxQueueSize: 50
queueSizeRejectionThreshold: 30
keepAliveTimeMinutes: 3

3.配置fallback

因业务处理不同,建议每个feign client使用不同的fallback

3m2q2ib.jpg!web

6rQ7n22.jpg!web

到此,hystrix已经可以走马上任,至于干活儿稳不稳那是后话。

4.配置的其他姿势

hystrix到任务后,发现有的服务接口1s内就完事儿 ,还有的5s到10几秒才堪堪返回。一刀切的配置已难以管理诸多服务&接口。

想必已经有人发现,之前配置中混进了奇怪的东西——default关键词。这是对全局配置,那么对应的肯定有局部的配置。

如:对服务的,对某个接口的…

hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 60000
threadpool:
#全局配置
default:
coreSize: 10
maxQueueSize: 50
queueSizeRejectionThreshold: 30
keepAliveTimeMinutes: 3
#对某个服务配置,写service-id
base-rpc:
coreSize: 10
maxQueueSize: 30
queueSizeRejectionThreshold: 20
keepAliveTimeMinutes: 3
#对某个接口配置
BaseApiClient#searchItemSkuList(PosSkuSearch):
coreSize: 10
maxQueueSize: 40
queueSizeRejectionThreshold: 30
keepAliveTimeMinutes: 1

另外,还可以使用@HystrixCommand注解进行配置。

5.配置的动态修改

很多情况下,不能修改个配置,特别是临时修改配置就重启下服务,能动态刷新就最好了。

于是我们盯上了hystrix使用archaius管理配置的问题。

archaius是Netflix公司开源项目之一,基于java的配置管理类库,主要用于多配置存储的动态获取。

主要功能是对apache common configuration类库的扩展。在云平台开发中可以将其用作分布式配置管理依赖构件。同时,它有如下一些特性:

动态获取属性

高效和线程安全的配置操作

配置改变时提供回调机制

可以通过jmx操作配置

复合配置

说了这么多那该怎么整呢?以下就是简单的示例。

//捞配置
AbstractConfiguration config = ConfigurationManager.getConfigInstance();

//提取关注的部分,比如hystrix.threadpool
Iterable<String> iterable = () -> config.getKeys("hystrix.threadpool");
List<Property> result = StreamSupport.stream(iterable.spliterator(), false).map(t -> new Property(t, config.getString(t, "")))
.sorted(Comparator.comparing(Property::getName)).collect(Collectors.toList());

//修改配置
config.setProperty("hystrix.threadpool.base-rpc.coreSize", 20);

//移除配置
config.clearProperty(hystrix.threadpool.base-rpc.coreSize");

三、其他参数

要是觉得hystrix这么听话,那就太小看它了。别忘了前面有feign,后面还有ribbon,再往后http client呢!一堆超时参数,当代的八门金锁阵

1.feign超时

feign:
hystrix:
enabled: true
client:
config:
default:
connectTimeout: 5000
readTimeout: 5000
rpc-pos:
connectTimeout: 5000
readTimeout: 8000
xx-rpc:
connectTimeout: 5000
readTimeout: 12000
order-rpc:
connectTimeout: 5000
readTimeout: 8000

feign是暴露给用户使用的,Spring在处理这一块的时候,会有意识地使用feign的超时时间来设置后面的ribbon 和http client组件。

2.ribbon超时

#全局配置
ribbon:
ReadTimeout: 60000
ConnectTimeout: 10000
#false to only allow get method to retry
OkToRetryOnAllOperations: true
# Max number of next servers to retry (excluding the first server)
MaxAutoRetriesNextServer: 2
# Max number of retries on the same server (excluding the first try)
MaxAutoRetries: 0
# Interval to refresh the server list from the source
ServerListRefreshInterval: 5000
retryableStatusCodes: 404,500
#服务配置
base-rpc:
ribbon:
ReadTimeout: 60000
ConnectTimeout: 10000
#false to only allow get method to retry
OkToRetryOnAllOperations: true
# Max number of next servers to retry (excluding the first server)
MaxAutoRetriesNextServer: 2
# Max number of retries on the same server (excluding the first try)
MaxAutoRetries: 0
# Interval to refresh the server list from the source
ServerListRefreshInterval: 5000
retryableStatusCodes: 404,500

当feign设置了超时时间,Ribbon会依据feign的设置同步。Ribbon的这个超时时间,用于指导真正调用接口时,设置真正实现者的超时时间。

httpclient超时

feign:
hystrix:
enabled: true
okhttp:
enabled: true
httpclient:
enabled: false
//连接池最大连接数,默认200
max-connections: 500
//每一个IP最大占用多少连接 默认 50
max-connections-per-route: 50
//默认连接超时时间:2000毫秒
connection-timeout: 8000
//连接池管理定时器执行频率:默认 3000毫秒
connection-timer-repeat: 6000
//连接池中存活时间,默认为5
time-to-live: 5
time-to-live-unit: minutes

超时设置遵循的基本原则是:依赖方的超时配置覆盖被依赖方的配置,而其配置覆盖的形式,则是使用的Spring Boot 的 AutoConfiguration 机制实现的

如:若开启feign.okhttp.enabled=true,则okhttp的超时时间是feign.httpclient.connectionTimeout的值,默认2000毫秒

总结:超时——还是  feign  说了算!

四、hystrix dashboard

能够将这些状态可视化,是非常棒的,需要引入一个jar包。

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>
</dependency>

下面这张图,就是针对后台监控的一些解释。

zeU73qB.jpg!web(图片来自网络)

附:配置参数说明

一、Command Properties

以下属性控制HystrixCommand,前缀hystrix.command.default

1、Execution

以下属性控制HystrixCommand.run()如何执行。

比较重要的参数,有:

execution.isolation.strategy

execution.isolation.thread.timeoutInMilliseconds

IvAZFbE.jpg!web

2、Fallback

以下属性控制HystrixCommand.getFallback()如何执行。这些属性适用于ExecutionIsolationStrategy.THREAD和ExecutionIsolationStrategy.SEMAPHORE。

eyiUbiI.jpg!web

3、Circuit Breaker

断路器属性控制HystrixCircuitBreaker。

a2iEVbz.jpg!web

4、Metrics

以下属性与从HystrixCommand和HystrixObservableCommand执行捕获指标有关。

vyIBVnr.jpg!web

5、Request Context

这些属性涉及HystrixCommand使用的HystrixRequestContext功能

zYVzUzF.jpg!web

二、Command Properties

下列属性控制HystrixCollapser行为。前缀:hystrix.collapser.default

FFFvYvE.jpg!web

三、ThreadPool Properties

以下属性控制Hystrix命令在其上执行的线程池的行为。

大多数时候,默认值为10的线程会很好(通常可以做得更小)前缀:hystrix.threadpool.default

3UzANjM.jpg!web

End

B7rmUru.jpg!web

这货,说不更新,还真不更新了。但我们的遗留系统,有很多模块在用着,所以我还是把它的细节参数给抠出来了。这应该是绝版吧,因为hystrix是绝更了。

本文只适合收藏,不适合分享。分享出去,会等于拿着大喇叭告诉别人,你正在给某个遗留系统填坑呢。

作者简介: 小姐姐味道 (xjjdog),一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构,日百亿流量,与你探讨高并发世界,给你不一样的味道。我的个人微信xjjdog0,欢迎添加好友,进一步交流。

近期热门文章

《必看!java后端,亮剑诛仙》

后端技术索引,中肯火爆

《学完这100多技术,能当架构师么?(非广告)》

精准点评100多框架,帮你选型

《Linux上,最常用的一批命令解析(10年精选)》

CSDN发布首日,1k赞。点赞率1/8。

《这次要是讲不明白Spring Cloud核心组件,那我就白编这故事了》

用故事讲解核心组件,包你满意

《Linux生产环境上,最常用的一套“Sed“技巧》

最常用系列Sed篇,简单易懂。Vim篇更加易懂。

EnUneen.gif


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK