Как мы все знаем, для разработки приложений на основе микросервисов нам необходимо иметь представление о различных темах, таких как:
- Шлюз API
- Обнаружение службы
- Балансировщик нагрузки
- Синхронная/асинхронная связь
- Масштабирование
- Распределенные транзакции
- Управление журналом
- Масштабный куб
- Шаблон автоматического выключателя и т. Д.
Итак, в этой серии я рассмотрю все темы, связанные с микросервисами, одну за другой. В этом посте я расскажу об обнаружении служб и реестре.
Введение: Реестр услуг
При разработке приложений на основе микросервисов требуется связь между микросервисами, и для этого нам нужен адрес служб, с которыми мы хотим соединиться.
Один из способов подключения — использование IP: port. Но проблема, связанная с этим способом, заключается в том, что IP-адрес и порт работающей службы могут быть изменены, и тогда нам нужно внести изменения во все службы, которые его используют. Даже мы не можем использовать статические IP-адреса. потому что примеров много.
Другим способом может быть использование шлюза API, но шлюзу также нужны все адреса.
Service Discovery — это шаблон, позволяющий узнать адреса всех экземпляров.
Чтобы узнать адреса, мы используем реестр служб — базу данных, содержащую службы и их адреса.
Теперь, используя промежуточный реестр служб (клиент и сервер), всякий раз, когда клиент или шлюз API хотят взаимодействовать, они просто запрашивают в реестре адреса конкретной микрослужбы.
Как реестр службы получает адреса?
Существует два способа, с помощью которых реестр службы собирает адреса различных экземпляров.
Самостоятельно: служба регистрируется в реестре и через несколько минут/секунд обновляет адреса своих новых экземпляров в реестре. и если служба не обновляет реестр, она удалит эти адреса, считая, что она не работает.
Сторонние: в этом случае реестр будет запрашивать у каждой микрослужбы их адреса и порты. С помощью событий в кластере это происходит и он периодически проверяет, живы инстансы или нет, таким образом у него есть все последние адреса.
Обнаружение служб — это полная противоположность реестру служб. Существует два способа выполнить обнаружение служб.
- Использование на стороне клиента
- Использование шлюза API (на стороне сервера)
Шлюз Client/API взаимодействует с реестром и получает список конкретных служб. а затем, используя балансировку нагрузки, он будет общаться с конкретным экземпляром службы.
Для реализации этих функций мы можем использовать разные библиотеки. В случае весенней загрузки у нас есть сервер Netflix Eureka, клиент Eureka, Consul и Apache ZooKeeper.
Создание сервера и клиента Eureka с использованием Spring Boot
Чтобы создать сервер eureka, мы можем создать проект весенней загрузки с https://start.spring.io/, а затем добавить зависимость сервера Eureka. после этого просто запустите проект. Это будет использоваться в качестве реестра.
Добавьте @EnableEurekaServer в основной класс и конфигурацию в файле application.yml и запустите сервер.
После запуска сервера вы увидите вот такую страницу.
Аналогичным образом для создания клиента мы можем добавить зависимость Eureka Client и добавить @EnableEurekaClient в основной класс и конфигурацию в файле application.yml.
Теперь это будет регистрироваться без реестра, который мы запустили ранее. потому что в defaultZone мы дали один и тот же URL. Если мы обновим страницу реестра, мы увидим там этот шлюз.
Итак, в этом посте мы рассказали о реестре и обнаружении сервисов, а также о том, как создать реестр сервисов с помощью весенней загрузки и зарегистрированного API-шлюза в реестре.
В следующем посте мы обсудим, как мы можем создать API-шлюз и что такое API-шлюз.
Если есть какие-либо улучшения или предложения, дайте мне знать.
Спасибо за прочтение!
