Zuul что это за программа

Пример распределения нагрузки с помощью Zuul и Eureka

1. обзор

В этой статье мы рассмотрим, как балансировка нагрузки работает с Zuul и Eureka.

We’ll route requests to a REST Service discovered by Spring Cloud Eureka through Zuul Proxy.

2. Начальная настройка

Нам нужно настроитьEureka server/client, как показано в статьеSpring Cloud Netflix-Eureka.

3. Настройка Zuul

Zuul, помимо прочего, выбирает из сервисов Eureka и выполняет балансировку нагрузки на стороне сервера.

3.1. Конфигурация Maven

Сначала мы добавимZuul Server иEureka dependency к нашемуpom.xml:

org.springframework.cloud spring-cloud-starter-netflix-zuul org.springframework.cloud spring-cloud-starter-netflix-eureka-client

3.2. Общение с Эврикой

Во-вторых, мы добавим необходимые свойства в файл Zuulapplication.properties:

server.port=8762 spring.application.name=zuul-server eureka.instance.preferIpAddress=true eureka.client.registerWithEureka=true eureka.client.fetchRegistry=true eureka.client.serviceUrl.defaultZone=$

Здесь мы говорим Zuul зарегистрировать себя как службу в Eureka и работать на порту 8762.

Микросервисы на Spring: перенаправления в API Gateway (2022)

Мы укажем в нашем браузереhttp://localhost:8762/routes. Должны появитьсяall the routes available for Zuul, обнаруженныеEureka:

Теперь мы будем общаться с клиентом Eureka, используя полученный маршрут Zuul Proxy. Если указать нашему браузеру наhttp://localhost:8762/spring-cloud-eureka-client/greeting, должен появиться примерно такой ответ:

Hello from ‘SPRING-CLOUD-EUREKA-CLIENT with Port Number 8081’!

4. Балансировка нагрузки с помощью Zuul

When Zuul receives a request, it picks up one of the physical locations available and forwards requests to the actual service instance. Весь процесс кэширования местоположения экземпляров службы и пересылки запроса в фактическое местоположение предоставляется из коробки без дополнительных настроек.

Здесь мы можем увидеть, как Zuul инкапсулирует три разных экземпляра одного и того же сервиса:

image

Внутренне Zuul использует Netflix Ribbon для поиска всех экземпляров службы из службы обнаружения (Eureka Server).

Давайте посмотрим на это поведение, когда вызывается несколько экземпляров.

4.1. Регистрация нескольких экземпляров

Начнем с запуска двух экземпляров (порты 8081 и 8082).

Как только все экземпляры будут запущены, мы можем наблюдать в журналах, что физические местоположения экземпляров зарегистрированы вDynamicServerListLoadBalancer, а маршрут отображается наZuul Controller, который заботится о пересылке запросов к фактическому экземпляру:

