spring cloud 使用Zuul 实现API网关服务问题

通过前面几次的分享,我们了解了微服务架构的几个核心设施,通过这些组件我们可以搭建简单的微服务架构系统。比如通过Spring Cloud Eureka搭建高可用的服务注册中心并实现服务的注册和发现;

通过Spring Cloud Ribbon或Feign进行负载均衡;通过Spring Cloud Hystrix进行服务容错保护以避免故障蔓延。微服务搭建好了之后我们肯定会提供给外部系统一些统一的RESTFul API服务接口进行调用,

但是当外部系统调用我们的RESTful API的时候,怎么确定它需要的功能具体是哪个服务提供的呢?这个就涉及到一个路由规则和服务实例列表的维护问题。

这就引入了我们今天的主角--Spring Cloud Zuul,它是基于Netflix Zuul实现的API网关组件。它可以解决两个大问题:

  • 就是我们上面提到的路由规则和服务实例的维护问题
  • 对于一些校验(比如登录校验等)冗余问题。 按照我们的习惯的做法,是在每个服务中都需要加入这些校验,但是这样会导致代码冗余并且维护也比较麻烦,有了Spring Cloud Zuul这个网关服务之后,我们可以将这些共通的校验放到网关里面统一维护。

好,接下来我们就来看下怎么实现这个网关服务。

一、构建网关,配置路由

这里我们还是需要使用到前面的hello-service和feign-consumer服务。我们之前把feign-consumer作为服务消费者,但是别忘了在eureka体系里面,每个服务既是服务提供者又是服务消费者,所以feign-consumer也是一个服务提供者,并且http://localhost:9001/feign-consumer等接口就是它提供的服务。

接下来我们构建一个网关服务,代码结构如下:

代码实现步骤:

新建maven工程api-gateway

修改POM文件

<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">
 <modelVersion>4.0.0</modelVersion>
 <groupId>com.sam</groupId>
 <artifactId>api-gateway</artifactId>
 <version>0.0.1-SNAPSHOT</version>
 <parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>1.5.1.RELEASE</version>
 </parent>
 <properties>
  <javaVersion>1.8</javaVersion>
 </properties>
 <!-- 使用dependencyManagement进行版本管理 -->
 <dependencyManagement>
  <dependencies>
   <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-dependencies</artifactId>
    <version>Camden.SR6</version>
    <type>pom</type>
    <scope>import</scope>
   </dependency>
  </dependencies>
 </dependencyManagement>
 <dependencies>
  <!-- 引入zuul依赖 , 它依赖了spring-boot-starter-actuator/spring-boot-starter-hystrix/spring-boot-starter-ribbon-->
  <dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-zuul</artifactId>
  </dependency>
 </dependencies>
</project>

新建启动类

/**
 * @EnableZuulProxy 开启Zuul 的API网关服务功能
 *
 */
