SpringCloud 学习总结（二）

• SpringCloud 学习总结（一）
• SpringCloud 学习总结（二）

服务容错保护Hystrix

Hystix是Netflix开源的一个延迟和容错库，其中提供了基础的熔断功能，用于隔离访问远程服务、第三方库，防止出现级联失败。关于Hystrix更详细的原理，可以参考官方文档：https://github.com/Netflix/Hystrix/

雪崩问题： 在微服务框架中，系统间都通过微服务进行调用，在微服务之间会存在这相互依赖关系。假设每个微服务运行在不同的进程中，依赖的调用只则需要使用远程调用方式。如果其中一个网络出现问题，或者延迟，此时，调用方式在不断的调用，后方的依赖会出现故障。当响应过多时，就可能出现雪崩效应，造成系统的崩溃。

下图中，我们可以看到微服务中，服务间复杂的调用关系，一个请求，可能需要调用多个微服务接口才能实现，会形成非常复杂的调用链路：

如图，一次业务请求，需要调用A、P、H、I四个服务，这四个服务又可能调用其它服务。如果此时，某个服务出现异常：

例如：微服务I发生异常，请求阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：

服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪崩效应。

Hystix解决雪崩问题：

• 线程隔离(服务降级)
• 服务熔断

服务降级

服务降级： 当系统的访问量突然特别大时，因为资源有限，不可能提供全部服务的时候，优先保证核心服务，非核心服务不可用或者弱可用。

在Hystrix中也提供了服务降级的机制，Hystrix为每个依赖服务调用分配一个小的线程池，如果线程池已满调用将被立即拒绝，默认不采用排队，加速失败判定时间。用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，或者请求超时，则会进行降级处理。

通过服务降级，用户的请求故障时，不会被阻塞，更不会无休止的等待或者看到系统崩溃，至少可以看到一个执行结果（例如返回友好的提示信息）。服务降级虽然会导致请求失败，但是不会导致阻塞，而且最多会影响这个依赖服务对应的线程池中的资源，对其它服务没有响应。

触发Hystix服务降级的情况：

• 线程池已满
• 请求超时

Hystrix将降级策略封装在Commend中，不同的Commend根据group分割开。Commend内置了run和fallback两个方法，内置方法。正常情况下，会先执行run方法（正常执行逻辑），若发生了故障，再执行fallback方法并返回其结果。若发生多次故障会在一定时间范围内触发短路，即跳过run方法，直接执行fallback方法。

在程序中测试Hystrix：

引入依赖：首先在springboot-service-consumer的pom.xml中引入Hystrix依赖：

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

修改启动器的代码：添加开启熔断注解：@EnableCircuitBreaker

@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker   //开启熔断
public class SpringbootServiceConsumerApplication {
   
   
		、、、、
}

组合注解：@SpringCloudApplication，相当于@SpringBootApplication + @EnableDiscoveryClient + @EnableCircuitBreaker，可以用来简化我们的注解：

使用组合注解代替之前的3个注解：

@SpringCloudApplication //组合注解，相当于@SpringBootApplication + @EnableDiscoveryClient + @EnableCircuitBreaker
public class SpringbootServiceConsumerApplication {
   
   

    @Bean
    @LoadBalanced  //开启负载均衡
    public RestTemplate restTemplate() {
   
   
        return new RestTemplate();
    }

    public static void main(String[] args) {
   
   
        SpringApplication.run(SpringbootServiceConsumerApplication.class, args);
    }

}

编写降级逻辑：

改造springboot-service-consumer，当目标服务的调用出现故障，我们希望快速失败，给用户一个友好提示。因此需要提前编写好失败时的降级处理逻辑，要使用@HystixCommond来完成：

@RestController
@RequestMapping("consumer/user")
public class UserController {
   
   

    @Autowired
    private RestTemplate restTemplate;

	@GetMapping
    @HystrixCommand(fallbackMethod = "queryUserByIdFallback")  //声明熔断(降级逻辑)的方法
    public String queryUserById(@RequestParam("id") Long id) {
   
   
        return this.restTemplate.getForObject("http://service-provider/user/" + id, String.class);
    }
    
    public String queryUserByIdFallBack(Long id){
   
   
        return "请求繁忙，请稍后再试！";
    }
   
}

注意：熔断的降级逻辑方法必须跟正常逻辑方法保证：相同的参数列表和返回值声明。失败逻辑中返回User对象没有太大意义，一般会返回友好提示。所以我们把queryById的方法改造为返回String，反正也是Json数据。这样失败逻辑中返回一个错误说明，会比较方便。

运行测试：

