Zuul маршрут от корневого пути

Question

У меня есть некоторые микросервисы, обнаруженные с Eureka. Большинство из них предоставляют некоторые API. И у меня есть сервис «edge», называемый «Gateway service», который фактически является Zuul Proxy. Дело в том, что есть веб-приложение. Он долгое время поддерживался шлюзом, и с этим не было никаких проблем. Но сейчас мне нужно разместить этого клиента на отдельном сервисе за шлюзом. Это не проблема. Я создал новый сервис и разместил там веб-приложение. Но дело в том, что Zuul на службу шлюза имеют следующую конфигурацию

zuul: 
    ignoredServices: '*' 
    prefix: /api 
    sensitiveHeaders: Cookie, Set-Cookie 
    routes: 
    config-service: 
     path: /conf/** 
     serviceId: config-service 
    security-service: 
     path: /security/** 
     serviceId: security-service 
     stripPrefix: false 
    request-service: 
     path: /requests/** 
     stripPrefix: false 

мне нужно сделать так, что пользователь в состоянии получить доступ веб-приложения из корневого пути, как этот http://app.com/. Но сейчас я могу получить к нему доступ только http://app.com/api/, что совершенно неверно.

Моя задача:

1. Сделать веб-приложение размещается на другой сервис доступен из корневого пути.
2. Также очень важно, чтобы префикс /api оставался для всех других услуг.

Я попытался реализовать ZuulFilter. Но похоже, что он ничего не делает с корневым путем и запускается только тогда, когда есть соответствие с любыми маршрутами, описанными выше.

Как это сделать?

ОБНОВЛЕНИЕ: У меня есть небольшой успех с ZuulFilter. Я заставил его работать. Вот конфигурация Zuul:

zuul: 
    ignoredServices: '*' 
    sensitiveHeaders: Cookie, Set-Cookie 
    routes: 
    api: /api/** 
    config-service: 
     path: /conf/** 
     serviceId: config-service 
    security-service: 
     path: /security/** 
     serviceId: security-service 
     stripPrefix: false 
    request-service: 
     path: /requests/** 
     stripPrefix: false 
    frontend-host-service: 
     path: /** 

И ZuulFilter сам

@Bean 
    public ZuulFilter apiPrefixStrip(RouteLocator routeLocator) { 
     return new ZuulFilter() { 

      @Override 
      public String filterType() { 
       return "pre"; 
      } 

      @Override 
      public int filterOrder() { 
       return 0; 
      } 

      @Override 
      public boolean shouldFilter() { 
       RequestContext context = RequestContext.getCurrentContext(); 
       return context.getRequest().getRequestURI().startsWith("/api"); 
      } 

      @Override 
      public Object run() { 
       RequestContext context = RequestContext.getCurrentContext(); 
       String path = context.getRequest().getRequestURI(); 
       Route route = routeLocator.getMatchingRoute(path.substring(4)); 
       if (route != null) { 
        context.put("proxy",route.getId()); 
        context.put("requestURI", route.getPath()); 
        context.set("serviceId", route.getLocation()); 
       } 
       return null; 
      } 
     }; 
    } 

Как эта работа: есть свойство zuul.routes.api=/api/**, который ничего не делает на самом деле. Он просто позволяет сопоставить все согласованные пути с цепочкой фильтров Zuul (described in documentation). Все остальные маршруты, описанные здесь, установлены так, как будто нет /api. Он позволяет достичь таких сервисов: http://app.com/requests, например. для обслуживания запросов. ZuulFilter выполняет проверку для каждого запроса, описанного в свойствах, но он выполняется только в том случае, если запрошенный URI начинается с /api и перенаправляет этот запрос таким же образом, как и в пути /api.

Это работает действительно. Но мне все еще не нравится это решение, потому что есть конечные точки без /api префикс все еще остаются на шлюзе. Может быть, кто-нибудь знает, как его улучшить?

Answer 1

Я хотел бы сделать следующее:

1. Отбросьте zuul.prefix свойство.
2. Подготовить префикс 'api to all of your zuul.routes. *. Path` свойства.
3. Добавить окончательный маршрут (в конце списка), который имеет следующие свойства:

---

app: 
    path: /** 
    stripPrefix: false 

(3) очень важно, так как порядок маршрутов здесь имеет значение. Это порядок, по которому входящие запросы будут оценивать, совпадает ли маршрут. Также важно, чтобы вы сделали это в yaml, так как порядок будет сохранен, где он может быть не с файлом свойств (в соответствии с documentation).