电商平台管理项目 springcloud

文章目录

• Ribbon

• Ribbon实现负载均衡案例

• 启动两个服务实例
• 开启负载均衡

• 源码追踪
• 负载均衡策略

• Hystrix

• 雪崩问题
• 线程隔离，服务降级

• 原理
• 动手实践

• 引入依赖
• 开启熔断
• 编写降级逻辑
• 默认FallBack
• 设置超时

• 服务熔断

• 1.4.1.熔断原理
• 动手实践

• Feign

• 简介
• 快速入门
• Ribbon支持
• Hystrix支持

• Feign中服务降级

• 请求压缩(了解)
• 日志级别(了解)

• Zuul

• 简介
• Zuul加入后的架构
• 快速入门
• 面向服务的路由
• 简化的路由配置
• 默认的路由规则
• 路由前缀
• 过滤器

• 3.8.1.ZuulFilter
• 过滤器执行生命周期
• 使用场景

• 自定义过滤器
• 负载均衡和熔断

Ribbon

在使用Eureka的案例中，我们启动了一个cncs_service_provider，然后通过DiscoveryClient来获取服务实例信息，然后获取ip和端口来访问。但是实际环境中，我们往往会开启很多个cnscs_service_provider的集群。此时我们获取的服务列表中就会有多个，到底该访问哪一个呢？

一般这种情况下我们就需要编写负载均衡算法，在多个实例列表中进行选择。

不过Eureka中已经帮我们集成了负载均衡组件：Ribbon，简单修改代码即可使用。

什么是Ribbon：

Ribbon是Netflix发布的负载均衡器，它有助于控制HTTP和TCP的客户端的行为。为Ribbon配置服务提供者地址后，Ribbon就可基于某种负载均衡算法，自动地帮助服务消费者去请求。Ribbon默认为我们提供了很多负载均衡算法，例如轮询、随机等。当然，我们也可为Ribbon实现自定义的负载均衡算法。

在Spring Cloud中，当Ribbon与Eureka配合使用时，Ribbon可自动从Eureka Server获取服务提供者地址列表，并基于负载均衡算法，请求其中一个服务提供者实例。展示了Ribbon与Eureka配合使用时的架构。

接下来，我们就来使用Ribbon实现负载均衡。

Ribbon实现负载均衡案例

启动两个服务实例

(1)由于Eureka已经帮忙集成了Ribbon，这里不再引入依赖

(2)启动两个服务实例

拷贝一个服务实例，并修改端口后，启动后：

Eureka监控面板：

开启负载均衡

(1)在cncs_service_customer工程里修改引导类中的代码

• 在RestTemplate的配置方法上添加@LoadBalanced注解

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

(2)修改调用方式，不再手动获取ip和端口，而是直接通过服务名称调用

@RequestMapping("{id}")
    public User queryUserById(@PathVariable("id")Integer id){
        return restTemplate.getForObject("http://service-provider/user/"+id,User.class); //解决硬编码问题
    }

(3)启动工程，访问localhost/customer/user/48，查看结果：

源码追踪

在方法上加上断点，debug运行cncs_service_customer，看见源码追踪的过程：

负载均衡策略

Ribbon默认的负载均衡策略是简单的轮询，我们可以测试一下。

编写测试类，在刚才的源码中我们看到拦截中是使用RibbonLoadBalanceClient来进行负载均衡的：

图中可以看见：RibbonLoadBalanceCient实现了LoadBalancerCient接口，LoadBalancerCient接口继承了ServiceInstanceChooser接口。

在ServiceInstanceChooser接口中可以看见choose()：

方法介绍：从负载均衡器中选择一个指定了服务名称的服务实例。

我们新建一个测试类：RibbonLoadBalancerTest：

代码内容

@SpringBootTest
@RunWith(SpringRunner.class)
public class RibbonLoadBalanceTest {

    @Autowired
    private RibbonLoadBalancerClient client;

    @Test
    public void test(){
        for (int i = 0; i < 50; i++) {
            ServiceInstance instance = this.client.choose("service-provider"); //默认负载均衡的算法是轮询
            System.out.println(instance.getHost()+":"+instance.getPort());
        }
    }
}

点击测试后，可以看见主机+端口号，负载均衡器默认的算法采用轮询：

跟踪源码：

看到负载均衡的算法：

SpringBoot也帮我们提供了修改负载均衡规则的配置入口，在cncs_service_consumer的application.yml中添加如下配置

service-provider: # 服务提供方的id
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡使用随机算法

再次测试，发现结果变成了随机：

Hystrix

Hystrix，英文意思是豪猪，全身是刺，看起来就不好惹，是一种保护机制。

