到目前为止,我们Spring Cloud中的内容已经介绍了很多了,Ribbon、Hystrix、Feign这些知识点大家都耳熟能详了,我们在前文也提到过微服务就是把一个大的项目拆分成很多小的独立模块,然后通过服务治理让这些独立的模块配合工作等。那么大家来想这样两个问题:1.如果我的微服务中有很多个独立服务都要对外提供服务,那么对于开发人员或者运维人员来说,他要如何去管理这些接口?特别是当项目非常大非常庞杂的情况下要如何管理?2.权限管理也是一个老生常谈的问题,在微服务中,一个独立的系统被拆分成很多个独立的模块,为了确保安全,我难道需要在每一个模块上都添加上相同的鉴权代码来确保系统不被非法访问?如果是这样的话,那么工作量就太大了,而且维护也非常不方便。
为了解决上面提到的问题,我们引入了API网关的概念,API网关是一个更为智能的应用服务器,它有点类似于我们微服务架构系统的门面,所有的外部访问都要先经过API网关,然后API网关来实现请求路由、负载均衡、权限验证等功能。Spring Cloud中提供的Spring Cloud Zuul实现了API网关的功能,本文我们就先来看看Spring Cloud Zuul的一个基本使用。
构建网关
网关的构建我们通过下面三个步骤来实现。
1.创建Spring Boot工程并添加依赖
首先我们创建一个普通的Spring Boot工程名为api-gateway,然后添加相关依赖,这里我们主要添加两个依赖spring-cloud-starter-zuul和spring-cloud-starter-eureka,spring-cloud-starter-zuul依赖中则包含了ribbon、hystrix、actuator等,如下:
<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.5.7.RELEASE</version> <relativePath/> <!-- lookup parent from repository --> </parent> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding> <java.version>1.8</java.version> <spring-cloud.version>Dalston.SR3</spring-cloud.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zuul</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-eureka</artifactId> </dependency> </dependencies> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>${spring-cloud.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>
2.添加注解
然后在入口类上添加@EnableZuulProxy注解表示开启Zuul的API网关服务功能,如下:
@SpringBootApplication @EnableZuulProxy public class ApiGatewayApplication { public static void main(String[] args) { SpringApplication.run(ApiGatewayApplication.class, args); } }
3.配置路由规则
application.properties文件中的配置可以分为两部分,一部分是Zuul应用的基础信息,还有一部分则是路由规则,如下:
# 基础信息配置 spring.application.name=api-gateway server.port=2006 # 路由规则配置 zuul.routes.api-a.path=/api-a/** zuul.routes.api-a.serviceId=feign-consumer # API网关也将作为一个服务注册到eureka-server上 eureka.client.service-url.defaultZone=http://localhost:1111/eureka/
我们在这里配置了路由规则所有符合/api-a/**的请求都将被转发到feign-consumer服务上,至于feign-consumer服务的地址到底是什么则由eureka-server去分析,我们这里只需要写上服务名即可。以上面的配置为例,如果我请求 http://localhost:2006/api-a/hello1 接口则相当于请求 http://localhost:2005/hello1 (我这里feign-consumer的地址为 http://localhost:2005 ),我们在路由规则中配置的api-a是路由的名字,可以任意定义,但是一组path和serviceId映射关系的路由名要相同。
OK,做好这些之后,我们依次启动我们的eureka-server、provider和feign-consumer,然后访问如下地址 http://localhost:2006/api-a/hello1 ,访问结果如下:
看到这个效果说明我们的API网关服务已经构建成功了,我们发送的符合路由规则的请求自动被转发到相应的服务上去处理了。
请求过滤
构建好了网关,接下来我们就来看看如何利用网关来实现一个简单的权限验证。这里就涉及到了Spring Cloud Zuul中的另外一个核心功能:请求过滤。请求过滤有点类似于Java中Filter过滤器,先将所有的请求拦截下来,然后根据现场情况做出不同的处理,这里我们就来看看Zuul中的过滤器要如何使用。很简单,两个步骤:
1.定义过滤器
首先我们定义一个过滤器继承自ZuulFilter,如下:
public class PermisFilter extends ZuulFilter { @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(); String login = request.getParameter("login"); if (login == null) { ctx.setSendZuulResponse(false); ctx.setResponseStatusCode(401); ctx.addZuulResponseHeader("content-type","text/html;charset=utf-8"); ctx.setResponseBody("非法访问"); } return null; } }
关于这个类我说如下几点:
1.filterType方法的返回值为过滤器的类型,过滤器的类型决定了过滤器在哪个生命周期执行,pre表示在路由之前执行过滤器,其他可选值还有post、error、route和static,当然也可以自定义。
2.filterOrder方法表示过滤器的执行顺序,当过滤器很多时,这个方法会有意义。
3.shouldFilter方法用来判断过滤器是否执行,true表示执行,false表示不执行,在实际开发中,我们可以根据当前请求地址来决定要不要对该地址进行过滤,这里我直接返回true。
4.run方法则表示过滤的具体逻辑,假设请求地址中携带了login参数的话,则认为是合法请求,否则就是非法请求,如果是非法请求的话,首先设置ctx.setSendZuulResponse(false);表示不对该请求进行路由,然后设置响应码和响应值。这个run方法的返回值在当前版本(Dalston.SR3)中暂时没有任何意义,可以返回任意值。
2.配置过滤器Bean
然后在入口类中配置相关的Bean即可,如下:
@Bean PermisFilter permisFilter() { return new PermisFilter(); }
此时,如果我们访问 http://localhost:2006/api-a/hello1 ,结果如下:
如果给请求地址加上login参数,则结果如下:
总结
到这里小伙伴们应该已经见识到Spring Cloud Zuul的强大之处了吧,API网关作为系统的的统一入口,将微服务中的内部细节都屏蔽掉了,而且能够自动的维护服务实例,实现负载均衡的路由转发,同时,它提供的过滤器为所有的微服务提供统一的权限校验机制,使得服务自身只需要关注业务逻辑即可。
Zuul的入门知识我们就先介绍到这里,小伙伴们有问题欢迎留言讨论。以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持小牛知识库。
本文向大家介绍浅谈SpringCloud之zuul源码解析,包括了浅谈SpringCloud之zuul源码解析的使用技巧和注意事项,需要的朋友参考一下 zuul各版本实现存在一些微小的变化,总的实现思想未改变,以spring-cloud-netflix-core-1.3.6.RELEASE为例 一、zuul的重要的初始化类 org.springframework.cloud.netflix.zuu
在微服务架构中,建议: > 客户端应用程序到API网关的通信应该是同步的(就像http上的REST一样)。 API网关到微服务的通信也应该是同步的 但是服务到服务的通信应该是异步的。 您应该尽可能遵循的另一个规则是,只使用内部服务之间的异步消息传递,只使用从客户端应用程序到前端服务(API网关加上第一级微服务)的同步通信(如HTTP)。 现在,如果我理解正确的话,当用户向API gateway请求
我正在尝试构建一个微服务架构。我已经了解了API网关的一些好处,比如:负载平衡、调用多个微服务并聚合结果、缓存管理等。所以我决定将它包含在我的系统中。 我的问题是,我应该在网关层还是在每个微服务endpoint单独实现授权?例如,在网关上验证用户,并以解密的形式将用户声明传递给每个服务调用的授权逻辑。 在调用每个服务之前授权一些聚合似乎是有意义的,并且节省了处理时间。然而,授权逻辑实际上是单个服务
我们能在Spring Cloud API网关和没有服务发现的情况下生存吗?
本文向大家介绍浅谈PHP的反射API,包括了浅谈PHP的反射API的使用技巧和注意事项,需要的朋友参考一下 PHP的反射API,即在PHP运行状态下,通过分析PHP程序,可以导出对象所属的类,方法,属性,参数等信息。 如何使用反射API 示例代码 Person.php Person类,包含一个成员变量和三个成员方法 获取$student对象的方法和属性列表 ReflectionClass类报告了一
本文向大家介绍浅谈Android Service服务的高级技巧,包括了浅谈Android Service服务的高级技巧的使用技巧和注意事项,需要的朋友参考一下 1 前台服务 因为服务的优先级较低,所以当系统内存不足时,可能会回收正在后台运行的服务。如果若要避免服务被回收,可以使用前台服务。 前台服务会一直有一个图标在系统的状态栏中显示,下拉状态栏可以看到更加详细的信息,类似于消息通知效果。 在此构