当springboot-service-provder正常提供服务时

将springboot-service-provider停机时，会发现页面返回了降级处理信息：

指定全局熔断的熔断方法：

局部:（要和被熔断的方法返回值和参数列表一致）
@HystrixCommand(fallbackMethod=“局部熔断方法名”)：声明被熔断的方法

全局:（返回值类型要被熔断的方法一致，参数列表必须为空）
@DefaultProperties(defaultFallback = “defaultFallBack”)：在类上指明统一的失败降级方法
defaultFallback：默认降级方法，不用任何参数，以匹配更多方法，但是返回值一定一致
@HystrixCommand：在方法上直接使用该注解，使用默认的剪辑方法。

优先级：局部>全局

我们刚才把fallback写在了某个业务方法上，如果这样的方法很多，那岂不是要写很多。所以我们可以把Fallback配置加在类上，实现默认fallback：

@RestController
@RequestMapping("consumer/user")
@DefaultProperties(defaultFallback = "fallBackMethod") // 指定一个类的全局熔断方法
public class UserController {
   
   

    @Autowired
    private RestTemplate restTemplate;

    @GetMapping
    @HystrixCommand // 标记该方法需要熔断
    public String queryUserById(@RequestParam("id") Long id) {
   
   
        String user = this.restTemplate.getForObject("http://service-provider/user/" + id, String.class);
        return user;
    }

    /**
     * 熔断方法
     * 返回值要和被熔断的方法的返回值一致
     * 熔断方法不需要参数
     * @return
     */
    public String fallBackMethod(){
   
   
        return "服务器正忙,请稍后再试！";
    }
}

设置超时

在微服务中，由于网络或者运算量等问题，超时是很常见的。Hystix中的默认超时时长为1，在互联网中，有些服务需要访问第三方应用，或者处理大量的数据，使用默认的1秒很容易超时，这时需要问们进行超时设置，通过hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds可以设置Hystrix超时时间。该配置没有提示：

hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 6000 # 设置hystrix的超时时间为6000ms

改造服务提供者

改造服务提供者的UserController接口，随机休眠一段时间，以触发熔断：

@GetMapping("{id}")
public User queryUserById(@PathVariable("id") Long id) {
   
   
    try {
   
   
        Thread.sleep(10000);
    } catch (InterruptedException e) {
   
   
        e.printStackTrace();
    }
    return this.userService.queryUserById(id);
}

运行查看结果：

服务熔断

熔断原理：熔断器(断路器)，当某些服务反应慢或者存在大量超时问题时，服务调用方可以自己进行判断，并进行熔断，防止整个系统被拖垮。当情况好转时，在进行自动重连。

通过断路器的方式，可以将后续请求直接拒绝掉，一段时间之后允许部分请求通过，如果调用成功则回到电路闭合状态，否则继续断开。

熔断状态机3个状态：

• Closed：关闭状态，所有请求都正常访问。
• Open：打开状态，所有请求都会被降级。Hystix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全打开。默认失败比例的阈值是50%，请求次数最少不低于20次。
• Half Open：半开状态，open状态不是永久的，打开后会进入休眠时间（默认是5S）。随后断路器会自动进入半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会完全关闭断路器，否则继续保持打开，再次进行休眠计时

在程序中测试：

在consumer的调用业务中加入一段逻辑：

@GetMapping
@HystrixCommand(fallbackMethod = "queryUserByIdFallback")  //声明熔断的方法
public String queryUserById(@RequestParam("id") Long id) {
   
   
    if(id==1){
   
   
        throw new RuntimeException();
    }
    return this.restTemplate.getForObject("http://service-provider/user/" + id, String.class);
}

这样如果参数是id为1，一定失败，其它情况都成功。（不要忘了清空service-provider中的休眠逻辑）

当我们连续访问id为1的请求时（超过20次，手速要快），就会触发熔断。断路器会断开，一切请求都会被降级处理。此时你访问id为2的请求，会发现返回的也是失败，而且失败时间很短，只有几毫秒左右：

第一次访问id=2：

连续访问id=1：

再次访问id=2：

不过，默认的熔断触发要求较高，休眠时间窗较短，为了测试方便，我们可以通过配置修改熔断策略：

circuitBreaker:
	requestVolumeThreshold: 10   #触发熔断的最小请求次数，默认20
	sleepWindowInMilliseconds: 10000   #触发熔断的失败请求最小占比，默认50%
	errorThresholdPercentage: 50    #休眠时长，默认是5000毫秒

声明式服务调用Feign

