SpringCloud微服务治理三（Zuul网关）

SpringCloud微服务治理一（介绍，环境搭建，Eureka）
SpringCloud微服务治理二(Robbin,Hystix,Feign)
SpringCloud微服务治理三（Zuul网关）

9.Zuul网关

经过前面的学习，使用Spring Cloud实现微服务的架构基本成型，大体是这样的：

在该架构中，咱们的服务集群包含：内部服务Service A和Service B，他们都会注册与订阅服务至Eureka Server，而Open Service是一个对外的服务，经过均衡负载公开至服务调用方。咱们把焦点汇集在对外服务这块，直接暴露咱们的服务地址，这样的实现是否合理，或者是否有更好的实现方式呢？

先来讲说这样架构须要作的一些事儿以及存在的不足：

• 首先，破坏了服务无状态特色。
  • 为了保证对外服务的安全性，咱们须要实现对服务访问的权限控制，而开放服务的权限控制机制将会贯穿并污染整个开放服务的业务逻辑，这会带来的最直接问题是，破坏了服务集群中REST API无状态的特色。
  • 从具体开发和测试的角度来讲，在工做中除了要考虑实际的业务逻辑以外，还须要额外考虑对接口访问的控制处理。
• 其次，没法直接复用既有接口。
  • 当咱们须要对一个即有的集群内访问接口，实现外部服务访问时，咱们不得不经过在原有接口上增长校验逻辑，或增长一个代理调用来实现权限控制，没法直接复用原有的接口。

面对相似上面的问题，咱们要如何解决呢？答案是：服务网关！

为了解决上面这些问题，咱们须要将权限控制这样的东西从咱们的服务单元中抽离出去，而最适合这些逻辑的地方就是处于对外访问最前端的地方，咱们须要一个更强大一些的均衡负载器的 服务网关。

服务网关是微服务架构中一个不可或缺的部分。经过服务网关统一贯外系统提供REST API的过程当中，除了具有服务路由、均衡负载功能以外，它还具有了权限控制等功能。Spring Cloud Netflix中的Zuul就担任了这样的一个角色，为微服务架构提供了前门保护的做用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体可以具有更高的可复用性和可测试性。

9.1.Zuul加入后的架构

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

9.2.Zuul简介

9.3.快速入门

9.3.1.新建工程

填写基本信息：

添加Zuul依赖：

9.3.2.编写启动类

经过@EnableZuulProxy注解开启Zuul的功能：

@SpringBootApplication
@EnableZuulProxy // 开启Zuul的网关功能
public class ZuulDemoApplication {

	public static void main(String[] args) {
		SpringApplication.run(ZuulDemoApplication.class, args);
	}
}
复制代码

9.3.3.编写配置

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

9.3.4.编写路由规则

咱们须要用Zuul来代理user-service服务，先看一下控制面板中的服务状态：

• ip为：127.0.0.1
• 端口为：8081

映射规则：

