zuul简单使用

zuul路由的几个配置参数
1.静态路由
zuul:
routes:
myroute1:
path: /mypath/**
url: http://localhost:8080 (注意这里url要http://开头)
2.静态路由+ribbon负载均衡/故障切换
zuul:
routes:
myroutes1:
path: /mypath/**
serviceId: myserverId
myserverId:
ribbon:
listOfServers: localhost:8080, localhost:8081
ribbon:
eureka:
enabled: false
3.动态路由+ribbon负载均衡/故障切换
zuul:
routes:
myroutes1:
path: /mypath/**
serviceId: myserviceId
eureka:
client:
serviceUrl:
defaultZne:xxx
4.路由匹配的一些配置
stripPrefix=true,转发会过滤掉前缀。
path: /myusers/**,默认时转发到服务的请求是/**,如果stripPrefix=false,转发的请求是/myusers/**
zuul.prefix=/api 会对所有的path增加一个/api前缀

ignoredPatterns: /**/admin/** 过滤掉匹配的url
route:
users: /myusers/** 会匹配所有/myusers/**的url,但由于ignoredPatterns, /myusers/**/admin/**的请求不会被转发,而是直接由zuul里的接口接收

匹配顺序
path:/myusers/**
path:/** 如果是在application.yml中配置的,那么会优先匹配/myusers/**
但如果是applicaiton.properties配置的,那么可能导致/myusers/**被/**覆盖
ignored-Services: ‘*‘ 对于自动发现的services,除了route中明确指定的,其他都会被忽略
5.请求头过滤
route.sensitiveHeaders: Cookie,Set-Cookie,Authorization
默认就有这三个请求头,意思是不向下游转发请求这几个头
zuul.ignoredHeaders 是一个全局设置,而route.sensitiveHeaders是局部设置

zuul过滤器
标准的zuul过滤器有4中,分别对应一次路由转发的几个关键点;
pre: 在路由转发之前起作用
routing: 在路由时其作用
post: 在把结果返回给浏览器时起作用
error: 在整个路由阶段,出现异常时起作用

如果要分析前端传来的参数,验证前端身份等对前端参数的操作,显然是用pre过滤器
如果是要对返回给前端的结果进行操作或者分析,显然是用post过滤器

编写自定义路由器

public class MyFilter extends ZuulFilter{
filterType() 重写,返回这个过滤器的类型
filterOrder() 重写,返回这个过滤器在过滤器链的顺序
shouldFilter() true启动
run() 具体逻辑
}
然后向Spring注入这个Bean就行了

时间: 2024-10-12 09:08:14

zuul简单使用的相关文章

zuul源码分析-探究原生zuul的工作原理

前提 最近在项目中使用了SpringCloud,基于zuul搭建了一个提供加解密.鉴权等功能的网关服务.鉴于之前没怎么使用过Zuul,于是顺便仔细阅读了它的源码.实际上,zuul原来提供的功能是很单一的:通过一个统一的Servlet入口(ZuulServlet,或者Filter入口,使用ZuulServletFilter)拦截所有的请求,然后通过内建的com.netflix.zuul.IZuulFilter链对请求做拦截和过滤处理.ZuulFilter和javax.servlet.Filter的

跟我学SpringCloud | 第九篇:服务网关Zuul初

SpringCloud系列教程 | 第九篇:服务网关Zuul初探 前面的文章我们介绍了,Eureka用于服务的注册于发现,Feign支持服务的调用以及均衡负载,Hystrix处理服务的熔断防止故障扩散,Spring Cloud Config服务集群配置中心,似乎一个微服务框架已经完成了. 我们还是少考虑了一个问题,外部的应用如何来访问内部各种各样的微服务呢?在微服务架构中,后端服务往往不直接开放给调用端,而是通过一个API网关根据请求的url,路由到相应的服务.当添加API网关后,在第三方调用端

微服务SpringCloud之服务网关zuul一

前面学习了Eureka.Feign.Hystrix.Config,本篇来学习下API网关zuul.在微服务架构中,后端服务往往不直接开放给调用端,而是通过一个API网关根据请求的url,路由到相应的服务.当添加API网关后,在第三方调用端和服务提供方之间就创建了一面墙,这面墙直接与调用方通信进行权限控制,后将请求均衡分发给后台服务端. 为什么需要API Gateway 1.简化客户端调用复杂度 在微服务架构模式下后端服务的实例数一般是动态的,对于客户端而言很难发现动态改变的服务实例的访问地址信息

史上最简单的SpringCloud教程 | 第五篇: 路由网关(zuul)(Finchley版本)

在微服务架构中,需要几个基础的服务治理组件,包括服务注册与发现.服务消费.负载均衡.断路器.智能路由.配置管理等,由这几个基础组件相互协作,共同组建了一个简单的微服务系统.一个简答的微服务系统如下图: 注意:A服务和B服务是可以相互调用的,作图的时候忘记了.并且配置服务也是注册到服务注册中心的. 在Spring Cloud微服务系统中,一种常见的负载均衡方式是,客户端的请求首先经过负载均衡(zuul.Ngnix),再到达服务网关(zuul集群),然后再到具体的服.,服务统一注册到高可用的服务注册

史上最简单的SpringCloud教程 | 第五篇: 路由网关(zuul)

在微服务架构中,需要几个基础的服务治理组件,包括服务注册与发现.服务消费.负载均衡.断路器.智能路由.配置管理等,由这几个基础组件相互协作,共同组建了一个简单的微服务系统.一个简答的微服务系统如下图: 注意:A服务和B服务是可以相互调用的,作图的时候忘记了.并且配置服务也是注册到服务注册中心的. 在Spring Cloud微服务系统中,一种常见的负载均衡方式是,客户端的请求首先经过负载均衡(zuul.Ngnix),再到达服务网关(zuul集群),然后再到具体的服.,服务统一注册到高可用的服务注册

SpringCloud Zuul网关的简单理解

Zuul网关功能 请求路由.服务路由.请求过滤 请求路由 参数配置如下所示,所有能够配置path规则的请求,都会被zuul网关转发到对应的url上. zuul.routes.user-service.path=/user-service/** zuul.routes.user-service.url=http://178.69.1.39:9104/ 服务路由 参数配置如下所示,zuul会对服务user-service进行路由,所有能够配置path规则的请求,都会被zuul网关转发到serivce

笔记:Spring Cloud Zuul 快速入门

Spring Cloud Zuul 实现了路由规则与实例的维护问题,通过 Spring Cloud Eureka 进行整合,将自身注册为 Eureka 服务治理下的应用,同时从 Eureka 中获取了所有其他微服务的实例信息,这样的设计非常巧妙的将服务治理体系中维护的实例信息利用起来,使得维护服务实例的工作交给了服务治理框架自动完成,而对路由规则的维护,默认会将通过以服务名作为 ContextPath 的方式来创建路由映射,也可以做一些特别的配置,对于签名校验.登录校验等在微服务架构中的冗余问题

springCloud(13):使用Zuul构建微服务网关-简介

一.为什么要使用微服务网关 不同的微服务一般会有不同的网络地址,而外部客户端可能需要调用多个服务的接口才能完成一个业务需求.如:一个电影购票的手机APP,可能会调用多个微服务,才能完成一次购票的业务流程.如果让客户端直接与各个微服务通信,会有以下的问题: 1.客户端会多次请求不同的微服务,增加了客户端的复杂性: 2.存在跨域请求,在一定场景下处理相对复杂: 3.认证复杂,每个服务都需要独立认证: 4.难以重构,随着项目的迭代,可能需要重新划分微服务,如果客户端直接与微服务通信,那么重构将会很难实

springCloud(14):使用Zuul构建微服务网关-路由端点与路由配置详解

一.Zuul的路由端点 当@EnableZuulProxy与SpringBoot Actuator配合使用时,Zuul会暴露一个路由管理端点/routes.借助这个端点,可以方便.直观地查看以及管理Zuul的路由. /routes端点的使用非常简单,使用GET方法访问该端点,即可返回Zuul当前映射的路由列表:使用POST方法访问该端点就会强制刷新Zuul当前映射的路由列表(尽管路由会自动刷新,Spring Cloud依然提供了强制立即刷新的方式). 由于spring-cloud-starter