Zuul详解与实例

浅浅的花香味﹌ 2022-01-23 03:45 338阅读 0赞

前言

  1. 介绍完分布式配置中心,结合前面的文章。我们已经有了一个微服务的框架了,可以对外提供api接口服务了。但现在试想一下,在微服务框架中,每个对外服务都是独立部署的,对外的api或者服务地址都不是不尽相同的。对于内部而言,很简单,通过注册中心自动感知即可。但我们大部分情况下,服务都是提供给外部系统进行调用的,不可能同享一个注册中心。同时一般上内部的微服务都是在内网的,和外界是不连通的。而且,就算我们每个微服务对外开放,对于调用者而言,调用不同的服务的地址或者参数也是不尽相同的,这样就会造成消费者客户端的复杂性,同时想想,可能微服务可能是不同的技术栈实现的,有的是`http``rpc`或者`websocket`等等,也会进一步加大客户端的调用难度。所以,**一般上都有会有个api网关,根据请求的url不同,路由到不同的服务上去,同时入口统一了,还能进行统一的身份鉴权、日志记录、分流等操作**。接下来,我们就来了解今天要讲解的`路由服务:zuul`

为什么要使用微服务网关

  1. 简单来说,微服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中,除了具备服务路由、均衡负载功能之外,它还具备了权限控制等功能。

在未加入网关时,一般上会在服务外网架设一个负载均衡,如nginx等。此时,微服务的组成为:

20181015104055_784.jpg

  1. 此时,对于`Open Service`而言可能需要提供权限控制等和业务无关的能力,这样本身就破坏了微服务服务单一的原则。所以,一般上在`Open Service`之上,还有一层服务提供诸如通用的权限校验、参数校验等功能,此服务就是**网关**了。之后,对于内部微服务而言,只需要关系各自微服务提供的业务功能即可,无需去关心其他非业务相关的功能。

API网关是什么

API网关可以提供一个单独且统一的API入口用于访问内部一个或多个API。简单来说嘛就是一个统一入口,比如现在的支付宝或者微信的相关api服务一样,都有一个统一的api地址,统一的请求参数,统一的鉴权。

客户端和服务端直连的弊端

  • 客户端会对此请求不同的微服务,增加客户端复杂性
  • 存在跨域请求时,需要进行额外处理
  • 认证服务,每个服务需要独立认证
  • UI端和微服务耦合

Zuul介绍和使用

ZuulNetflix开源的微服务网关,可以和EurekaRibbonHystrix等组件配合使用,Spring CloudZuul进行了整合与增强,Zuul的主要功能是路由转发过滤器

Zuul基于JVM的路由器和服务器端负载均衡器。同时,Zuul的规则引擎允许规则和过滤器基本上用任何JVM语言编写,内置支持JavaGroovy。这个功能,就可以实现动态路由的功能了。当需要添加某个新的对外服务时,一般上不停机更新是通过数据缓存配置或者使用Groovy进行动态路由的添加的。

Zuul的核心一系列的过滤器:

  • 身份认证与安全:识别每个资源的验证要求,并拒绝那些与要求不符的请求。
  • 审查与监控:在边缘位置追踪有意义的数据和统计结果,从而带来精确的生产视图。
  • 动态路由:动态地将请求路由到不同的后端集群。
  • 压力测试:逐渐增加指向集群的流量,以了解性能。
  • 负载分配:为每一种负载类型分配对应容量,并启用超出限定值的请求。
  • 静态响应处理:在边缘位置直接建立部分相应,从而避免其转发到内部集群。

加入Zuul网关后:

watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70

Zuul实践

  • 一个服务注册中心,EUREKASERVER,端口为5555;
  • HELLOSERVER工程跑了三个实例,端口分别为5556、5557、5558,分别向服务注册中心注册;
  • SERVICE-RIBBON端口为5560,向服务注册中心注册;
  • SERVICE_FEIGN端口为5565,向服务注册中心注册;

