SPRING CLOUD微服务DEMO-下篇

1 Hystix

1.1 简介

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

我感觉难以解释清楚，鉴于接下来的demo项目基本不会用这个模块，就过一遍代码算了。

1.2 配置并测试

模拟一下熔断：一旦请求的接口超过1s没有响应就不再继续请求，开始执行实现定义好的回滚函数，返回一个提示信息。
注意：Ribbon的重试机制和Hystrix的熔断机制有一定关系。

1.2.1 引入依赖

往user-consume即服务调用者的pom文件里面添加hystrix依赖。

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

1.2.2 开启熔断

在UserConsumeApplication中添加@EnableCircuitBreaker

可以看到注解有点多了，可以用@SpringCloudApplication代替上面三个注解

//@EnableDiscoveryClient // 开启EurekaClient功能
//@EnableCircuitBreaker  //开启熔断
//@SpringBootApplication
@SpringCloudApplication   //三合一注解

1.2.3 改造consume

改造consume即消费者的调用方法，记录调用接口耗费的时间，编写调用超时的回滚方法。

@HystrixCommand(fallbackMethod="queryUserByIdFallback")：声明一个失败回滚处理函数queryUserByIdFallback，当queryUserById执行超时（默认是1000毫秒），就会执行fallback函数，返回错误提示。

@Component
public class UserDao {
    @Autowired
    private RestTemplate restTemplate;

    private static final Logger logger = LoggerFactory.getLogger(UserDao.class);

    @HystrixCommand(fallbackMethod = "queryUserByIdFallback")
    public User queryUserById(Long id){
        long begin = System.currentTimeMillis();
        String url = "http://user-service/user/" + id;
        User user = this.restTemplate.getForObject(url, User.class);
        long end = System.currentTimeMillis();
        // 记录访问用时：
        logger.info("访问用时：{}", end - begin);
        return user;
    }

    public User queryUserByIdFallback(Long id){
        User user = new User();
        user.setId(id);
        user.setUsername("用户信息查询出现异常！");
        return user;
    }
}

@Service
public class UserService {
    @Autowired
    private UserDao userDao;

    public List<User> queryUserByIds(List<Long> ids) {
        List<User> users = new ArrayList<>();
        ids.forEach(id -> {
            // 我们测试多次查询，
            users.add(this.userDao.queryUserById(id));
        });
        return users;
    }
}

1.2.4 改造service

即改造服务提供者，将方法随机延迟一段时间，模拟超时。

@Service
public class UserService {
    @Autowired
    private UserMapper userMapper;

    public User queryById(Long id)  throws InterruptedException {
        // 为了演示超时现象，我们在这里然线程休眠,时间随机 0~2000毫秒
        Thread.sleep(new Random().nextInt(2000));
        return this.userMapper.selectByPrimaryKey(id);
    }
}

1.2.5 结果

很明显，超过1000ms的请求被回滚方法处理掉了。

1.2.6 设置Hystrix超时时间

之前我们设置的Robbin的ReadTimeout是1000ms，即请求一个接口超过1000ms未响应就请求另一个有相同功能的接口而Hystrix的超时时间默认也是1000ms，观察现象可知，先触发了熔断。但这样是不合理的，明明可以请求另一个接口得到结果，结果触发了熔断，返回的是找不到结果。
所以注意一点：Hystrix的超时时间一定要大于Robbin的重试时间。

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

2. Feign

2.1 简介

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

2.2 使用Feign

Feign的引入和配置全部都在consume中进行

2.2.1 引入依赖

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

2.2.2 UserConsumeApplication添加注解

@EnableFeignClients

2.2.3 编写UserClient接口

在项目中添加client包，下面新建UserClient接口

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

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

2.2.4 使用UserClient请求数据

改造UserService，改为使用UserClient请求数据

@Service
public class UserService {
    //@Autowired
    //private UserDao userDao;

    @Autowired
    private UserClient userClient;    //注入UserClient

    public List<User> queryUserByIds(List<Long> ids) {
        List<User> users = new ArrayList<>();
        ids.forEach(id -> {
            //使用UserClient请求接口
            users.add(userClient.queryUserById(id));
            //users.add(this.userDao.queryUserById(id));
        });
        return users;
    }
}

2.3 负载均衡

Feign是对请求的封装，本身集成了Ribbon负载均衡。可以对其进行配置,和单独使用Robbin的写法一样

