SpringCloud入门学习总结

摆脱啊

已于 2024-05-17 11:34:41 修改

阅读量1.3k

点赞数 25

分类专栏：框架文章标签： springcloud

于 2019-12-11 21:23:52 首次发布

本文链接：https://blog.csdn.net/qq_41075298/article/details/103499864

版权

框架专栏收录该内容

1 篇文章 0 订阅

订阅专栏

项目框架演变过程

单一应用架构（ORM)

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。
Nginx +Tomcat + Database (负载均衡)

垂直应用架构（MVC)

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的 Web 框架(MVC)是关键。

分布式服务架构 (RPC)

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。
为了扛住并发才有的分布式
手动管理Controller调用服务

流动计算架构 (SOA)

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。
出现了注册中心( ZooKeeper ),用于管理远程调用
注册中心将服务列表推送给Controller(长连接)

微服务架构

注册中心将服务列表拉取给服务调用者(短链接)

SOA的架构与微服务的区别

dubbo和springcloud的区别

dubbo
- RPC (技术)
- 提供者,消费者,注册中心 (角色)
springcloud
- HTTP
- 微服务,注册中心

远程调用技术

dubbo RPC远程服务调用方案(长连接)
httpclient http协议(短连接)
webservice SOAP协议(长连接)

服务调用方式

RPC：Remote Produce Call远程过程调用，类似的还有RMI（remote method invoke）。自定义数据格式，基于原生TCP通信，速度快，效率高。早期的webservice，现在热门的dubbo，都是RPC的典型代表.
Http：http其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议，也可以用来进行远程服务调用。缺点是消息封装臃肿，优势是对服务的提供和调用方没有任何技术限定，自由灵活，更符合微服务理念。

现在热门的Rest风格，就可以通过http协议来实现。

RestTemplate介绍

Spring提供了一个RestTemplate模板工具类，对基于Http的客户端进行了封装，并且实现了对象与json的序列化和反序列化，非常方便。RestTemplate并没有限定Http的客户端类型，而是进行了抽象，目前常用的3种都有支持：

HttpClient
OkHttp
JDK原生的URLConnection（默认的）

SpringCloud简介

Spring最擅长的就是集成，把世界上最好的框架拿过来，集成到自己的项目中。

SpringCloud也是一样，它将现在非常流行的一些技术整合到一起，实现了诸如：配置管理，服务发现，智能路由，负载均衡，熔断器，控制总线，集群状态等等功能。其主要涉及的组件包括：

Netflix：

Eureka：注册中心
Zuul：服务网关
Ribbon：负载均衡
Feign：服务调用
Hystix：熔断器

Eureka注册中心

Eureka就好比是滴滴，负责管理、记录服务提供者的信息。服务调用者无需自己寻找服务，而是把自己的需求告诉Eureka，然后Eureka会把符合你需求的服务告诉你。

同时，服务提供方与Eureka之间通过“心跳”机制进行监控，当某个服务提供方出现问题，Eureka自然会把它从服务列表中剔除。

这就实现了服务的自动注册、发现、状态监控。

renewal：续约

Eureka-Server：就是服务注册中心（可以是一个集群），对外暴露自己的地址。
提供者：启动后向Eureka注册自己信息（地址，服务名称等），并且定期进行服务续约
消费者：服务调用方，会定期去Eureka拉取服务列表，然后使用负载均衡算法选出一个服务进行调用。
心跳(续约)：提供者定期通过http方式向Eureka刷新自己的状态

Eureka入门案例

编写EurekaServer

创建一个EurekaServer项目

导入依赖eureka-server

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

编写启动类加入注解

@EnableEurekaServer // 声明这个应用是一个EurekaServer

编写配置文件

server:
  port: 10086
spring:
  application:
    name: eureka-server # 应用名称，会在Eureka中作为服务的id标识（serviceId）
