SpringCloud Zuul在何种情况下使用Hystrix及问题小结

首先,引入spring-cloud-starter-zuul之后会间接引入:

hystrix依赖已经引入,那么何种情况下使用hystrix呢?

在Zuul的自动配置类ZuulServerAutoConfiguration和ZuulProxyAutoConfiguration中总共会向Spring容器注入3个Zuul的RouteFilter,分别是

•SimpleHostRoutingFilter

简单路由,通过HttpClient向预定的URL发送请求

生效条件:

RequestContext.getCurrentContext().getRouteHost() != null
 ​ && RequestContext.getCurrentContext().sendZuulResponse()

1、RequestContext中的routeHost不为空,routeHost就是URL,即使用URL直连

2、RequestContext中的sendZuulResponse为true,即是否将response发送给客户端,默认为true

•RibbonRoutingFilter

使用Ribbon、Hystrix和可插入的http客户端发送请求

生效条件:

(RequestContext.getRouteHost() == null && RequestContext.get(SERVICE_ID_KEY) != null
 ​ && RequestContext.sendZuulResponse())

1、RequestContext中的routeHost为空,即URL为空

2、RequestContext中的serviceId不为空

3、RequestContext中的sendZuulResponse为true,即是否将response发送给客户端,默认为true

•SendForwardFilter

forward到本地URL

生效条件:

RequestContext.containsKey(FORWARD_TO_KEY)
 ​ && !RequestContext.getBoolean(SEND_FORWARD_FILTER_RAN, false)

1、RequestContext中包含FORWARD_TO_KEY,即URL使用 forward: 映射

2、RequestContext中SEND_FORWARD_FILTER_RAN为false,SEND_FORWARD_FILTER_RAN意为“send forward是否运行过了”,在SendForwardFilter#run()时会ctx.set(SEND_FORWARD_FILTER_RAN, true)

综上所述,在使用serviceId映射的方法路由转发的时候,会使用Ribbon+Hystrix

而哪种路由配置方式是“URL映射”,哪种配置方式又是“serviceId映射”呢?

Zuul有一个前置过滤器PreDecorationFilter用于通过RouteLocator路由定位器决定在何时以何种方式路由转发

RouteLocator是用于通过请求地址匹配到Route路由的,之后PreDecorationFilter再通过Route信息设置RequestContext上下文,决定后续使用哪个RouteFilter做路由转发

所以就引出以下问题:

•什么是Route
•RouteLocator路由定位器如何根据请求路径匹配路由
•匹配到路由后,PreDecorationFilter如何设置RequestContext请求上下文

什么是Route

我总共见到两个和Route相关的类

ZuulProperties.ZuulRoute,用于和zuul配置文件关联,保存相关信息

org.springframework.cloud.netflix.zuul.filters.Route, RouteLocator找到的路由信息就是这个类,用于路由转发
public static class ZuulRoute {
 private String id; //ZuulRoute的id
 private String path; //路由的pattern,如 /foo/**
 private String serviceId; //要映射到此路由的服务id
 private String url; //要映射到路由的完整物理URL
 private boolean stripPrefix = true; //用于确定在转发之前是否应剥离此路由前缀的标志位
 private Boolean retryable; //此路由是否可以重试,通常重试需要serviceId和ribbon
 private Set<String> sensitiveHeaders = new LinkedHashSet(); //不会传递给下游请求的敏感标头列表
 private boolean customSensitiveHeaders = false; //是否自定义了敏感头列表
}
public class Route {
 private String id;
 private String fullPath;
 private String path;
 private String location; //可能是 url 或 serviceId
 private String prefix;
 private Boolean retryable;
 private Set<String> sensitiveHeaders = new LinkedHashSet<>();
 private boolean customSensitiveHeaders;
}

可以看到org.springframework.cloud.netflix.zuul.filters.Route和ZuulProperties.ZuulRoute基本一致,只是Route用于路由转发定位的属性location根据不同的情况,可能是一个具体的URL,可能是一个serviceId

RouteLocator路由定位器如何根据请求路径匹配路由

Zuul在自动配置加载时注入了2个RouteLocator