Hystrix是一个延迟和容错库，旨在隔离对远程系统，服务和第三方库的访问点，停止级联故障，并在不可避免发生故障的复杂分布式系统中实现弹性。

Hystrix也是Netflix公司的一款组件。

主页：https://github.com/Netflix/Hystrix/

那么Hystix的作用是什么呢？具体要保护什么呢？

Hystix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败。

雪崩问题

微服务中，服务间调用关系错综复杂，一个请求，可能需要调用多个微服务接口才能实现，会形成非常复杂的调用链路：

如图，一次业务请求，需要调用A、P、H、I四个服务，这四个服务又可能调用其它服务。

如果此时，某个服务出现异常：

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

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

这就好比，一个汽车生产线，生产不同的汽车，需要使用不同的零件，如果某个零件因为种种原因无法使用，那么就会造成整台车无法装配，陷入等待零件的状态，直到零件到位，才能继续组装。 此时如果有很多个车型都需要这个零件，那么整个工厂都将陷入等待的状态，导致所有生产都陷入瘫痪。一个零件的波及范围不断扩大。

Hystix解决雪崩问题的手段有两个：

• 线程隔离
• 服务熔断

线程隔离，服务降级

原理

线程隔离示意图：

解读

Hystrix为每个依赖服务调用分配一个小的线程池，如果线程池已满调用将被立即拒绝，默认不采用排队.加速失败判定时间。

用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，或者请求超时，则会进行降级处理。

什么是服务降级？

服务降级：优先保证核心服务，而非核心服务不可用或弱可用。

用户的请求故障时，不会被阻塞，更不会无休止的等待或者看到系统崩溃，至少可以看到一个执行结果（例如返回友好的提示信息） 。

服务降级虽然会导致请求失败，但是不会导致阻塞，而且最多会影响这个依赖服务对应的线程池中的资源，对其它服务没有响应。

触发Hystix服务降级的情况

• 线程池已满
• 请求超时

动手实践

引入依赖

首先在cncs_service_customer的pom.xml中引入Hystrix依赖：

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

开启熔断

@SpringBootApplication // 声明这是一个springboot应用
@EnableDiscoveryClient // 开启eureka客户端
@EnableCircuitBreaker // 开启熔断
public class CncsServiceCustomerApplication {

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

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

}

可以看到，我们类上的注解越来越多，在微服务中，经常会引入上面的三个注解，于是Spring就提供了一个组合注解：@SpringCloudApplication。因此，我们可以使用这个组合注解来代替之前的3个注解。

编写降级逻辑

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

• @HystrixCommand(fallbackMethod = “queryUserByIdFallback”)：用来声明一个降级逻辑的方法

@HystrixCommand(fallbackMethod = "queryUserByIdFallback") // 指定局部熔断的方法
public String queryUserById(@PathVariable("id") Integer id) {
    return restTemplate.getForObject("http://service-provider/user/" + id, String.class); //解决硬编码问题
}
public String queryUserByIdFallback(Integer id){
        return "请求的服务已经超时！";
    }

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

测试

当cncs_service_provider正常提供服务时，访问与以前一致。但是当我们对cncs_service_provider工程做一点修改：

• 添加了一段20s的休眠，

@RestController
@RequestMapping("user")
public class UserController {
    @Autowired
    private UserService userService;