eureka:
  client:
    service-url: # EurekaServer的地址，现在是自己的地址，如果是集群，需要写其它Server的地址。
      defaultZone: http://127.0.0.1:10086/eureka
    register-with-eureka: false       # 不注册自己
    fetch-registry: false             #不拉取服务
  instance:
    lease-expiration-duration-in-seconds: 90    #服务失效默认90,从服务列表中剔除(秒)
  server:
    enable-self-preservation: false        # 关闭自我保护模式（缺省为打开）
    eviction-interval-timer-in-ms: 60000    #清理间隔 #默认是60*1000

启动服务，并访问：http://127.0.0.1:10086

服务注册

导入eureka-client依赖

<!-- Eureka客户端 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

启动类添加注解
```
@EnableEurekaClient // 开启Eureka客户端发现功能
```
- @EnableDiscovervclient Dubbo注册中心也用
- @EnableEurekaClient 仅Eureka可用(确认项目全是springcloud推荐)

配置编写

eureka:
  client:
    service-url: # EurekaServer地址
      defaultZone: http://127.0.0.1:10086/eureka

重启项目，访问Eureka监控页面查看

服务发现

导入eureka-client依赖
启动类添加注解
配置编写

修改代码，用DiscoveryClient类的方法，根据服务名称，获取服务实例：


    @Autowired
    private RestTemplate restTemplate;

    @Autowired
    private DiscoveryClient discoveryClient;

    @GetMapping("{id}")
    public SsCompany findOne(@PathVariable("id") String id){
        List<ServiceInstance> instances = discoveryClient.getInstances("company-service");
        String url = instances.get(0).getUri().toString();
        SsCompany ssCompany = restTemplate.getForObject(url+"/company/" + id, SsCompany.class);
        return ssCompany;
    }

高可用的Eureka Server

所谓的高可用注册中心，其实就是把EurekaServer自己也作为一个服务，注册到其它EurekaServer上，这样多个EurekaServer之间就能互相发现对方，从而形成集群。

因此，无论客户端访问到Eureka Server集群中的任意一个节点，都可以获取到完整的服务列表信息。

如果有三个Eureka，则每一个EurekaServer都需要注册到其它几个Eureka服务中，例如：有三个分别为10086、10087、10088，则：

10086要注册到10087和10088上
10087要注册到10086和10088上
10088要注册到10086和10087上

JVM参数覆盖配置文件配置：

-Dserver.port=10087 -Deureka.client.serviceUrl.defaultZone=http://127.0.0.1:10086/eureka

配置:

eureka:
  instance:
    ip-address: 127.0.0.1 # ip地址
    prefer-ip-address: true # 更倾向于使用ip，而不是host名
    instance-id: ${eureka.instance.ip-address}:${server.port} # 自定义实例的id   
    lease-renewal-interval-in-seconds: 30		#服务续约默认30,发心跳(秒)
    lease-expiration-duration-in-seconds: 90    #服务失效默认90,从服务列表中剔除(秒)
  client:
    service-url: # EurekaServer地址,多个地址以','隔开
    defaultZone: http://127.0.0.1:10086/eureka,http://127.0.0.1:10087/eureka
    registry-fetch-interval-seconds: 30
  server:
    enable-self-preservation: false 		# 关闭自我保护模式（缺省为打开）
    eviction-interval-timer-in-ms: 60000    #清理间隔 #默认是60*1000

总结：

服务的注册和发现都是可控制的，可以关闭也可以开启。默认都是开启
注册后需要心跳，心跳周期默认30秒一次，超过90秒没法认为宕机
服务拉取默认30秒拉取一次
Eureka每个60秒会剔除标记为宕机的服务
Eureka会有自我保护，当心跳失败比例超过85%阈值，那么开启自我保护，不再剔除服务。
Eureka高可用就是多台Eureka互相注册在对方上

Ribbon负载均衡

概述

Ribbon是Nettix发布的负载均衡器,它有助于控制HTTP和TCP客户端的行为。

为 Ribbon配置服务提供者地址列表后, Ribbon就可基于某种负载均衡算法, 自动地帮助服务消费者去请求。

Ribbon默认为我们提供了很多的负载均衡算法,例如轮询、随机等。当然,我们也可为Ribbon实现自定义的负载均衡算法。

实现(调用者)

首先我们启动两个company-service实例，一个8081，一个8082。

