Feign+Hystrix笔记
1、OpenFeign
1.1OpenFeign简介
OpenFeign是Netflix开发的⼀个轻量级RESTful的HTTP服务客户端(用它来发起请求,远程调用的),是以Java接⼝注解的⽅式调用Http请求,⽽不⽤像Java中通过封装HTTP请求报⽂的⽅式直接调⽤,Feign被⼴泛应⽤在Spring Cloud 的解决⽅案中。类似于Dubbo,服务消费者拿到服务提供者的接⼝,然后像调⽤本地接⼝⽅法⼀样去调⽤,实际发出的是远程的请求。
- Feign可帮助我们更加便捷,优雅的调⽤HTTP API:不需要我们去拼接url然后呢调⽤restTemplate的api,在SpringCloud中,使⽤Feign⾮常简单,创建⼀个接⼝(在消费者--服务调⽤⽅这⼀端),并在接⼝上添加⼀些注解,代码就完成了
- SpringCloud对Feign进⾏了增强,使Feign⽀持了SpringMVC注解(OpenFeign)
本质:封装了Http调用流程,更符合面向接口编程规范,类似于Dubbo的服务调用。
Feign,假装,伪装。OpenFeign可以将提供者提供的Restful服务伪装为接口进行消费,消费者只需使用“feign接口 + 注解”的方式即可直接调用提供者提供的 Restful 服务,而无需再使用 RestTemplate。注意:Feign 仅是一个伪客户端,其不会对请求做任何处理。Feign 是通过注解的方式实现 RESTful 请求的。
Feign = RestTemplate + Ribbon + Hystrix
1.2Feign应用
1、基础应用
POM
启动类
@SpringBootApplication
@EnableFeignClients
@EnableDiscoveryClient
public class FeignApplication8091 {
public static void main(String[] args) {
SpringApplication.run(FeignApplication8091.class, args);
}
}
配置文件
server:
port: 8091
spring:
application:
name: service-consumer-byFeign
eureka:
client:
service-url:
defaultZone: http://localhost:8761/eureka,http://localhost:8762/eureka
feign:
client:
config:
default:
# 指定Feign客户端连接提供者的超时时限
connectTimeout: 5000
# 指定Feign客户端连接上提供者后,向提供者进行提交请求,从提交时刻开始,到接收到响应,这个时段的超时时限
readTimeout: 5000
Feign客户端
@FeignClient(name = "service-provider")
@RequestMapping("/demo")
public interface ProviderFeign {
@GetMapping("/hello")
String sayHello();
}
2、Feign集成负载均衡
Feign 本身已经集成了Ribbon依赖和⾃动配置,因此我们不需要额外引⼊依赖,可以直接通过配置来设置负载均衡
Feign默认的请求处理超时时⻓1s,有时候我们的业务确实执⾏的需要⼀定时间,那么这个时候,我们就需要调整请求处理超时时⻓,Feign⾃⼰有超时设置,如果配置Ribbon的超时,则会以Ribbon的为准
service-provider:
ribbon:
#请求连接超时时间
ConnectTimeout: 2000
#请求处理超时时间
ReadTimeout: 3000 #Feign超时时长设置
#对所有操作都进行重试
OkToRetryOnAllOperations: true
####根据如上配置,当访问到故障请求的时候,它会再尝试访问一次当前实例(次数由MaxAutoRetries配置),
####如果不行,就换一个实例进行访问,如果还不行,再换一次实例访问(更换次数由MaxAutoRetriesNextServer配置),
####如果依然不行,返回失败信息。
MaxAutoRetries: 0 #对当前选中实例重试次数,不包括第一次调用
MaxAutoRetriesNextServer: 0 #切换实例的重试次数
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule #负载策略调整
3、Feign对熔断器的支持
Feign内置的有Hystrix功能,因此使用的时候可以对Feign客户端接口进行熔断处理。
# 开启Feign的熔断功能
feign:
hystrix:
enabled: true
#Hystrix的超时时长设置
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 1000
熔断设置
@FeignClient(name = "service-provider", fallback = ProviderFallback.class , path = "/demo")
public interface ProviderFeign {
@GetMapping("/hello")
String hello();
}
降级之后的类
@Component
public class ProviderFallback implements ProviderFeign {
@Override
public String hello() {
return "降级";
}
}
注意:
1、@FeignClient中的path属性相当于@RequestMapping属性,用来给所有的方法添加属性的。
2、开启Hystrix之后,Feign中的⽅法都会被进⾏⼀个管理了,⼀旦出现问题就进⼊对应的回退逻辑处理
3、针对超时这⼀点,当前有两个超时时间设置(Feign/hystrix),熔断的时候是根据这两个时间的最⼩值来进⾏的,即处理时⻓超过最短的那个超时时间了就熔断进⼊回退降级逻辑。
4、Feign打印debug日志管理
#开启feign日志
logging:
level:
# Feign日志只会对日志级别为debug的做出响应
com.lagou.edu.controller.service.ResumeServiceFeignClient: debug
5、Feign对请求压缩和响应压缩的⽀持
Feign ⽀持对请求和响应进⾏GZIP压缩,以减少通信过程中的性能损耗。通过下面的参数 即可开启请求与响应的压缩功能:
feign:
compression:
request:
enabled: true # 开启请求压缩
mime-types: text/html,application/xml,application/json # 设置 压缩的数据类型,此处也是默认值
min-request-size: 2048 # 设置触发压缩的⼤⼩下限,此处也是默认值
response:
enabled: true # 开启响应压缩
1.3Feign源码分析
1、重要类与接口解析
(1)@EnableFeignClients
用于启动feignClient功能。
(2)@FeignClient
用于标注接口为Feign接口,并且指定调用的远程服务名
(3)FeignClientSpecification类
FeignClientSpecification 是一个 Feign Client 的生成规范。包含有name和congiguration
(4)BeanDefinition接口
Spring中BeanDefinition 是一个 Bean 定义器。
(5)BeanDefinitionRegistry接口
BeanDefinitionRegistry 是一个 BeanDefinition 注册器。
(6)FeignContext类
FeignContext 是一个为 Feign Client 创建所准备的上下文对象。
[图片上传失败...(image-aba764-1615007165817)]
继承于NamedContextFactory;在NamedContextFactory中有两个非常重要的属性。
[图片上传失败...(image-27e7de-1615007165817)]
属性说明:
1、contexts 中的key为FeignClient的名称,即微服务名称,value则为Spring子容器。该子容器中存放着创建这个 FeignClient 所必须的所有元数据。
2、configurations 这个 map 中包含两类 entry。
1)第一类entry只有一个,其key为default+当前应用启动类名,value为@EnableFeignClients中的 defaultConfiguration 实例。
2)第二类 entry 有多个,当前应用中有几个FeignClient,就会有几个这类 entry。其 key 为@FeignClient的name属性值,即微服务名称,value为@FeignClient的configuration属性实例。
2、Ribbon
2.1负载均衡简介
负载均衡⼀般分为服务器端负载均衡和客户端负载均衡
所谓服务器端负载均衡,⽐如Nginx、F5这些,请求到达服务器之后由这些负载均衡器根据⼀定的算法将请求路由到⽬标服务器处理。
所谓客户端负载均衡,比如我们要说的Ribbon,服务消费者客户端会有⼀个服务器地址列表,调⽤⽅在请求前通过⼀定的负载均衡算法选择⼀个服务器进⾏访问,负载均衡算法的执⾏是在请求客户端进⾏。
2.2、Ribbon基础应用
1、Ribbon简介
Ribbon是Netflix发布的负载均衡器。Eureka⼀般配合Ribbon进⾏使⽤,Ribbon利⽤从Eureka中读取到服务信息,在调⽤服务提供者提供的服务时,会根据⼀定的算法进⾏负载。
2、简单应用
在EurekaClinet端会自动引入Ribbon,在使用的时候我们直接注入RestTemplate上贴上注解@LoadBalanced即可使用。
@LoadBalanced
@Bean
public RestTemplate restTemplate(){
return new RestTemplate();
}
修改负载均衡配置
#只针对service-provider服务生效
service-provider: #你的服务名称
ribbon:
#负载策略调整
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
#全量生效
ribbon:
#负载策略调整
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
通过注入Bean的方式修改:
@Bean
public IRule iRule(){
return new RoundRobinRule();
}
3、Ribbon内置的负载均衡策略
| 负载均衡策略 | 描述 |
| RoundRobinRule:轮询策略 | 默认超过10次获取到的server都不可⽤,会返回⼀个空的server |
| RandomRule:随机策略 | 如果随机到的server为null或者不可⽤的话,会while不停的循环选取 |
| RetryRule:重试策略 | 重试策略。先按照 RoundRobinRule 策略获取 provider,若获取失败,则在指定的时限内重试。默认的时限为 500 毫秒。 |
| BestAvailableRule:最⼩连接数策略 | 最可用策略。选择并发量最小的 provider,即连接的消费者数量最少的 provider。 |
| AvailabilityFilteringRule:可⽤过滤策略 | 可用过滤算法。该算法规则是:过滤掉处于熔断状态的 provider 与已经超过连接极限的provider,对剩余 provider 采用轮询策略。 |
| ZoneAvoidanceRule:区域权衡策略(默认策略) | zone 回避策略。根据 provider 所在 zone 及 provider 的可用性,对 provider 进行选择。 |
| WeightedResponseTimeRule权重响应时间 | 根据每个 provider 的平均响应时间计算其权重,响应时间越快权重越大,被选中的机率就越高。在刚启动时采用轮询策略。后面就会根据权重进行选择了。 |
2.3、Ribbon源码剖析
1、Ribbon原理分析
总得概述一下,就是在执行请求的时候通过拦截器获取到所有提供者的服务列表,然后通过算法找出一个提供者进行调用。
2、Ribbon架构图
[图片上传失败...(image-8b36b5-1615007165817)]
Ribbon核心还是LoaderBalancer其中IPing、IRule、ServerListFilter、ServerListUpdater属于Ribbon的四大组件。
- IRule:是在选择实例的时候的负载均衡策略对象
- IPing:是⽤来向服务发起⼼跳检测的,通过⼼跳检测来判断该服务是否可⽤
- ServerListFilter:根据⼀些规则过滤传⼊的服务实例列表
- ServerListUpdater:定义了⼀系列的对服务列表的更新操作
3、Hystrix
3.1、雪崩效应
1、什么是雪崩?
微服务中,⼀个请求可能需要多个微服务接⼝才能实现,会形成复杂的调⽤链路。
[图片上传失败...(image-87dfb6-1615007165817)]
比如商品服务调用订单服务,仓储服务,消息通知服务才能完成,如果商品服务一旦订单服务出现问题对订单服务的调⽤就会占⽤越来越多的系统资源,进⽽引起系统崩溃,也就是所谓的“雪崩效应”。
扇入:代表着该微服务被调用的次数,扇入大,说明该模块复用性好
扇出:该微服务调⽤其他微服务的个数,扇出⼤,说明业务逻辑复杂
扇⼊⼤是⼀个好事,扇出⼤不⼀定是好事。
2、雪崩效应解决方案
从可⽤性可靠性着想,为防⽌系统的整体缓慢甚至崩溃,采⽤的技术⼿段;
1、服务熔断
熔断机制是应对雪崩效应的⼀种微服务链路保护机制。我们在各种场景下都会接触到熔断这两个字。⾼压电路中,如果某个地⽅的电压过⾼,熔断器就会熔断,对电路进⾏保护。同样,在微服务架构中,熔断机制也是起着类似的作⽤。当扇出链路的某个微服务不可⽤或者响应时间太⻓时,熔断该节点微服务的调⽤,进⾏服务的降级,快速返回错误的响应信息。当检测到该节点微服务调⽤响应正常后,恢复调⽤链路。
注意:
1)服务熔断重点在“断”,切断对下游服务的调⽤
2)服务熔断和服务降级往往是⼀起使⽤的,Hystrix就是这样。
2、服务降级
通俗讲就是整体资源不够⽤了,先将⼀些不关紧的服务停掉(调⽤我的时候,给你返回⼀个预留的值,也叫做兜底数据),待渡过难关⾼峰过去,再把那些服务打开。
服务降级⼀般是从整体考虑,就是当某个服务熔断之后,服务器将不再被调⽤,此刻客户端可以⾃⼰准备⼀个本地的fallback回调,返回⼀个缺省值,这样做,虽然服务⽔平下降,但好⽍可⽤,⽐直接挂掉要强。
3、服务限流
服务降级是当服务出问题或者影响到核⼼流程的性能时,暂时将服务屏蔽掉,待⾼峰或者问题解决后再打开;但是有些场景并不能⽤服务降级来解决,⽐如秒杀业务这样的核⼼功能,这个时候可以结合服务限流来限制这些场景的并发/请求量。
流措施也很多,比如:
- 限制总并发数(⽐如数据库连接池、线程池)
- 限制瞬时并发数(如nginx限制瞬时并发连接数)
- 限制时间窗⼝内的平均速率(如Guava的RateLimiter、nginx的limit_req模块,限制每秒的平均速率)
- 限制远程接⼝调⽤速率、限制MQ的消费速率等
3.2Hystrix简介
Hystrix(豪猪----->刺),宣⾔“defend your app”是由Netflix开源的⼀个延迟和容错库,⽤于隔离访问远程系统、服务或者第三⽅库,防⽌级联失败,从⽽提升系统的可⽤性与容错性。Hystrix主要通过以下⼏点实现延迟和容错。其主要功能:
- 包裹请求:使⽤HystrixCommand包裹对依赖的调⽤逻辑。 商品服务(@HystrixCommand 添加Hystrix控制)——调⽤订单服务
- 跳闸机制:当某服务的错误率超过⼀定的阈值时,Hystrix可以跳闸,停⽌请求该服务⼀段时间。
- 资源隔离:Hystrix为每个依赖都维护了⼀个⼩型的线程池(舱壁模式)(或者信号量)。如果该线程池已满, 发往该依赖的请求就被⽴即拒绝,而不是排队等待,从而加速失败判定。
- 监控:Hystrix可以近乎实时地监控运⾏指标和配置的变化,例如成功、失败、超时、以及被拒绝 的请求等。
- 回退机制:当请求失败、超时、被拒绝,或当断路器打开时,执⾏回退逻辑。回退逻辑由开发⼈员 ⾃⾏提供,例如返回⼀个缺省值。
- 自我修复:断路器打开⼀段时间后,会⾃动进⼊“半开”状态。
3.3Hystrix应用
1、简单应用
引入依赖
配置类上开启注解
@SpringBootApplication
@EnableHystrix //开启hystrix
@EnableCircuitBreaker//针对所有的熔断器
//@SpringCloudApplication //@SpringBootApplication + @EnableDiscoveryClient + @EnableCircuitBreaker
public class ServiceConsumer {
public static void main(String[] args) {
SpringApplication.run(ServiceConsumer.class, args);
}
@LoadBalanced
@Bean
public RestTemplate restTemplate(){
return new RestTemplate();
}}
在需要降级的方法上添加注解
// 使用@HystrixCommand注解进行熔断控制
@HystrixCommand(
commandProperties = {
// 每一个属性都是一个HystrixProperty
@HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value="2000")
}
)
设置的超时事件为2s的 一旦超过2s就会抛出异常。
2、服务降级应
@GetMapping("/hello")
// 使用@HystrixCommand注解进行熔断控制
@HystrixCommand(
// commandProperties熔断的一些细节属性配置
commandProperties = {
// 每一个属性都是一个HystrixProperty
@HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value="2000")
},
fallbackMethod = "myFallback"
)
public String getProvider(){
return restTemplate.getForObject(*url *+ "/demo/hello",String.class);
}
降级方法
public String myFallback(){
return "fall back";
}
注意:降级方法一定要和远程调用方法的形参和返回值保持一致也即方法签名要保持一致。
3、舱壁模式应用
一个应用中所有贴了@HystrixCommand注解的方法都会共享一个线程池,默认线程数为10个,所谓舱壁模式就是给贴了@HystrixCommand注解的方法单独设置一个线程池,那么彼此之间不会影响。
使用方式
@GetMapping("/hello")
// 使用@HystrixCommand注解进行熔断控制
@HystrixCommand(
// 线程池标识,要保持唯一,不唯一的话就共用了
threadPoolKey = "findResumeOpenStateTimeout",
// 线程池细节属性配置
threadPoolProperties = {
@HystrixProperty(name="coreSize",value = "1"), // 线程数
@HystrixProperty(name="maxQueueSize",value="20") // 等待队列长度
},
// commandProperties熔断的一些细节属性配置
commandProperties = {
// 每一个属性都是一个HystrixProperty
@HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value="2000")
},
fallbackMethod = "myFallback"
)
public String getProvider(){
return restTemplate.getForObject(*url *+ "/demo/hello",String.class);
}
3.4 Hystrix高级应用
1、执行隔离策略(舱壁模式)
执行隔离策略有两大作用:防止服务熔断,防止服务雪崩。
对某种依赖的请求数量进行限制的方式,称为执行隔离。
类型
隔离请求的方式有两种类型:
线程隔离:Hystrix 的默认隔离策略。系统会创建一个依赖线程池,为每个依赖请求分配一个独立的线程,而每个依赖所拥有的线程数量是有上限的。当对该依赖的调用请求数量达到上限后再有请求,则直接拒绝该请求,并对该请求做降级处理。所以对某依赖的并发量取决于为该依赖线程池所分配的线程数量。
信号量隔离:对依赖的调用所使用的线程仍为请求线程,即不会为依赖请求再新创建新的线程。但系统会为每种依赖分配一定数量的信号量,而每个依赖请求分配一个信号。当对该依赖的调用请求数量达到上限后再有请求,则直接拒绝该请求,并直接对该请求做降级处理。所以对某依赖的并发量取决于为该依赖所分配的信号量数量。
对比
- 线程是进程的一个执行体,其具有独立运行的特性,而信号量却不是,其仅仅是线程执行的条件。
- 线程隔离中请求线程与提供者调用线程不是同一个线程,而信号量隔离中请求线程与调用线程是同一个线程。
- 线程隔离的执行效率要高于信号量隔离的,因为线程隔离的执行体数量是信号量隔离的2 倍。
- 线程隔离使每台主机处理请求的数量是有限制的,因为主机线程数量是有上限的。而信号量隔离不同,其没有上限,因为所谓信号量就是一个计数器,是一个数值,其不存在上限。
- 在服务器少而请求并发量大的情况下不建议使用线程隔离,否则可能会使系统对请求的并发能力下降。
- 线程隔离便于控制反馈给客户端的降级时间。
2、跳闸与自我修复机制
原理
执行步骤说明:
1、当调⽤出现问题时,开启⼀个时间窗(10s)
2、在这个时间窗内,统计调⽤次数是否达到最⼩请求数?
如果没有达到,则重置统计信息,回到第1步
如果达到了,则统计失败的请求数占所有请求数的百分⽐,是否达到阈值?
如果达到,则跳闸(不再请求对应服务)
如果没有达到,则重置统计信息,回到第1步
3、如果跳闸,则会开启⼀个活动窗⼝(默认5s),每隔5s,Hystrix会让⼀个请求通过,到达那个问题服务,看 是否调⽤成功,如果成功,重置断路器回到第1步,如果失败,回到第3步
配置
需求是配置一个事件窗为10s,最小请求数量为10次,错误阈值达到50%的比例会跳闸,窗口期会5s
@HystrixCommand(
// 线程池标识,要保持唯一,不唯一的话就共用了
threadPoolKey = "helloFallback",
// 线程池细节属性配置
threadPoolProperties = {
@HystrixProperty(name="coreSize",value = "2"), // 线程数
@HystrixProperty(name="maxQueueSize",value="20") // 等待队列长度
},
// commandProperties熔断的一些细节属性配置
commandProperties = {
// 每一个属性都是一个HystrixProperty
@HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value="2000"),
// hystrix高级配置,定制工作过程细节
// 统计时间窗口定义
@HystrixProperty(name = "metrics.rollingStats.timeInMilliseconds",value = "10000"),
// 统计时间窗口内的最小请求数
@HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "10"),
// 统计时间窗口内的错误数量百分比阈值
@HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value = "50"),
// 自我修复时的活动窗口长度
@HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value = "5000")
},
fallbackMethod = "myFallBack" // 回退方法
)
这些属性也可以在配置文件中进行配置
# 配置熔断策略:
hystrix:
command:
default:
circuitBreaker:
# 强制打开熔断器,如果该属性设置为true,强制断路器进⼊打开状态,将会拒绝所有的请求。 默认false关闭的
forceOpen: true
# 触发熔断错误⽐例阈值,默认值50%
errorThresh oldPercentage: 50
# 熔断后休眠时⻓,默认值5秒
sleepWindowInMilliseconds: 3000
# 熔断触发最⼩请求次数,默认值是20
requestVolumeThreshold: 2
execution:
isolation:
thread:
# 熔断超时设置,默认为1秒
timeoutInMilliseconds: 2000
查看服务状态的方法
通过SpringBoot健康检查的断点进行查看,
配置
# springboot中暴露健康检查等断点接口
management:
endpoints:
web:
exposure:
include: "*"
# 暴露健康接口的细节
endpoint:
health:
show-details: always
访问地址:https://localhost:{YourPort}/actuator/health
观察
hystrix正常⼯作状态
[图片上传失败...(image-76cc6b-1615007165816)]
跳闸状态
[图片上传失败...(image-b1a7b1-1615007165816)]
活动窗⼝内⾃我修复
[图片上传失败...(image-7f0357-1615007165816)]
3、Hystrix Dashbord仪表盘
Hystrix Dashbord仪表盘是制作了一个页面用来专门监控Hystrix的请求状况,依赖于SpringBootActuator
使用
在consumer引入依赖
在被监控系统中添加Bean用于监听Hystrix的信息流
@Bean
public ServletRegistrationBean getServlet(){
HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet();
ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet);
registrationBean.setLoadOnStartup(1);
registrationBean.addUrlMappings("/actuator/hystrix.stream");
registrationBean.setName("HystrixMetricsStreamServlet");
return registrationBean;
}
在启动类上开启Dashboard @EnableHystrixDashboard
访问 http://localhost:{your port} /hystrix/
输入 http://localhost:your port/actuator/hystrix.stream
仪表盘说明
[图片上传失败...(image-14f0a4-1615007165816)]
百分⽐,10s内错误请求百分比
实心圆:
大小:代表请求流量的⼤⼩,流量越⼤球越⼤
颜色:代表请求处理的健康状态,从绿⾊到红⾊递减,绿⾊代表健康,红⾊就代表很不健康
曲线波动图:记录了2分钟内该⽅法上流量的变化波动图,判断流量上升或者下降的趋势
4、Hystrix Turbine聚合监控
Turbine 对于集群分组进行监控的原理是,在集群之上再添加一种分类:组。为每个集群中的 Sever 都添加一个 groupId,而 Turbine 是基于 groupId 进行监控的。这个 groupId 是基于自定义的 Eureka 元数据实现的。
Eureka 元数据是指,Eureka Client 向 Eureka Server 注册时的描述信息,注册数据。其有两种类型:
- 标准元数据:Eureka 中已经定义好的客户端描述信息。
- 自定义元数据:在客户端配置文件中自己指定的 key-value 数
思考:如果微服务比较多的情况下,去查看对应微服务的状态信息,那么就需要一个一个服务去查看这样子的话比较麻烦有什么比较好的方式?
Hystrix Turbine技术就是将被监控的各个微服务的hystrix监控流信息汇聚成一个监控流信息。
[图片上传失败...(image-c0a015-1615007165816)]
使用
新创建一个项目
引入EurekaClinet的作用主要是为了方便管理和配置所需。
启动类
@SpringBootApplication
@EnableDiscoveryClient
@EnableTurbine // 开启Turbine聚合功能
public class HystrixTurbineApplication9001 {
public static void main(String[] args) {
SpringApplication.run(HystrixTurbineApplication9001.class,args);
}
}
配置
server:
port: 9001
Spring:
application:
name: spirng-cloud-hystrix-turbine
eureka:
client:
serviceUrl: # eureka server的路径
defaultZone: http://localhost:8761/eureka/,http://localhost:8762/eureka/
instance:
prefer-ip-address: true
instance-id: {spring.application.name}:${server.port}:@project.version@
#turbine配置
turbine:
# appCofing配置需要聚合的服务名称,比如这里聚合自动投递微服务的hystrix监控数据
# 如果要聚合多个微服务的监控数据,那么可以使用英文逗号拼接,比如 a,b,c
appConfig: lagou-service-autodeliver
clusterNameExpression: "'default'" # 集群默认名称
配置好之后直接访问地址 http://localhost:9001/turbine.stream 就是聚合后的信息,将当前信息粘贴到Dasboard中就能观察数据。