    @RequestMapping("{id}")
    public User findById(@PathVariable("id")Integer id){
        try {
            Thread.sleep(20000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return userService.queryById(id);
    }
}

当请求发出，在1s内没有受到响应，会触发服务降级处理，会发现页面返回了降级处理信息：

默认FallBack

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

• @DefaultProperties(defaultFallback = “fallbackMethod”)，在类上指明统一的失败降级方法
• @HystrixCommand：在方法上直接使用该注解，使用默认失败降级方法，加上参数使用自定义降级方法。
• defaultFallback：默认降级方法，不用任何参数，以匹配更多方法，但是返回值一定一致

@RestController
@RequestMapping("customer/user")
@DefaultProperties(defaultFallback = "fallbackMethod")
public class UserController {

    @HystrixCommand
    public String queryUserById(@PathVariable("id") Integer id) {
        return restTemplate.getForObject("http://service-provider/user/" + id, String.class); //解决硬编码问题
    }
    
    /**
     * 熔断方法
     * 返回值要和被熔断的方法的返回值一致
     * 熔断方法不需要参数
     * @return
     */
    public String fallbackMethod() {
        return "请求的服务已经超时！";
    }
}

设置超时

在之前的案例中，请求在超过1秒后都会返回错误信息，这是因为Hystix的默认超时时长为1，我们可以通过配置修改这个值。

我们通过修改application.yaml文件来设置Hystrix超时时间。该配置没有提示。

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

访问页面，查看超时时间：

服务熔断

1.4.1.熔断原理

熔断器，也叫断路器，其英文单词为：Circuit Breaker ，它的熔断机制的原理：

熔断状态机3个状态：

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

动手实践

为了能够精确控制请求的成功或失败，我们在cncs_service_customer工程的controller调用业务中加入一段逻辑

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

@RequestMapping("{id}")
@ResponseBody
@HystrixCommand //配置了全局熔断方法就不用配置fallbackMethod参数,但是注解必须加上
public String queryUserById(@PathVariable("id") Integer id) {
    if (id == 1) {
        throw new RuntimeException("请求的id不存在！");
    }
    return restTemplate.getForObject("http://service-provider/user/" + id, String.class); //解决硬编码问题
}

我们准备两个请求窗口：

• 一个请求：http://localhost/customer/user/1，注定失败
• 一个请求：http://localhost/customerr/user/45，肯定成功

当我们疯狂访问id为1的请求时（超过20次），就会触发熔断。断路器会断开，一切请求都会被降级处理。

此时你访问id为2的请求，会发现返回的也是失败，而且失败时间很短，只有几毫秒左右。

修改熔断策略（application.properties）

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

circuitBreaker.requestVolumeThreshold=10
circuitBreaker.sleepWindowInMilliseconds=10000
circuitBreaker.errorThresholdPercentage=50

解读

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

Feign

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

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

如果就学到这里，你可能以后需要编写类似的大量重复代码，格式基本相同，无非参数不一样。有没有更优雅的方式，来对这些代码再次优化呢？

这就是我们接下来要学的Feign的功能了。

简介

Feign的英文意思是：假装，伪装。

为什么叫伪装？

Feign可以把Rest的请求进行隐藏，伪装成类似SpringMVC的Controller一样。你不用再自己拼接url，拼接参数等等操作，一切都交给Feign去做。

github项目主页：https://github.com/OpenFeign/feign

Feign is a Java to HTTP client binder inspired by Retrofit, JAXRS-2.0, and WebSocket. Feign’s first goal was reducing the complexity of binding Denominator uniformly to HTTP APIs regardless of ReSTfulness.

Feign是受Retrofit，JAXRS-2.0和WebSocket启发的Java到HTTP客户端绑定程序。
Feign的目标是减少与ReSTfulness无关的将Denominator统一绑定到HTTP API的复杂性。

快速入门

(1)改造cncs_service_customer工程，导入依赖

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

(2)开启Feign功能，我们在启动类上，添加注解，开启Feign功能

@SpringCloudApplication
@EnableFeignClients // 开启feign客户端
public class CncsServiceCustomerApplication {
    
    public static void main(String[] args) {
        SpringApplication.run(ItcastServiceConsumerApplication.class, args);
    }
}

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

(3)定义Feign的客户端，在cncs_service_cusomer工程中，添加UserClient接口

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

@FeignClient(value ="service-provider",fallback = UserClientImpl.class) //标注该类是一个feign接口，声明服务降级的方法
public interface UserClient {

    @RequestMapping("user/{id}")
    User findById(@PathVariable("id")Integer id);
}

(4)改造原来的调用逻辑，调用UserClient接口

• 这里要注意删除原来的hystrix配置

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

    @Autowired
    private UserClient userClient;
    
    @RequestMapping("{id}")
    @ResponseBody
    public User queryUserById(@PathVariable("id") Integer id) {
        return userClient.findById(id);
    }
}

(5)启动测试

Ribbon支持

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

此时application.yaml还是随机策略

service-provider: # 服务提供方的id
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡使用随机算法

运行测试程序，可以看见，负载均衡算法执行的是随机策略：

Hystrix支持

Feign默认也有对Hystrix的集成：

只不过，默认情况下是关闭的，我们需要通过下面的参数来开启：(在cncs_service_customer工程添加配置内容)

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

Feign中服务降级

Feign中的Fallback配置

(1)定义一个类UserClientFallback，实现刚才编写的UserClient，作为fallback的处理类。

@Component
public class UserClientFallback implements UserClient {
    @Override
    public User findById(Integer id) {
        User user = new User();
        user.setUsername("请求的服务暂不可用！");
        return user;
    }
}

(2)在UserClient中，指定UserClientFallback作为服务降级处理类

@FeignClient(value = "service-provider", fallback = UserClientFallback.class) //标注该类是一个feign接口，声明服务降级的方法
public interface UserClient {

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

(3)测试，发出请求后，收到响应信息：

请求压缩(了解)

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 # 设置触发压缩的大小下限

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

日志级别(了解)

前面讲过，通过logging.level.xx=debug来设置日志级别。然而这个对Fegin客户端而言不会产生效果。因为@FeignClient注解修改的客户端在被代理时，都会创建一个新的Fegin.Logger实例。我们需要额外指定这个日志的级别才可以。

(1) 设置com.cncs包下的日志级别都为debug

logging:
  level:
    com.cncs: debug

(2) 编写配置类，定义日志级别：

@Configuration
public class FeignLogConfig {