和Eureka的高可用配置方式一致，复制启动参数，修改启动端口
```
 -Dserver.port=8082
```
因为Eureka中已经集成了Ribbon，所以我们无需引入新的依赖。直接修改代码：
在RestTemplate的配置方法上添加@LoadBalanced注解：

@Bean
@LoadBalanced
public RestTemplate restTemplate() {
    return new RestTemplate();
}

Ribbon默认为轮询的方式

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

@GetMapping("{id}")
public User queryById(@PathVariable("id") Long id){
    String url = "http://company-service/user/" + id;
    User user = restTemplate.getForObject(url, User.class);
    return user;
}

Hystrix熔断器

简介

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

雪崩问题

若某个微服务发生异常，请求阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞
服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪崩效应。

解决雪崩问题

Hystix解决雪崩问题的手段主要是服务降级，包括：

线程隔离
服务熔断

线程隔离，服务降级

服务降级

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

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

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

触发Hystix服务降级的情况：

线程池已满
请求超时

实现(调用者)

引入依赖

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

开启熔断

在启动类上添加注解：@EnableCircuitBreaker
```
@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class ConsumerApplication {
	// ...
}
```
可以看到，我们类上的注解越来越多，在微服务中，经常会引入上面的三个注解，于是Spring就提供了一个组合注解：@SpringCloudApplication

编写降级逻辑

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

@GetMapping("{id}")
@HystrixCommand(fallbackMethod = "findOneFallBack")	//用来声明一个降级逻辑的方法
public SsCompany findOne(@PathVariable("id") String id){
    String url = "http://company-service/company/" + id;
    SsCompany company = restTemplate.getForObject(url, SsCompany.class);
    return company;
}

public SsCompany findOneFallBack(String id){
    log.error("查询用户信息失败，id：{}", id);
    return "对不起，网络太拥挤了！";
}

默认的Fallback(不要写参数,返回值要一致)

@DefaultProperties(defaultFallback = "defaultFallBack")：//在类上指明统一的失败降级方法

超时设置：

Hystix的默认超时时长为1，我们可以通过配置修改这个值：

hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 2000  #默认是1秒超时

服务熔断

熔断器，也叫断路器，其英文单词为：Circuit Breaker

状态机有3个状态：

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

熔断器的默认触发阈值是20次请求，不好触发。休眠时间时5秒，时间太短，不易观察，为了测试方便，我们可以通过配置修改熔断策略：

circuitBreaker:
 requestVolumeThreshold: 5        #最小请求次数，默认是20次
 sleepWindowInMilliseconds: 10000 #休眠10秒，默认是5秒
 errorThresholdPercentage: 50     #默认50%的触发熔断

Feign服务调用

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

实现(调用者)

导入依赖

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

Feign的客户端

@FeignClient("company-service")    //这里填写的是eureka上要代理的service名称
public interface CompanyClient {

    @GetMapping("/company/{id}")  //这里的返回结果和 url地址一定要和提供方保持一致
    SsCompany findOne(@PathVariable("id") String id);
}

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

改造原来的调用逻辑，使用companyClient访问：

@RestController
public class ConsumerController {

    @Autowired
    private CompanyClient companyClient;

    @GetMapping("/company/{id}")
    public SsCompany findOne(@PathVariable("id") String id){
        return companyClient.findOne(id);
    }
}

开启Feign功能

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

@SpringCloudApplication
@EnableFeignClients // 开启Feign功能
public class ConsumerDemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConsumerDemoApplication.class, args);
    }
}

Feign集成Ribbon和Hystix

Feign中已经自动集成了Ribbon负载均衡，因此我们不需要自己定义RestTemplate了

Feign默认也有对Hystix的集成(默认关闭)

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

Feign中的Fallback配置:

首先，我们要定义一个类，实现刚才编写的CompanyClientFallback，作为fallback的处理类

@Component	//注册到容器
public class CompanyClientFallback implements CompanyClient {
    @Override
    public SsCompany findOne(String id) {
        SsCompany company = new SsCompany();
        company.setId(id);
        company.setName("用户查询出现异常！");
        return company;
    }
}

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

@FeignClient(value = "company-service", fallback = CompanyClientFallback.class)
public interface CompanyClient {

