ЗАЧЕМ ЭТО НУЖНО?
Допустим, компания написала приложение на микросервисной архитектуре, где каждый сервис работает независимо и имеет свою БД. Соответственно, каждый из них может отвалится в любой самый непредсказуемый момент времени. Это значит, что нужно это отслеживать. Так вот для этого и был написан мой микросервис, он как раз и проверяет состояние эндпоинтов с разной периодичностью, так как сервисы имеют разную нагрузку(также можно проверить любой эндпоинт отдельно, не дожидаясь таймера проверки). Также важным преимуществом является тот факт, что если в текущий момент времени никто не отслеживает состояние сервисов на фронтенде, например сотрудники просто заняты своими задачами, то как только таймер проверки эндпоинта обновится и будет выявлено, что он отвалился(или отвалилась БД у сервиса), то ему прийдет уведомление в ТГ и на почту
СХЕМА РАБОТЫ МИКРОСЕРВИСА
КАК ЭТО РАБОТАЕТ:
-
Пользователь проходит процес аутентификации (реализовано посредством Spring Security) и получает доступ к просмотру всех эндпоинтов (реализовано посредством Spring MVC)
-
Сразу после аутентификации происходит вызов функции, которая опрашивает эндпоинты (у каждого эндпоинта своя периодичность опроса, так как некоторые эндпоинты могут быть высоконагруженными и информацию о них нужно узнавать часто, а некоторые эндпоинты опрашиваются редко, так как они менее нагруженные)
-
Реализован функционал для опроса конкретного эндпоинта без ожидания общего опроса, так как иногда нужно быстро узнать состояние эндпоинта.
-
Для доступа к эндпоинтам также проводится процесс аутентификации (обращение к эндпоинтам реализовано через синхронный http-клиент - Rest Client)
-
Если какой то эндпоинт упал, то на странице отображается черный значок, который подразумевает, что эндпоинт выключен; зеленый - значит все работает; красный - значит отвалилась SQL или noSQL
-
Также если эндпоинт упал, то отслылается письмо по email и в телеграм бота
-
Общение между микросервисом и эндпоинтами, а также между микросервисом и tg-ботом происходит через http-клиенты.