@EnableZuulProxy
@SpringCloudApplication
public class GateWayApp {

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

新建application.properties

server.port=5555
spring.application.name=api-gateway
#增加路由规则的配置
#通过zuul.routes.<route>.path和zuul.routes.<route>.url进行配置,<route>为路由的名字,可以任意指定,但是一组path和url的路由名要相同
#如下面的例子:所有满足/api-a/** 规则的访问都会被路由转发到//localhost:9001的地址
#也就是说,我们访问http://localhost:5555/api-a/hello的时候,API网关服务就会将该请#求路由到 http://localhost:9001/hello提供的微服务接口上
zuul.routes.api-a.path=/api-a/**
zuul.routes.api-a.url=http://localhost:9001
zuul.routes.api-b.path=/api-b/**
zuul.routes.api-b.url=http://localhost:9090

测试,启动eureka、hello-service、feign-consumer以及本次新加的api-gateway服务,然后访问http://localhost:5555/api-a/feign-consumer

成功访问到了feign-consumer的服务接口--feign-consonsumer。

以上步骤实现了传统路由的配置,这种配置有个大的缺点,就是需要手工在application.properties文件中进行路由规则的配置,当服务很多的时候,维护工作量就会很大。为了减小维护成本,还有另外一种路由--面向服务的路由。

二、面向服务的路由

Spring Cloud Zuul和Eureka进行整合,我们可以让路由的path不是映射具体的url,而是具体的某个服务,而服务的url则交给Eureka服务发现机制自动维护,这类路由就是面向服务的路由。具体代码配置如下:

修改POM文件,引入Eureka依赖

<!-- 引入eureka依赖 -->
  <dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-eureka</artifactId>
  </dependency>

修改application.properties配置文件

server.port=5555
spring.application.name=api-gateway
zuul.routes.api-a.path=/api-a/**
#这里用serviceId代替url,用服务名代替ip+端口号
zuul.routes.api-a.serviceId=hello-service
eureka.client.service-url.defaultZone=http://localhost:1111/eureka

注意:zuul.routes.api-a.url=hello-service也能实现功能,但是它不能进行正常的负载均衡和容错保护。

测试,访问http://localhost:5555/api-a/hello

访问成功。

 三、服务路由的默认规则

在面向服务的路由中,由于<route>名字是随意起的,那么是不是可以这样:

zuul.routes.hello-service.path=/hello-service/**
zuul.routes.hello-service.serviceId=hello-service

<route>名字就是服务名,其实在实际的应用中,我们往往就是这样命名的。如果有这样的规则的话,那Zuul就可以帮我们默认实现这样的功能,进一步省去了配置的麻烦。

我们来做个实验,将配置文件改为:

server.port=5555
spring.application.name=api-gateway
eureka.client.service-url.defaultZone=http://localhost:1111/eureka

然后页面访问验证

访问成功。

但是由于默认情况下,Eureka上的服务都会被Zuul创建默认的映射关系来进行路由,使得我们不想对外开放的服务也被外部访问到,这个时候可以通过配置zuul.ignored-services来进行配置不需要自动创建路由的规则。当zuul.ignored-services=*的时候,所有的服务都不会自动创建路由规则,这个时候需要通过前面的配置进行相关路由配置了。

================华丽的分割线===================

前面说了那么多都是围绕一个问题展开的:路由规则和服务实例的维护问题,那么怎么解决第二个问题(校验冗余问题)呢?

 四、请求过滤

为了在API网关中实现对客户端请求的校验,我们可以通过过滤器来实现对请求的拦截和过滤,实现方法比较简单,只需要继承ZuulFilter抽象类并实现其四个方法就行了。

修改api-gateway:

新增过滤器类

/**
 * 继承ZuulFilter,并且实现其4个接口
 *
 * 用来进行请求过滤
 *
 */
public class AccessFilter extends ZuulFilter {
 Logger logger = LoggerFactory.getLogger(AccessFilter.class);
 /*
  * shouldFilter 判断该过滤器是否需要被执行
  *
  * 这里直接返回true,表示该过滤器对所有请求都会生效。
  * 实际运用中我们可以利用该函数指定过滤器的有效范围
  */
 @Override
 public boolean shouldFilter() {
  return true;
 }
 /*
  * 过滤器的具体逻辑
  *
  * 这里我们通过ctx.setSendZuulResponse(false)让zuul过来请求,不对其进行路由
  * 然后通过ctx.setResponseStatusCode(401)设置了返回的错误码
  *
  */
 @Override
 public Object run() {
  RequestContext context = RequestContext.getCurrentContext();
  HttpServletRequest request = context.getRequest();
  Object accessToken = request.getParameter("accessToken");
  logger.info("send {} request to {}", request.getMethod(),request.getRequestURL().toString());
  if(accessToken == null) {
   context.setSendZuulResponse(false);
   context.setResponseStatusCode(401);
  }
  return null;
 }
 /* filterType 返回过滤器类型
  * 他决定了过滤器在请求的哪个生命周期中执行。这里定义为pre,代表会在请求被路由前执行。
  *
  * pre:请求执行之前filter
  * route: 处理请求,进行路由
  * post: 请求处理完成后执行的filter
  * error:出现错误时执行的filter
  */
 @Override
 public String filterType() {
  return "pre";
 }
 /*
  * filterOrder 返回过滤器的执行顺序
  *
  * 当请求在一个阶段有多个过滤器是,需要根据该方法的返回值来一次执行
  *
  */
 @Override
 public int filterOrder() {
  return 0;
 }
}

修改启动类

/**
 * @EnableZuulProxy 开启Zuul 的API网关服务功能
 *
 */
@EnableZuulProxy
@SpringCloudApplication
public class GateWayApp {
 //追加bean的是实现
 @Bean
 public AccessFilter accessFilter() {
  return new AccessFilter();
 }

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

测试

)访问http://localhost:5555/hello-service/hello,访问失败

)访问http://localhost:5555/hello-service/hello?accessToken=token,正常访问