Feign是Netfix开发的声明式、模板化的HTTP客户端，它可帮助我们更加快捷的调用HTTP API，其中支持自带的注解，JAX-Rs注解，SpringMVC注解，并且还整合了Ribbon与Eureka。通过使用Feign可以把Rest的请求进行隐藏，伪装成类似SpringMVC的Controller一样。你不用再自己拼接url，拼接参数等等操作，一切都交给Feign去做，十分方便。

Feign项目地址：https://github.com/OpenFeign/feign

在前面的学习中，我们使用了Ribbon的负载均衡功能，大大简化了远程调用时的代码：

String user = this.restTemplate.getForObject("http://service-provider/user/" + id, String.class);

快速入门:

改造springboot-service-consumer工程：

导入依赖：

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

开启Feign功能：在启动类上，添加注解，@EnableFeignClients开启Feign功能

@SpringCloudApplication //组合注解，相当于@SpringBootApplication + @EnableDiscoveryClient + @EnableCircuitBreaker
@EnableFeignClients     //启用feign组件
public class SpringbootServiceConsumerApplication {
   
   

    /*@Bean
    @LoadBalanced  //开启负载均衡
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }*/

    public static void main(String[] args) {
   
   
        SpringApplication.run(SpringbootServiceConsumerApplication.class, args);
    }

}

删除RestTemplate：feign已经自动集成了Ribbon负载均衡的RestTemplate。所以，此处不需要再注册RestTemplate。

配置Feign的客户端：

在springboot-service-consumer工程中，添加UserClient接口：

//@FeignClient(value = "service-provider") // 标注该类是一个feign接口
@FeignClient(value = "service-provider",fallback = UserClientFallBack.class)
public interface UserClient {
   
   

    @GetMapping("user/{id}")
    User queryById(@PathVariable("id") Long id);
}

• 首先这是一个接口，Feign会通过动态代理，帮我们生成实现类。这点跟mybatis的mapper很像
• @FeignClient，声明这是一个Feign客户端，类似@Mapper注解。同时通过value属性指定服务名称
• 接口中的定义方法，完全采用SpringMVC的注解，Feign会根据注解帮我们生成URL，并访问获取结果

改造原来的调用逻辑，调用UserClient接口：

@RestController
@RequestMapping("consumer/user")
public class UserController {
   
   

    @Autowired
    private UserClient userClient;

    @GetMapping
    public String queryUserById(@RequestParam("id") Long id){
   
   
        User user = this.userClient.queryUserById(id);
        return user.toString();
    }

}

启动测试：

访问接口：

正常获取到了结果。

负载均衡与Hystrix支持：

Feign中本身已经集成了Ribbon依赖和自动配置，因此我们不需要额外引入依赖，也不需要再注册RestTemplate对象。

同时Feign默认也有对Hystrix的集成，只不过，默认情况下是关闭的。我们需要通过下面的参数来开启：(在springboot-service-consumer工程添加配置内容)：

feign:
  hystrix:
    enabled: true # 开启Feign的熔断功能

但是，Feign中的Fallback配置不像hystrix中那样简单了。首先，我们要定义一个类UserClientFallback，实现刚才编写的UserClient，作为fallback的处理类

@Component
public class UserClientFallBack implements UserClient {
   
   
    @Override
    public User queryUserById(Long id) {
   
   
        User user = new User();
        user.setUsername("服务器正忙，请稍后再试！！！");
        return user;
    }
}

然后在UserFeignClient中，指定刚才编写的实现类

@FeignClient(value = "service-provider", fallback = UserClientFallback.class) // 标注该类是一个feign接口
public interface UserClient {
   
   

    @GetMapping("user/{id}")
    User queryUserById(@PathVariable("id") Long id);
}

重启测试：

请求压缩：

Spring Cloud Feign 支持对请求和响应进行GZIP压缩，以减少通信过程中的性能损耗。通过下面的参数即可开启请求与响应的压缩功能：

feign:
  compression:
    request:
      enabled: true # 开启请求压缩
    response:
      enabled: true # 开启响应压缩

同时，我们也可以对请求的数据类型，以及触发压缩的大小下限进行设置：

feign:
  compression:
    request:
      enabled: true # 开启请求压缩
      mime-types: text/html,application/xml,application/json # 设置压缩的数据类型
      min-request-size: 2048 # 设置触发压缩的大小下限

注：上面的数据类型、压缩大小下限均为默认值。

Zuul网关

通过前面的学习，使用Spring Cloud实现微服务的架构基本成型，大致是这样的：

• 使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现；
• 服务间通过Ribbon或Feign实现服务的消费以及均衡负载。
• 为了使得服务集群更为健壮，使用Hystrix的融断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。

