SpringCloud(二)——Feign、Zuul、SpringCloudConfig

上一篇介绍了SpringCloud(一):

Feign

Feign可以把Rest的请求进行隐藏,伪装成类似SpringMVC的Controller一样,不用再自己拼接url,拼接参数等操作

快速入门

导入依赖

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

Feign的客户端

@FeignClient("user-service")
public interface UserClient {
    @GetMapping("/user/{id}")
    User queryById(@PathVariable("id") Long id);
}

  • 首先这是一个接口,Feign会通过动态代理,帮我们生成实现类。
  • @FeignClient 声明这是一个Feign客户端,同时通过value属性指定服务名称
  • 接口中的定义方法,完全采用SpringMVC的注解,Feign会根据注解帮我们生成URL,并访问获取结果
    改造原来的调用逻辑,使用UserClient访问:
@RestController
@RequestMapping("consumer")
@Slf4j
public class ConsumerController {
    @Autowired
    private RestTemplate restTemplate;

    @Autowired
    private DiscoveryClient discoveryClient;

    @Autowired
    private UserClient userClient;

    @GetMapping("{id}")
    @HystrixCommand
    public User queyById(@PathVariable("id") Long id) {

        return userClient.queryById(id);
    }
}

开启Feign功能

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

@SpringCloudApplication
@EnableFeignClients//开启Feign功能呢个
public class ConsumerApplication {
 

    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args);
    }
}
  • Feign中已经自动集成了Ribbon负载均衡,我们在这里不需要自己定义RestTemplate了

启动测试

image.png

负载均衡

Feign中本身已经集成了Ribbon依赖和自动配置
我们使用Feign不需要额外引入依赖
Feign内置的ribbon默认设置了请求超时时长,默认是1000ms,我们可以通过手动配置来修改这个超时时长

ribbon:
  ReadTimeout: 2000 # 读取超时时长
  ConnectTimeout: 1000 # 建立链接的超时时长

ribbon内部由重试机制,一旦超时,会自动重新发起请求,如果希望关闭重试,可以添加配置

ribbon:
  ReadTimeout: 2000 # 数据通信超时时长
  ConnectTimeout: 500 # 连接超时时长
  MaxAutoRetries: 0 # 当前服务器的重试次数
  MaxAutoRetriesNextServer: 1 # 重试多少次服务
  OkToRetryOnAllOperations: false # 是否对所有的请求方式都重试

Hystix支持

Feign默认也集成了Hystix,只不过默认情况下是关闭的,我们需要通过下面的参数来开启

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

开启后,我们需要配置Fallback 降级逻辑,Feign的降级逻辑不像Hystrix中那样简单了

  1. 首先,我们定义一个类,实现刚才编写的UserFeignClient 作为fallback的处理类
@Component
public class UserClientFallBack implements UserClient {
    @Override
    public User queryById(Long id) {
        User user = new User();
        user.setId(id);
        user.setName("用户查询异常");
        return user;
    }
}
  1. 然后在UserFeignClient中,指定刚才编写的实现类
@FeignClient(value = "user-service",fallback = UserClientFallBack.class)
public interface UserClient {
    @GetMapping("/user/{id}")
    User queryById(@PathVariable("id") Long id);
}

  1. 重启测试
    我们关闭user-service 查看页面的服务降级


    image.png

请求压缩

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

feign:
  hystrix:
    enabled: true # 开启Feign的熔断功能
  compression:
    request:
      enabled: true # 开启请求压缩
    response:
      enabled: true # 开启响应压缩

同时,我们也可以对请求的数据类型,以及处罚压缩的大小下限进行设置:

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

日志级别

@FeignClient注解修改的客户端在被代理时,都会创建一个新的Feign.Logger实例。我们需要额外指定这个日志的级别才可以

  1. 设置指定包名下的日志级别都为debug
logging:
  level: 
    com.itheima: debug
  1. 编写配置类,定义日志级别
@Configuration
public class FeignConfig {
@Bean
Logger.Level feignLoggerLevel(){
return Logger.Level.FULL;
}
}

