十次方——SpringCloud之Hystrix、Zuul

 

一.  熔断器Hystrix

1.1 为什么要使用熔断器

在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。​ 如果下图所示：A作为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，雪崩效应就形成了。

如何避免产生这种雪崩效应呢？我们可以使用Hystrix来实现熔断器。

1.2 什么是Hystrix

Hystrix 能使你的系统在出现依赖服务失效的时候，通过隔离系统所依赖的服务，防止服务级联失败，同时提供失败回退机制，更优雅地应对失效，并使你的系统能更快地从异常中恢复。

了解熔断器模式请看下图：

1.3 快速体验

Feign 本身支持Hystrix，不需要额外引入依赖。

（1）修改tensquare_qa模块的application.yml ，开启hystrix

feign:
  hystrix:
    enabled: true

（2）在com.tensquare.qa.client包下创建impl包，包下创建熔断实现类，实现自接口BaseClient

package com.tensquare.qa.client.impl;

//jar包

@Component
public class BaseClientImpl implements BaseClient{
    @Override
    public Result findById(String labelId) {
        return new Result(false , StatusCode.ERROR , "熔断器触发了");
    }
}

（3）修改BaseClient的注解

（4）测试运行

重新启动问答微服务，测试看熔断器是否运行。

2 微服务网关Zuul

2.1 为什么需要微服务网关
 

不同的微服务一般有不同的网络地址，而外部的客户端可能需要调用多个服务的接口才能完成一个业务需求。比如一个电影购票的收集APP,可能回调用电影分类微服务，用户微服务，支付微服务等。如果客户端直接和微服务进行通信，会存在一下问题：

• 客户端会多次请求不同微服务，增加客户端的复杂性
• 存在跨域请求，在一定场景下处理相对复杂
• 认证复杂，每一个服务都需要独立认证
• 难以重构，随着项目的迭代，可能需要重新划分微服务，如果客户端直接和微服务通信，那么重构会难以实施
• 某些微服务可能使用了其他协议，直接访问有一定困难

上述问题，都可以借助微服务网关解决。微服务网关是介于客户端和服务器端之间的中 间层，所有的外部请求都会先经过微服务网关。

2.2 什么是Zuul

Zuul是Netflix开源的微服务网关，他可以和Eureka,Ribbon,Hystrix等组件配合使用。Zuul组件的核心是一系列的过滤器，这些过滤器可以完成以下功能：

# 身份认证和安全: 识别每一个资源的验证要求，并拒绝那些不符的请求
# 审查与监控：
# 动态路由：动态将请求路由到不同后端集群
# 压力测试：逐渐增加指向集群的流量，以了解性能
# 负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求
# 静态响应处理：边缘位置进行响应，避免转发到内部集群
# 多区域弹性：跨域AWS Region进行请求路由，旨在实现ELB(ElasticLoad Balancing)使用多样化

Spring Cloud对Zuul进行了整合和增强。使用Zuul后，架构图演变为以下形式

2.3 Zuul路由转发

2.3.1 管理后台微服务网关

（1）首先创建子模块tensquare_backmanager

（2）在pom.xml中引入eureka-client和zuul的依赖

（3）编写配置文件application.yml

（4）编写启动类就OK了

启动启动类后，我们首先不从网关去访问base模块了label方法，即在postman中输入：http://localhost:9001/label

以后为了方便，我们就可以直接从网关走了，即：http://localhost:9011/base/label   

2.3.2 网站前台的微服务网关

和上面后台网关一样，建个tensquare_web模块，配置文件除了端口和名字，其他和上面一样，启动类也一样

2.4 Zuul过滤器

2.4.1 Zuul过滤器快速体验

我们再前台网关模块创建一个简单的zuul过滤器，

package com.tensquare.web.filter;

import com.netflix.zuul.ZuulFilter;
import com.netflix.zuul.exception.ZuulException;

public class WebFilter extends ZuulFilter{


    /**
     * 在请求前pre或者后post执行
     * @return
     */
    @Override
    public String filterType() {
        return "pre";
    }