在该架构中，我们的服务集群包含：内部服务Service A和Service B，他们都会注册与订阅服务至Eureka Server，而Open Service是一个对外的服务，通过均衡负载公开至服务调用方。我们把焦点聚集在对外服务这块，直接暴露我们的服务地址，这样的实现是否合理，或者是否有更好的实现方式呢？

我们可以将权限控制这样的东西从我们的服务单元中抽离出去，而最适合这些逻辑的地方就是处于对外访问最前端的地方，我们需要一个更强大一些的均衡负载器的服务网关。

服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能。Spring Cloud Netflix中的Zuul就担任了这样的一个角色，为微服务架构提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体能够具备更高的可复用性和可测试性。

Zuul网关官网：https://github.com/Netflix/zuul

Zuul加入后的架构

不管是来自于客户端（PC或移动端）的请求，还是服务内部调用。一切对服务的请求都会经过Zuul这个网关，然后再由网关来实现 鉴权、动态路由等等操作。Zuul就是我们服务的统一入口。

快速入门

新建工程：

添加Zuul依赖：


工程目录：

pom.xml文件

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.2.11.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <groupId>com.ly</groupId>
    <artifactId>ly-zuul</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>ly-zuul</name>
    <description>Demo project for Spring Boot</description>

    <properties>
        <java.version>1.8</java.version>
        <spring-cloud.version>Hoxton.SR9</spring-cloud.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-zuul</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
            <version>2.0.0.RELEASE</version>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
            <exclusions>
                <exclusion>
                    <groupId>org.junit.vintage</groupId>
                    <artifactId>junit-vintage-engine</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

    </dependencies>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>${spring-cloud.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

</project>

新建application.yml文件，编写配置

server:
  port: 10010   #服务端口
spring:
  application:
    name: ly-zuul  #指定服务名

编写引导类：

通过@EnableZuulProxy注解开启Zuul的功能：

@SpringBootApplication
@EnableZuulProxy // 开启网关功能
public class ItcastZuulApplication {
   
   

    public static void main(String[] args) {
   
   
        SpringApplication.run(ItcastZuulApplication.class, args);
    }
}

编写路由规则：

我们需要用Zuul来代理service-provider服务，先看一下控制面板中的服务状态：

映射规则：

server:
  port: 10010
spring:
  application:
    name: ly-zuul

zuul:
  routes:
    service-provider: /service-provider/** #路由名称，可以随便起，习惯上是服务名
      path: /service-provider/**   # 这里是映射路径
      url: http://localhost:8081   # 映射路径对应的实际url地址

我们将符合path 规则的一切请求，都代理到 url参数指定的地址

本例中，我们将 /service-provider/**开头的请求，代理到http://localhost:8081

启动测试:

访问的路径中需要加上配置规则的映射路径，我们访问：http://localhost:10010/service-provider/user/2

面向服务的路由

在刚才的路由规则中，我们把路径对应的服务地址写死了！如果同一服务有多个实例的话，这样做显然就不合理了。我们应该根据服务的名称，去Eureka注册中心查找 服务对应的所有实例列表，然后进行动态路由才对！

对ly-zuul工程修改优化，添加Eureka客户端依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

添加Eureka配置，获取服务信息：

eureka:
  client:
    registry-fetch-interval-seconds: 5 # 获取服务列表的周期：5s
    service-url:
      defaultZone: http://localhost:10086/eureka

开启Eureka客户端发现功能：

@SpringBootApplication
@EnableZuulProxy  //启用zuul网关组件
@EnableDiscoveryClient  //启用客户端
public class LyZuulApplication {
   
   

    public static void main(String[] args) {
   
   
        SpringApplication.run(LyZuulApplication.class, args);
    }

}

修改映射配置，通过服务名称获取:

因为已经有了Eureka客户端，我们可以从Eureka获取服务的地址信息，因此映射时无需指定IP地址，而是通过服务名称来访问，而且Zuul已经集成了Ribbon的负载均衡功能。

zuul:
  routes:
    service-provider: # 这里是路由id，随意写
      path: /service-provider/** # 这里是映射路径
      serviceId: service-provider # 指定服务名称

启动测试:

再次启动，这次Zuul进行代理时，会利用Ribbon进行负载均衡访问：

路由配置的四种方式： (一般使用的是第三种)

zuul:
  routes:
    service-provider: 
      path: /service-provider/** #路由名称，可以随便起，习惯上是服务名
      url: http://localhost:8081
    
zuul:
  routes:
    service-provider:
      path: /service-provider/**   #路由名称，可以随便起，习惯上是服务名
      serviceId: service-provider  #指定服务名
      
#而大多数情况下,路由名称往往和服务名会写成一样的,因此Zuul就提供了一种简化的配置语法：
zuul:
  routes:
    service-provider: /provider/** #路由名称，可以随便起，习惯上是服务名
 
-不用配置，默认就是服务id开头路径 
-Zuul就指定了默认的路由规则：默认情况下,一切服务的映射路径就是服务名本身

测试第三种方法：使用prefix: /*配置虚拟路径

zuul:
  routes:
    service-provider: /provider/** #路由名称，可以随便起，习惯上是服务名
  prefix: /api  #虚拟路径

过滤器

Zuul作为网关的其中一个重要功能，就是实现请求的鉴权。而这个动作我们往往是通过Zuul提供的过滤器来实现的。

ZuulFilter：
ZuulFilter是过滤器的顶级父类。在这里我们看一下其中定义的4个最重要的方法：

public abstract ZuulFilter implements IZuulFilter{
   
   

    abstract public String filterType();

    abstract public int filterOrder();
    
    boolean shouldFilter();// 来自IZuulFilter

    Object run() throws ZuulException;// IZuulFilter
}

• shouldFilter：返回一个Boolean值，判断该过滤器是否需要执行。返回true执行，返回false不执行。
• run：过滤器的具体业务逻辑。
• filterType：返回字符串，代表过滤器的类型。包含以下4种：
  • pre：请求在被路由之前执行
  • route：在路由请求时调用
  • post：在route和errror过滤器之后调用
  • error：处理请求时发生错误调用
• filterOrder：通过返回的int值来定义过滤器的执行顺序，数字越小优先级越高。

过滤器执行生命周期:

这张是Zuul官网提供的请求生命周期图，清晰的表现了一个请求在各个过滤器的执行顺序。

正常流程：

• 请求到达首先会经过pre类型过滤器，而后到达route类型，进行路由，请求就到达真正的服务提供者，执行请求，返回结果后，会到达post过滤器。而后返回响应。

异常流程：

• 整个过程中，pre或者route过滤器出现异常，都会直接进入error过滤器，在error处理完毕后，会将请求交给POST过滤器，最后返回给用户。
• 如果是error过滤器自己出现异常，最终也会进入POST过滤器，将最终结果返回给请求客户端。
• 如果是POST过滤器出现异常，会跳转到error过滤器，但是与pre和route不同的是，请求不会再到达POST过滤器了。

所有内置过滤器列表：

使用场景:

• 请求鉴权：一般放在pre类型，如果发现没有访问权限，直接就拦截了
• 异常处理：一般会在error类型和post类型过滤器中结合来处理。
• 服务调用时长统计：pre和post结合使用。

自定义过滤器:

接下来我们来自定义一个过滤器，模拟一个登录的校验。基本逻辑：如果请求中有access-token参数，则认为请求有效，放行。

定义过滤器类:

@Component
public class LoginFilter extends ZuulFilter {
   
   

    @Override
    public String filterType() {
   
   
        return "pre";
    }

    /**
     * 执行顺序，返回值越小，优先级越高
     * @return
     */
    @Override
    public int filterOrder() {
   
   
        return 10;
    }

    /**
     * 是否执行该过滤器
     * @return
     */
    @Override
    public boolean shouldFilter() {
   
   
        return true;
    }

    /**
     * 编写过滤器的业务逻辑
     * @return
     * @throws ZuulException
     */
    @Override
    public Object run() throws ZuulException {
   
   
        //初始化context上下文对象，servlet spring
        RequestContext context =RequestContext.getCurrentContext();

        //获取request对象
        HttpServletRequest request =context.getRequest();

        //获取参数
        String token =request.getParameter("token");
        if(StringUtils.isBlank(token)){
   
   
            //拦截，不转发请求
            context.setSendZuulResponse(false);
            //响应状态码，401-身份未认证
            context.setResponseStatusCode(HttpStatus.SC_UNAUTHORIZED);
            //设置响应的提示
            context.setResponseBody("request error!");
        }

        //返回值为null,就代表该过滤器什么都不做
        return null;
    }
}

运行测试：

没有token参数时，访问失败：

添加token参数后：

负载均衡和熔断:

Zuul中默认就已经集成了Ribbon负载均衡和Hystix熔断机制。但是所有的超时策略都是走的默认值，比如熔断超时时间只有1S，很容易就触发了。因此建议我们手动进行配置：

hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 2000 # 设置hystrix的超时时间为6000ms

来源：oschina

链接：https://my.oschina.net/u/4297302/blog/4795147