•CompositeRouteLocator: 组合的RouteLocator,在getMatchingRoute()时会依次调用其它的RouteLocator,先找到先返回;CompositeRouteLocator的routeLocators集合中只有DiscoveryClientRouteLocator
•DiscoveryClientRouteLocator: 可以将静态的、已配置的路由与来自DiscoveryClient服务发现的路由组合在一起,来自DiscoveryClient的路由优先;SimpleRouteLocator的子类(SimpleRouteLocator 基于加载到ZuulProperties中的配置定位Route路由信息)

其中CompositeRouteLocator是 @Primary 的,它是组合多个RouteLocator的Locator,其getMatchingRoute()方法会分别调用其它所有RouteLocator的getMatchingRoute()方法,通过请求路径匹配路由信息,只要匹配到了就马上返回

默认CompositeRouteLocator混合路由定位器的routeLocators只有一个DiscoveryClientRouteLocator,故只需分析DiscoveryClientRouteLocator#getMatchingRoute(path)

//----------DiscoveryClientRouteLocator是SimpleRouteLocator子类,其实是调用的SimpleRouteLocator##getMatchingRoute(path)
@Override
public Route getMatchingRoute(final String path) {
 return getSimpleMatchingRoute(path);
}
protected Route getSimpleMatchingRoute(final String path) {
 if (log.isDebugEnabled()) {
  log.debug("Finding route for path: " + path);
 }
 // routes是保存路由信息的map,如果此时还未加载,调用locateRoutes()
 if (this.routes.get() == null) {
  this.routes.set(locateRoutes());
 }
 if (log.isDebugEnabled()) {
  log.debug("servletPath=" + this.dispatcherServletPath);
  log.debug("zuulServletPath=" + this.zuulServletPath);
  log.debug("RequestUtils.isDispatcherServletRequest()="
    + RequestUtils.isDispatcherServletRequest());
  log.debug("RequestUtils.isZuulServletRequest()="
    + RequestUtils.isZuulServletRequest());
 }
 /**
  * 下面的方法主要是先对path做微调
  * 再根据path到routes中匹配到ZuulRoute
  * 最后根据 ZuulRoute 和 adjustedPath 生成 Route
  */
 String adjustedPath = adjustPath(path);
 ZuulRoute route = getZuulRoute(adjustedPath);
 return getRoute(route, adjustedPath);
}

下面我们来看看locateRoutes()是如何加载静态的、已配置的路由与来自DiscoveryClient服务发现的路由的

//----------DiscoveryClientRouteLocator#locateRoutes() 服务发现路由定位器的locateRoutes()
@Override
protected LinkedHashMap<String, ZuulRoute> locateRoutes() {
 //保存ZuulRoute的LinkedHashMap
 LinkedHashMap<String, ZuulRoute> routesMap = new LinkedHashMap<String, ZuulRoute>();
 //调用父类SimpleRouteLocator#locateRoutes()
 //加载ZuulProperties中的所有配置文件中的路由信息
 routesMap.putAll(super.locateRoutes());
 //如果服务发现客户端discovery存在
 if (this.discovery != null) {
  //将routesMap已经存在的配置文件中的ZuulRoute放入staticServices<serviceId, ZuulRoute>
  Map<String, ZuulRoute> staticServices = new LinkedHashMap<String, ZuulRoute>();
  for (ZuulRoute route : routesMap.values()) {
   String serviceId = route.getServiceId();
   //如果serviceId为null,以id作为serviceId,此情况适合 zuul.routes.xxxx=/xxxx/** 的情况
   if (serviceId == null) {
    serviceId = route.getId();
   }
   if (serviceId != null) {
    staticServices.put(serviceId, route);
   }
  }
  // Add routes for discovery services by default
  List<String> services = this.discovery.getServices(); //到注册中心找到所有service
  String[] ignored = this.properties.getIgnoredServices()
    .toArray(new String[0]);
  //遍历services
  for (String serviceId : services) {
   // Ignore specifically ignored services and those that were manually
   // configured
   String key = "/" + mapRouteToService(serviceId) + "/**";
   //如果注册中心的serviceId在staticServices集合中,并且此路由没有配置URL
   //那么,更新路由的location为serviceId
   if (staticServices.containsKey(serviceId)
     && staticServices.get(serviceId).getUrl() == null) {
    // Explicitly configured with no URL, cannot be ignored
    // all static routes are already in routesMap
    // Update location using serviceId if location is null
    ZuulRoute staticRoute = staticServices.get(serviceId);
    if (!StringUtils.hasText(staticRoute.getLocation())) {
     staticRoute.setLocation(serviceId);
    }
   }
   //如果注册中心的serviceId不在忽略范围内,且routesMap中还没有包含,添加到routesMap
   if (!PatternMatchUtils.simpleMatch(ignored, serviceId)
     && !routesMap.containsKey(key)) {
    // Not ignored
    routesMap.put(key, new ZuulRoute(key, serviceId));
   }
  }
 }
 // 如果routesMap中有 /** 的默认路由配置
 if (routesMap.get(DEFAULT_ROUTE) != null) {
  ZuulRoute defaultRoute = routesMap.get(DEFAULT_ROUTE);
  // Move the defaultServiceId to the end
  routesMap.remove(DEFAULT_ROUTE);
  routesMap.put(DEFAULT_ROUTE, defaultRoute);
 }
 //将routesMap中的数据微调后,放到values<String, ZuulRoute>,返回
 LinkedHashMap<String, ZuulRoute> values = new LinkedHashMap<>();
 for (Entry<String, ZuulRoute> entry : routesMap.entrySet()) {
  String path = entry.getKey();
  // Prepend with slash if not already present.
  if (!path.startsWith("/")) {
   path = "/" + path;
  }
  if (StringUtils.hasText(this.properties.getPrefix())) {
   path = this.properties.getPrefix() + path;
   if (!path.startsWith("/")) {
    path = "/" + path;
   }
  }
  values.put(path, entry.getValue());
 }
 return values;
}