    @GetMapping("/company/{id}")
    SsCompany findOne(@PathVariable("id") String 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 # 设置触发压缩的大小下限，单位是kb

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

日志级别

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

1）设置cn.itcast包下的日志级别都为debug

logging:
  level:
    cn.itcast: debug

2）编写配置类，定义日志级别

@Configuration
public class FeignConfig {
    @Bean
    public Logger.Level feignLoggerLevel(){
        return Logger.Level.FULL;
    }
}

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

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

3）在FeignClient中指定配置类：

@FeignClient(value = "company-service", fallback = CompanyClientFallback.class, configuration = FeignConfig.class)
public interface CompanyClient {
    @GetMapping("/company/{id}")
    SsCompany findOne(@PathVariable("id") String id);
}

Zuul网关

概述

Zuul是Netfix开源的微服务网关,它可以和Eureka, Ribbon,Hystrix等组件配合使用。
Zul的核心是一系列的过滤器,这些过滤器可以完成以下功能
- 身份认证与安全:识别每个资源的验证要求,并拒绝那些与要求不符的请求
- 审查与监控:在边缘位置追踪有意义的数据和统计结果,从而带来精确的生产视图。
- 动态路由:动态地将请求路由到不同的后端集群
- 压力测试:逐渐增加指向集群的流量,以了解性能
- 负载分配:为每一种负载类型分配对应容量,并弃用超出限定值的请求
- 静态响应处理:在边缘位置直接建立部分响应,从而避免其转发到内部集群
- 多区域弹性:跨越AWS Region进行请求路由,旨在实现ELB ( Elastic Load Balancing)使用的多样化,以及让系统的边缘更贴近系统的使用者
pring Cloud对Zuul进行了整合与增强
- Zuul使用的默认HTTP客户端是Apache HTTP Client,也可以使用RestClient或者okhttp3.0kHttpClient
- 如果想要使用RestClient,可以设置ribbon.restclient. enabled-true
- 想要使用okhttp3.0kHttpClient,可以设置ribbon.okhttp.enabled-true
网关的核心功能是：过滤和路由
不管是来自于客户端（PC或移动端）的请求，还是服务内部调用。一切对服务的请求都会经过Zuul这个网关，然后再由网关来实现鉴权、动态路由等等操作。Zuul就是我们服务的统一入口。

实现

新建工程

导入依赖

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

编写启动类

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

@SpringBootApplication
@EnableZuulProxy // 开启Zuul的网关功能,过滤功能比@EnableZuulServer多
public class ZuulApplication {

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

编写配置

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

编写路由规则

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

ip为：127.0.0.1

端口为：8081

映射规则：
```
zuul:
  routes:
    company-service: # 这里是路由id，随意写
      path: /service-path/** # 这里是映射路径,建议直接写eureka中服务名称
      url: http://127.0.0.1:8081 # 映射路径对应的实际url地址
```
我们将符合path 规则的一切请求，都代理到 url参数指定的地址

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

添加Eureka客户端依赖

根据服务的名称，去Eureka注册中心查找服务对应的所有实例列表，然后进行动态路由

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

开启Eureka客户端发现功能

@SpringBootApplication
@EnableZuulProxy // 开启Zuul的网关功能
@EnableDiscoveryClient
public class ZuulApplication {

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

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

eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka

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

因为已经有了Eureka客户端，我们可以从Eureka获取服务的地址信息，因此映射时无需指定IP地址，而是通过服务名称来访问，而且Zuul已经集成了Ribbon的负载均衡功能。
```
zuul:
  routes:
    user-service: # 这里是路由id，随意写
      path: /service-path/** # 这里是映射路径
      serviceId: company-service # 指定服务名称
```

简化的路由配置

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

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

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

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

zuul:
  routes:
    company-service: /company-service/** #  必须和注册的服务名称一致:冒号后是映射路径随意

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

默认的路由规则

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

默认情况下，一切服务的映射路径就是服务名本身。
- 例如服务名为：company-server，则默认的映射路径就是：/company-server/**

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

如果想要禁用某个路由规则，可以这样：

http://localhost:10010/eureka-server可以看到所有的服务相关信息,

注意单个eureka时，需要注册自己拉取服务才能在zuul上看到效果

zuul:
  ignored-services:   #路由忽略列表
    - eureka-server

路由前缀

配置示例：

zuul:
  prefix: /api # 添加路由前缀
  routes:
    company-service: /company-service/** # 这里是映射路径

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

路径/api/company-service/company/1将会被代理到/company-service/company/1

扩展知识：

strip-prefix可以默认true改为false可以去除路由前缀，比如如果路由改为名字的路径是company，进行请求的时候就是/company/company/1，两次重复可以通过strip-prefix去除掉路由的company，但简化的路由配置不能设置

zuul:
  routes:
    company-service:
      path: /company/**
      strip-prefix: false #去除path前缀可以不用/company/company/1这样请求直接去掉了路由的company

过滤器

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
}

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

pre：请求在被路由之前执行

route：在路由请求时调用

error：处理请求时发生错误调用

post：在routing和errror过滤器之后调用
filterOrder：通过返回的int值来定义过滤器的执行顺序，数字越小优先级越高。
shouldFilter：返回一个Boolean值，判断该过滤器是否需要执行。返回true执行，返回false不执行。
run：过滤器的具体业务逻辑。

过滤器执行生命周期

正常流程：
- 请求到达首先会经过pre类型过滤器，而后到达routing类型，进行路由，请求就到达真正的服务提供者，执行请求，返回结果后，会到达post过滤器。而后返回响应。
异常流程：
- 整个过程中，pre或者routing过滤器出现异常，都会直接进入error过滤器，再error处理完毕后，会将请求交给POST过滤器，最后返回给用户。
- 如果是error过滤器自己出现异常，最终也会进入POST过滤器，而后返回。
- 如果是POST过滤器出现异常，会跳转到error过滤器，但是与pre和routing不同的时，请求不会再到达POST过滤器了。

使用场景

场景非常多：

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

自定义过滤器

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

PRE_DECORATION_FILTER_ORDER 路由定义寻找接口，值越小越会在前执行

定义过滤器类

@Component
public class LoginFilter extends ZuulFilter {
    @Override
    public String filterType() {
        return FilterConstants.PRE_TYPE; //在路由之前判断是否有权限
    }

    @Override
    public int filterOrder() {
        return FilterConstants.PRE_DECORATION_FILTER_ORDER - 1; //比PRE类型过滤器还要小
    }

    @Override
    public boolean shouldFilter() {
        return true;   //设置为可执行
    }

    @Override
    public Object run() throws ZuulException {
        // 获取请求上下文
        RequestContext ctx = RequestContext.getCurrentContext();
        // 获取request对象
        HttpServletRequest request = ctx.getRequest();
        // 获取请求参数
        String token = request.getParameter("token");
        // 判断是否存在
        if(StringUtils.isBlank(token)){
            // 不存在，未登录，拦截
            ctx.setSendZuulResponse(false);
            // 设置返回状态码
            ctx.setResponseStatusCode(HttpStatus.UNAUTHORIZED.value());
        }
        return null;
    }
}

测试：没有token参数时，访问失败，有token参数时，正常访问

负载均衡和熔断

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

hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 6000
ribbon:
  ConnectTimeout: 1000
  ReadTimeout: 2000
  MaxAutoRetries: 0
  MaxAutoRetriesNextServer: 1

Zuul的高可用

启动多个Zuul服务，自动注册到Eureka，形成集群。如果是服务内部访问，你访问Zuul，自动负载均衡，没问题。

但是，Zuul更多是外部访问，PC端、移动端等。他们无法通过Eureka进行负载均衡，那么该怎么办？

此时，我们会使用其它的服务网关，来对Zuul进行代理。比如：Nginx

摆脱啊

关注

25
点赞
踩
13

收藏

觉得还不错? 一键收藏
1
评论
SpringCloud入门学习总结

项目框架演变过程单一应用架构（ORM)当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。Nginx +Tomcat + Database (负载均衡)垂直应用架构（MVC)当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页...
复制链接

扫一扫