В этой статье мы собираемся изучить интеграционное тестирование клиента Feign .
Мы создадим базовый клиент Open Feign, для которого напишем простой интеграционный тест с помощью WireMock .
После этого мы добавим конфигурацию ленты в наш клиент, а также создадим для нее интеграционный тест. И, наконец, мы настроим тестовый контейнер Eureka и протестируем эту настройку , чтобы убедиться, что вся наша конфигурация работает должным образом. ** ** ****
В этой статье мы рассмотрим основные функции проекта Spring Cloud Gateway , нового API на основе Spring 5, Spring Boot 2 и Project Reactor.
Инструмент предоставляет готовые механизмы маршрутизации, часто используемые в приложениях микрослужб как способ скрыть несколько служб за одним фасадом.
Для объяснения паттерна Gateway без проекта Spring Cloud Gateway ознакомьтесь с нашей предыдущей статьей .
В этом уроке мы узнаем, как использовать функцию Spring Cloud.
Мы создадим и запустим простую облачную функцию Spring локально, а затем развернем ее на AWS.
Для начала реализуем с нуля и протестируем простой проект с двумя функциями, используя разные подходы:
OpenFeign — это декларативный клиент REST, который мы можем использовать в приложениях Spring Boot . Предположим, что у нас есть REST API, защищенный с помощью OAuth2 , и мы хотим вызвать его с помощью OpenFeign. В этой ситуации нам нужно будет предоставить токен доступа с помощью OpenFeign.
В этом руководстве мы расскажем , как добавить поддержку OAuth2 в клиент OpenFeign .
Проверка подлинности между службами — популярная тема в области безопасности API. Мы можем использовать mTLS или JWT , чтобы обеспечить механизм аутентификации для REST API. Однако протокол OAuth2 по умолчанию является решением для защиты API . Допустим, мы хотим вызвать безопасную службу (роль сервера), используя другую службу (роль клиента). В этом сценарии мы используем тип предоставления учетных данных клиента . Обычно мы используем учетные данные клиента для аутентификации между двумя API или системами без конечного пользователя. На рисунке ниже показаны основные участники этого типа гранта:
В предыдущей статье мы рассмотрели, что такое Spring Cloud Gateway и как использовать встроенные предикаты для реализации основных правил маршрутизации. Однако иногда этих встроенных предикатов может быть недостаточно. Например, наша логика маршрутизации может по какой-то причине потребовать поиска в базе данных.
В этих случаях Spring Cloud Gateway позволяет нам определять пользовательские предикаты. После определения мы можем использовать их как любой другой предикат, что означает, что мы можем определять маршруты с помощью Fluent API и/или DSL.
Вкратце, предикат в Spring Cloud Gateway — это объект, который проверяет, соответствует ли данный запрос заданному условию. Для каждого маршрута мы можем определить один или несколько предикатов, которые, если они будут удовлетворены, будут принимать запросы для настроенного бэкенда после применения любых фильтров.
Обычный вариант использования Spring Cloud Gateway — выступать в качестве фасада для одной или нескольких служб, предлагая клиентам более простой способ их использования.
В этом руководстве мы покажем различные способы настройки открытых API-интерфейсов путем перезаписи URL-адресов перед отправкой запроса на серверные части.
Проект Spring Cloud Gateway построен на основе популярных Spring Boot 2 и Project Reactor , поэтому он наследует их основные преимущества:
Spring Cloud Gateway — это библиотека, которая позволяет нам быстро создавать легкие шлюзы API на основе Spring Boot, о которых мы уже рассказывали в предыдущих статьях.
На этот раз мы покажем, как быстро реализовать шаблоны OAuth 2.0 поверх него .
Стандарт OAuth 2.0 — это хорошо зарекомендовавший себя стандарт, используемый во всем Интернете в качестве механизма безопасности, с помощью которого пользователи и приложения могут безопасно получать доступ к ресурсам.
Spring Cloud Gateway — это интеллектуальный прокси-сервис, часто используемый в микросервисах. Он прозрачно централизует запросы в единой точке входа и направляет их в соответствующий сервис. Одной из самых интересных его особенностей является концепция фильтров ( WebFilter или GatewayFilter ).
WebFilter вместе с Predicate factory включает в себя полный механизм маршрутизации. Spring Cloud Gateway предоставляет множество встроенных фабрик WebFilter , которые позволяют взаимодействовать с HTTP-запросами до достижения прокси-сервиса и HTTP-ответами перед доставкой результата клиенту . Также возможно реализовать пользовательские фильтры .
В этом руководстве мы сосредоточимся на встроенных фабриках WebFilter , включенных в проект, и на том, как их использовать в расширенных случаях использования.
веб- фильтровКогда мы создаем решение для микросервисов, и Spring Cloud , и Kubernetes являются оптимальными решениями, поскольку они предоставляют компоненты для решения наиболее распространенных задач. Однако, если мы решим выбрать Kubernetes в качестве основного менеджера контейнеров и платформы развертывания для нашего решения, мы все равно сможем использовать интересные функции Spring Cloud в основном через проект Spring Cloud Kubernetes .
Этот относительно новый проект, несомненно, обеспечивает простую интеграцию с Kubernetes для приложений Spring Boot . Перед началом может быть полезно посмотреть, как развернуть приложение Spring Boot в Minikube , локальной среде Kubernetes .
В этом уроке мы:
YAML . По мере того, как микросервисные архитектуры становятся все более популярными, становится все более распространенным запускать несколько сервисов, распределенных по разным серверам. В этом кратком руководстве мы рассмотрим использование Spring Cloud Load Balancer для создания более отказоустойчивых приложений .
Балансировка нагрузки — это процесс распределения трафика между разными экземплярами одного и того же приложения.
Чтобы создать отказоустойчивую систему, обычно запускают несколько экземпляров каждого приложения. Таким образом, всякий раз, когда одной службе необходимо связаться с другой, она должна выбрать конкретный экземпляр для отправки своего запроса.