    /**
     * 多个过滤器的执行顺序，数字越小，表示越先执行
     * @return
     */
    @Override
    public int filterOrder() {
        return 0;
    }

    /**
     * 当前过滤器是否开启，true表示开启
     * @return
     */
    @Override
    public boolean shouldFilter() {
        return true;
    }

    /**
     * 过滤器内执行的操作return任何object的值都表示继续执行
     * setsendzuulResponse(false)
     * @return
     * @throws ZuulException
     */
    @Override
    public Object run() throws ZuulException {
        System.out.println("经过后台过滤器了！");
        return null;
    }
}

我们再次访问http://localhost:9011/base/label   时，就会在控制台看到

说明过滤器已经执行。

filterType：返回一个字符串代表过滤器的类型，在zuul中定义了四种不同生命周期的过滤器类型，具体如下：

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

filterOrder ：通过int值来定义过滤器的执行顺序

shouldFilter ：返回一个boolean类型来判断该过滤器是否要执行，所以通过此函数可实现过滤器的开关。在上例中，我们直接返回true，所以该过滤器总是生效

run ：过滤器的具体逻辑。

2.5  网关头信息丢失示例

我们还是以9001/label为例子，现在我们将LabelController的添加输出头信息的功能：

然后我们不通过网关直接访问：

我们可以看到base拿到了头信息abc

但我们如果经过网关：

则base模块则拿不到头信息了

因为头信息里面都是权限用户名等信息，网关拿到头信息后就不会继续转发了。所以我们需要在网关转发header。我们只需要把前端WebFilter中的run方法改为如下：

    public Object run() throws ZuulException {
        
        //得到request上下文
        RequestContext requestContext = RequestContext.getCurrentContext();
        //得到request域
        HttpServletRequest request = requestContext.getRequest();
        //得到头信息
        String authorization = request.getHeader("Authorization");
        if(authorization!=null){
            requestContext.addZuulRequestHeader("Authorization",authorization);
        }
        return null;
    }

这样原封不动的将header转发过去base就可以得到头信息了。

2.6  后台网关验证权限

因为要用到common模块中的jwtUtil工具类，所以先导入common模块

然后在application.yml中配置jwt

再将jwtUtil工具类放到spring容器中，即在BackmanagerApplication中注入

准备工作做完了后，我们就可以在BackmanagerFilter类中重写run方法了

网关转发时是有个内部方法OPTIONS（这个方法的功能是找往哪个分支转发），任何经过网关都需要两次请求，第一次请求并不是带有头文件的请求，而是内部分发路径，所以在程序中需要判断一下，如果是OPTIONS方法，就不需要头信息

同样，对于登录操作，也是不需要头信息的。

 /**
     * 过滤器内执行的操作return任何object的值都表示继续执行
     * setsendzuulResponse(false)
     * @return
     * @throws ZuulException
     */
    @Override
    public Object run() throws ZuulException {

        //得到request上下文
        RequestContext requestContext = RequestContext.getCurrentContext();
        //得到request域
        HttpServletRequest request = requestContext.getRequest();
        //得到头信息

        //当时OPTIONS方法时，不需要请求头自动跳过
        if(request.getMethod().equals("OPTIONS")){
            return null;
        }

        //当方法是登录时，也不需要请求头,getRequestURI得到请求路径
        if(request.getRequestURI().indexOf("login")>0){
            return null;
        }

        String header = request.getHeader("Authorization");
        if(header!=null  &&  "".equals(header)){
           if(header.startsWith("Bearer ")){
               //得到token
               String token = header.substring(7);
               try{
                   Claims claims = jwtUtil.parseJWT(token);
                   String roles = (String) claims.get("roles");
                   //判断是否是admin用户
                   if(roles.equals("admin")){
                       //把头信息转发过去，并且放行
                       requestContext.addZuulRequestHeader("Authorization" , header);
                       return null;
                   }
               }catch( Exception e){
                   e.printStackTrace();
                   requestContext.setSendZuulResponse(false); //终止运行
               }
           }
        }
        requestContext.setSendZuulResponse(false); //终止运行
        return null;
    }