Mapped URL path [/spring-cloud-eureka-client/**] onto handler of type [class org.springframework.cloud.netflix.zuul.web.ZuulController] Client:spring-cloud-eureka-client instantiated a LoadBalancer: DynamicServerListLoadBalancer:,Server stats: []>ServerList:null Using serverListUpdater PollingServerListUpdater DynamicServerListLoadBalancer for client spring-cloud-eureka-client initialized: DynamicServerListLoadBalancer:, Server stats: [[Server:0.0.0.0:8080; Zone:defaultZone;. ], [Server:0.0.0.0:8081; Zone:defaultZone; . ],

Примечание: журналы были отформатированы для лучшей читаемости.

Микросервисы на Spring Cloud, используя Zuul Proxy и OpenFeign

Источник: www.codeflow.site

Что такое зуул?

Zuul — это ворота для всех запросов с устройств и веб-сайтов. В качестве пограничного сервисного приложения Zuul используется для поддержки динамической маршрутизации, мониторинга, отказоустойчивости и безопасности. При необходимости он также может направлять запросы в несколько групп Amazon Auto scaling.

Зачем устанавливать Zuul Gateway?

Объем и разнообразие трафика платформы иногда могут вызывать проблемы, которые возникают быстро и без предупреждения. Нам нужна система, которая позволяет нам быстро менять поведение, чтобы реагировать на эти ситуации.

Zuul использует серию различных типов фильтров, что позволяет нам быстро и гибко применять функции к нашим пограничным сервисам. Эти фильтры помогают нам выполнять следующие функции:

  • Аутентификация и безопасность личности. Определите требования к проверке личности каждого ресурса и отклоните те запросы, которые им не соответствуют.
  • Анализ и мониторинг, отслеживание значимых данных и статистики, чтобы мы имели точное представление о производстве.
  • Динамическая маршрутизация — динамически направляет запросы к различным внутренним кластерам по мере необходимости.
  • Стресс-тест — Постепенно увеличивайте трафик кластера, чтобы оценить производительность.
  • Распределение нагрузки — выделение емкости для каждого типа запроса и удаление запросов, превышающих лимит.
  • Обработка статических ответов — создание некоторых ответов непосредственно на границе вместо пересылки их во внутренний кластер.
  • Межрегиональная гибкость-маршрутизация запросов по регионам AWS направлена ​​на диверсификацию использования ELB и обеспечение максимального приближения периферийного местоположения к пользователю.
Читайте также:
Coreldraw что это за программа и нужна ли

Первая зуульская программа

Мы создадим проект для демонстрации использования zuul в соответствии со следующей архитектурой. И «служба шлюза», и «поставщик услуг» являются простыми проектами Spring Boot, а «служба шлюза» пересылает запрос браузера пользователя «поставщику услуг». «Для достижения функции маршрутизации.

Поскольку программа Zuul обычно используется в среде распределенного кластера, в этой вводной демонстрации будет напрямую использоваться Zuul Netflix, интегрированный в Spring Cloud. Он не использует Zuul собственного Netflix. Вам необходимо провести небольшое исследование основных Партнеры могут посетить проекты и документы, размещенные Netflix на GitHub, а также есть демонстрационные примеры (ну, извините за заголовок, прежде чем я объяснил конкретный класс инструментов, а затем интегрировал Spring Cloud для использования).

Создайте простой проект java maven zuul-provider для предоставления услуг доступа (синий поставщик услуг на рисунке) и введите зависимости Spring Boot в pom.xml:

org.springframework.boot spring-boot-starter-parent 2.0.2.RELEASE org.springframework.boot spring-boot-starter-web

Затем создайте стартовый класс ProviderApp.class.Для удобства я интегрировал контроллер, который предоставляет сервис, в этот стартовый класс:

Поставщик услуг настроен, запустите проект zuul-provider, посетите: http: // localhost: 8080 / msg / spirit, вы увидите, что поставщик услуг может предоставлять услуги в обычном режиме:

Затем создайте простой проект java maven zuul-router в качестве службы шлюза, введите интегрированную зависимость zuul от Spring Cloud в pom.xml, поскольку zuul полагается на базовый уровень, чтобы использовать httpClient, предоставленный Apache для пересылки запросов, затем мы добавляем эту зависимость httpClient :

org.springframework.cloud spring-cloud-dependencies Dalston.SR5 pom import org.springframework.cloud spring-cloud-starter-zuul org.apache.httpcomponents httpclient 4.5.5

Создайте новый файл application.yml в каталоге src / main / resources, настройте порт запуска и правила маршрутизации zuul:

server: port: 8081 zuul: routes: users: path: /myusers/** url: http://localhost:8080

И zuul, и маршрутизаторы являются назначенными пространствами имен;

users — имя правила маршрутизации (вы можете назвать его сами по своему усмотрению, не повторяйте имя);

Путь — это правило, соответствующее службе фильтрации. Если путь не указан, он будет заменен на имя правила маршрутизации;

url — это путь пересылки.

Более подробная информация будет обновлена ​​в следующем блоге, здесь в основном демонстрируется программа входа zuul.

Запустите проект zuul-router, посетите: http: // localhost: 8081 / myusers / msg / spirit, вы увидите, что zuul перенаправил наш запрос zuul-provider:

Механизм работы фильтра в зууле

Большинство функций Zuul реализованы через фильтры.

Стандартный фильтр

Zuul определяет четыре стандартных типа фильтров, которые соответствуют типичному жизненному циклу запросов.

  1. PRE: этот фильтр вызывается перед маршрутизацией запроса. Мы можем использовать этот фильтр для реализации аутентификации, выбора запрошенной микросервиса в кластере, записи отладочной информации и так далее.
  2. МАРШРУТИЗАЦИЯ: этот фильтр направляет запросы к микросервисам. Этот фильтр используется для создания запросов, отправляемых микрослужбам, и использования Apache HttpClient или Netfilx Ribbon для запроса микросервисов.
  3. POST: этот фильтр выполняется после перенаправления на микросервис. Этот фильтр можно использовать для добавления стандартного HTTP-заголовка к ответу, сбора статистики и показателей и отправки ответа от микросервиса клиенту.
  4. ОШИБКА: используйте этот фильтр, когда на других этапах возникают ошибки.

Встроенный специальный фильтр

  1. StaticResponseFilter: аналогично ускорению узла CDN, StaticResponseFilter позволяет генерировать ответ от самого Zuul, а не пересылать запрос источнику.
  2. SurgicalDebugFilter: SurgicalDebugFilter позволяет направлять определенные запросы на отдельные отладочные кластеры или узлы.

В дополнение к двум вышеупомянутым типам фильтров мы также можем настраивать фильтры и комбинировать фильтры, предоставляемые zuul, для удовлетворения потребностей нашего бизнеса.

Источник: russianblogs.com

Обеспечьте безопасность в Zuul с помощью OAuth2 и JWT

Проще говоря, архитектура микросервиса позволяет нам разбить нашу систему и наш API на набор автономных сервисов, которые могут быть развернуты полностью независимо.

Хотя это здорово с точки зрения непрерывного развертывания и управления, это может быстро усложниться, когда дело доходит до удобства использования API. С различными конечными точками для управления зависимым приложениям потребуется управлять CORS (Совместное использование ресурсов разных источников) и различным набором конечных точек.

Zuul-это пограничный сервис, который позволяет нам направлять входящие HTTP-запросы в несколько внутренних микросервисов. Во-первых, это важно для обеспечения единого API для потребителей наших внутренних ресурсов.

Читайте также:
Daraz что это за программа

В принципе, Zuul позволяет нам объединить все наши сервисы, сидя перед ними и действуя в качестве прокси-сервера. Он получает все запросы и направляет их в нужную службу. Для внешнего приложения наш API отображается как единая область поверхности API.

В этом уроке мы поговорим о том, как мы можем использовать его именно для этой цели, в сочетании с OAuth 2.0 и JWTs , чтобы быть на переднем крае защиты наших веб-сервисов. В частности, мы будем использовать поток Предоставление пароля для получения маркера доступа к защищенным ресурсам.

Краткое, но важное замечание состоит в том, что мы используем поток предоставления паролей только для изучения простого сценария; большинство клиентов, скорее всего, будут использовать поток предоставления авторизации в производственных сценариях.

2. Добавление зависимостей Zuul Maven

Давайте начнем с добавления Zuul в наш проект . Мы делаем это, добавляя spring-cloud-starter-netflix-zuul артефакт:

org.springframework.cloud spring-cloud-starter-netflix-zuul 2.0.2.RELEASE

3. Включение Zuul

Приложение, которое мы хотели бы направить через Zuul, содержит сервер авторизации OAuth 2.0, который предоставляет токены доступа, и сервер ресурсов, который их принимает. Эти службы работают на двух отдельных конечных точках.

Мы хотели бы иметь единую конечную точку для всех внешних клиентов этих служб, с разными путями, ответвляющимися от разных физических конечных точек. Для этого мы представим Zuul в качестве пограничного сервиса.

4. Настройка маршрутов Zuul

Прежде чем мы сможем пойти дальше, нам нужно настроить несколько свойств Zuul. Первое, что мы настроим, – это порт, на котором Zuul прослушивает входящие соединения. Это нужно ввести в файл /src/main/ресурсы/application.yml :

server: port: 8080

Теперь о забавных вещах, настройке реальных маршрутов, на которые будет перенаправляться Зуул. Для этого нам нужно отметить следующие службы, их пути и порты, которые они прослушивают.

Сервер авторизации является поставщиком удостоверений OAuth. Он существует для предоставления маркеров авторизации серверу ресурсов, который, в свою очередь, предоставляет некоторые защищенные конечные точки.

Сервер авторизации предоставляет Клиенту Маркер доступа, который затем использует этот маркер для выполнения запросов к Серверу ресурсов от имени Владельца Ресурса. Быстрый просмотр терминологии OAuth поможет нам сохранить эти концепции в поле зрения.

Теперь давайте наметим несколько маршрутов к каждой из этих служб:

zuul: routes: spring-security-oauth-resource: path: /spring-security-oauth-resource/** url: http://localhost:8082/spring-security-oauth-resource oauth: path: /oauth/** url: http://localhost:8081/spring-security-oauth-server/oauth

На этом этапе любой запрос, поступающий в Zuul на localhost:8080/oauth/** , будет перенаправлен в службу авторизации, работающую на порту 8081. Любой запрос на localhost:8080/spring-security-oauth-ресурс/** будет перенаправлен на сервер ресурсов, работающий на 8082.

5. Обеспечение Безопасности Внешних Транспортных Путей Zuul

Несмотря на то, что наша пограничная служба Zuul теперь правильно маршрутизирует запросы, она делает это без каких-либо проверок авторизации. Сервер авторизации , расположенный за /oauth/* , создает JWT для каждой успешной аутентификации. Естественно, он доступен анонимно.

Сервер ресурсов , расположенный по адресу /spring – security-oauth-resource/** , с другой стороны, всегда должен быть доступен с помощью JWT, чтобы гарантировать, что авторизованный клиент получает доступ к защищенным ресурсам.

Во-первых, мы настроим Zuul для прохождения через JWT к службам, которые находятся за ним. В нашем случае здесь эти службы сами должны проверить токен.

Мы делаем это, добавляя чувствительные заголовки: Cookie,Set-Cookie .

Это завершает нашу конфигурацию Zuul:

server: port: 8080 zuul: sensitiveHeaders: Cookie,Set-Cookie routes: spring-security-oauth-resource: path: /spring-security-oauth-resource/** url: http://localhost:8082/spring-security-oauth-resource oauth: path: /oauth/** url: http://localhost:8081/spring-security-oauth-server/oauth

После того, как мы покончим с этим, нам нужно будет разобраться с авторизацией на грани. Прямо сейчас Zuul не будет проверять JWT перед передачей его нашим нижестоящим службам. Эти службы сами проверят JWT, но в идеале мы хотели бы, чтобы пограничная служба сделала это первой и отклоняла любые несанкционированные запросы, прежде чем они распространятся глубже в нашу архитектуру.

Давайте настроим безопасность Spring, чтобы убедиться, что авторизация проверена в Zuul.

Во-первых, нам нужно будет включить в наш проект зависимости безопасности Spring. Мы хотим spring-security-oauth2 и spring-security-jwt:

org.springframework.security.oauth spring-security-oauth2 2.3.3.RELEASE org.springframework.security spring-security-jwt 1.0.9.RELEASE

Теперь давайте напишем конфигурацию для маршрутов, которые мы хотим защитить, расширив ResourceServerConfigurerAdapter:

Класс Конфигурация шлюза определяет, как Spring Security должен обрабатывать входящие HTTP-запросы через Zuul. Внутри метода configure мы сначала сопоставили наиболее ограничительный путь с помощью antMatchers , а затем разрешили анонимный доступ через PermitAll .

Читайте также:
Программа Opera max для Андроид что это

То есть все запросы, поступающие в /oauth/** , должны быть разрешены без проверки каких-либо маркеров авторизации. Это имеет смысл, потому что это путь, по которому генерируются токены авторизации.

Затем мы сопоставили все остальные пути с/* * и посредством вызова аутентифицированного настояли на том, чтобы все остальные вызовы содержали маркеры доступа.

6. Настройка ключа, используемого для проверки JWT

Теперь, когда конфигурация установлена, все запросы, направленные по пути /oauth/** , будут разрешены анонимно, в то время как все остальные запросы потребуют аутентификации.

Однако есть одна вещь, которую мы здесь упускаем, и это фактический секрет, необходимый для проверки того, что JWT действителен. Для этого нам нужно предоставить ключ (в данном случае симметричный), используемый для подписи JWT. Вместо того, чтобы писать код конфигурации вручную, мы можем использовать spring-security-oauth2-автоматическая настройка .

Давайте начнем с добавления артефакта в наш проект:

org.springframework.security.oauth.boot spring-security-oauth2-autoconfigure 2.1.2.RELEASE

Затем нам нужно добавить несколько строк конфигурации в наше приложение .yaml файл для определения ключа, используемого для подписи JWT:

security: oauth2: resource: jwt: key-value: 123

Строка ключ-значение: 123 задает симметричный ключ, используемый Сервером авторизации для подписи JWT. Этот ключ будет использоваться spring-security-oauth2-автоматическая настройка для настройки синтаксического анализа токенов.

Важно отметить, что в производственной системе мы не должны использовать симметричный ключ, указанный в исходном коде приложения. Это, естественно, должно быть настроено извне.

7. Тестирование пограничной службы

7.1. Получение токена доступа

Теперь давайте проверим, как ведет себя наш пограничный сервис Zuul – с помощью нескольких команд curl.

Сначала мы посмотрим, как мы можем получить новый JWT с сервера авторизации, используя предоставление пароля .

Здесь мы обмениваем имя пользователя и пароль на токен доступа . В этом случае мы используем ‘ john ‘в качестве имени пользователя и’ 123 ‘ в качестве пароля:

curl -X POST http://localhost:8080/oauth/token -H ‘Authorization: Basic Zm9vQ2xpZW50SWRQYXNzd29yZDpzZWNyZXQ=’ -H ‘Cache-Control: no-cache’ -H ‘Content-Type: application/x-www-form-urlencoded’ -d ‘grant_type=passwordusername=john’

Этот вызов дает токен JWT, который мы затем можем использовать для аутентифицированных запросов к нашему серверу ресурсов.

Обратите внимание на поле заголовка “Авторизация: Базовая…”|/. Это необходимо для того, чтобы сообщить серверу авторизации, какой клиент к нему подключается.

Это для клиента (в данном случае запрос cURL), что такое имя пользователя и пароль для пользователя:

7.2. Тестирование запроса сервера ресурсов

Затем мы можем использовать JWT, полученный с сервера авторизации, для выполнения запроса к серверу ресурсов:

curl -X GET curl -X GET http:/localhost:8080/spring-security-oauth-resource/users/extra -H ‘Accept: application/json, text/plain, */*’ -H ‘Accept-Encoding: gzip, deflate’ -H ‘Accept-Language: en-US,en;q=0.9’ -H ‘Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXV. ‘ -H ‘Cache-Control: no-cache’

Пограничная служба Zuul теперь будет проверять JWT перед маршрутизацией на сервер ресурсов.

Затем это извлекает ключевые поля из JWT и проверяет наличие более детальной авторизации, прежде чем отвечать на запрос:

8. Безопасность На Разных Уровнях

Важно отметить, что JWT проверяется пограничной службой Zuul перед передачей на сервер ресурсов. Если JWT недействителен, то запрос будет отклонен на границе пограничной службы.

С другой стороны, если JWT действительно действителен, запрос передается по потоку. Затем сервер ресурсов снова проверяет JWT и извлекает ключевые поля, такие как область действия пользователя, организация (в данном случае пользовательское поле) и полномочия. Он использует эти поля, чтобы решить, что пользователь может и не может делать.

Чтобы быть ясным, во многих архитектурах нам на самом деле не нужно будет дважды проверять JWT – это решение, которое вам придется принять на основе ваших моделей трафика.

Например, в некоторых производственных проектах доступ к отдельным серверам ресурсов может осуществляться как напрямую, так и через прокси – сервер, и мы можем захотеть проверить токен в обоих местах. В других проектах трафик может поступать только через прокси-сервер, и в этом случае проверки токена достаточно.

9. Краткое изложение

Как мы видели, Zuul предоставляет простой, настраиваемый способ абстрагирования и определения маршрутов для служб. Вместе с Spring Security это позволяет нам авторизовывать запросы на границах службы.

Наконец, как всегда, код доступен на Github .

Читайте ещё по теме:

  • Сервер Ресурсов OAuth 2.0 С Spring Security 5
  • Сервер авторизации Spring Security OAuth

Источник: javascopes.com

Рейтинг
( Пока оценок нет )
Загрузка ...
EFT-Soft.ru