    @Bean
    Logger.Level feignLoggerLevel(){
        return Logger.Level.FULL; //记录所有的请求和响应的明细，包括头信息，请求体，元数据
    }
}

这里指定的Level级别是FULL，Feign支持4种级别：

• NONE：不记录任何日志信息，这是默认值。
• BASIC：仅记录请求的方法，URL以及响应状态码和执行时间
• HEADERS：在BASIC的基础上，额外记录了请求和响应的头信息
• FULL：记录所有请求和响应的明细，包括头信息、请求体、元数据。

(3) 在FeignClient中指定FeignLogConfiguration：

@FeignClient(value ="service-provider",fallback = UserClientImpl.class,configuration = FeignLogConfig.class) //标注该类是一个feign接口，声明服务降级的方法
public interface UserClient {

    @RequestMapping("user/{id}")
    User findById(@PathVariable("id")Integer id);
}

(4)重启项目，然后访问服务，可以看见访问日志：

Zuul

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

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

在该架构中，我们的服务集群包含：

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

先来说说这样架构需要做的一些事儿以及存在的不足：

• 破坏了服务无状态特点。
  为了保证对外服务的安全性，我们需要实现对服务访问的权限控制，而开放服务的权限控制机制将会贯穿并污染整个开放服务的业务逻辑，这会带来的最直接问题是，破坏了服务集群中REST API无状态的特点。
  从具体开发和测试的角度来说，在工作中除了要考虑实际的业务逻辑之外，还需要额外考虑对接口访问的控制处理。
• 无法直接复用既有接口。
  当我们需要对一个即有的集群内访问接口，实现外部服务访问时，我们不得不通过在原有接口上增加校验逻辑，或增加一个代理调用来实现权限控制，无法直接复用原有的接口。

面对类似上面的问题，我们要如何解决呢？答案是：服务网关！

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

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

简介

Zuul加入后的架构

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

快速入门

(1)新建工程，记住添加zuul依赖，【Spring Could Routing】> 【zuul】：

(2)编写配置

server:
  port: 10086 # 指定zuul网关端口号
spring:
  application:
    name: cncs-zuul # 指定zuul网关应用名称

(3)编写引导类

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

@SpringBootApplication
@EnableZuulProxy //开启zuul组件
public class CncsZuulApplication {

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

(4)编写路由规则

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

• ip为：127.0.0.1
• 端口为：9092

在application.yml文件中编写映射规则

server:
  port: 10086 # 指定zuul网关端口号
spring:
  application:
    name: cncs-zuul # 指定zuul网关应用名称
zuul:
  routes:
    service-provider:   # 这是路由id，随意写
      path: /service-provider/** # 映射路径
      url: http://localhost:9092 # 服务映射地址对应的具体url

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

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

(5)访问的路径中需要加上配置规则的映射路径，我们访问：http://127.0.0.1:10086/service-provider/user/1

面向服务的路由

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

对cncs-zuul工程修改优化：

(1)添加Eureka客户端依赖

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

(2)添加Eureka配置，获取服务信息

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

(3)开启Eureka客户端发现功能

@SpringBootApplication
@EnableZuulProxy //开启zuul组件
@EnableDiscoveryClient //开启eureka客户端组件
public class CncsZuulApplication {

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

(4)修改映射配置，通过服务名称获取

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

重新配置路由规则

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

(5)启动测试

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

简化的路由配置

在刚才的配置中，我们的规则是这样的：

• zuul.routes.<route>.path=/xxx/**： 来指定映射路径。<route>是自定义的路由名
• zuul.routes.<route>.serviceId=service-provider：来指定服务名。

而大多数情况下，我们的<route>路由名称往往和服务名会写成一样的。因此Zuul就提供了一种简化的配置语法：zuul.routes.<serviceId>=<path>

比方说上面我们关于service-provider的配置可以简化为一条：

zuul:
  routes:
    service-provider: /service-provider/** # 这里是映射路径

省去了对服务名称的配置。

默认的路由规则

在使用Zuul的过程中，上面讲述的规则已经大大的简化了配置项。但是当服务较多时，配置也是比较繁琐的。因此Zuul就指定了默认的路由规则。

默认情况下，一切服务的映射路径就是服务名本身。例如服务名为：service-provider，则默认的映射路径就 是：/service-provider/**，下面这样配置就可以了

zuul:
  routes:
    service-provider: # 映射路径默认是：/**

也就是说，刚才的映射规则我们完全不配置也是OK的。

路由前缀

配置示例：

zuul:
  routes:
    service-provider: /service-provider/**
    service-consumer: /service-consumer/**
  prefix: /api # 添加路由前缀

我们通过zuul.prefix=/api来指定了路由的前缀，这样在发起请求时，路径就要以/api开头，如下图所示：

过滤器

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

3.8.1.ZuulFilter

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

• IZuulFilter接口中两个方法：

• shouldFilter：返回一个Boolean值，判断该过滤器是否需要执行。返回true执行，返回false不执行。
• run：过滤器的具体业务逻辑。

public interface IZuulFilter {
    /**
     * a "true" return from this method means that the run() method should be invoked
     *
     * @return true if the run() method should be invoked. false will not invoke the run() method
     */
    boolean shouldFilter();

