spring cloud之zuul路由网关（六）

转自：
http://blog.csdn.net/forezp/article/details/69939114

在微服务架构中，需要几个基础的服务治理组件，包括服务注册与发现、服务消费、负载均衡、断路器、智能路由、配置管理等，由这几个基础组件相互协作，共同组建了一个简单的微服务系统。一个简答的微服务系统如下图：



注意：A服务和B服务是可以相互调用的，作图的时候忘记了。并且配置服务也是注册到服务注册中心的。
在Spring Cloud微服务系统中，一种常见的负载均衡方式是，客户端的请求首先经过负载均衡（zuul、Ngnix），再到达服务网关（zuul集群），然后再到具体的服务。服务统一注册到高可用的服务注册中心集群，服务的所有的配置文件由配置服务管理，配置服务的配置文件放在git仓库，方便开发人员随时改配置。

一、Zuul简介

路由器和过滤器：Zuul

路由在微服务体系结构的一个组成部分。例如，

/

可以映射到您的Web应用程序，

/api/users

映射到用户服务，并将

/api/shop

映射到商店服务。Zuul是Netflix的基于JVM的路由器和服务器端负载均衡器。
Netflix使用Zuul进行以下操作：
认证

洞察

压力测试

金丝雀测试

动态路由

服务迁移

负载脱落

安全

静态响应处理

主动/主动流量管理

二、准备工作

继续使用上一节的工程。在原有的工程上，创建一个新的工程。

三、创建zuul-service工程

其pom.xml文件如下：

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <parent>
<artifactId>spring-cloud</artifactId>
<groupId>com.alen</groupId>
<version>0.0.1-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<packaging>jar</packaging>
<artifactId>zuul-service</artifactId>
<dependencies>
<!--eureka client -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
<!--zuul-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zuul</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
</dependencies>

<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>

加上配置文件application.properties加上以下的配置代码：

#端口
server.port=8086
eureka.instance.hostname=localhost
#设置eureka服务器所在的地址，查询服务和注册服务都需要依赖这个地址。
eureka.client.serviceUrl.defaultZone=http\://localhost\:8081/eureka/
#这在以后的服务与服务之间相互调用一般都是根据这个name
spring.application.name=zuul-service
zuul.routes.api-a.path= /api-a/**
zuul.routes.api-a.serviceId= eureka-client
zuul.routes.api-b.path=/api-b/**
zuul.routes.api-b.serviceId=feign-service

首先指定服务注册中心的地址为http://localhost:8081/eureka/，服务名为zuul-service；以/api-a/ 开头的请求都转发给eureka-client服务；以/api-b/开头的请求都转发给feign-service服务；
依次运行这五个工程;打开浏览器访问：http://localhost:8086/api-a/hello?age=10 ;浏览器显示：20
这说明zuul起到了路由的作用

四、服务过滤

zuul不仅只是路由，并且还能过滤，做一些安全验证。继续改造工程；

/**
* 过滤器
**/
@Component
public class MyFilter extends ZuulFilter{

private static final Logger log=Logger.getLogger(MyFilter.class);
@Override
public String filterType() {
return "pre";
}

@Override
public int filterOrder() {
return 0;
}

@Override
public boolean shouldFilter() {
return true;
}

@Override
public Object run() {
RequestContext ctx = RequestContext.getCurrentContext();
HttpServletRequest request = ctx.getRequest();
Object accessToken = request.getParameter("token");
if(accessToken == null) {
log.warn("token is empty");
ctx.setSendZuulResponse(false);
ctx.setResponseStatusCode(401);
try {
ctx.getResponse().getWriter().write("token is empty");
}catch (Exception e){}
return null;
}
log.info("ok");
return null;
}
}
filterType：返回一个字符串代表过滤器的类型，在zuul中定义了四种不同生命周期的过滤器类型，具体如下：

pre：路由之前
routing：路由之时
post： 路由之后
error：发送错误调用
filterOrder：过滤的顺序
shouldFilter：这里可以写逻辑判断，是否要过滤，本文true,永远过滤。
这时访问：http://localhost:8086/api-a/hello?age=10 ；网页显示：
token is empty

五：一些Zuul 路由配置

此时必须要知道应用程序的名称，但是如果不知道这个名称肯定无法访问，可是如果让用户知道这个名称，那么使用 zuul 就
没有任何的实际意义，直接调用即可。而 zuul 的主要功能是代理，那么代理的功能就是不让用户看见真实的操作，所以在实际的
使用之中就需要为 zuul 设置一些路由规则。
1、 【microcloud-zuul-gateway-9501】 为指定的应用设置路径，修改 application.yml 配置文件：
zuul:
routes:
microcloud-provider-company: /company-proxy/**
那么此时就可以通过“/company-proxy”来访问“microcloud-provider-company”名称。 http://gateway-9501.com:9501/company-proxy/company/get/hello 但是现在还会存在有一个实际的问题，虽然现在开启了路由访问支持，但是依然支持通过应用名称进行访问： http://gateway-9501.com:9501/microcloud-provider-company/company/get/hello 2、 【microcloud-zuul-gateway-9501】修改 application.yml 配置文件忽略掉应用名称访问：
· 忽略掉“microcloud-provider-company”应用名称；
zuul:
ignored-services:
microcloud-provider-company
routes:
microcloud-provider-company: /company-proxy/**
这个时候就可以进行代理的安全使用，但是如果你一个系统之中存在有几百个微服务，如果按照如上的方式进行配置就会非
常的麻烦，所以最简单的做法是可以采用一个通配符“*”的模式来完成：
zuul:
ignored-services:
"*"
routes:
microcloud-provider-company: /company-proxy/**
现在表示所有的 Eureka 中的服务名称的信息访问都要忽略掉，所有的访问都需要配置一个映射路径的模式来完成。
3、 【microcloud-zuul-gateway-9501】除了以上的模式进行服务定义之外，在 zuul 之中也可以采用如下的方式进行处理：
zuul:
ignored-services:
"*"
routes:
mycompany.path: /company-proxy/**
mycompany.serviceId: microcloud-provider-company
其中在代码里面出现的“mycompany”是一个逻辑名称，该名称的主要作用是将 path 与 serviceId 绑定在一起。
4、 【microcloud-zuul-gateway-9501】如果说现在不想通过 Eureka 进行访问，则也可以直接连接到 company 微服务的地址
zuul:
ignored-services:
"*"
routes:
company.path: /company-proxy/**
company.url: http://company-8101.com:8101/company
此时的地址上由于已经存在有了“company”前缀，所以访问地址为： http://gateway-9501.com:9501/company-proxy/get/hello 但是从实际的开发来讲不建议采用此类模式处理，因为所有的服务如果直接绑定了指定的服务提供者的地址，那么将不方便
进行负载均衡的配置处理，而且没有 Eureka 所有微服务的管理也非常不方便。
5、 【microcloud-zuul-gateway-9501】设置公共前缀：
zuul:
prefix: /mldn-proxy
ignored-services:
"*"
routes:
microcloud-provider-company: /company-proxy/**
一旦存在有前缀定义之后所有微服务的访问上就必须追加有前缀名称： http://gateway-9501.com:9501/mldn-proxy/company-proxy/company/get/hello 以上的地址：
· “/mldn-proxy”：整个 zuul 的前缀；
· “/company-proxy”：是在 zuul 中定义的映射路径；
· “/company/get/hello”：是微服务提供者提供的操作