修改后的代码结构:

 五、拓展延伸

其实路由功能在真正运行时,他的路由映射和请求转发都是由几个不同的过滤器完成的。

路由映射主要通过pre类型的过滤器完成,他将请求路径与配置的路由规则进行匹配,找到需要转发的目标地址。

而请求转发的部分则是由route类型的过滤器完成的,对pre类型过滤器获取的路由地址进行转发。

所以,过滤器可以说是Zuul实现API网关功能最为核心的部件,每一个进入Zuul的HTTP请求都会经过一系列的过滤器处理链得到请求响应并返回给客户端。

总结

以上所述是小编给大家介绍的spring cloud 使用Zuul 实现API网关服务问题,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对我们网站的支持!

(0)

相关推荐

  • 详解spring cloud构建微服务架构的网关(API GateWay)

    前言 在我们前面的博客中讲到,当服务A需要调用服务B的时候,只需要从Eureka中获取B服务的注册实例,然后使用Feign来调用B的服务,使用Ribbon来实现负载均衡,但是,当我们同时向客户端暴漏多个服务的时候,客户端怎么调用我们暴漏的服务了,如果我们还想加入安全认证,权限控制,过滤器以及动态路由等特性了,那么就需要使用Zuul来实现API GateWay了,下面,我们先来看下Zuul怎么使用. 一.加入Zuul的依赖 <dependency> <groupId>org.spri

  • Spring Cloud入门教程之Zuul实现API网关与请求过滤

    简介 Zuul是Netflix基于JVM的路由器和服务器端负载均衡器.最常用的场景是替换Nginx反向代理后台微服务供前端UI访问. Zuul使用Ribbon来定位一个通过发现转发的实例,所有请求都以hystrix命令执行,所以故障将显示在Hystrix指标中. 注:Zuul不包括发现客户端,因此对于基于服务ID的路由,需要在类路径中提供其中一个路由 Zuul是Spring Cloud提供的api网关和过滤组件,它提供如下功能: 认证 过滤 压力测试 Canary测试 动态路由 服务迁移 负载均

  • 浅谈Spring Cloud中的API网关服务Zuul

    到目前为止,我们Spring Cloud中的内容已经介绍了很多了,Ribbon.Hystrix.Feign这些知识点大家都耳熟能详了,我们在前文也提到过微服务就是把一个大的项目拆分成很多小的独立模块,然后通过服务治理让这些独立的模块配合工作等.那么大家来想这样两个问题:1.如果我的微服务中有很多个独立服务都要对外提供服务,那么对于开发人员或者运维人员来说,他要如何去管理这些接口?特别是当项目非常大非常庞杂的情况下要如何管理?2.权限管理也是一个老生常谈的问题,在微服务中,一个独立的系统被拆分成很

  • spring cloud 使用Zuul 实现API网关服务问题

    通过前面几次的分享,我们了解了微服务架构的几个核心设施,通过这些组件我们可以搭建简单的微服务架构系统.比如通过Spring Cloud Eureka搭建高可用的服务注册中心并实现服务的注册和发现: 通过Spring Cloud Ribbon或Feign进行负载均衡:通过Spring Cloud Hystrix进行服务容错保护以避免故障蔓延.微服务搭建好了之后我们肯定会提供给外部系统一些统一的RESTFul API服务接口进行调用, 但是当外部系统调用我们的RESTful API的时候,怎么确定它

  • Spring Cloud Gateway替代zuul作为API网关的方法

    目录 第一,pom文件 第二,项目结构 第三,项目代码和运行截图 运行效果图 参考文档: 本文简要介绍如何使用Spring Cloud Gateway 作为API 网关(不是使用zuul作为网关),关于Spring Cloud Gateway和zuul的性能比较本文不再赘述,基本可以肯定Spring Cloud Finchley版本的gateway比zuul 1.x系列的性能和功能整体要好. 特别提醒:Spring Cloud Finchley版本中,即使你引入了spring-cloud-sta

  • Spring Cloud基于zuul实现网关过程解析

    这篇文章主要介绍了Spring Cloud基于zuul实现网关过程解析,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 利用zuul网关统一向外暴露接口 1.新建项目 spring-zuul 2.引入pom <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-zuu

  • 详解Spring Cloud Netflix Zuul中的速率限制

    Spring Cloud Netflix Zuul是一个包含Netflix Zuul的 开源网关.它为Spring Boot应用程序添加了一些特定功能.不幸的是,开箱即用不提供速率限制. 除了Spring Cloud Netflix Zuul依赖项之外,我们还需要将Spring Cloud Zuul RateLimit 添加到我们的应用程序的pom.xml中: <dependency> <groupId>org.springframework.cloud</groupId&g

  • spring cloud gateway整合sentinel实现网关限流

    这篇文章主要介绍了spring cloud gateway整合sentinel实现网关限流,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 说明: sentinel可以作为各微服务的限流,也可以作为gateway网关的限流组件. spring cloud gateway有限流功能,但此处用sentinel来作为替待. 说明:sentinel流控可以放在gateway网关端,也可以放在各微服务端. 1,以父工程为基础,创建子工程 2,添加pom依赖

  • Spring Cloud详解实现声明式微服务调用OpenFeign方法

    目录 OpenFeign介绍 项目实战 创建项目 启动项目验证 总结 OpenFeign介绍 一开始,我们使用原生的 DiscoveryClient 发现服务和使用RestTemplate进行服务间调用,然后我们自己手动开发了一个负载均衡组件,最后介绍了负载均衡组件Ribbon.每个章节调用服务的方式也有所不同,共同点则是都是基于RestTemplate 来实现的,想必大家都会觉得这样的调用方式有点麻烦,每次调用前都要写请求协议,服务名称,接口名称.组装参数.处理响应数据类型,这些都是一些重复的

  • 详解Spring Cloud Alibaba Sidecar多语言微服务异构

    自 Spring Cloud Alibaba 2.1.1 版本后增加了 spring-cloud-alibaba-sidecar 模块作为作为一个代理的服务来间接性的让其他语言可以使用spring cloud alibaba等相关组件.通过与网关的来进行路由的映射,从而可以做到服务的获取,然后可以使用Ribbon间接性调用. 如上图, Spring Cloud 应用 请求 sidercar 然后转发给其他语言的模块,优势是对于异构服务代码 零侵入,不需要直接根据 nacos 或其他注册中心 ap

  • spring cloud 使用Hystrix 实现断路器进行服务容错保护的方法

    在微服务中,我们将系统拆分为很多个服务单元,各单元之间通过服务注册和订阅消费的方式进行相互依赖.但是如果有一些服务出现问题了会怎么样? 比如说有三个服务(ABC),A调用B,B调用C.由于网络延迟或C本身代码有问题导致B迟迟得不到回应,这样B调用C的请求就会被挂起,等待. 在高并发的访问的情况下,这些挂起的线程得不到释放,使后续的请求阻塞,最终导致B也挂掉了.依次类推,A可能也会挂掉,进而使整个系统全部崩溃. 为了解决整个问题,Spring Cloud 使用Hystrix进行服务容错保护,包括断

随机推荐