zuul:
 routes:
 user-service: # 这里是路由id，随意写
 path: /user-service/** # 这里是映射路径
 url: http://127.0.0.1:8081 # 映射路径对应的实际url地址
复制代码

咱们将符合path 规则的一切请求，都代理到 url参数指定的地址

本例中，咱们将 /user-service/**开头的请求，代理到http://127.0.0.1:8081

9.3.5.启动测试：

访问的路径中须要加上配置规则的映射路径，咱们访问：http://127.0.0.1:8081/user-service/user/10

9.4.面向服务的路由

在刚才的路由规则中，咱们把路径对应的服务地址写死了！若是同一服务有多个实例的话，这样作显然就不合理了。

咱们应该根据服务的名称，去Eureka注册中心查找 服务对应的全部实例列表，而后进行动态路由才对！

9.4.1.添加Eureka客户端依赖

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

9.4.2.开启Eureka客户端发现功能

@SpringBootApplication
@EnableZuulProxy // 开启Zuul的网关功能
@EnableDiscoveryClient
public class ZuulDemoApplication {

	public static void main(String[] args) {
		SpringApplication.run(ZuulDemoApplication.class, args);
	}
}
复制代码

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

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

9.4.4.修改映射配置，经过服务名称获取

由于已经有了Eureka客户端，咱们能够从Eureka获取服务的地址信息，所以映射时无需指定IP地址，而是经过服务名称来访问，并且Zuul已经集成了Ribbon的负载均衡功能。

zuul:
 routes:
 user-service: # 这里是路由id，随意写
 path: /user-service/** # 这里是映射路径
 serviceId: user-service # 指定服务名称
复制代码

9.4.5.启动测试

再次启动，此次Zuul进行代理时，会利用Ribbon进行负载均衡访问：

日志中能够看到使用了负载均衡器：

9.5.简化的路由配置

在刚才的配置中，咱们的规则是这样的：

• zuul.routes.<route>.path=/xxx/**： 来指定映射路径。<route>是自定义的路由名
• zuul.routes.<route>.serviceId=/user-service：来指定服务名。

而大多数状况下，咱们的<route>路由名称每每和 服务名会写成同样的。所以Zuul就提供了一种简化的配置语法：zuul.routes.<serviceId>=<path>

比方说上面咱们关于user-service的配置能够简化为一条：

zuul:
 routes:
 user-service: /user-service/** # 这里是映射路径
复制代码

省去了对服务名称的配置。

9.6.默认的路由规则

在使用Zuul的过程当中，上面讲述的规则已经大大的简化了配置项。可是当服务较多时，配置也是比较繁琐的。所以Zuul就指定了默认的路由规则：

• 默认状况下，一切服务的映射路径就是服务名自己。
  • 例如服务名为：user-service，则默认的映射路径就是：/user-service/**

也就是说，刚才的映射规则咱们彻底不配置也是OK的

9.7.路由前缀

配置示例：

zuul:
 prefix: /api # 添加路由前缀
 routes:
 user-service: # 这里是路由id，随意写
 path: /user-service/** # 这里是映射路径
 service-id: user-service # 指定服务名称
复制代码

咱们经过zuul.prefix=/api来指定了路由的前缀，这样在发起请求时，路径就要以/api开头。

路径/api/user-service/user/1将会被代理到/user-service/user/1

9.8.过滤器

Zuul做为网关的其中一个重要功能，就是实现请求的鉴权。而这个动做咱们每每是经过Zuul提供的过滤器来实现的。

9.8.1.ZuulFilter

ZuulFilter是过滤器的顶级父类。在这里咱们看一下其中定义的4个最重要的方法：

public abstract ZuulFilter implements IZuulFilter{

    abstract public String filterType();

    abstract public int filterOrder();
    
    boolean shouldFilter();// 来自IZuulFilter

    Object run() throws ZuulException;// IZuulFilter
}
复制代码

• shouldFilter：返回一个Boolean值，判断该过滤器是否须要执行。返回true执行，返回false不执行。
• run：过滤器的具体业务逻辑。
• filterType：返回字符串，表明过滤器的类型。包含如下4种：
  • pre：请求在被路由以前执行
  • routing：在路由请求时调用
  • post：在routing和errror过滤器以后调用
  • error：处理请求时发生错误调用
• filterOrder：经过返回的int值来定义过滤器的执行顺序，数字越小优先级越高。

9.8.2.过滤器执行生命周期：

这张是Zuul官网提供的请求生命周期图，清晰的表现了一个请求在各个过滤器的执行顺序。

​

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

全部内置过滤器列表：

​

9.8.3.使用场景

场景很是多：

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

9.9.自定义过滤器

接下来咱们来自定义一个过滤器，模拟一个登陆的校验。基本逻辑：若是请求中有access-token参数，则认为请求有效，放行。

9.9.1.定义过滤器类

@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() throws ZuulException {
        // 登陆校验逻辑。
        // 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;
    }
}

复制代码

9.10.负载均衡和熔断

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

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
复制代码