上一篇介绍了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中那样简单了

首先，我们定义一个类，实现刚才编写的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;
    }
}

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

@FeignClient(value = "user-service",fallback = UserClientFallBack.class)
public interface UserClient {
    @GetMapping("/user/{id}")
    User queryById(@PathVariable("id") Long id);
}

重启测试
我们关闭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实例。我们需要额外指定这个日志的级别才可以

设置指定包名下的日志级别都为debug

logging:
  level: 
    com.itheima: debug

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

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

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

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

在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获取配置文件的内容

配置服务端

将配置文件提交到码云

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

配置中心微服务

创建工程module ly-config
引入依赖

<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>

创建启动类

@SpringBootApplication
@EnableConfigServer // 开启配置服务
public class ConfigServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }
}

编写配置文件application.yml

spring:
  application:
    name: config-server
  cloud:
    config:
      server:
        git:
          uri: https://gitee.com/probuing/leyou-config.git
server:
  port: 12000

启动浏览器访问 http://localhost:12000/item-dev.yml 可以看到配置的内容

配置客户端

在user_service工程中添加配置依赖

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

在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可以实现配置的自动更新

配置服务端

修改ly_config的pom 引入依赖

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

修改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

配置客户端

我们修改user_service工程，引入依赖

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

在码云的配置文件中配置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

SpringCloud(二)——Feign、Zuul、SpringCloudConfig

Feign

快速入门

导入依赖

Feign的客户端

开启Feign功能

启动测试

负载均衡

Hystix支持

请求压缩

日志级别

Zuul网关

Zuul加入后的架构

快速入门

新建工程

添加依赖

编写启动类

编写配置

编写路由规则

启动测试

面向服务的路由

添加Eureka客户端依赖

开启Eureka客户端发现

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

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

启动测试

简化的路由配置

默认路由规则

路由前缀

过滤器

ZuulFilter

过滤器执行生命周期

过滤器的使用场景

自定义过滤器

自定义过滤器类

测试

负载均衡和熔断

Zuul的高

bootstrap.yml和application.yml

集中配置组件SpringCloudConfig

SpringCloudConfig简介

配置服务端

将配置文件提交到码云

配置中心微服务

配置客户端

消息总线组件SpringCloudBus

SpringCloudBus简介

配置服务端

配置客户端