user-service:
  ribbon:
    ConnectTimeout: 250 # 连接超时时间(ms)
    ReadTimeout: 1000 # 通信超时时间(ms)
    OkToRetryOnAllOperations: true # 是否对所有操作重试
    MaxAutoRetriesNextServer: 1 # 同一服务不同实例的重试次数
    MaxAutoRetries: 1 # 同一实例的重试次数

2.4 Hystrix支持

Feign也集成了Hystrix。

需要配置以开启Hystrix

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

回滚方法不像之前那样写了，要专门定义一个类。

@Component
public class UserFeignClientFallback implements UserClient {
    @Override
    public User queryUserById(Long id) {
        User user = new User();
        user.setId(id);
        user.setUsername("用户查询出现异常");
        return user;
    }
}

在UserClient接口上配置回滚类

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

2.5.请求压缩

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

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

3. Zuul网关

3.1 简介

Zuul是Netflix开源的微服务网关，它可以和Eureka、Ribbon和Hystrix等组件配合使用。核心是一系列的过滤器，完成身份认证与权限管理、动态路由、压力测试等功能。

工作流程如下所示

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

3.2 搭建

3.2.1 建一个新的module

其他步骤前面已经说过，选择模块时注意选择Zuul即可。

3.2.2 引入依赖

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

3.2.3 添加注解

@SpringBootApplication
@EnableZuulProxy        //开启zuul网关
@EnableDiscoveryClient  //开启Eureka客户端发现功能
public class ZuulApplication {
    public static void main(String[] args) {
        SpringApplication.run(ZuulApplication.class, args);
    }
}

3.3 路由功能

测试之前先把之前添加的user-service的随机延迟给注释掉

Zuul的路由功能：

• 配置

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

eureka:
  client:
    registry-fetch-interval-seconds: 5 # 获取服务列表的周期：5s
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka,http://127.0.0.1:10087/eureka
  instance:
    prefer-ip-address: true
    ip-address: 127.0.0.1