1、加入pom依赖

  1. <!-- zuul 依赖 -->
  2. <dependency>
  3. <groupId>org.springframework.cloud</groupId>
  4. <artifactId>spring-cloud-starter-zuul</artifactId>
  5. </dependency>
  6. <!-- eureka client 依赖 -->
  7. <dependency>
  8. <groupId>org.springframework.cloud</groupId>
  9. <artifactId>spring-cloud-starter-eureka</artifactId>
  10. </dependency>

注意:这里的Eureka不是必须的。在没有注册中心的情况下,也是可以进行zuul使用的。

  1. server:
  2. port: 5580 #端口号
  3. spring:
  4. application:
  5. name: service-zuul #服务注册中心测试名
  6. zuul:
  7. #ignored-services: microservicecloud-dept //外部通过微服务应用不可以访问
  8. prefix: /atguigu //添加前缀
  9. ignored-services: "*" //忽略所有的
  10. routes:
  11. api-a: #可以随便写,在zuul上面唯一即可;当这里的值=service-id时,service-id可以不写。
  12. path: /ribbon/**
  13. serviceId: service-ribbon #如果是/ribbon/**路径下的请求,则跳转到service-ribbon
  14. api-b:
  15. path: /feign/**
  16. serviceId: service-feign #如果是/feign/**路径下的请求,则跳转到service-feign
  17. eureka:
  18. client:
  19. serviceUrl:
  20. defaultZone: http://localhost:5555/eureka/ #服务注册中心

友情提示: 默认情况下:Zuul代理所有注册到EurekaServer的微服务,路由规则: `http://ZUUL_HOST:ZUUL_PORT/微服务实例名(serverId)/`转发至serviceId对应的微服务。**

2.启动类加入@EnableZuulProxy注解,声明一个Zuul代理。

  1. @EnableEurekaClient
  2. @EnableZuulProxy
  3. @SpringBootApplication
  4. public class SpringcloudzuulApplication {
  5. public static void main(String[] args) {
  6. SpringApplication.run(SpringcloudzuulApplication.class, args);
  7. }
  8. @Bean
  9. public AccessFilter accessFilter() {
  10. return new AccessFilter();
  11. }
  12. }
  13. 首先指定服务注册中心的地址为http://localhost:5555/eureka/;Zuul服务端口为5580,服务名为service-zuul;以/ribbon/ 开头的请求都转发给service-ribbon服务;以/feign/开头的请求都转发给service-feign服务。

映射规则:

SouthEast

我们可以通过下表中的示例来进一步理解这三个通配符的含义并进行参考使用。

SouthEast 1

3、过滤器类

  1. public class AccessFilter extends ZuulFilter {
  2. private static Logger log = LoggerFactory.getLogger(AccessFilter.class);
  3. @Override
  4. public String filterType() {
  5. return FilterConstants.PRE_TYPE;
  6. }
  7. @Override
  8. public int filterOrder() {
  9. return 0;
  10. }
  11. @Override
  12. public boolean shouldFilter() {
  13. return true;
  14. }
  15. @Override
  16. public Object run() {
  17. //获取上下文
  18. RequestContext ctx = RequestContext.getCurrentContext();
  19. //获取Request
  20. HttpServletRequest request = ctx.getRequest();
  21. //获取请求参数accessToken
  22. String accessToken = request.getParameter("accessToken");
  23. //使用String工具类
  24. if (StringUtils.isBlank(accessToken)) {
  25. log.warn("accessToken is empty");
  26. ctx.setSendZuulResponse(false); //进行拦截
  27. ctx.setResponseStatusCode(401);
  28. try {
  29. ctx.getResponse().getWriter().write("accessToken is empty");
  30. } catch (Exception e) {
  31. }
  32. return null;
  33. }
  34. log.info("access is ok");
  35. return null;
  36. }
  37. }
  • filterType: 过滤器的类型,它决定过滤器在请求的哪个生命周期中执行。这里定义为pre,代表会在请求被路由之前执行。有前置、后置和路由过滤器。pre:可以在请求被路由之前调用。routing: 路由请求时被调用。post:在routing和error过滤器之后被调用。error:处理请求时发生错误时被调用
  • filterOrder: 过滤器的执行顺序。当请求在一个阶段中存在多个过滤器时,需要根据该方法返回的值来依次执行。
  • shouldFilter: 判断该过滤器是否需要被执行。这里我们直接返回了true,因此该过滤器对所有请求都会生效。实际运用中我们可以利用该函数来指定过滤器的有效范围。
  • run: 过滤器的具体逻辑。这里我们通过ctx.setSendZuulResponse(false)令zuul过滤该请求,不对其进行路由,然后通过ctx.setResponseStatusCode(401)设置了其返回的错误码,当然也可以进 一步优化我们的返回,比如,通过ctx.setResponseBody(body)对返回的body内容进行编辑等。

路由请求生命周期

  1. 外部http请求到达api网关服务的时候,首先它会进入第一个阶段pre,在这里它会被pre类型的过滤器进行处理。该类型过滤器的主要目的是在进行请求路由之前做一些前置加工,比如请求的校验等。在完成了pre类型的过滤器处理之后,请求进入第二个阶段routing,也就是之前说的路由请求转发阶段,请求将会器处理。这里的具体处理内容就是将外部请求转发到具体服务实例上去的过程,当服务实例请求结果都返回之后,routing阶段完成,请求进入第三个阶段post。此时请求将会被post类型的过滤器处理,这些过滤器在处理的时候不仅可以获取到请求信息,还能获取到服务实例的返回信息,所以在post类型的过滤器中,我们可以对处理结果进行一些加工或转换等内容。另外,还有一个特殊的阶段error,该阶段只有在上述三个阶段中发生异常的时候才会触发,但是它的最后流向还是post类型的过滤器,因为它需要通过post过滤器将最终结果返回给请求客户端(对于error过滤器的处理,在spring cloud zuul的过滤链中实际上有一些不同)。

watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 1

4、测试

(1)访问:http://localhost:5555/

watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 2

(2)访问:http://localhost:5580/ribbon/hello

20190602110304872.png

(3)访问:http://localhost:5580/ribbon/hello?accessToken=ribbon

20190602110313489.png

(4)访问:http://localhost:5580/feign/hello

20190602110324740.png

(5)访问:http://localhost:5580/feign/hello?accessToken=feign

SouthEast 2

通过以上的测试,可以得出Zuul的路由和过滤都起作用了。

参考文章:

https://blog.csdn.net/smartdt/article/details/79043282

发表评论

表情:
评论列表 (有 0 条评论,338人围观)

还没有评论,来说两句吧...

相关阅读

    相关 SCTP协议详解实例

    2016-03-31 18:24 1666人阅读 1.SCTP是什么? 只要是接触过编程的人,当你问他传输层都有哪些协议?我想几乎很多人会说TCP,IP协议而很少有人知

    相关 SpringCloudzuul

    微服务的网关学习: 简介 Zuul包含了对请求的路由和过滤两个最主要的功能: 其中路由功能负责将外部请求转发到具体的微服务实例上,是实现外部访问统一入口的基础而过

    相关 JWTZuul

    非对称加密 加密技术是对信息进行编码和解码的技术,编码是把原来可读信息(又称明文)译成代码形式(又称密文),其逆过程就是解码(解密),加密技术的要点是加密算法,加密算法可

    相关 Hystrix详解实例

    引言         首先,之所以谈这个话题呢,是发现现在很多人对微服务的设计缺乏认识,所以写一篇扫盲文。当然,考虑到目前大多微服务的文章都是口水文,烟哥争取将实现方式讲

    相关 Zuul详解实例

    前言        介绍完分布式配置中心,结合前面的文章。我们已经有了一个微服务的框架了,可以对外提供api接口服务了。但现在试想一下,在微服务框架中,每个对外服务都是独

    相关 Ribbon详解实例

            Ribbon是一个为客户端提供负载均衡功能的服务,它内部提供了一个叫做ILoadBalance的接口代表负载均衡器的操作,比如有添加服务器操作、选择服务器操作、

    相关 Zuul过滤器详解

    Zuul过滤器 在Spring Cloud Zuul中实现的过滤器必须包含4个基本特征:过滤类型、执行顺序、执行条件、具体操作。这些元素看起来非常熟悉,实际上它就是Zuu