    /**
     * if shouldFilter() is true, this method will be invoked. this method is the core method of a ZuulFilter
     *
     * @return Some arbitrary artifact may be returned. Current implementation ignores it.
	 * @throws ZuulException if an error occurs during execution.
     */
    Object run() throws ZuulException;

}

• ZuulFilter抽象类中两个重要方法：

• filterType：返回字符串，代表过滤器的类型。包含以下4种：

• pre：请求在被路由之前执行
• route：在路由请求时调用
• post：在route和errror过滤器之后调用
• error：处理请求时发生错误调用

• filterOrder：通过返回的int值来定义过滤器的执行顺序，数字越小优先级越高。

public abstract class ZuulFilter implements IZuulFilter, Comparable<ZuulFilter> {

    private final AtomicReference<DynamicBooleanProperty> filterDisabledRef = new AtomicReference<>();

    /**
     * to classify a filter by type. Standard types in Zuul are "pre" for pre-routing filtering,
     * "route" for routing to an origin, "post" for post-routing filters, "error" for error handling.
     * We also support a "static" type for static responses see  StaticResponseFilter.
     * Any filterType made be created or added and run by calling FilterProcessor.runFilters(type)
     *
     * @return A String representing that type
     */
    abstract public String filterType();

    /**
     * filterOrder() must also be defined for a filter. Filters may have the same  filterOrder if precedence is not
     * important for a filter. filterOrders do not need to be sequential.
     *
     * @return the int order of a filter
     */
    abstract public int filterOrder();
}

过滤器执行生命周期

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

正常流程：

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

异常流程：

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

所有内置过滤器列表：

使用场景

场景非常多：

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

自定义过滤器

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

(1)定义过滤器类

内容

• 记得使用@Component将过滤器放入spring容器中

@Component //将过滤器放入spring容器中
public class LoginFilter extends ZuulFilter {
    //过滤器类型：pre，route，post，error
    @Override
    public String filterType() {
        return "pre";
    }

    //过滤器优先级，注意从10 or 20开始，留有余量，方便扩展
    @Override
    public int filterOrder() {
        return 10;
    }

    //是否启用过滤器，true：启用
    @Override
    public boolean shouldFilter() {
        return true;
    }

    /**
     * 编写过滤器中的业务逻辑：判断请求参数中是否有token参数，有的话就放行，否则返回null
     * @return
     * @throws ZuulException
     */
    @Override
    public Object run() throws ZuulException {
        //获取context
        RequestContext context = RequestContext.getCurrentContext();
        //获取request
        HttpServletRequest request = context.getRequest();
        //获取taken参数
        String token = request.getParameter("token");
        if(StringUtils.isBlank(token)){
            //如果token为空，则拦截该请求，不对其进行路由
            context.setSendZuulResponse(false);
            //设置响应状态码，401，未认证
            context.setResponseStatusCode(HttpStatus.SC_UNAUTHORIZED);
            //设置响应提示信息
            context.setResponseBody("401,Request Error!");
        }
        //认证成功，将登录信息放入上下文信息，然后继续执行
        context.set("token",token);
        return null;
    }
}

(2)测试，没有token参数（或者参数为空）时，访问失败：

有token参数，访问成功：

负载均衡和熔断

Zuul中默认就已经集成了Ribbon负载均衡和Hystix熔断机制：

但是所有的超时策略都是走的默认值，比如熔断超时时间只有1S，很容易就触发了。因此建议手动进行配置：

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