Регистрация службы и обнаружение весеннего облачного шлюза

При перепечатке просьба указывать источник:www.fangzhipeng.comЭта статья взята изБлог Фан Чжипэна

В предыдущей статье я представил Predict (assert) и Filter (фильтр) Spring Cloud Gateway. У всех есть предварительное представление о Spring Cloud Gateway. В части маршрутизации и переадресации услуг предыдущая статья жестко запрограммирована. пересылка. В этой статье объясняется, как Spring Cloud Gateway взаимодействует с реестром служб для маршрутизации и переадресации в форме кейса.

Инженерное введение

В этом случае версия весенней загрузки — 2.0.3.RELEASE, а версия весеннего облака — Finchley.RELEASE. Задействовано три проекта, а именно центр регистрации eureka-server, поставщик услуг service-hi и сервисный шлюз service-gateway, а именно:

Название конструкции	порт	эффект
eureka-server	8761	реестр эврика сервера
service-hi	8762	провайдер услуг eurka ​​клиент
service-gateway	8081	шлюз маршрутизации клиент eureka

Среди этих трех проектов service-hi и service-gateway зарегистрированы в центре регистрации eureka-server. Запрос пользователя сначала проходит через сервис-шлюз, а прогноз шлюза определяет, в какой маршрутизатор входить в соответствии с путем.После того, как маршрутизатор обрабатывается различными фильтрами, он, наконец, направляется к определенной бизнес-службе, такой как service-hi. Как показано на рисунке:

Два проекта eureka-server и service-hi напрямую скопированы из другой моей статьи https://blog.csdn.net/forezp/article/details/81040925, которая здесь не повторяется, вы можете просмотреть исходный код, исходный код кодовый адрес См. ссылку в конце статьи. Среди них служба service-hi предоставляет интерфейс RESTFUL «/hi». Теперь сосредоточьтесь на объяснении сервисного шлюза.

Подробное введение проекта шлюза

Введите зависимости, требуемые проектом, в проект шлюза, включая начальные зависимости eureka-client и начальные зависимости шлюза. Код выглядит следующим образом:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>

В конфигурационном файле проекта application.yml укажите порт запуска программы как 8081, адрес регистрации, конфигурацию шлюза и др. Информация о конфигурации выглядит следующим образом:

server:
  port: 8081

spring:
  application:
    name: sc-gateway-service
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true
          lowerCaseServiceId: true
          
eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/

Среди них значение spring.cloud.gateway.discovery.locator.enabled равно true, что указывает на то, что шлюз включает функцию регистрации и обнаружения службы, а шлюз Spring Cloud автоматически создает маршрутизатор для каждой службы на основе обнаружения службы. с именем службы. Путь запроса перенаправляется на соответствующую службу. spring.cloud.gateway.discovery.locator.lowerCaseServiceId предназначен для настройки имени службы в пути запроса в нижнем регистре (поскольку при регистрации службы имя службы преобразуется в верхний регистр при регистрации в реестре), например /service- hi Путь запроса /* направляется в службу с именем service-hi.

На ввод запроса браузера localhost:8081/service-hi/hi?name=1323 веб-страница получает следующий ответ:

hi 1323 ,i am from port:8762

В приведенном выше примере при отправке запроса в службу шлюза URL-адрес должен иметь префикс с именем службы, прежде чем его можно будет перенаправить в службу-привет, а служба-привет будет удалена перед пересылкой. Так можно ли настроить путь запроса?В конце концов, имя службы иногда слишком длинное, или историческая причина не может быть маршрутизирована в соответствии с именем службы, и ее нужно перенаправить на конкретную службу по пользовательскому пути. Ответ да, да, вам нужно только изменить файл конфигурации проекта application.yml, конкретная конфигурация выглядит следующим образом:

spring:
  application:
    name: sc-gateway-server
  cloud:
    gateway:
      discovery:
        locator:
          enabled: false
          lowerCaseServiceId: true
      routes:
      - id: service-hi
        uri: lb://SERVICE-HI
        predicates:
          - Path=/demo/**
        filters:
          - StripPrefix=1
         

В приведенной выше конфигурации настроено предсказание пути, и запросы, начинающиеся с /demo/**, будут перенаправляться на адрес, uri которого равен lb://SERVICE-HI, где lb://SERVICE-HI — это service-hi. адрес службы балансировки нагрузки и используйте фильтр StripPrefix для удаления /demo перед пересылкой. В то же время измените spring.cloud.gateway.discovery.locator.enabled на false.Если это не изменить, предыдущий адрес запроса, такой как localhost:8081/service-hi/hi?name=1323, также может быть доступен в обычном режиме. , т.к. в это время создается 2 роутера на каждый сервис.

Запрос localhost:8081/demo/hi?name=1323 в браузере возвращает следующий ответ:

hi 1323 ,i am from port:8762

Возвращенный результат такой, как мы и ожидали.

Загрузка исходного кода

GitHub.com/forephotos/День SP…

использованная литература

nuggets.capable/post/684490…

woo woo Краткое описание.com/afraid/1 из 942 ah 8AB…

nuggets.capable/post/684490…