SpringCloud Zuul基于Consul配置及详解

一.构建工程

　　1.引入依赖

        <!--SpringBoot2.0以上版本需引入该依赖-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-zuul</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-consul-discovery</artifactId>
        </dependency>

 

　　2.建立主类

@SpringBootApplication
@EnableDiscoveryClient
@EnableZuulProxy
@RestController
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }

}

　　3.配置application.properties

zuul.routes.api-a.path=/api-a/**
zuul.routes.api-a.service-id=api-a

zuul.routes.api-b.path=/api-b/**
zuul.routes.api-b.service-id=api-b

　　这里存在 api-a 和 api-b 两个微服务应用, 当请求http://localhost:port/api-a/helloWorld, 会被路由转发至 api-a 服务的 /helloWorld 接口, 当请求http://localhost:port/api-b/helloWorld, 会被路由转发至 api-b 服务的 /helloWorld 接口. 当请求 URL 符合配置规则时, 就会被转发至 service-id 对应的微服务应用接口.

 

　　4.配置请求过滤

　　SpringCloud Zuul 还有另外一个和核心功能: 请求过滤. Zuul 容许开发者在 API 网关上经过定义过滤器来实现对请求的拦截与过滤, 实现方法很是简单, 只需继承 ZuulFilter 抽象类并实现它定义的4个抽象函数就能够完成对请求的拦截和过滤.

public class MyGatewayFilter extends ZuulFilter {

　　/*4种过滤器类型, 
：能够在请求被路由以前调用, 
：在路由请求时候被调用, 　　pre　　route

：在route和error过滤器以后被调用, 
：处理请求时发生错误时被调用*/ 　　post　　error

　　@Override 
　　public String filterType() { 
　　　　return "pre";
　　}

 @Override public int filterOrder() { return 0;　　//优先级为0，数字越大，优先级越低 } @Override public boolean shouldFilter() { return true;　　// 是否执行该过滤器，此处为true，说明须要过滤 } @Override public Object run() { RequestContext ctx = RequestContext.getCurrentContext(); HttpServletRequest request = ctx.getRequest(); log.info(String.format("%s request to %s", request.getMethod(), request.getRequestURL().toString())); Object accessToken = request.getParameter("token");　　//获取token参数 if (accessToken == null) { log.warn("token is empty"); ctx.setSendZuulResponse(false);　　//过滤该请求, 不对其进行路由 ctx.setResponseStatusCode(401);　　//返回错误码 ctx.setResponseBody("token is null!");　　//返回错误内容 return null;　　　//Zuul还未对返回数据作处理 }
　　　　return null; } } 

　　

　　建立过滤器后,它并不会直接生效, 咱们还需为其建立具体的 Bean 才能启动该过滤器.

@SpringBootApplication
@EnableDiscoveryClient
@EnableZuulProxy
@RestController
public class LixjApplication {

    public static void main(String[] args) {
        SpringApplication.run(LixjApplication.class, args);
    }

    @Bean
    public MyGatewayFilter myGatewayFilter(){
        return new MyGatewayFilter();
    }
}

 

二. 路由详解

　　1.路径匹配规则　　

　　　　/api-a/?　　　 能够匹配 /api-a/ 以后拼接一个任务字符的路径 , 好比 /api-a/a , /api-a/b , /api-a/c

　　　　/api-a/*　　　 能够匹配 /api-a/ 以后拼接任意字符的路径, 好比 /api-a/a, /api-a/aaa, /api-a/bbb . 但它没法匹配 /api-a/a/b 这种多级目录路径

　　　　/api-a/**　　　能够匹配 /api-a/* 包含的内容以外, 还能够匹配形如 /api-a/a/b 的多级目录路径

 

　　2.路由匹配顺序

　　　　随着版本的迭代, 咱们须要对一个服务作一些功能拆分, 将原属于 api-a 服务的某些功能拆分到另外一个全新的服务 api-a-part 中, 而这些拆分的外部调用 URL 路径但愿可以符合规则 /api-a/part/** .

　　　　zuul.routes.api-a.path=/api-a/**
　　　　zuul.routes.api-a.service-id=api-a

　　　　zuul.routes.api-a-part.path=/api-a/part/**
　　　　zuul.routes.api-a-part.service-id=api-a-part

　　　　在源码中, 路由规则是经过 LinkedHashMap 保存的, 也就是说, 路由规则的保存时有序的, 而内容的加载是经过遍历配置文件中路由规则依次加入的, 因此致使问题的根本缘由是对配置文件中内容的读取, 但上述properties配置没法保证路由规则加载顺序, 咱们须要使用 YML 文件来配置, 以实现有序的路由规则. 

zuul:
    routes:
        api-a-part:
            path=/api-a/part/**
            service-id=api-a-part　
        api-a:
            path=/api-a/**
            service-id=api-a        

 

　　3.本地跳转　

zuul.routes.api-c.path=/api-c/**
zuul.routes.api-c.url=forward:/api-c

 

　　　　以上配置使用了本地跳转,当 url 符合 /api-c/** 规则时,会被网关转发到 本身自己 服务的对应接口.