zuul:
  prefix: /api # 添加路由前缀
  routes:
    user-service: # 路由id,一般与服务名相同
      path: /user-service/** # 映射路径
      serviceId: user-service

• 解释：Zuul从Eureka中拉取服务列表，如果有人请求/api/user-service/**，将请求转发给服务列表中的

  user-service服务。

坑爹的一点：之前测试的时候Zuul一直报找不到user-service服务的错误，找了一段时间后来自己好了。

没有再复现出来，不知道为啥。如果报错了，可以尝试着用maven的reimport，再等等试试。

• 由于路由id一般与服务名相同，因此zuul提供了一种简化配置，与上面实现相同功能

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

访问http://localhost:10010/api/user-service/user/20即可得到结果。

3.4 过滤功能

3.4.1 ZuulFilter

ZuulFilter是过滤器的顶级父类，我们自己实现的过滤器都要继承自它。我们看看其中重要的四个方法：

public abstract ZuulFilter implements IZuulFilter{
    abstract public String filterType();
    abstract public int filterOrder();
    boolean shouldFilter();
    Object run() throws ZuulException;
}

• shouldFilter：返回布尔值，判断过滤器是否需要执行。true表示执行，false反之。
• run：表示具体的过滤逻辑。
• filterType：返回字符串，表示本过滤器的类型
  • pre：请求在被路由之前执行。
  • routing：在路由请求时调用
  • post：在routing和errror过滤器之后调用
  • error：处理请求时发生错误调用
• filterOrder：通过返回的int值来定义过滤器的执行顺序，数字越小优先级越高。

3.4.2 生命周期

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

3.4.3 使用场景

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

3.4.4 模拟登录校验

添加登录过滤器

@Component
public class LoginFilter extends ZuulFilter {
    @Override
    public String filterType() {
        // 登录校验，肯定是在前置拦截
        return "pre";
    }
    @Override
    public int filterOrder() {
        // 顺序设置为1
        return 1;
    }
    @Override
    public boolean shouldFilter() {
        // 返回true，代表过滤器生效。
        return true;
    }
    @Override
    public Object run() {
        // 登录校验逻辑。
        // 1）获取Zuul提供的请求上下文对象
        RequestContext ctx = RequestContext.getCurrentContext();
        // 2) 从上下文中获取request对象
        HttpServletRequest req = ctx.getRequest();
        // 3) 从请求中获取token
        String token = req.getParameter("access-token");
        // 4) 判断
        if(token == null || "".equals(token.trim())){
            // 没有token，登录校验失败，拦截
            ctx.setSendZuulResponse(false);
            // 返回401状态码。也可以考虑重定向到登录页。
            ctx.setResponseStatusCode(HttpStatus.UNAUTHORIZED.value());
        }
        // 校验通过，可以考虑把用户信息放入上下文，继续向后执行
        return null;
    }
}

• 访问http://localhost:10010/api/user-service/user/20，提示401未授权
• 访问http://localhost:10010/api/user-service/user/20?access-token=123 ，能正常访问

3.5 负载均衡和熔断功能

Zuul内部集成了Ribbon负载均衡和Hystrix熔断器，需要配置

zuul:
  retryable: true
ribbon:
  ConnectTimeout: 250 # 连接超时时间(ms)
  ReadTimeout: 2000 # 通信超时时间(ms)
  OkToRetryOnAllOperations: true # 是否对所有操作重试
  MaxAutoRetriesNextServer: 2 # 同一服务不同实例的重试次数
  MaxAutoRetries: 1 # 同一实例的重试次数
hystrix:
  command:
    default:
        execution:
          isolation:
            thread:
              timeoutInMillisecond: 6000 # 熔断超时时长：6000ms

总结

一直在想着如何配置，如何实现，容易犯一叶障目不见泰山的毛病，下面就概括一下。

Eureka 注册中心

服务提供者在里面注册，服务消费者拉取服务列表，根据服务列表去发请求并获取数据。

这其中涉及到最重要的一个问题：如何保证服务列表里面的服务是有效的？

• 对于提供者，这个问题是：你怎么才能知道我什么时候可用，什么时候不可用？

Eureka和提供者就形成了约定：提供者准备好后在Eureka里面注册，Eureka知道提供者可用了。注册后提供者每隔一段时间向Eureka发个消息说我还活着，Eureka就知道提供者依旧可用。Eureka每隔一段时间就会扫描整个服务列表，把很长时间没报告过的服务剔除出去。这样注册中心的服务列表就能始终更新，始终可用。

• 对于消费者，这个问题是：我怎么知道你不行了？

消费者每隔一段时间就从注册中心拉取服务列表，注册中心和服务提供者的约定保证了这个列表可以信任，我就根据这个列表发出请求，得到数据。

注意上面的三个时间段，这都是可以配置的，怎么配置就根据实际情况来了。

Robbin 负载均衡

服务的消费者在拉取服务列表后，针对同一业务可能有多个可选的服务提供者。

如果一直使用其中一个，那就是传说中的"一核有难，八核围观"，表现差劲，浪费资源，这就需要负载均衡了。

Ribbon提供了诸如随机、轮询等多种策略可选。

它还提供了重试机制：选择了一个服务后，如果这个服务坏了（毕竟每隔一段时间才拉取服务列表，服务列表也是每隔一段时间才更新），或者说反应太慢，到了一定时间就考虑再换一个服务。

Hystrix 熔断机制

为了避免一个模块的错误拖垮整个系统，因此将其隔离起来。

不要让一颗老鼠屎坏了一锅汤？这个机制我不太能讲清楚。

但是注意它和Ribbon的联系，一个服务没有反应，应该先用Ribbon进行重试，而不是先熔断。然后这又引出来一个问题，一个错误如果每次都被重试机制掩盖了，那系统还会被拖垮吗？还是说这个业务的服务都坏了，试来试去找不到一个好用的，才触发熔断？想不清楚，真遇到了再说吧。

Feign 请求封装

封装了RestTemplate，让请求的编码更简单。

请求必然涉及负载均衡和熔断问题，所以Feign里面也可以配置Robbin和Hystrix。

但不光如此，Feign还提供了请求压缩等小功能。

Zuul 网关

微服务提供者的接口是暴露在外的，要是谁都能用那就乱套了。

就像学校的器材室有各种器材，但是谁都能自由取用就乱了。因此我们需要一个管理器材的老师，拿器材的人来了，先判断他有没有老师的批准，再根据老师的批准决定他能拿什么器材，最后把他带到对应的器材室拿相应的器材。

Zuul就像是这个老师，负责鉴权（判断一个人能不能拿器材，能拿什么器材）、路由（领到地方拿器材）。

Zuul虽然不发请求，但是对请求有很强的干预能力，所以它也可以配置负载均衡和熔断。

写在最后

这篇文章基本上是照抄网上流传的黑马乐优商城的资料，外加自己的一点点见解。
虽然培训班的名声不太好，但只要能学到知识，我不管知识是从哪里来的，别人随便鄙视，无所谓。
最后还是要感谢让我学到知识的那些人。