微服务网关 Zuul

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

# 客户端会多次请求不同微服务，增加客户端的复杂性

# 存在跨域请求，在一定场景下处理相对复杂

# 认证复杂，每一个服务都需要独立认证

# 难以重构，随着项目的迭代，可能需要重新划分微服务，如果客户端直接和微服务通信，那么重构会难以实施

# 某些微服务可能使用了其他协议，直接访问有一定困难

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

 

Zuul是Netflix开源的微服务网关，他可以和Eureka,Ribbon,Hystrix等组件配合使

用。Zuul组件的核心是一系列的过滤器，这些过滤器可以完成以下功能：

# 身份认证和安全: 识别每一个资源的验证要求，并拒绝那些不符的请求

#审查与监控：

## 动态路由：动态将请求路由到不同后端集群

# 压力测试：逐渐增加指向集群的流量，以了解性能

# 负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求

# 静态响应处理：边缘位置进行响应，避免转发到内部集群

# 多区域弹性：跨域AWS Region进行请求路由，旨在实现ELB(ElasticLoad Balancing)使

用多样化

Spring Cloud对Zuul进行了整合和增强。

 

引入依赖 

 

<dependencies> 
    <dependency>
       <groupId>org.springframework.cloud</groupId>             
       <artifactId>spring‐cloud‐starter‐netflix‐eureka‐ client</artifactId>
    </dependency>
    <dependency> 
       <groupId>org.springframework.cloud</groupId> 
       <artifactId>spring‐cloud‐starter‐netflix‐zuul</artifactId> 
    </dependency>
 </dependencies>

配置文件

server: 
    port: 9011
spring: 
　　application: 
　　　　name: test‐getway #指定服务名 
eureka: 
　　client: 
　　　　serviceUrl: #Eureka客户端与Eureka服务端进行交互的地址 
　　　　　　defaultZone: http://127.0.0.1:6868/eureka/ 
　　instance: prefer‐ip‐address: true 
zuul: 
　　routes:
 　　　　test‐gathering: # 路由id，随意写   
　　　　　　path: /gathering/** ## 这里是映射路径
　　　　　　serviceId: test‐gathering #指定Eureka注册中心中的服务id 
　　　　 test‐article: 
　　　　　　path: /article/** 
　　　　　　serviceId: test‐article 
　　　　 test‐base:  
　　　　　　path: /base/**  
　　　　　　serviceId: test‐base 
　　prefix: /api # 添加路由前缀

 

简化 配置 

zuul:
  routes:
    service-provider: /service-provider/** # 这里是映射路径

路由过滤 

Zuul中提供了一个ignored-patterns属性，用来忽略不希望路由的URL路径，示例：

zuul.ignored-patterns: /upload/**

Zuul还提供了ignored-services属性，进行服务过滤：

zuul.ignored-services: upload-servie

 

 

启动类 加注解 

 @EnableZuulProxy

 

 

Zuul过滤器 

   

@Component 
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 任何ojbect的值都表示继续执行
 * setsendzullRespponse(false)表示不再继续执行
 * @return
 * @throws ZuulException
 */
    @Override 

    public Object run() throws ZuulException { 
       System.out.println("zuul过滤器..."); 
        return null; }
    }

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

滤器类型，具体如下：

pre ：可以在请求被路由之前调用

route ：在路由请求时候被调用

post ：在route和error过滤器之后被调用

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

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

shouldFilter ：返回一个boolean类型来判断该过滤器是否要执行，所以通过此函数可

实现过滤器的开关。在上例中，我们直接返回true，所以该过滤器总是生效

run ：过滤器的具体逻辑

 

 

 

 

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

 

 

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