余思博客

超时时间设置Ribbon配置由于Spring Cloud Feign的客户端负载均衡时通过Spring Cloud Ribbon实现的，因此我们可以直接通过配置Ribbon客户端的方式来自定义各个服务客户端调用的参数。接下来就学习如何在使用Spring Cloud Feign的工程中使用Ribbon的配置。当然后续也会学习如何直接设置Feign的超时时间。 全局配置全局配置的方式非常简单，只需在application.yml配置文件中使用诸如ribbon.<key>=<value>的方式来设置Ribbon的各项默认参数。 请注意此时必须选择Feign包内自带的Ribbon，因为Maven自带的Ribbon可能会冲突失效。如笔者这里使用的SpringBoot版本是2.3.3，而SpringCloud版本则是Hoxton.SR7，因此对应的Ribbon可能会与Feign自带的版本产生冲突： 接下来举一个例子来演示ribbon.<key>=<value>的方式，如修改默认的客户端调用超时时间如下所示： 1234# 全局配置ribbon: C ...

参数绑定正如你所看到的，在入门demo中我们使用Spring Cloud Feign实现的是一个不带参数的REST服务绑定，但是在实际开发过程中，更多的则是携带参数的情况，同时返回请求响应的时候也可能是一个复杂的对象结构。接下来就开始对Feign中对于不同形式参数绑定方法的学习。 服务提供者提供演示接口既然是服务调用，那么首先应该有服务提供者，因此需要在eureka-client项目（服务名为hello-service，即服务提供者）内提供几个携带参数的API接口。在HelloController类中新增如下代码： 12345678910111213141516171819202122@GetMapping(value = "/feignOne")public String feignOne(@RequestParam("name")String name){ return "welcome "+ name +"to Beijing!";}@GetMapping(value = & ...

写在前面在前面我们学习了SpringCloud Ribbon和SpringCloud Hystrix这两个非常重要的组件，学会了如何在微服务架构中实现客户端负载均衡的服务调用以及如何通过断路器来保护我们的微服务应用。这两者通常是作为基础工具类框架被广泛运用在各个微服务的实现中，不仅包括我们自身的业务类微服务，也包括一些基础设施类微服务，如后面要学习的网关。同时经过大量的实践，我们发现这两个框架几乎都是同时出现的，那么问题来了，我们是否可以将这两个工具进行更深层次的封装用以简化开发呢？答案是肯定的，俗话说的好，前人种树后人乘凉，接下来就学习基于这两个工具的更深层次封装的组件Spring Cloud Feign。Spring Cloud Feign基于Netflix Feign实现，它整合了SpringCloud Ribbon和SpringCloud Hystrix，并在此基础上提供了一种声明式的Web服务客户端定义方式。 Spring Cloud Feign简介在前面我们学习Spring Cloud Ribbon的时候，通常都会利用它对RestTemplate的请求拦截来实现对依赖服务的 ...

Hystrix仪表盘监控集群应用在前面介绍Hystrix Dashboard的首页时，我们知道Hystrix Dashboard支持三种不同的监控方式，而前面只介绍了第三种单体应用的监控，接下来开始介绍前两种对于集群的监控。由于默认集群和自定义集群仅仅是名字和配置方式不同，其他的都是一样的，因此这里以监控默认集群为例进行介绍。Hystrix Dashboard首页如下所示： 也就是说turbine.stream?cluster=[clusterName]和turbine.stream都是针对集群使用的，其实从端点的命名中就可以知道这里需要引入Turbine，然后通过它来汇集监控信息，并将聚合后的信息提供给Hystrix Dashboard来集中展示和监控。 接下来将对前面实现的例子进行一些扩展，通过引入Turbine来聚合ribbon-consumer项目（即服务消费者）的监控信息，并输出给Hystrix Dashboard进行展示，最后完成时的架构图如下所示： 为了完成上述功能，这里新建一个SpringBoot工程，相应的操作如下： 第一步，新建一个普通的SpringBoot工程 ...

Hystrix仪表盘在断路器原理介绍那篇文章中，我们学习了许多关于请求命令的度量指标的判断。这些度量指标都是HystrixCommand和HystrixObservableCommand实例在执行过程中记录的重要信息，它们除了在Hystrix断路器中使用之外，对于系统运维也是有极大的帮助。 这些指标信息会以“滚动时间窗”与“桶”结合的方式进行汇总，并在内存中驻留一段时间，以供内部或外部进行查询使用，Hystrix仪表盘可以显示这些指标信息，通过可视化的显示，可以让我们更加清楚知道系统的健康状况。Spring Cloud不仅整合了Hystrix，还整合了Hystrix的仪表盘组件Hystrix Dashboard，它主要用于实时监控Hystrix的各项指标信息。通过Hystrix Dashboard反馈的实时信息，可以帮助我们快递发现系统中存在的问题，从而及时地采取应对措施。 Hystrix仪表盘实例演示学习使用Hystrix仪表盘对于开发和运维显得非常重要，因此本篇将从链各个方面来学习Hystrix仪表盘的使用，一是监控单体应用，二是整合Turbine实现对集群的监控。 Hystrix ...

异常处理当我们在调用服务提供者时有可能会抛异常（注意HystrixBadRequestException异常是不会触发服务降级，原因会在后面进行介绍），默认情况下方法抛了异常会自动触发服务降级，并交给服务降级中的方法去处理。同样由于Hystrix命令存在两种实现方法来调用服务，因此异常处理也需要分为两种情况。 继承类方式如果开发者使用继承类的方式来实现Hystrix命令，那么我们可以在getFallback()方法内通过Throwable executionException = getExecutionException();方法来获取具体的异常信息，然后通过判断以进入不同的处理逻辑。 修改MovieCommand类中的getFallback方法的代码为如下所示： 123456@Overrideprotected Movie getFallback() { Throwable executionException = getExecutionException(); System.out.println(executionException.getMessage ...

使用详解在前面我们已经使用了Hystrix中的核心注解@HystrixCommand，通过它创建了HystrixCommand的实现，同时利用fallback属性指定了服务降级的实现方法。但是这都是Hystrix的一小部分，在实现一个大型分布式系统时，还需要更多高级的配置功能，接下来就详细学习Hystrix各接口和注解的使用方法。 自定义HystrixCommandHystrix命令就是之前所说的HystrixCommand，它用来封装具体的依赖服务调用逻辑。在前面是使用了@HystrixCommand注解的方式，其实也可以采用自定义类然后继承HystrixCommand抽象类的方式。 第一步，在之前的ribbon-consumer项目内新建pojo包，并在里面新建一个Movie类，其中的代码为： 123456public class Movie { private String name; private double price; private String author; //getter、setter、toString和有参、无参的构造方法& ...

断路器原理断路器在HystrixCommand和HystrixObservableCommand执行过程中起到了非常重要的作用，它是Hystrix的核心部件。那么问题来了，断路器是如何决策熔断和记录信息的呢？本篇就来深入了解这其中的原理。 首先我们在服务消费者的入口类上添加@EnableCircuitBreaker注解，它的作用是开启断路器，查看一下该注解的源码： 1234567@Target({ElementType.TYPE})@Retention(RetentionPolicy.RUNTIME)@Documented@Inherited@Import({EnableCircuitBreakerImportSelector.class})public @interface EnableCircuitBreaker {} 既然开启的是CircuitBreaker（断路器），且此处必定和Hystrix相关，因此可以搜索HystrixCircuitBreaker这个对象，可以发现存在一个同名的类和接口，此处主要关注接口，查看一下 ...

原理分析通过前面的demo演示，我们对Hystrix的使用场景和使用方法已经有了一个初步的了解。接下来通过解读Netflix Hystrix官方提供的流程图来详细了解当一个请求调用了相关服务依赖之后Hystrix是如何工作的（即当你访问http://localhost:9000/ribbon-consumer请求之后，在RIBBON-CONSUMER中是如何处理的）。 工作流程接下来根据官方提供的Netflix Hystrix流程图中的所标记的数字顺序来解释每一个环节的详细内容，如下图所示： 这一流程中所涉及的流程如下所示：（1）创建HystrixCommand或HystrixObservableCommand对象；（2）执行command命令；（3）结果是否被缓存；（4）断路器是否打开;（5）线程池/请求队列/信号量是否占满；（6）HystrixObservableCommand.construct() 或者HystrixCommand.run()；（7）计算断路器的健康度；（8）fallback处理；（9）返回成功的响应。接下来将详细对以上流程进行分析，以加深对于Netflix ...

Hystrix断路器在微服务架构中，我们将系统拆分成很多服务单元，各单元的应用间通过服务注册与订阅的方式互相依赖。由于每个单元都在不同的进程中运行，依赖通过远程调用的方式执行，这样就有可能因为网络原因或是依赖服务自身问题出现调用故障或延迟，而这些问题会直接导致调用方的对外服务也出现延迟，若此时调用方的请求不断增加，最后就会因等待出现故障的依赖方响应形成任务积压，最终导致自身服务的瘫痪。 上面那样说你可能不太明白，没关系接下来举一个司空见惯的例子来帮助你理解。如果你想开发一个电商网站，里面包括用户管理、商品管理、类目管理、订单管理等模块，按照传统的软件开发方式其实非常简单，只需要创建一个Web服务，很快就能将这个功能上线，但是如果我们会采用微服务架构+服务治理的方式来实现，那么此时就稍微麻烦一些。首先需要将这个项目拆分为用户管理、商品管理、类目管理、订单管理等4个微服务，这四个服务各建一个模块，分别是用户模块、商品模块、类目模块、订单模块，然后这四个模块通过内部服务治理互相调用。但是可能会出现一个问题，就是目前这些模块是通过服务注册与订阅的方式互相依赖，如果某个模块出现故障，那么会导致依 ...