这里指定的Level级别是Full,Feign支持4种级别

  • NONE:不记录任何日志信息,默认
  • BASIC:仅记录请求的方法,URL以及相应状态码和执行时间
  • HEADERS:在BASIC的基础上,额外记录了请求和响应的头信息
  • FULL:记录所有请求和响应的明细,包括头信息、请求体、元数据
  1. 在FeignClient中指定配置类:
@
FeignClient(value = "user-service", fallback = UserClientFallback.class,
configuration = FeignConfig.class)
public interface UserClient {
@GetMapping("/user/{id}")
User queryById(@PathVariable("id") Long id);
}
日志

Zuul网关

zuul介绍

网关的核心功能呢个是:过滤(鉴权)和路由

Zuul加入后的架构

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

快速入门

新建工程

添加依赖

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

编写启动类

@SpringBootApplication
@EnableZuulProxy //开启zuul网关功能
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 我们可以看到Eureka的监控面板


image.png
  • ip为 127.0.0.1
  • 端口为:8081
    映射规则:
zuul:
  routes: 
    user-service:
      path: /user-service/** #映射路径
      url: http://127.0.0.1:8081 # 映射路径对应的实际url地址

启动测试

我们在访问的路径中加上配置规则的映射路径
http://127.0.0.1:10010/user-service/user/1
页面响应:

image.png

面向服务的路由

在上面的路由规则中,我们将路径对应的服务地址写死了。这样做不合理
我们应该根据服务的名称,去Eureka注册中心查找服务对应的所有实例列表,然后进行动态路由

添加Eureka客户端依赖

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

开启Eureka客户端发现

@SpringBootApplication
@EnableZuulProxy //开启zuul网关功能
@EnableDiscoveryClient //开启Eureka客户端发现
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

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

zuul:
  routes:
    user-service:
      path: /user-service/** #映射路径
      serviceId: user-service # 指定服务名称

启动测试

image.png

简化的路由配置

在刚才的配置中,我们配置的规则是:

  • zuul.routes.<route名>.path=/xxx/**:来指定映射路径。
  • zuul.routes.<route名>.serviceId=/user-service 来指定服务名
    在大多数情况下 我们的<route>路由名称往往和服务名会写成一样的。因此zuul提供了一种简化的配置语法: zuul.routes.<serviceId>=<path>
    我们简化上面的配置
zuul:
  routes:
  # 简化写法
    user-service: /user-service/** #指定映射路径

这样可以省去对服务名称的配置

默认路由规则

  • 默认情况下,一切服务的映射路径就是服务名本身
    • 例如服务名为:user-service 则默认的映射路径就是/user-service/**
      也就是说,刚才的映射规则我们完全不配置也是可以的
      如果想要禁用某个路由规则,则可以
zuul:
  ignored-services:
    - eureka-server

路由前缀

配置实例

zuul:
  # 禁用某个路由规则
  ignored-services:
    - eureka-server
  prefix: /api #添加路由前缀
  routes:
    user-service: /user-service/**  # 指定映射路径

我们通过zuul.prefix=/api来指定了路由的前缀,这样在发起请求时,路径就要以/api开头
按照上面的配置 /api/user-service/user/1 ===》/user-service/user/1

过滤器

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:在路由请求时调用
    • post:在routing和error过滤器之后调用
    • error:处理请求时发生错误调用
  • filterOrder:通过返回的int值来定义过滤器的执行顺序,数字越小优先级越高
  • shouldFilter:返回一个Boolean值,判断该过滤器是否需要执行。返回true执行,返回false不执行
  • run:过滤器的具体业务逻辑

过滤器执行生命周期

官方执行流程图


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

过滤器的使用场景

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

自定义过滤器

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

自定义过滤器类

@Component
@Slf4j
public class LoginFilter extends ZuulFilter {
    @Override
    public String filterType() {
        log.info("filterType");
        return FilterConstants.PRE_TYPE;
    }

    @Override
    public int filterOrder() {
        log.info("filterOrder");
        return FilterConstants.PRE_DECORATION_FILTER_ORDER -1;
    }

    @Override
    public boolean shouldFilter() {
        log.info("shouldFilter");
        return true;
    }

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

测试

没有token参数时,访问失败


image.png

添加token后,正常访问


image.png

负载均衡和熔断

Zuul中默认就已经集成了Ribbon负载均衡和Hystix熔断机制。但是所有的超时策略都是默认的,因此建议我们手动进行配置

hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 6000

ribbon:
  ConnectTimeout: 1000
  ReadTimeout: 2000
  MaxAutoRetries: 0 # 自动重试设置0
  MaxAutoRetriesNextServer: 1

Zuul的高

启动多个Zuul服务,自动注册到Eureka,形成集群。如果是服务内部访问,你访问Zuul,自动负载均衡。
但是,Zuul更多是外部访问,PC端、移动端等。他们无法通过Eureka进行负载均衡,那么该怎么办?
一般在这种情况下,我们会使用其它的服务网关,来对Zuul进行代理。如Nginx

bootstrap.yml和application.yml

bootstrap.yml用来程序引导时执行,应用于更加早起配置信息读取。
application.yml应用程序特有配置信息,可以用来配置后续各个模块中需使用的公共参数等

bootstrap.yml先于application.yml加载
从技术上来说,bootstrap.yml是被一个父级的Spring ApplicationContext加载的。
这个父级的Spring ApplicationContext加载的。
这个父级的Spring ApplicationContext是先加载的,在加载application.yml的ApplicationContext之前
可以通过设置 spring.cloud.bootstrap.enabled=false来禁用bootstrap

集中配置组件SpringCloudConfig

SpringCloudConfig简介

在分布式系统中,由于服务数量巨多,为了方便服务配置文件统一管理,实时更新,所以需要分布式配置中心组件。在Spring Cloud中,有分布式配置中心组件Spring cloud config,它支持配置服务放在配置服务的内存中。也支持放在远程Git仓库中。在Spring cloud config组件中,分两个角色 一个是config server 二是config client

  • Config Server 是一个可横向扩展、集中式的配置服务器,它用于集中管理用用程序各个环境下的配置,默认使用Git存储配置文件内容,也可以使用SVN存储,或者是本地文件存储
  • Config Client 是Config Server的客户端,用于操作存储在Config Server中的配置内容,微服务在启动时会请求Config Server获取配置文件的内容

配置服务端

将配置文件提交到码云

  1. 注册一个码云(gitee.com)帐号,并登陆到管理控制台
  2. 创建仓库leyou-config
  3. 上传配置文件,将user_service工程的application.yml改名为item-dev.yml后上传

配置中心微服务

  1. 创建工程module ly-config
  2. 引入依赖
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
</dependencies>
  1. 创建启动类
@SpringBootApplication
@EnableConfigServer // 开启配置服务
public class ConfigServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }
}

  1. 编写配置文件application.yml
spring:
  application:
    name: config-server
  cloud:
    config:
      server:
        git:
          uri: https://gitee.com/probuing/leyou-config.git
server:
  port: 12000
  1. 启动浏览器访问 http://localhost:12000/item-dev.yml 可以看到配置的内容

配置客户端

  1. 在user_service工程中添加配置依赖
  <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-config</artifactId>
        </dependency>
  1. 在ly_item_service工程中添加bootstrap.yml 删除application.yml
spring:
  cloud:
    config:
      name: item
      profile: dev
      label: master
      uri: http://127.0.0.1:12000

消息总线组件SpringCloudBus

SpringCloudBus简介

SpringCloudBus可以实现配置的自动更新

配置服务端

  1. 修改ly_config的pom 引入依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>
  1. 修改application.yml配置
spring:
  rabbitmq:
    host: 127.0.0.1
    port: 5672
    virtual-host: /leyou
    username: leyou
    password: leyou
management: #暴露触发消息总线的地址
  endpoints:
    web:
      exposure:
        include: bus-refresh

配置客户端

  1. 我们修改user_service工程,引入依赖
 <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-bus-amqp</artifactId>
        </dependency>
  1. 在码云的配置文件中配置rabbitMQ的地址
spring:
  rabbitmq:
    host: 127.0.0.1
    port: 5672
    virtual-host: /leyou
    username: leyou
    password: leyou

(3)启动 注册中心、配置中心、服务提供方、消费方项目看是否正常运行

(4)修改码云上的配置文件 ,将数据库连接IP 改为127.0.0.1 ,在本地部署一份数据库。
(5)测试 Url: http://127.0.0.1:12000/actuator/bus-refresh Method: post