此方法运行后就已经加载了配置文件中所有路由信息,以及注册中心中的服务路由信息,有的通过URL路由,有的通过serviceId路由

只需根据本次请求的requestURI与 路由的pattern匹配找到对应的路由

匹配到路由后,PreDecorationFilter如何设置RequestContext请求上下文

//----------PreDecorationFilter前置过滤器
@Override
public Object run() {
 RequestContext ctx = RequestContext.getCurrentContext();
 final String requestURI = this.urlPathHelper.getPathWithinApplication(ctx.getRequest());
 Route route = this.routeLocator.getMatchingRoute(requestURI); //找到匹配的路由
 //----------------到上面为止是已经分析过的,根据requestURI找到匹配的Route信息
 // ==== 匹配到路由信息
 if (route != null) {
  String location = route.getLocation();
  if (location != null) {
   ctx.put(REQUEST_URI_KEY, route.getPath());//RequestContext设置 requestURI:路由的pattern路径
   ctx.put(PROXY_KEY, route.getId());//RequestContext设置 proxy:路由id
   //设置需要忽略的敏感头信息,要么用全局默认的,要么用路由自定义的
   if (!route.isCustomSensitiveHeaders()) {
    this.proxyRequestHelper
      .addIgnoredHeaders(this.properties.getSensitiveHeaders().toArray(new String[0]));
   }
   else {
    this.proxyRequestHelper.addIgnoredHeaders(route.getSensitiveHeaders().toArray(new String[0]));
   }
   //设置重试信息
   if (route.getRetryable() != null) {
    ctx.put(RETRYABLE_KEY, route.getRetryable());
   }
   //如果location是 http/https开头的,RequestContext设置 routeHost:URL
   //如果location是 forward:开头的,RequestContext设置 forward信息、routeHost:null
   //其它 RequestContext设置 serviceId、routeHost:null、X-Zuul-ServiceId
   if (location.startsWith(HTTP_SCHEME+":") || location.startsWith(HTTPS_SCHEME+":")) {
    ctx.setRouteHost(getUrl(location));
    ctx.addOriginResponseHeader(SERVICE_HEADER, location);
   }
   else if (location.startsWith(FORWARD_LOCATION_PREFIX)) {
    ctx.set(FORWARD_TO_KEY,
      StringUtils.cleanPath(location.substring(FORWARD_LOCATION_PREFIX.length()) + route.getPath()));
    ctx.setRouteHost(null);
    return null;
   }
   else {
    // set serviceId for use in filters.route.RibbonRequest
    ctx.set(SERVICE_ID_KEY, location);
    ctx.setRouteHost(null);
    ctx.addOriginResponseHeader(SERVICE_ID_HEADER, location);
   }
   //是否添加代理头信息 X-Forwarded-For
   if (this.properties.isAddProxyHeaders()) {
    addProxyHeaders(ctx, route);
    String xforwardedfor = ctx.getRequest().getHeader(X_FORWARDED_FOR_HEADER);
    String remoteAddr = ctx.getRequest().getRemoteAddr();
    if (xforwardedfor == null) {
     xforwardedfor = remoteAddr;
    }
    else if (!xforwardedfor.contains(remoteAddr)) { // Prevent duplicates
     xforwardedfor += ", " + remoteAddr;
    }
    ctx.addZuulRequestHeader(X_FORWARDED_FOR_HEADER, xforwardedfor);
   }
   //是否添加Host头信息
   if (this.properties.isAddHostHeader()) {
    ctx.addZuulRequestHeader(HttpHeaders.HOST, toHostHeader(ctx.getRequest()));
   }
  }
 }
 // ==== 没有匹配到路由信息
 else {
  log.warn("No route found for uri: " + requestURI);
  String fallBackUri = requestURI;
  String fallbackPrefix = this.dispatcherServletPath; // default fallback
               // servlet is
               // DispatcherServlet
  if (RequestUtils.isZuulServletRequest()) {
   // remove the Zuul servletPath from the requestUri
   log.debug("zuulServletPath=" + this.properties.getServletPath());
   fallBackUri = fallBackUri.replaceFirst(this.properties.getServletPath(), "");
   log.debug("Replaced Zuul servlet path:" + fallBackUri);
  }
  else {
   // remove the DispatcherServlet servletPath from the requestUri
   log.debug("dispatcherServletPath=" + this.dispatcherServletPath);
   fallBackUri = fallBackUri.replaceFirst(this.dispatcherServletPath, "");
   log.debug("Replaced DispatcherServlet servlet path:" + fallBackUri);
  }
  if (!fallBackUri.startsWith("/")) {
   fallBackUri = "/" + fallBackUri;
  }
  String forwardURI = fallbackPrefix + fallBackUri;
  forwardURI = forwardURI.replaceAll("//", "/");
  ctx.set(FORWARD_TO_KEY, forwardURI);
 }
 return null;
}

