Будьте тем изменением, которое вы хотите видеть в мире. - Махатма Ганди
Вступление
Поиск физических адресов вокруг сервисов внутри наших микросервисов - это хорошо известная концепция с момента зарождения распределенных вычислений. Это ключевой элемент нашей архитектуры, поскольку он напрямую влияет на нашу распределенную архитектуру, начиная со следующих трех основных причин:
- Горизонтальная масштабируемость: он предлагает приложению возможность быстро масштабировать услуги вниз и вверх, не нарушая работу потребителей услуг;
- Абстракция: поскольку физическое местонахождение не известно потребителям сервисов, новые экземпляры могут быть удалены и добавлены в любой момент в доступный пул сервисов;
- Отказоустойчивость:. Если по какой-либо причине микросервис становится недоступным, он автоматически удаляется из списка доступных сервисов, направляя других потребителей сервиса вокруг себя.
Большая разница между обнаружением служб (SD) и DNS состоит в том, что SD может иметь приложение N сервер, на котором запущен , DNS, всегда будет иметь статический номер, который не будет увеличиваться или уменьшаться. Еще одно отличие - состояние сохранения, означающее, что, находясь на SD, мы можем перезапустить любую службу в любое время и получить их исходное состояние с помощью DNS мы всегда будем в том же состоянии, что и во время сбоя. С этими основными отличиями мы уже можем видеть, что некоторые из наших горизонтальных масштабов становятся ограниченными.
В этой статье я объясню вам, как это облачное решение будет работать вместе с кэшированием на стороне клиента и балансировкой нагрузки (когда SD недоступен).
Будет создан проект-заглушка с целью показать вам, насколько легко расширить возможности вашей микросервисной архитектуры с помощью нескольких шагов, просто используя Spring Cloud и Netflix's Eureka агент обнаружения службы.
Архитектура обнаружения сервисов
Во всех доступных реализациях обнаружения служб используются четыре основных концепции: мониторинг работоспособности, общая информация, поиск адресов службы и регистрация услуг.
- Мониторинг работоспособности: как служба будет сообщать о его внутреннем состоянии здоровья?
- Общая информация: как служба будет делиться информацией с другими службами?
- Поиск адресов службы. Как служба будет получать информацию о других службах?
- Регистрация служб: Как служба регистрируется в агенте обнаружения служб?
На все эти вопросы мы ответим в статье.
Рабочий процесс
- На первом этапе сервис зарегистрируется на SD. Для этого вызов будет выполнен с соответствующим именем службы, предварительно определенным в его файле конфигурации, и физическим расположением;
2. Другое местоположение службы можно найти по логическому имени на SD;
После того, как служба подключается к сети, для конкретной конечной точки выполняется проверка пульса. Если какая-либо служба не вернет правильную проверку работоспособности, она будет удалена из пула доступных служб.
3. SD возвращает запрошенное местоположение службы;
4. Все готово к выполнению запроса.
Балансировка нагрузки на стороне клиента
Балансировка нагрузки была введена с основной целью поиска и кеширования реестра в каждом экземпляре службы для повышения производительности.
Как это работает:
- После того, как службы зарегистрируются в Eureka, SD будет знать физическое местоположение каждой службы и номер порта каждого экземпляра службы, а также идентификатор службы (имя службы), которая запускается.
- Когда служба A вызывает службу B, она будет использовать библиотеку Netflix Ribbon (балансировка нагрузки на стороне клиента). Затем Ribbon свяжется с Netflix Eureka (SD), чтобы получить информацию о соответствующей услуге, а затем кэшировать ее локально.
- Ribbon будет регулярно связываться с SD и обновлять свой локальный кеш.
Вот и все, этот простой процесс может стать решающим фактором между успехом и неудачей вашего приложения.
Создайте свой Spring Eureka Service
Поскольку это сторонний проект весенних облаков, настроить его довольно просто. Сначала мы начнем с создания нового проекта Spring со следующими зависимостями pom.xml:
Затем нам нужно определить, на каком порту должна работать наша SD, и определить некоторые из поведения SD. Для этого откройте application.yml и установите следующие свойства:
Чтобы закончить, нам просто нужно отредактировать наш класс начальной загрузки приложения и добавить аннотацию @EnableEurekaServer, например:
На этом этапе вы можете запустить службу Eureka, выполнив следующие команды в каталоге проекта:
- чистая установка mvn
- java -jar target / eureka-0.0.1-SNAPSHOT.jar
После этого вы должны получить доступ к http: // localhost: 8761 / и увидеть что-то вроде этого:
Вот и все, всего за три шага, и у нас есть наш агент обнаружения сервисов! Давайте создадим простой пример, чтобы проверить, правильно ли он работает.
Создание модуля клиентского обслуживания
В предыдущем посте мы создали простого клиента, получающего свою конфигурацию с общего сервера конфигурации. Здесь мы придерживаемся того же подхода, но большая разница в том, что теперь у нас есть две клиентские службы, где клиент A в процессе обработки будет вызывать службу клиента B для получения некоторых данных.
- Создайте еще один проект весенней загрузки со следующими зависимостями pom.xml:
Примечание. Было добавлено еще несколько зависимостей, например h2 в базе данных памяти, чтобы увидеть полный файл pom.xml, вы можете перейти по ссылке выше. Для поиска контекста важная часть - это spring-cloud-starter-netflix-eureka-client.
Откройте application.yml и bootstrap.yml и определите следующие свойства:
предпочитают-ip-адрес следует использовать в основном в среде на основе контейнеров, используя в качестве примера докер, по умолчанию службы запускаются со случайно сгенерированными именами хостов и без записей DNS для них.
Примечание. Убедитесь, что URL-адрес SD правильно указан в качестве имени службы, это обязательно для успешной работы службы.
Чтобы проверить, насколько хорошо работают эти конфигурации, выполните следующие команды в каталоге проекта:
- чистая установка mvn
- java -jar target / client1-0.0.1-SNAPSHOT.jar
В интерфейсе SD вы должны увидеть что-то вроде этого:
И снова, всего за 3 шага, наша клиентская служба запущена и работает, регистрируясь на SD, как показано в начале.
Остается только иметь клиента, с которым можно взаимодействовать через нашу SD. Процесс в основном такой же, как и ранее показанный, включая конфигурации. Создайте новый проект весенней загрузки и запустите его в другом порту. Каждый раз, когда вторая служба запускается и работает, в Eureka должна появиться новая запись, например:
В рамках контекста у нас есть две запущенные и работающие службы: клиентская и адресная. Мы сделаем простой запрос, чтобы получить адрес клиента с заданным идентификатором, выполнив следующие действия:
- Клиентская служба получит клиента с заданным идентификатором;
- Служба поддержки клиентов запросит у Eureka адрес службы поддержки;
- Создает простой HTTP-запрос к конечной точке, которая получит адрес по полученному идентификатору адреса клиента;
- Служба клиента сопоставляет возвращаемый объект json с адресом DTO;
- Готовы вернуть адресный объект;
Настройка сущностей JPA и определение контроллеров REST выходят за рамки этой статьи, однако в ближайшей функции вы сможете увидеть, как это сделать в другой статье, так что следите за обновлениями.
При этом наиболее важным разделом будет вопрос о том, как клиентская служба будет запрашивать у Eureka адрес службы адреса и как затем будут извлекаться данные.
Для этого убедитесь, что ваш класс начальной загрузки служб содержит аннотацию @EnableDiscoveryClient и предоставляет компонент RestTemplate, аннотированный как @LoadBalaced, например:
Этот баланс нагрузки позволяет службе использовать библиотеку ленты для извлечения кэшированной информации, однажды предоставленной SD;
Затем на третьем и четвертом шагах у нас есть что-то вроде:
А также:
При этом конечная точка должна получить объект json, например:
Заключение
Как уже упоминалось, вы сможете проверить все эти примеры, запущенные и работающие на этой странице github, и попробовать их все самостоятельно. С помощью этих простых шагов вы наверняка расширите возможности своей архитектуры микросервисов для повышения качества вашего проекта. Не стесняйтесь комментировать и оставлять любые предложения по статьям!
