余思博客

写在前面在前面我们学习了Spring Cloud Zuul中的两类路由功能：传统路由方式和面向服务的路由方式的简单使用，接下来将进一步学习路由的相关知识。 传统路由配置所谓的传统路由配置其实就是不依赖于服务发现机制的情况，也就是直接在配置文件中来具体指定每个路由表达式与服务实例的映射关系，进而实现API网关对外部请求的路由。 既然不依赖服务治理框架提供的服务发现功能，那么在实际情况中需要根据服务实例的数量来采取不同的配置方式，进而实现路由规则。 单实例配置对于单实例的配置，我们可以通过zuul.routes.<route>.path和zuul.routes.<route>.url参数对的方式来进行配置，如下所示： 12345zuul: routes: user-service: path: /user-service/** url: http://localhost:8080/ 通过上面的配置，只要是符合/user-service/**规则的请求路径，都会被转发到http://localhost:8080/地址。举个例子，假设当一个 ...

请求路由上面只是搭建完成了API网关服务，但是里面什么也没有，接下来我们将通过一个简单的例子来往这个API网关服务中增加请求路由的功能。 首先需要将之前的服务注册中心（eureka-server）、服务提供者（eureka-client，服务名为hello-service）、服务消费者(feign-consumer)都启动起来，每个项目只需启动一个服务实例即可，然后访问Eureka信息面板的地址http://localhost:1111即可看到如下信息： 传统路由方式为了加深大家对于Zuul的理解，这里先学习使用传统的路由方式来实现请求路由的功能。使用Spring Cloud Zuul实现路由功能非常简单，只需要对api-gateway服务增加一些关于路由规则的配置，就可以实现传统的路由转发功能，在application.yml配置文件中添加如下配置： 12345zuul: routes: api-test-url: path: /api-test-url/** url: http://localhost:8083 以上配置定义了发往API网关服务的请求中 ...

写在前面通过前面的学习，我们已经对Spring Cloud Netflix下的核心组件了解了一大半。这些组件基本涵盖了微服务架构中最为基础的几个核心设施，利用这些组件我们已经可以构建起一个简单的微服务架构系统。如使用Spring Cloud Eureka实现高可用的服务注册中心以及服务的注册与发现；使用Spring Cloud Ribbon或者Feign来实现服务间负载均衡的接口调用；使用Spring Cloud Hystrix实现线程隔离并加入熔断机制，以避免微服务架构中因个别服务出现异常而引起级联故障蔓延，提高了系统的健壮性。 基于上述思路，截止到目前我们可以设计出类似于下图所示的基础系统架构： 接下来仔细分析一下该架构的特点。在该架构中，我们的服务集群包含内部服务ServiceA和ServiceB，它们都会向Eureka Server集群进行注册与订阅服务，而Open Service是一个对外的RESTful API服务，它通过F5、Nginx等网络设备或工具软件实现对各个微服务的路由与负载均衡，并公开给外部的客户端调用。 接下来我们将重点研究对外服务这一块Edge Servi ...

超时时间设置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和有参、无参的构造方法& ...