总结:

•只要引入了spring-cloud-starter-zuul就会间接引入Ribbon、Hystrix
•路由信息可能是从配置文件中加载的,也可能是通过DiscoveryClient从注册中心加载的
•zuul是通过前置过滤器PreDecorationFilter找到与当前requestURI匹配的路由信息,并在RequestContext中设置相关属性的,后续的Route Filter会根据RequestContext中的这些属性判断如何路由转发
•Route Filter主要使用 SimpleHostRoutingFilter 和 RibbonRoutingFilter
•当RequestContext请求上下文中存在routeHost,即URL直连信息时,使用SimpleHostRoutingFilter简单Host路由
•当RequestContext请求上下文中存在serviceId,即服务id时(可能会与注册中心关联获取服务列表,或者读取配置文件中serviceId.ribbon.listOfServers的服务列表),使用RibbonRoutingFilter,会使用Ribbon、Hystrix

总结

以上所述是小编给大家介绍的SpringCloud Zuul在何种情况下使用Hystrix,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对我们网站的支持!

(0)

相关推荐

  • 详解Spring Cloud Stream使用延迟消息实现定时任务(RabbitMQ)

    我们在使用一些开源调度系统(比如:elastic-job等)的时候,对于任务的执行时间通常都是有规律性的,可能是每隔半小时执行一次,或者每天凌晨一点执行一次.然而实际业务中还存在另外一种定时任务,它可能需要一些触发条件才开始定时,比如:编写博文时候,设置2小时之后发送.对于这些开始时间不确定的定时任务,我们也可以通过Spring Cloud Stream来很好的处理. 为了实现开始时间不确定的定时任务触发,我们将引入延迟消息的使用.RabbitMQ中提供了关于延迟消息的插件,所以本文就来具体介绍

  • 使用Servlet处理一个上传的文件

    Servlet中可以使用post请求上传文件,使用getReader()和getInputStream()自己处理,也可以使用getPart()或getParts()封装了一些功能的方法处理,getParts()可以同时上传多个文件.接下来使用四个Demo来练习一下使用方法 一.使用getReader()和getInputStream() Demo1 <!-- 这是HTML代码块,窗体网页上显示的是一个选择文件的input框和一个upload的button --> <!DOCTYPE h

  • Servlet+MyBatis项目转Spring Cloud微服务,多数据源配置修改建议

    一.项目需求 在开发过程中,由于技术的不断迭代,为了提高开发效率,需要对原有项目的架构做出相应的调整. 二.存在的问题 为了不影响项目进度,架构调整初期只是把项目做了简单的maven管理,引入springboot并未做spring cloud微服务处理.但随着项目的进一步开发,急需拆分现有业务,做微服务处理.因此架构上的短板日益突出.spring cloud config 无法完全应用,每次项目部署需要修改大量配置文件.严重影响开发效率,因此便萌生了对项目架构再次调整的决心. 三.调整建议 为了

  • spring cloud gateway 限流的实现与原理

    在高并发的系统中,往往需要在系统中做限流,一方面是为了防止大量的请求使服务器过载,导致服务不可用,另一方面是为了防止网络攻击. 常见的限流方式,比如Hystrix适用线程池隔离,超过线程池的负载,走熔断的逻辑.在一般应用服务器中,比如tomcat容器也是通过限制它的线程数来控制并发的:也有通过时间窗口的平均速度来控制流量.常见的限流纬度有比如通过Ip来限流.通过uri来限流.通过用户访问频次来限流. 一般限流都是在网关这一层做,比如Nginx.Openresty.kong.zuul.Spring

  • 详解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 CLI简单介绍

    1.简介 在本文中,我们将介绍Spring Boot Cloud CLI(或简称Cloud CLI).该工具为Spring Boot CLI提供了一组命令行增强功能,有助于进一步抽象和简化Spring Cloud部署. CLI于2016年底推出,允许使用命令行..yml配置文件和Groovy脚本快速自动配置和部署标准Spring Cloud服务. 2.安装 Spring Boot Cloud CLI 1.3.x需要Spring Boot CLI 1.5.x,因此请务必从Maven Central

  • 详解SpringCloud Finchley Gateway 统一异常处理

    SpringCloud Finchley Gateway 统一异常处理 全文搜索[@@]搜索重点内容标记 1 . 问题:使用SpringCloud Gateway时,会出现各种系统级异常,默认返回HTML. 2 . Finchley版本的Gateway,使用WebFlux形式作为底层框架,而不是Servlet容器,所以常规的异常处理无法使用 翻阅源码,默认是使用DefaultErrorWebExceptionHandler这个类实现结构如下: 可以实现参考DefaultErrorWebExcep

  • Spring Cloud Ribbon的踩坑记录与原理详析

    简介 Spring Cloud Ribbon 是一个基于Http和TCP的客服端负载均衡工具,它是基于Netflix Ribbon实现的.它不像服务注册中心.配置中心.API网关那样独立部署,但是它几乎存在于每个微服务的基础设施中.包括前面的提供的声明式服务调用也是基于该Ribbon实现的.理解Ribbon对于我们使用Spring Cloud来讲非常的重要,因为负载均衡是对系统的高可用.网络压力的缓解和处理能力扩容的重要手段之一.在上节的例子中,我们采用了声明式的方式来实现负载均衡.实际上,内部

  • 详解Spring Cloud Gateway 数据库存储路由信息的扩展方案

    动态路由背景 ​ 无论你在使用Zuul还是Spring Cloud Gateway 的时候,官方文档提供的方案总是基于配置文件配置的方式 例如: # zuul 的配置形式 routes: pig-auth: path: /auth/** serviceId: pig-auth stripPrefix: true # gateway 的配置形式 routes: - id: pigx-auth uri: lb://pigx-auth predicates: - Path=/auth/** filte

  • 详解Spring Cloud微服务架构下的WebSocket解决方案

    WebSocket在现代浏览器中的应用已经算是比较普遍了,在某些业务场景下,要求必须能够在服务器端推送消息至客户端.在没有WebSocket的年代,我们使用过dwr,在那个时候dwr真实一个非常棒的方案.但是在WebSocket兴起之后,我们更愿意使用标准实现来解决问题. 首先交代一下,本篇文章不讲解WebSocket的配置,主要讲的是针对在微服务架构集群模式下解决方案的选择. 微服务架构大家应该都不陌生了,在微服务架构下,服务是分布式的,而且为了保证业务的可用性,每个服务都是以集群的形式存在.

随机推荐